Deadlocks
4.1 Definition and Necessary Conditions
A deadlock is a situation where a set of processes are all blocked, each waiting for a resource Held by another process in the set.
Coffman conditions (all four must hold simultaneously):
- Mutual exclusion: At least one resource is non-sharable.
- Hold and wait: A process holds at least one resource and is waiting for others.
- No preemption: Resources cannot be forcibly taken.
- Circular wait: A circular chain of processes exists, each waiting for a resource held by the next.
4.2 Deadlock Prevention
Eliminate one of the four Coffman conditions:
| Condition | Prevention strategy |
|---|---|
| Mutual exclusion | Generally not feasible for non-sharable resources |
| Hold and wait | Require all resources upfront before execution |
| No preemption | Release held resources if a new request cannot be granted |
| Circular wait | Impose a total ordering on resources; request in increasing order |
4.3 Deadlock Avoidance: Banker”s Algorithm
The Banker’s algorithm avoids deadlock by checking whether granting a request leads to a safe State.
Definitions:
- Available: Vector of available instances of each resource type.
- Maximum: Matrix where is the maximum demand of process for resource .
- Allocation: Matrix where is the current allocation.
- Need: .
Safety algorithm:
1. Work = Available; Finish[i] = false for all i2. Find i such that Finish[i] == false AND Need[i] <= Work3. If no such i exists, go to step 54. Work = Work + Alloc[i]; Finish[i] = true; go to step 25. If Finish[i] == true for all i, system is SAFEResource request algorithm. When process requests resources:
1. If Request[i] > Need[i], error (exceeded maximum claim)2. If Request[i] > Available, process must wait3. Pretend to allocate: Available = Available - Request[i] Alloc[i] = Alloc[i] + Request[i] Need[i] = Need[i] - Request[i]4. Run safety algorithm. If safe, grant the request. If unsafe, roll back and make the process wait.Example. Five processes, three resource types, :
| Process | Allocation | Max | Need |
|---|---|---|---|
| (0,1,0) | (7,5,3) | (7,4,3) | |
| (2,0,0) | (3,2,2) | (1,2,2) | |
| (3,0,2) | (9,0,2) | (6,0,0) | |
| (2,1,1) | (2,2,2) | (0,1,1) | |
| (0,0,2) | (4,3,3) | (4,3,1) |
Safety check: has . Execute Release New . Then : . Continuing, All processes can complete: system is safe.
Worked Example 4.1 — Banker's Algorithm Step-by-Step
Given the state above, suppose requests .
Step 1: Verify . OK.
Step 2: Verify . OK.
Step 3: Pretend to allocate:
| Process | Allocation | Max | Need |
|---|---|---|---|
| (0,1,0) | (7,5,3) | (7,4,3) | |
| (3,0,2) | (3,2,2) | (0,2,0) | |
| (3,0,2) | (9,0,2) | (6,0,0) | |
| (2,1,1) | (2,2,2) | (0,1,1) | |
| (0,0,2) | (4,3,3) | (4,3,1) |
.
Step 4: Run safety algorithm.
- : . Execute, .
- : . Execute, .
- : . Execute, .
- : . Execute, .
- : . Execute, .
All processes finish. The request is granted. Safe sequence: .
Worked Example 4.2 — Unsafe State Detection
Suppose instead requests in the original state.
Step 1: . OK.
Step 2: . OK.
Step 3: Pretend to allocate. New , .
Step 4: Safety check. No process can execute: needs but only available (second component insufficient). needs — OK, execute : . Then : — OK, execute: . But now needs — exact match, execute: . : — OK, execute: . : — OK.
Safe sequence: . The request is granted.
Theorem 4.1. The Banker’s algorithm is correct: if it declares a state safe, there exists a Sequence of process completions that avoids deadlock.
Proof. The safety algorithm constructs an explicit sequence. Each process in the sequence can run To completion with the currently available resources plus those released by previously completed Processes. If no such sequence exists, there is a set of processes whose combined needs exceed Available resources.
4.4 Deadlock Detection
Allow deadlocks to occur, then detect and recover.
Detection algorithm:
1. Work = Available Finish[i] = false if Alloc[i] != 0; true otherwise2. Find i such that Finish[i] == false AND Request[i] <= Work3. If found: Work = Work + Alloc[i]; Finish[i] = true; go to step 24. If not found: processes with Finish[i] == false are deadlockedRecovery strategies:
- Process termination: Kill deadlocked processes one at a time until the cycle is broken.
- Resource preemption: Forcibly reclaim resources; must handle rollback of the affected process.
- Checkpoint and rollback: Periodically save process state; restore on deadlock.
Worked Example 4.3 — Deadlock Detection
Three processes and one resource type with 10 instances:
| Process | Allocation | Maximum |
|---|---|---|
| 5 | 9 | |
| 2 | 4 | |
| 2 | 7 |
Available = .
, , .
Detection:
- Work = 1. No process has .
- No process can proceed. All three are deadlocked.
The system is in an unsafe state with a deadlock involving .
Recovery: Preempt 3 units from (reducing its allocation to 2). Now Available = 4. can proceed (). After finishes, Available = . : Proceeds. After: Available = . proceeds. Deadlock resolved.
4.5 Deadlock Handling in Practice
Most modern OSes (Linux, Windows) use the ostrich algorithm: ignore deadlocks and rely on process Termination or reboot. Rationale: deadlocks are rare, detection is expensive, and prevention is Overly restrictive.