Deadlocks

1. Deadlocks • A situation in which process holding onto resources is waiting for other resources that are held by processes waiting for resources held by the original process • We will look at • Deadlock Prevention • Deadlock Avoidance • Deadlock Detection and Handling

2. Simple Example • System has 2 processes • P0 and P1 • and 2 non-preemptable resources • R0 and R1 • P0 asks for R0 and is granted it • P1 asks for R1 and is granted it • At a later point P0 asks for R1 • And P1 asks for R0 • Both resources are being held and so both processes must wait • Neither process will its resource until it terminates • Deadlock

3. Deadlock Characterization • Necessary Conditions for Deadlock: • Mutual Exclusion - resources are nonsharable • Hold and Wait - there must be processes holding resources and waiting (blocked) • No preemption - a resource cannot be preempted once held by a process • Circular Wait - there must exist a set of processes waiting for processes in a circular fashion (P0 waits for P1 which waits for P2 … which waits for P0) • All 4 must hold for deadlock to arise

4. Resource-Allocation Graph • A system resource-allocation graph is a pictorial way of describing OS resources and processes • A process which is holding a resource has a directed edge from the resource to the process • A process requesting a resource has a directed edge from the process to the resource • See Fig 7.1, p 211, Fig 7.2, p. 212 and Fig 7.3, p. 213 • If the graph contains no cycles, then there is no deadlock. If the graph contains cycles, deadlock may exist

5. Deadlock Prevention • We can prevent deadlock by ensuring that at least one of the 4 conditions does not occur • Mutual Exclusion - some devices can be sharable such as read-only files • However, many resources must be nonsharable (e.g. printer) and therefore, mutual exclusion must hold • Hold and Wait - we can ensure that no waiting processes hold devices • This is very restrictive but possible by either forcing processes to request all resources at the beginning of their execution or by allowing processes to request resources only if they currently have none (similar case)

6. Deadlock Prevention Cont. • No Preemption - if a process is holding a resource requested by another process, then all resources currently being held by the waiting process should be preempted • This is difficult to implement for printers currently printing or files that have been partially changed. • Circular Wait - ensure that circular wait conditions can never occur • This can be done by restricting the resources that a process can request after it has begun • This is also restrictive but not difficult to implement

7. Deadlock Avoidance • Deadlock prevention is difficult to implement and overly restrictive • Instead, deadlock avoidance ensures that a deadlock state cannot arise by considering what resources each process currently has and may want in the future • The OS only grants resource requests if the granting does not enter a state that could potentially lead to deadlock • This is less restrictive and simpler to implement

8. Safe State • The system is in a safe state if it can allocate resources to each process in some order and still prevent deadlock • or if there exists a safe sequence which means that there is a sequence for executing the processes such that, in granting resource requests, a deadlock cannot arise • If the OS can ensure that it is always in a safe state, then it avoids deadlock

9. Example • System with 12 tape drives and three processes: • P0: currently has 5, maximum need of 10 • P1: currently has 2, maximum need of 4 • P2: currently has 2, maximum need of 9 • State is currently safe • 3 more tape drives, 2 can be given to P1, when it terminates there will be 5 drives available, P0 can use them and terminate making 10 drives available, P2 can get 7 of them • However, if P2 were to request 1 additional drive, the state would become unsafe • because none of the 3 processes could obtain all of their needed drives to complete and free up their resources!

10. Using a resource-allocation graph • Add to our resource-allocation graph an extra link called a claim edge from Pi to Rj • represents that Pi might at some future point request Rj • claim edges denoted with dotted lines • otherwise, the graph is the same as before • if, in changing a request edge to a grant edge • I.e. from Pi to Rj changes to Rj to Pi • no loop comes into existence, then the state is still safe • A loop means an unsafe state (although not necessarily deadlock) • Note: to detect loops in a graph is O(n2)

11. Banker’s Algorithm • If a system has multiple instances of each resource, we will use another method - Banker’s Algorithm (which is less efficient) • A new process must declare the max number of each resource it will require • If allocation of these resources leaves the system in a safe state, the process is admitted and the resources granted otherwise the process must wait until some other process(es) has released its resources

12. Data Structures for Banker’s Alg • Available - vector indicating the number of available resources of each type (A[I] = k means there are currently k instances of resource I available) • Max - matrix defining the maximum demand of each request for each process (max[I,J] = k means process I will request at most k elements of resource J) • Allocation - matrix defining the current state of the system in terms of resource grants to each process • Need - matrix of the remaining resource needs for each process

13. Safety Algorithm • Let Work be a vector initialized to Available • Let Finish be a vector initialized to False for all I • Find an I such that finish[I]=false and Need[*] <= Work[I,*] • If an I is found, • set Work := Work+Allocation[I] and • Finish[I]:=True • We process I and when it terminates, it releases all of its allocated resources • and find a new I • If Finish[I]=True, then we are in a safe state • This algorithm is O(m*n2)

14. Banker’s Resource-Request Algorithm • Request[I] is the request vector for Pi • If Request[I,J]=K then Pi wants K instances of J • When a request occurs, the following happen • If Request[I]>Need[I] then raise error else If Request[I]>Available then Pi must wait else Have the system pretend to allocate the resources to Pi and modify the state by Available:=Available-Request[I]; Allocation[I]:=Allocation[I]+Request[I]; Need[I]:=Need[I]-Request[I]; • If this results in a safe state (no cycles) then the request is granted otherwise Pi must wait

15. Allocation Max Available A B C A B C A B C • P0 0 1 0 7 5 3 3 3 2 • P1 2 0 0 3 2 2 • P2 3 0 2 9 0 2 • P3 2 1 1 2 2 2 • P4 0 0 2 4 3 3 • Need = Max - Allocation • Sequence P1, P3, P4, P2, P0 is a safe sequence and therefore we are currently in a safe state (P1 borrows 1 A, 2 B’s and 2 C’2, then returns all 7 resources, P3 borrows 1 B and 1 C and then returns all 6 reoursces, P4 borrows 4 A’s, 3 B’s and 1 C, returns all resources, etc...

16. Example Continued: • Suppose P1 requests 1 A and 2 Cs, Request[1] = (1, 0, 2) -- Check to see if Request[1] <=Available[1] -- yes • Then, pretend request is fulfilled and we get: • Allocation Need Available A B C A B C A B C • P0 0 1 0 7 4 3 2 3 0 • P1 3 0 2 0 2 0 • P2 3 0 2 6 0 0 • P3 2 1 1 0 1 1 • P4 0 0 2 4 3 1 • We find a safe sequence of P1, P3, P4, P0, P2. Therefore we can grant p1’s request

17. Deadlock Detection • Rather than restricting resource requests and thereby preventing or avoiding deadlock, we can also grant any request made and risk the chance of deadlock arising • In such a case, we need an algorithm to look at the state of the resource allocation and determine if deadlock has occurred • If so, the OS needs an algorithm to recover

18. Single Instance Resource Types • Use a wait-for graph - variation of the resource-allocation graph where all resources are removed and edges collapsed, leaving just processes and directed edges • An edge from Pi to Pj in a wait-for graph means that Pi is waiting for a resource currently granted to Pj • See figure 7.7, page 225 (which is deadlocked) • If the wait-for graph has a cycle, then there is a deadlock

19. Several Instances • The wait-for graph will not apply if there are several instances of each resource type • Instead, we will use a variation of Banker’s Algorithm • Available (as before) • Allocation (as before) • Request - matrix similar to need but stores only the current requests of process I for resource J • Algorithm similar to Banker’s except that any process with Allocation[I]=0 has Finish[I]=True, and Request replaces Need. Finally, if Finish[I]=False for some I at the end of the algorithm, then a deadlock exists

20. Example • Allocation Request Available A B C A B C A B C • P0 0 1 0 0 0 0 0 0 0 • P1 2 0 0 2 0 2 • P2 3 0 3 0 0 0 • P3 2 1 1 1 0 0 • P4 0 0 2 0 0 2 • Currently not deadlocked • Processes could finish in order P0, P2, P3, P1, P4 or in order P2, P0, P3, P1, P4 • However, if P2 makes 1 additional request for C • Request[P2] becomes (0, 0, 1) • and the system becomes now deadlocked

21. Detection Usage • When should deadlock detection be invoked? • This is a good question because deadlock detection is expensive (algorithms are O(m*n2) and we don’t want to burden the processor with detection very often) • Some possibilities: • Every time a resource is requested • At specified intervals (once per hour) • When CPU utilization drops below a set amount

22. Recovery from Deadlock • What should the OS do if a deadlock is detected? • Process Termination - abort one deadlock process and see if it removes deadlock, or abort all deadlocked processes • Resource Preemption - select a resource to preempt that will resolve the deadlock or roll all processes back to a state prior to deadlock

23. Combined Approaches • Resources can be partitioned into classes that are ordered hierarchically • Resource ordering is applied between classes and a method of deadlock handling is chosen for each class based on whatever is most appropriate for that resource type • Internal resources - prevention through resource ordering • Memory - prevention through preemption • Assignable devices - avoidance • Swap space - preallocation