Questions: Spinlocks and Busy-Waiting Synchronization

Question 1

Thread A holds a lock while updating a single pointer — an operation that takes about 20 nanoseconds. Thread B wants the same lock. A context switch costs approximately 1–5 microseconds. Which synchronization choice is most efficient for Thread B?

• A. A blocking mutex, because it avoids wasting CPU cycles while waiting
• B. A spinlock, because the expected wait (20ns) is far less than the context switch cost (1000–5000ns)
• C. A spinlock, because spinlocks are always more efficient than blocking locks
• D. A blocking mutex, because spinlocks can only be used in kernel code

Answer: (B)

The decision between spinning and blocking is a cost comparison: how long will we wait versus how much does a context switch cost? If the critical section is 20ns and a context switch costs 1–5 microseconds, blocking would waste far more time than spinning. The breakeven is roughly: if expected wait < cost of two context switches (sleep + wake), spin. If expected wait > that cost, block. This is the exact logic kernels use — spinlocks protect very short critical sections; mutexes protect longer ones.

Question 2

On a single-processor system, thread A holds a spinlock and thread B is spinning on it. What happens?

• A. Thread B acquires the lock quickly because thread A will finish its critical section before the scheduler intervenes
• B. Thread B burns its entire time slice while thread A cannot run to release the lock — the spin is pure waste until the OS preempts thread B
• C. The OS detects the spin pattern and automatically converts it to a blocking wait
• D. Thread A is immediately preempted by the scheduler when thread B starts spinning

Answer: (B)

On a single CPU, the thread holding the lock cannot run while the spinner occupies the processor. Thread B loops uselessly until the OS timer interrupt fires and preempts it, finally scheduling thread A to run and release the lock. Then thread B can be scheduled back and acquire the lock. This wastes thread B's entire time slice accomplishing nothing. Spinlocks are fundamentally designed for multiprocessor systems where the lock holder is running on a *different* CPU and making progress toward releasing the lock.

Question 3

Spinlocks rely on atomic hardware instructions like test-and-set or compare-and-swap to ensure that only one thread enters the critical section at a time.

• T. True
• F. False

Answer: True

A spinlock loop like `while (test_and_set(&lock) == 1) {}` works because test-and-set is an atomic read-modify-write operation: it reads the current value and writes 1 in a single uninterruptible step. Without atomicity, two threads could both read 0, both decide the lock is free, and both enter the critical section — a race condition. The atomic instruction ensures mutual exclusion without OS intervention, which is what makes spinlocks viable in interrupt handlers and kernel code where calling into the scheduler is impossible.

Question 4

Spinlocks are typically more efficient than blocking locks because they avoid the overhead of context switches.

• T. True
• F. False

Answer: False

Spinlocks are only more efficient when the critical section is short enough that the wait time is less than the cost of a context switch, AND only on multiprocessor systems where the lock holder can make progress on another CPU. On a single-processor system, spinning wastes the entire time slice. Under high contention or for long critical sections, spinning burns CPU cycles that could do useful work elsewhere. A blocking lock that yields the CPU is more efficient whenever the expected wait exceeds the context switch cost.

Question 5

Why are spinlocks used inside OS kernels for protecting short critical sections, and what would go wrong if kernel code tried to use a blocking mutex instead?

Model answer: Kernel code often cannot sleep: interrupt handlers run with interrupts disabled, and scheduler code cannot block because the scheduler itself is not yet runnable. A blocking mutex requires calling into the scheduler to sleep — which is circular or impossible in these contexts. Spinlocks work because they never call the scheduler; they just loop in the hardware.

Spinlocks are the synchronization primitive of last resort for code that cannot call into the scheduler. Interrupt handlers are the clearest example: an interrupt fires, preempting whatever was running, and the handler may need to access a shared data structure. If that structure is locked, the handler must spin — it cannot block because there is no return path through the scheduler. Similarly, the scheduler's own data structures (run queues, etc.) must be protected with spinlocks because protecting them with blocking locks would require the scheduler to be running — a chicken-and-egg problem. The cost is CPU waste if the spin is long, which is why kernel spinlocks are reserved exclusively for genuinely short critical sections.