Home › GATE CSE › computerscience › Operating Systems › Linux's `pthread_mutex_lock()` is typically impl…
Linux's `pthread_mutex_lock()` is typically implemented as a HYBRID:
Apure spin only
Bpure blocking only
Cspin briefly, then sleep if still contended
Drandomly choose between spin and block per call
Answer & Solution
Correct answer: C. spin briefly, then sleep if still contended
1. OSTEP §28.13 describes the modern Linux approach (the FUTEX system call).
2. The idea: short critical sections benefit from spinning (cheap); long ones benefit from blocking (saves CPU).
3. HYBRID: try to acquire with TAS/CAS. If unsuccessful, spin briefly (often $\sim 50$-$100$ iterations). If still unsuccessful, call into the kernel (FUTEX_WAIT) to block the thread until the lock holder calls FUTEX_WAKE.
4. This gives the best of both worlds: low overhead for short contention, no CPU waste for long contention.
5. Options A, B, D describe simpler (and worse) strategies.
_Source: OSTEP Ch 28, §28.13 (Using Queues: Sleeping vs Spinning), p. 8-10 + §28.14 FUTEX, p. 10._
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 isWhat is the PRIMARY problem with using a SPIN LOCK on a SINGLE-CPU uniprocessor system (wiA LOCK is considered FAIR if