A LIVELOCK differs from a DEADLOCK in that
Alivelock threads keep changing state but make no progress
Blivelock is the same as starvation
Cdeadlock requires three or more threads; livelock only two
Dthey are identical phenomena
Answer & Solution
Correct answer: A. livelock threads keep changing state but make no progress
1. DEADLOCK: threads are permanently STUCK, none making progress, all waiting.
2. LIVELOCK: threads ARE doing work (changing state), but the overall system makes NO PROGRESS — like two people trying to pass each other in a narrow corridor, both stepping aside in the same direction indefinitely.
3. Example: both threads grab one lock, then release it because they can't get the second, then retry — both keep doing this forever, achieving nothing.
4. Detection: deadlock can be detected (resource allocation graph cycle). Livelock is harder — the system 'looks busy'.
5. STARVATION (option B) is a long-term unfairness — one thread always loses races but progresses occasionally. Livelock is global.
6. The N-thread count argument (option C) doesn't apply.
_Source: OSTEP Ch 32 (referenced) + concurrent programming literature. OSTEP discusses livelock briefly in advanced chapters._
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 isSuppose 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:What is the PRIMARY problem with using a SPIN LOCK on a SINGLE-CPU uniprocessor system (wiA LOCK is considered FAIR if