deadlock recovery

Suppose detection has just confirmed a pile-up: a group of processes are frozen, each gripping resources the others need. Knowing about the jam does not clear it — you still have to physically pull a car out of the intersection so traffic can flow again. Deadlock recovery is that clean-up step: the deliberate action the OS takes, once a deadlock is detected, to break the cycle and let the survivors proceed.

There are two broad recovery methods. The first is PROCESS TERMINATION: kill one or more of the deadlocked processes to release their resources. You can abort ALL deadlocked processes (drastic but certain) or abort them ONE AT A TIME, re-running detection after each kill until the deadlock clears (less wasteful but slower). The second is RESOURCE PREEMPTION: forcibly take resources away from some processes and give them to others, which raises three sub-problems — selecting a victim (which resources, from whom, at least cost), rollback (the preempted process must be reset to a safe earlier checkpoint, since it cannot simply continue without the resource), and starvation (you must avoid repeatedly choosing the same victim forever).

Recovery is unavoidably messy and lossy, which is the honest reason many systems prefer to avoid getting here at all. Killing a process throws away its work; if it was mid-update to a file or database, that may leave data inconsistent unless transactions can roll it back cleanly. Choosing the victim is a cost optimization with no perfect answer: pick by priority, by how long it has run, by how many resources it holds, by how close it is to finishing. And rollback requires the system to have checkpointed state, which is expensive to maintain — so recovery is a real but blunt instrument, not a free undo button.