Because they avoid overhead from operating system process rescheduling or context switching, spinlocks are efficient if threads are likely to be blocked for only short periods.
Implementing spinlocks correctly is challenging because programmers must take into account the possibility of simultaneous access to the lock, which could cause race conditions.
However, a number of performance optimizations are possible: On later implementations of the x86 architecture, spin_unlock can safely use an unlocked MOV instead of the slower locked XCHG.
On Hyper-Threading CPUs, pausing with rep nop gives additional performance by hinting to the core that it can work on the other thread while the lock spins waiting.
Although locks are still required as a fallback, they have the potential to greatly improve performance by having the processor handle entire blocks of atomic operations.
[4] With large numbers of processors, adding a random exponential backoff delay before re-checking the lock performs even better than TTAS.
There are two ways to avoid this: Most operating systems (including Solaris, Mac OS X and FreeBSD) use a hybrid approach called "adaptive mutex".
)[8] OpenBSD attempted to replace spinlocks with ticket locks which enforced first-in-first-out behaviour, however this resulted in more CPU usage in the kernel and larger applications, such as Firefox, becoming much slower.