Deadlock Detection and Recovery
- Process Management
- Memory Management
- Deadlocks
- OS Introduction & Fundamentals
- CPU Scheduling Algorithms
- Threads & Concurrency
- Inter-Process Communication (IPC)
- Process Synchronization
- Virtual Memory & Paging
- File Systems
- Disk Scheduling
- I/O Management
A Third Strategy: Let Deadlocks Happen, Then Deal With Them
Rather than preventing (covered earlier) or avoiding (also covered earlier) deadlocks upfront, this approach allows the system to run without those restrictions, periodically checks whether a deadlock has actually occurred, and takes corrective action if one is found.
The Core Idea Behind Detection
Detection algorithms examine the current pattern of which processes hold which resources and which processes are waiting for which resources, looking specifically for a circular chain of waiting - precisely the circular wait condition covered in the deadlock necessary-conditions note.
A Real Practical Trade-off: How Often to Check
| Checking frequency | Trade-off |
|---|---|
| Very frequently | Deadlocks caught quickly, but checking itself consumes real CPU overhead |
| Rarely | Low overhead, but a deadlock might persist unnoticed for a long time |
Recovery Option 1: Terminating a Process
The most direct recovery method is simply terminating one or more processes involved in the deadlock cycle, forcibly breaking it. This can mean terminating all deadlocked processes at once, or terminating them one at a time until the cycle is broken - deciding which process to sacrifice usually considers factors like priority and how much work would be lost.
Recovery Option 2: Preempting Resources
Forcibly take a resource away from one process in the cycle,
and give it to another - breaking the circular wait
without necessarily killing any process entirely.Rather than terminating a whole process, resources can be forcibly taken from one process in the cycle and given to another, breaking the deadlock - though the process that lost its resource must typically be rolled back to a safe earlier point, since it can no longer safely continue from where it was.
Why This Approach Is Sometimes More Practical Than Prevention or Avoidance
In systems where deadlocks are genuinely rare in practice, the overhead of strict prevention or avoidance every single time may not be worth it - occasionally detecting and recovering from a rare deadlock can be a more efficient overall trade-off than constantly restricting the system to avoid an event that almost never actually happens.