Spinlock

A spinlock is a mutual-exclusion lock in which a waiting task repeatedly checks the lock state instead of sleeping. It can be faster than a blocking mutex when the critical section is extremely short, but it wastes CPU time while waiting.

Spinlocks appear in kernels, low-level runtimes, device drivers, embedded firmware and multicore synchronization paths. They are not a general replacement for mutexes. A spinlock is appropriate only when hold time is bounded, the owner will not sleep, and the cost of blocking and waking would be larger than the expected spin.

Busy-Wait Model

Let the lock hold time seen by a waiter be:

and let lock acquisition polling cost per attempt be:

If polling happens at rate:

then the approximate CPU time spent spinning is:

and the number of polls is:

The waiting CPU is doing no useful work during that time. This is the core tradeoff.

Contention Cost

If there are:

waiters spinning for average time:

then aggregate busy-wait CPU demand is:

per acquisition event. A single short spin may be acceptable. Many waiters spinning on the same cache line can create memory traffic, reduce useful throughput and delay unrelated work.

Hold-Time Bound

A spinlock should have a documented maximum hold time:

For a task or interrupt path with response budget:

and other response terms:

the margin is:

The design passes this screen only when:

If the lock owner can be preempted, page fault, allocate memory, wait for I/O or sleep while holding the spinlock, the bound can fail catastrophically.

Atomic Operation

Spinlocks are commonly built from atomic operations such as test-and-set, exchange or compare-and-swap. A simplified acquire loop is:

where L=0 means unlocked and L=1 means locked. The lock release must publish protected data before making the lock available:

That ordering may require release semantics or a memory barrier on weakly ordered architectures.

Backoff and Fairness

Simple test-and-set loops can create heavy cache-coherence traffic. Backoff inserts delay between attempts. If backoff interval is:

for attempt:

then increasing B_k can reduce bus traffic but also increase latency. Ticket locks and queue-based locks improve fairness by controlling acquisition order, but they can cost more per acquisition.

Fairness is a requirement, not a default property. A spinlock without fairness can starve a task under repeated reacquisition by other cores.

Worked Timing Check

A firmware kernel uses a spinlock around a per-core statistics update. The measured maximum hold time is:

Other response terms for the monitored path are:

The response budget is:

The margin is:

The screen passes. If later logging expands the critical section to:

then:

The spinlock now violates the response budget even though the code still looks like a small protected section.

Boundary With Mutexes

A mutex normally blocks or sleeps a waiter. A spinlock keeps the waiter running. The spinlock is better only when the expected wait is shorter than the sleep-and-wakeup overhead and when the system can afford burning CPU during the wait. On a single-core system, spinning while the owner cannot run is usually a design error unless interrupts or special scheduler rules guarantee release.

Failure Modes

Common failure modes include spinning while the owner is preempted, holding the lock during I/O, cache-line bouncing, unfair reacquisition, priority inversion, interrupt masking that grows beyond its bound, missing memory barriers, livelock under excessive contention and watchdog resets caused by busy-wait loops.

Validation Evidence

Useful evidence includes maximum hold-time traces, spin duration distribution, waiter count, cache-coherence or bus counters, preemption state while held, interrupt-mask state, backoff behavior, fairness tests, watchdog behavior and regression rules for every protected section. A release claim should show that the worst spin path remains inside latency and deadline budgets under load.