What is a Livelock?
Learn what a livelock is — how it differs from deadlock, why symmetric retries cause it, and how randomized backoff fixes it.
Expected Interview Answer
A livelock is a condition where two or more threads keep changing their state in response to each other purely to avoid a conflict, so both stay actively busy and never remain blocked, yet no thread ever makes real progress toward completing its work.
Livelock is closely related to deadlock in that both leave threads permanently unable to finish, but the mechanics differ: a deadlocked thread is blocked and idle forever, while a livelocked thread keeps executing instructions, repeatedly reacting to the other thread’s state, so it looks alive and busy on a monitoring dashboard even though it is stuck. A classic example is two threads each holding a lock they need to release and re-acquire to avoid a deadlock: politely, each backs off when it detects contention, then both retry simultaneously, back off again, and repeat forever in lockstep. Livelock commonly arises from naive deadlock-avoidance retry logic that lacks randomness or backoff variation, causing threads to stay perfectly synchronized in their retries. The fix is typically to introduce randomized exponential backoff, break symmetry by giving threads distinct priorities or IDs to decide who yields, or bound the number of retries before escalating to a different resolution strategy.
- Distinguishes livelock (busy, no progress) from deadlock (blocked, no progress)
- Explains why naive retry/backoff logic can create livelock
- Motivates randomized backoff and priority-based tie-breaking
- Relevant to distributed systems retry storms, not just OS threads
AI Mentor Explanation
A livelock is like two fielders both sprinting toward the same catch, each politely peeling off at the last second when they see the other closing in, only for both to dash back in together a moment later and repeat the dodge endlessly — the ball drops because neither commits, even though both are constantly moving. Unlike a deadlock where both would simply stand frozen, here both fielders are visibly active the whole time yet the catch is never actually taken. The fix is a clear shout rule: whoever calls first commits and the other backs off for good.
Step-by-Step Explanation
Step 1
Contention detected
Two threads detect they are both about to conflict over a shared resource.
Step 2
Both back off symmetrically
Each thread releases its claim to politely avoid a deadlock, using identical retry logic.
Step 3
Synchronized retry
Both threads retry at the same moment, detect contention again, and back off again — in lockstep, forever.
Step 4
Fix applied
Randomized exponential backoff or a priority/ID-based tie-breaker breaks the symmetry so one thread proceeds.
What Interviewer Expects
- A clear contrast between livelock (active, no progress) and deadlock (blocked, no progress)
- Identifying that symmetric, deterministic retry logic causes livelock
- Naming randomized backoff or tie-breaking as the fix
- Recognizing livelock applies beyond OS threads, e.g. distributed retry storms
Common Mistakes
- Treating livelock and deadlock as the same thing
- Assuming livelocked threads must be idle or blocked (they are actively running)
- Not proposing randomization or priority as a fix, only “try again”
- Missing that naive, symmetric retry logic is the typical root cause
Best Answer (HR Friendly)
“A livelock is when two processes keep actively reacting to each other to avoid a collision, but end up perfectly cancelling each other out forever, so both stay busy without ever finishing their work. It looks different from a deadlock because nothing appears stuck — both sides are constantly doing something — the fix is usually adding some randomness or a clear tie-breaking rule so the symmetry breaks and one side can proceed.”
Code Example
/* Livelock-prone: symmetric, deterministic backoff */
void acquire_naive(lock_t *a, lock_t *b) {
while (!try_lock(a)) { /* spin */ }
if (!try_lock(b)) {
unlock(a); /* both threads back off identically */
acquire_naive(a, b); /* and retry in lockstep forever */
return;
}
}
/* Fixed: randomized backoff breaks the symmetry */
void acquire_fixed(lock_t *a, lock_t *b) {
while (!try_lock(a)) { /* spin */ }
if (!try_lock(b)) {
unlock(a);
usleep(rand() % 1000); /* random jitter avoids synchronized retries */
acquire_fixed(a, b);
return;
}
}Follow-up Questions
- How does a livelock differ from a deadlock in terms of thread state?
- Why does randomized backoff help resolve livelock?
- Can you give an example of livelock in a distributed system rather than an OS?
- How would you detect a livelock in a running system versus a deadlock?
MCQ Practice
1. What is the key difference between a livelock and a deadlock?
Livelocked threads are not blocked — they keep executing and reacting to each other — but still fail to make forward progress, unlike blocked, idle deadlocked threads.
2. What commonly causes a livelock?
When two threads use identical, non-randomized retry logic, they can keep backing off and retrying in perfect synchronization forever.
3. What is a standard fix for livelock?
Randomizing retry timing or assigning a deterministic tie-breaker breaks the symmetric pattern that causes livelock.
Flash Cards
What is a livelock? — Threads actively change state to avoid conflict but never make real progress, unlike a blocked deadlock.
What typically causes livelock? — Symmetric, deterministic retry/backoff logic causing threads to retry in lockstep.
How is livelock fixed? — Randomized backoff or a priority/ID-based tie-breaker that breaks the symmetry.
Livelock vs deadlock thread state? — Livelocked threads are actively running; deadlocked threads are blocked and idle.