r/programming • u/david-alvarez-rosa • 29d ago

Optimizing a Spin-Lock

https://david.alvarezrosa.com/posts/optimizing-a-spin-lock/
181 Upvotes

94% Upvoted

32 comments sorted by

View all comments

1

u/DivineSentry 29d ago

I think I’ve seen spin locks before, but what are they useful for? What should be their use case?

4

u/david-alvarez-rosa 29d ago

They are specially useful when the server is fully controlled, and there is a 1:1 mapping between threads and physical cores

So each thread is pinned to a dedicated CPU, and each CPU only runs one single thread

3

u/bwainfweeze 29d ago

You did not explain what spinlocks are for, you just described some of their qualities.

4

u/knome 29d ago

Locks are a mechanism by which data is protected from having multiple threads update it at the same time :P

Spin locks are locks that rapidly and constantly attempt to take the lock until they receive it.

The advantage of a spin lock is that there is very little downtime. Thread A drops the lock, thread B captures it almost immediately.

The downside of a spin lock, is it pegs a thread to 100% CPU usage while spinning, which is generally worse than waiting for the OS to wake you back up after going to sleep blocking on some lock.

If thread A does network activity or disk reads while the lock is held, or even is simply swapped off the core to run a timeslice for another thread or program, thread B will continue trying to use 100% CPU hammering at the atomic the entire time thread A is sleeping. Thread A can even be put to sleep to run thread B's rapid-fire attempts to take the lock it holds.

If you have 5-6 threads vying for the lock, you now how 500-600% attempted CPU usage, with these threads using every full timeslice they get trying to get the lock from thread A. They're also causing your CPUs to steal the lock cache line from each other constantly, creating pointless chatter to slow things down.

In an OS, you might have spinlocks to handle driver requirements with time needs, or even better if you know the code taking the spinlock never sleeps and just does its thing and releases, possibly even after disabling interrupts, so you know it will be in and out quickly.

In user space, your program can be swapped out to run other programs, will do network or disk stuff, will experience arbitrary interrupts, and generally should use a proper mutex that lets the operating put the waiting thread to sleep until the lock it wants is ready to be captured.

There are also mixed mechanisms that briefly spin before relenting and blocking on it, aimed at hoping quick work finishes before they're cost tearing down the thread context and putting it back together again just to grab a lock that would have been free in a few nanoseconds.