Two ways to wait
When a lock is held, a waiting thread can either spin, looping and checking until the lock frees, or block, going to sleep so the scheduler runs something else and wakes it later. Both are correct; they trade different costs.
The cost of each
- A spinlock keeps the thread on the CPU. If the wait is shorter than a context switch, spinning wins because there is no scheduling overhead. But it wastes every cycle it spins and is disastrous if the holder is descheduled.
- A blocking lock pays the cost of two context switches, to sleep and to wake, plus scheduler bookkeeping. That is expensive for short waits but frees the CPU for useful work during long waits.
The deciding factor
The rule of thumb compares expected wait time to context switch cost. Short critical sections favor spinning; long or unpredictable waits favor blocking. Holding a spinlock while doing I O or while preemptible is a classic mistake.
Hybrid approach
Many real locks spin briefly then block, an adaptive mutex that captures the best of both: cheap acquisition when the holder releases quickly, and a graceful fallback to sleeping when it does not.
Key idea
Spin when the expected wait is shorter than a context switch, block when it is longer, and adaptive locks do both.