Livelock is a failure where tasks are not blocked, they're actively running and changing state, but they make no useful forward progress because they keep reacting to each other in a way that repeats indefinitely. The classic analogy is two people meeting in a hallway who both step the same way to avoid each other, repeatedly, never passing. In RTOS code it commonly arises from naive timeout-and-retry deadlock recovery: two tasks each acquire one lock, fail to get the second within the timeout, both release their lock and immediately retry in lockstep, collide the same way again, and loop forever, no one is blocked (so it's not a deadlock), but no one progresses either, and the CPU may be pegged. The difference from deadlock is the state of the tasks: in deadlock the tasks are blocked in a wait cycle and consume no CPU; in livelock they're runnable and executing but accomplishing nothing. Both result in no progress, which is what matters for the system. The fix for the retry-induced case is to break the symmetry, randomize or stagger the backoff delay before retrying so the two tasks don't keep colliding, or use a consistent lock ordering so the retry situation doesn't arise in the first place (making timeouts unnecessary for that case). So livelock is "busy but stuck" versus deadlock's "blocked and stuck," and randomized backoff is the typical remedy.
RTOS & Real-Time Concepts · Interview question
What is livelock, and how is it different from deadlock?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Deadlocks & How to Avoid Them
Two tasks each holding a lock the other needs, frozen forever: the four conditions for deadlock, and the fixes (consistent lock ordering, avoiding hold-and-wait, and timeouts).