The point of using spinlocks is never to hold them very long, e.g. for modifying a small bit of memory like Alex said. Then release them again. You shouldn’t even make system calls or anything while holding them. They are extremely hot potatoes that you do not want to hold.

Cyril: After thread A gets the spinlock, it should also be at 100% cpu until it releases it again. It should also hold it for very little time; much less than a timeslice. If by luck its timeslice ends and B is scheduled, B may spin for a timeslice, it’s true. But B should be no busier than A. Thread A should be hustling while it has that lock.

peterix: Same as above. You’re right, they don’t play nice with schedulers. The idea is not to let it get to the scheduler most of the time. Grab and release the lock quickly so that the holding thread rarely gets descheduled while holding it. Don’t make syscalls which could deschedule the thread while holding it.

If the contending threads are constantly rapidly taking and releasing the spinlock, such that they’re likely to be interrupted while holding the lock, you’re spending too much time on synchronization anyway. It would be better to batch the communications somehow, then use mutexes that can safely be held for longer times. And maybe use spinlocks for a short, uncommon metadata transfers outside the batch.

Say you have a dual-core CPU and two processes use a spinlock to regulate access to a shared memory segment (sharing an int for example). Then comes a third CPU-hungry process and suddenly your performance goes to hell with latency going from microseconds to seconds.

So, beware. Spinlocks are of limited usefulness even on SMP machines. The kernel can afford that, because it has no ‘completely fair’ scheduler to deal with :/

With mutex:
Consumer TID 14146
Consumer TID 14147
Result – 4.739984

With Spinlock:
Consumer TID 14464
Consumer TID 14465
Result – 5.785072

With -O2 optimisation flags the difference is reduced but mutex are still faster.

If you only have a single CPU (or HT), then whatever you do, only one thread at a time can actually modify a memory value.
So while you’re spinlocking, you’re simply consuming CPU power for nothing, as, actually get the spinlock, you’ll have to wait for a kernel based context switch, and hoping you’re not elected back.

This means that, depending on kernel scheduler :
Thread A
take spin lock
write value to protected int

Thread B
want to take spin lock
(use 100% cpu for the whole thread time slice)
Here, the kernel can decide to reelect thread B, as it’s the thread doing the more work
Thread B
want to take spin lock
(use 100% cpu for the whole thread time slice)
and so on…

This shame is very very dangerous, that’s why in linux kernel, spinlock is a macro (not a function) that get disabled on SUP machine.