Spinlock

In <a href="/facts/Software_engineering/KX6cE9kz">software engineering</a>, a spinlock is a <a href="/facts/Lock_(computer_science)/e3a9gnJT">lock</a> that causes a <a href="/facts/Thread_(computer_science)/hh8WHyPd">thread</a> trying to acquire it to simply wait in a <a href="/facts/While_loop/hLrKdAFo">loop</a> ("spin") while repeatedly checking whether the lock is available. Since the thread remains active but is not performing a useful task, the use of such a lock is a kind of <a href="/facts/Busy_waiting/WUdbMj6z">busy waiting</a>. Once acquired, spinlocks will usually be held until they are explicitly released, although in some implementations they may be automatically released if the thread being waited on (the one that holds the lock) blocks or "goes to sleep".
Because they avoid overhead from <a href="/facts/Operating_system/8XTuvMh2">operating system</a> <a href="/facts/Scheduling_(computing)/XptmcM1a">process rescheduling</a> or <a href="/facts/Context_switch/N0oJQ6CC">context switching</a>, spinlocks are efficient if threads are likely to be blocked for only short periods. For this reason, <a href="/facts/Operating_system_kernel/uEj4U3Rz">operating-system kernels</a> often use spinlocks. However, spinlocks become wasteful if held for longer durations, as they may prevent other threads from running and require rescheduling. The longer a thread holds a lock, the greater the risk that the thread will be interrupted by the OS scheduler while holding the lock. If this happens, other threads will be left "spinning" (repeatedly trying to acquire the lock), while the thread holding the lock is not making progress towards releasing it. The result is an indefinite postponement until the thread holding the lock can finish and release it. This is especially true on a single-processor system, where each waiting thread of the same priority is likely to waste its quantum (allocated time where a thread can run) spinning until the thread that holds the lock is finally finished.
Implementing spinlocks correctly is challenging because programmers must take into account the possibility of simultaneous access to the lock, which could cause <a href="/facts/Race_condition/bvNpgy4F">race conditions</a>. Generally, such an implementation is possible only with special <a href="/facts/Assembly_language/7XuV0cla">assembly language</a> instructions, such as <a href="/facts/Atomic_operation/u3pnNCvs">atomic</a> (i.e. un-interruptible) <a href="/facts/Test-and-set/KyR6bYFo">test-and-set</a> operations and cannot be easily implemented in programming languages not supporting truly atomic operations. On architectures without such operations, or if high-level language implementation is required, a non-atomic locking algorithm may be used, e.g. <a href="/facts/Peterson%2527s_algorithm/DU3jLWsk">Peterson's algorithm</a>. However, such an implementation may require more <a href="/facts/Computer_memory/hQKVQ51J">memory</a> than a spinlock, be slower to allow progress after unlocking, and may not be implementable in a high-level language if <a href="/facts/Out-of-order_execution/bM0dQM8m">out-of-order execution</a> is allowed.

Spinlock open-in-new

Spinlock