Home › GATE CSE › computerscience › Operating Systems › What is the PRIMARY problem with using a SPIN LO…
What is the PRIMARY problem with using a SPIN LOCK on a SINGLE-CPU uniprocessor system (with preemptive scheduling)?
ASpinning blocks the lock holder from releasing
BSpin locks don't compile on single-CPU systems
CSpin locks require multiple cores by design
DSingle-CPU systems don't have race conditions
Answer & Solution
Correct answer: A. Spinning blocks the lock holder from releasing
1. On a SINGLE CPU, only one thread runs at a time.
2. If thread T1 holds the lock and gets preempted, thread T2 starts spinning waiting for the lock.
3. T2's spin uses the ENTIRE CPU. T1 (the lock holder) can NEVER run to release the lock UNTIL T2 is preempted off.
4. So spinning is PURE WASTE until T2's time slice expires — wasting up to one full time slice of CPU per failed attempt.
5. This is why uniprocessor systems prefer BLOCKING (sleep/wakeup) locks: a thread that can't acquire blocks until the lock holder releases AND signals.
6. Multi-CPU systems can tolerate spin-locking because T1 runs on a different core, so the spinner on its core just waits briefly.
7. Other options misstate the issue.
_Source: OSTEP Ch 28, §28.9 (Performance Concerns), p. 7-8._
Related questions
On a MULTI-CORE system, a SPIN LOCK is generallyDisabling INTERRUPTS as a way to implement mutual exclusion on a single-CPU system isA LIVELOCK differs from a DEADLOCK in thatSuppose thread A acquires lock L1, then thread B acquires lock L2. Now A tries to acquire Without atomic hardware support, building a correct mutual-exclusion lock for $N \geq 2$ tA CRITICAL SECTION isLinux's `pthread_mutex_lock()` is typically implemented as a HYBRID:A LOCK is considered FAIR if