Deadlock Problem Deadlock: A set of processes, each holding a resource, and each waiting to acquire a resource held by another process in the set. Example: – Suppose a system has two disk drives. – Processes P 1 and P 2 each hold one disk drive and are waiting for the other drive. Multithreaded processes are good candidates for deadlock because multiple threads can be competing for shared resources.

Deadlock Characterization Deadlock requires that four conditions hold simultaneously: 1.Mutual exclusion: only one process can use a resource at a time 2.Hold and wait: a process holding a resource is waiting to acquire a resource held by other processes 3.No preemption: a resource can only be released voluntarily by the process holding it, after it has completed its task 4.Circular wait: there exists a set {P 0, P 1,..., P n } of waiting processes such that P 0 is waiting for a resource held by P 1, P 1 is waiting for a resource held by P 2,..., P n-1 is waiting for a resource held by P n, and P n is waiting for a resource held by P 0.

Resource-Allocation Graph Round nodes indicate processes. Rectangular nodes indicate resources, which might have multiple instances. An arrow from a process to a resource indicates that the process has requested the resource. An arrow from a resource to a process indicates that the resource has been allocated to the process. If the graph contains no cycles, then there is no deadlock. If each resource has only one instance, then a cycle indicates deadlock. P1P1 P2P2 P3P3 R1R1 R2R2 R3R3 R4R4 no deadlock deadlock

Resource-Allocation Graph Note: A cycle indicates the possibility of deadlock. It does not guarantee that a deadlock exists. Example: The following resource-allocation graph contains a cycle, but not a deadlock: P2P2 P3P3 R1R1 R2R2 P4P4 P1P1

The following program might or might not cause deadlock when it is run. Java Deadlock Example class A implements Runnable { private Lock one, two; public A(Lock one, Lock two) { this.one = one; this.two = two; } public void run() { try { one.lock(); // do something two.lock(); // do something else } finally { one.unlock(); two.unlock(); } class A implements Runnable { private Lock one, two; public A(Lock one, Lock two) { this.one = one; this.two = two; } public void run() { try { one.lock(); // do something two.lock(); // do something else } finally { one.unlock(); two.unlock(); } class B implements Runnable { private Lock one, two; public A(Lock one, Lock two) { this.one = one; this.two = two; } public void run() { try { two.lock(); // do something one.lock(); // do something else } finally { two.unlock(); one.unlock(); } class B implements Runnable { private Lock one, two; public A(Lock one, Lock two) { this.one = one; this.two = two; } public void run() { try { two.lock(); // do something one.lock(); // do something else } finally { two.unlock(); one.unlock(); } public class DeadlockExample { public static void main (String arg[]) { Lock lockX = new ReentrantLock(); Lock lockY = new ReentrantLock(); Thread threadA = new Thread(new A(lockX, lockY)); Thread threadB = new Thread(new B(lockX, lockY)); threadA.start(); threadB.start(); } public class DeadlockExample { public static void main (String arg[]) { Lock lockX = new ReentrantLock(); Lock lockY = new ReentrantLock(); Thread threadA = new Thread(new A(lockX, lockY)); Thread threadB = new Thread(new B(lockX, lockY)); threadA.start(); threadB.start(); }

Handling Deadlocks Three strategies for handling deadlocks: 1.Ensure that the system will never enter a deadlocked state. 2.Allow the system to enter a deadlocked state, detect it, and recover. 3.Ignore the problem and pretend that deadlocks never occur. Strategy 3 is employed by most operating systems, including UNIX, Windows, and the JVM.

Deadlock Prevention Deadlock prevention: ensure that at least one of the four necessary conditions for deadlock cannot hold 1.Mutual exclusion: Can we eliminate mutual exclusion? Sharable resources (e.g. read-only files) cannot be involved in deadlock. Since some resources are intrinsically nonsharable, we generally cannot remove the mutual exclusion condition. 2.Hold and wait: How could we guarantee that a process never holds a resource while it waits for another? We could require that a process holding any resource may not request another resource (e.g. a process must request all resources when it is created). We could require that a process releases all resources before making a request for another resource. These protocols are not efficient.

Deadlock Prevention 3.No preemption: We could preempt resources from processes. If a process requests resources that are not available, we could preempt any resources that it currently holds. If a process requests resources held by another waiting process, we could preempt them from the other process. Preemption is difficult if the state of a resource cannot easily be saved and restored. 4.Circular wait: Can we eliminate circular waits? We could require that processes request resources in a particular order (e.g. tape drives, then disk drives, and finally printers). An ordering could be implemented in Java by using System.identityHashCode(). Often, requiring resource requests in a particular order is not convenient.

Deadlock Avoidance OS requires additional information from each process about the resources it will need, and the OS makes processes wait if they make a request that would produce deadlock. Simple strategy: – Require each profess to declare in advance the maximum number of resources of each type that it will need. – The system then allocates resources in such a way that a circular wait condition never exists. Safe state: The system is safe if it can allocate resources to each process and avoid deadlock. Safe sequence: A sequence of processes (P 1, P 2,..., P n ) is safe if the resources required by P i can be satisfied by the currently available resources plus those held by all P j, with j < i.

Deadlock Avoidance Safe state: The system is safe if it can allocate resources to each process and avoid deadlock. Unsafe state: The system might not be able to allocate resources to each processes and avoid deadlock. An unsafe state is not necessarily deadlocked!

Deadlock Avoidance Example Suppose a system has 10 tape drives and 3 processes: Maximum NeedsAllocation at t 0 P0P0 83 P1P1 64 P2P2 32 At t 0, the system is safe. Processes can run in the order P 2, P 1, P 0. However, suppose that we let process P 1 run and it requests and is allocated another tape drive at time t 1. The system state is then: Maximum NeedsAllocation at t 1 P0P0 83 P1P1 65 P2P2 32 This state is unsafe, because any process that runs next might request another tape drive, which we would be unable to allocate.

Deadlock Avoidance Strategy When a process requests resources, grant the resources only if the system will still be in a safe state. Resource utilization may be lower than it would otherwise be. If there is only one instance of each resource, we can implement this strategy using a variant of the resource- allocation graph. If there are multiple instances of each resource, we can use the “Banker’s Algorithm.”

Resource-Allocation-Graph Algorithm This avoids deadlock if there is only one instance of each resource type. Initially, each process must specify which resources it might request in the future. In the resource allocation graph, a dotted arrow from P i to R j is a claim edge, indicating that P i might request R j in the future. If the request occurs, the claim edge is converted to a request edge. A request can be granted if and only if converting the request edge to an assignment edge does not result in a cycle in the graph. Cycle-detection algorithms are O(n 2 ), where n is the number of vertices. R1R1 P1P1 R2R2 P2P2 R1R1 P1P1 R2R2 P2P2 Safe: no cycleUnsafe: a cycle

Banker’s Algorithm This avoids deadlock if there are many instances of each resource type. We must maintain the following data structures: (n is number of processes and m is number of resource types) – Available: vector of length m, indicating the number of available resources of each type Available[j] is the number of instances of resource R j. – Max: n x m matrix, indicating the maximum demand of each process Max[i][j] is the maximum number of instances of resource R j that process P i may request. – Allocation: n x m matrix, indicating the resources of each type currently allocated to each process Allocation[i][j] is the number of instances of resource R j currently allocated to process P i. – Need: n x m matrix, indicating the remaining resource need of each process Need[i][j] = Max[i][j] – Allocation[i][j]

Banker’s Algorithm 1.Let Work be a vector of length m, and set Work = Available. Let Finish be a vector of length n, initialized so that each entry is false. 2.Find an index i such that both a.Finish[i] == false b.Need[i] ≤ Work If no such i exists, go to step 4. 3.Work = Work + Allocation[i] Finish[i] = true Go to step 2. 4.If Finish[i] == true for all i, then the system is safe. Otherwise, the system is unsafe. Safety Algorithm: determines whether or not the system is in a safe state; the algorithm is O(mn 2 ) Example 3 resources: A (has 6 instances), B (has 3 instances), and C (has 4 instances) 4 processes, P 0, P 1, P 2, P 3, with maximums and allocations: MaxAllocation ABCABC P0P P1P P2P P3P Is the system in a safe state?

Banker’s Algorithm Let Request[i] be the request vector for P i. 1.If Request[i] ≤ Need[i], go to step 2. Otherwise, the request exceeds the process’ maximum. 2.If Request[i] ≤ Available[i], go to step 3. Otherwise, P i must wait. 3.Pretend to grant the request, as follows: Available = Available – Request[i] Allocation[i] = Allocation[i] + Request[i] Need[i] = Need[i] – Request[i] Check to see if the system would still be safe, then grant the request. Otherwise, roll back the changes and make P i wait. Resource-Request Algorithm: determines whether resources can be safely granted Example 3 resources: A (has 6 instances), B (has 3 instances), and C (has 4 instances) 4 processes, as before : MaxAllocation ABCABC P0P P1P P2P P3P What happens if the following requests are made (starting from the above state each time)? a.P 0 requests [1, 0, 0] b.P 2 requests [4, 0, 1] c.P 2 requests [2, 0, 1]

Deadlock Detection If a system does not prevent deadlocks, it may provide: – An algorithm that examines the state of the system to determine whether a deadlock has occurred – An algorithm to recover from deadlock If all resources have only a single instance, detecting deadlock involves looking for a cycle in the resource-allocation graph. In fact, we can collapse the resource-allocation graph to a wait-for graph, which indicates which processes are waiting for which other processes to release resources. resource- allocation graph corresponding wait-for graph P1P1 P4P4 P2P2 P3P3 P5P5 R1R1 P1P1 R2R2 P4P4 R5R5 P3P3 R4R4 P5P5 P2P2 R3R3

Deadlock Detection Algorithm If some resources have multiple instances, we must use the following data structures, similar to those in the Banker’s Algorithm: – Available: vector of length m, indicating the number of available resources of each type Available[j] is the number of instances of resource R j. – Allocation: n x m matrix, indicating the resources of each type currently allocated to each process Allocation[i][j] is the number of instances of resource R j currently allocated to process P i. – Request: n x m matrix, indicating the current request of each process Request[i][j] is the number of instances of resource R j requested by P i. The deadlock detection algorithm is O(mn 2 ).

Deadlock Detection Algorithm 1.Let Work be a vector of length m, and set Work = Available. Let Finish be a vector of length n. If Allocation[i] = 0, set Finish[i] = true; otherwise, set Finish[i] = false. 2.Find an index i such that both a.Finish[i] == false b.Request[i] ≤ Work If no such i exists, go to step 4. 3.Work = Work + Allocation[i] Finish[i] = true Go to step 2. 4.If Finish[i] == false for some i, then the system is in a deadlocked state. Example 3 resources: A (has 7 instances), B (has 4 instances), and C (has 2 instances) 4 processes, as before : AllocationRequest ABCABC P0P P1P P2P P3P Is the system deadlocked? What if P 1 instead requests [4, 2, 1]?

Deadlock Algorithm Usage How often should we run the deadlock detection algorithm? Factors to consider: – How often is deadlock likely to occur? – How many processes will be affected by deadlock if it happens? Running the deadlock detection algorithm whenever a process requests a resource would be computationally expensive. We could run the algorithm at periodic intervals (e.g. every hour). We could run the algorithm when CPU utilization drops below some threshold (e.g. 40%).

Deadlock Recovery One way to recover from deadlock is to terminate processes. Two strategies: 1.Abort all deadlocked processes: will surely work, but very expensive 2.Abort processes individually until deadlock is eliminated: still expensive, since we have to run the deadlock detection algorithm after each process terminated Aborting processes is tricky, because the system could be left in an inconsistent state (e.g. if the process was in the midst of updating a file). How do we choose which processes to terminate? Consider: – What is the priority of the process? – Are the resources held by the process are easy to preempt? – What is the least number or processes whose termination would resolve the deadlock? – How much computation would be repeated if the processes is restarted?

Deadlock Recovery Another way to recover from deadlock is to preempt resources. Three issues: 1.Selecting a victim: Which resources should be preempted from which processes? How expensive will this be? 2.Rollback: If we preempt a resource from a process, what happens to that process? Can we roll the process back to a previous state? Perhaps we will need to abort the process. 3.Starvation: How do we ensure that starvation will not occur? (i.e. we shouldn’t always preempt resources from the same process)