Deadlock

1. Deadlock • ICS 240: Operating Systems • Instructor: William McDaniel Albritton • Information and Computer Sciences Department at Leeward Community College • Original slides by Silberschatz, Galvin, and Gagne from Operating System Concepts with Java, 7th Edition with some modifications • Also includes material by Dr. Susan Vrbsky from the Computer Science Department at the University of Alabama 6/6/2014 6/6/2014 1 1

2. Deadlock • Deadlock is a set of processes permanently blocked, waiting for an event that will never occur • Blocked waiting for resources that are held by another process in the set and will never become available • Deadlock is slightly different than starvation • With starvation, process blocked on resources that become available, but never acquired

3. Deadlock • Deadlock theory very well developed • Many algorithms can be used to prevent or deal with deadlocks • However, few current operating systems use these deadlock prevention algorithms due to high overhead

4. Deadlock • Modern operating systems have increased possibility of deadlock, because of • Large number of concurrent processes • Multithreaded programs • Sharing of multiple resources in a system • Long-lived file and database servers • Because of these trends, operating systems in the near future will probably incorporate more algorithms that prevent deadlock

5. The Deadlock Problem • A set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the set • Example • System has 2 disk drives • Process #1 and Process #2 each hold one disk drive and each needs another one

6. The Deadlock Problem • A set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the set • Example • Semaphores A and B, initialized to 1 • Semaphore A = new Semaphore(1); • Semaphore B = new Semaphore(1); • Process #1 Process #2A.acquire(); B.acquire()B.acquire(); A.acquire()

7. Bridge Crossing Example • Traffic only in one direction on the bridge • Each section of a bridge can be viewed as a resource • If a deadlock occurs, it can be resolved if one car backs up • Preempt resources and rollback • Several cars may have to be backed up if a deadlock occurs • Starvation is also possible in this example

8. Bridge Crossing Example • Diagram

9. System Model • Resource typesR1, R2, . . ., Rm • For example, CPU, memory, and I/O devices such as printers • Each resource type Ri may have one (1) or more instances • For example, a system with 3 CPUs has 3 instances of a CPU resource • A system with 10 printers has 10 instances of a printer resource

10. System Model • Each process utilizes a resource as follows • Process requests resource • If the request cannot be processed immediately, the process must wait until it can acquire the resource • For example, open a file • Process uses resource • For example, write to a file • Process releases resource • For example, close a file

11. System Model • “Request, use, and release” may sound simple, but this is supported by a complex system • A system table is needed for the resources • Keep track of state of resource: free or allocated • Keep track of the process allocated to each resource • Each resource needs a queue for processes waiting on the resource • Multithreaded applications will be accessing the same resources, so easy to have deadlock

12. Deadlock Characterization • Deadlock can arise if these four (4) conditions hold simultaneously • Mutual exclusion • Hold and wait • No preemption • Circular wait

13. Deadlock Characterization • Mutual exclusion • Resources are not sharable • Only one process at a time can use a resource • If another process requests the resources, this process is delayed until the resource is released • Hold and wait • Process holds resources allocated to them while waiting to acquire additional resources • A process holding at least one resource is waiting to acquire additional resources held by other processes

14. Deadlock Characterization • No preemption • The system cannot forcibly take a resource from a process • A resource can be released only voluntarily by the process holding it, after that process has completed its task

15. Deadlock Characterization • Circular wait • There exists a set of processed {P0...Pn} such that • P0 is waiting for a resource held by P1 • P1 is waiting for a resource held by P2 • . . . • Pn-1 is waiting for a resource held by Pn • Pn is waiting for a resource held by P0

16. Resource-Allocation Graph • A set of vertices (nodes, circles) V and a set of edges (arrows, lines) E • V is partitioned into two types • P = {P1, P2, …, Pn}, the set consisting of all the processes in the system • R = {R1, R2, …, Rm}, the set consisting of all resource types in the system • “Process #i requests Resouce #j” is represented by the directed edge Pi  Rj • “Resource #j is assigned to Process #i” is represented by the directed edge Rj Pi

17. Resource-Allocation Graph • Process • Resource Type with 4 instances • Pirequests instance of Rj • Pi is holding an instance of Rj Pi Rj Pi Rj

18. Example Graph #1 • Resource Allocation Graph without a cycle • Processes: P1, P2, P3 • Resource Types: R1, R2, R3, R4 • Resource Instances • R1 & R3: one instance • R2: two instances • R4: three instances

19. Example Graph #1 • Process states • Process P1 • Waiting for an instance of Resource Type R1 • Acquired an instance of Resource Type R2 • Process P2 • Acquired an instance of Resource Type R1 • Acquired an instance of Resource Type R2 • Waiting for an instance of Resource Type R3

20. Example Graph #1 • Process states • Process P3 • Acquired an instance of Resource Type R3 • Since this graph has no cycles, no deadlock exists • If no cycles, then no deadlock

21. Example Graph #2 • Resource Allocation Graph With Deadlock • Cycles in this system • P1  R1  P2  R3 P3  R2  P1 • P2  R3  P3  R2 P2

22. Example Graph #2 • Processes P1, P2, and P3 are deadlocked • P2 is waiting on R3 • But R3 is held by P3 • P3 is waiting on R2 • But R2 is held by P1 and P2 • P1 is waiting on R1 • But R1 is held by P2

23. Example Graph #3 • Graph With A Cycle But No Deadlock • Cycles in this system • P1  R1  P3  R2 P1 • Have one cycle, but no deadlock • P4 may release R2 • Then, R2 can be allocated to P3 • This breaks the cycle

24. Basic Facts • If graph contains no cycles • No deadlock • If graph contains a cycle • If only one instance per resource type, then deadlock • If several instances per resource type, possibility of deadlock • In summary, if no cycles, then no deadlock; however, if cycles exist, then the system may or may not have deadlock

25. Solutions to Deadlock • Four ways to deal with deadlock problem • Prevention • Remove all possibility of deadlock by denying at least one of the four necessary conditions for deadlock • Detection and Recovery • Allow deadlock to occur, detect it when it does • Occasionally examine state of system, checking for deadlock • Clear deadlock when it occurs

26. Solutions to Deadlock • Four ways to deal with deadlock problem • Avoidance • Sidestep deadlock if it is imminent • Grant only those requests which cannot result in a state of deadlock • Ignore the problem • Pretend that deadlock never occurs • Used by most operating systems, including UNIX and Windows

27. Deadlock Prevention • Design system so deadlock can not occur by disallowing one of the necessary conditions • Mutual Exclusion • Mutual exclusion is not required for sharable resources • However, we cannot disallow mutual exclusion for resources that cannot be shared • So we cannot prevent deadlocks by disallowing mutual exclusion, as mutual exclusion is required to manage non-sharable resources

28. Deadlock Prevention • Design system so deadlock can not occur by disallowing one of the necessary conditions • Hold and Wait • Must guarantee that whenever a process requests a resource, it does not hold any other resources • Two possible protocols • Require process to request and be allocated all its resources before it begins execution • Allow process to request resources only when the process has none

29. Deadlock Prevention • Hold and Wait • Example: a process that copies a file from DVD to disk, sorts the file, and prints the file • Protocol #1: If the process is allocated all resources at once, then it has to hold the printer for the whole time period, even though it only needs the printer at the end. This is wasteful of resources. • Protocol #2: The process only acquires the DVD and disk, and then releases both. Then the process acquires the disk and printer, and then releases both. This assumes that the data is still on the file. 6/6/2014 29

30. Deadlock Prevention • Hold and Wait • Problems • A given process may not know all the resources that are needed • Wasteful of resources • Starvation is possible

31. Deadlock Prevention • Design system so deadlock can not occur by disallowing one of the necessary conditions • No preemption • Allow system to take a process’s resources • Two possible protocols • If process requests a resource that it can not immediately have, system takes all resources currently allocated to the process and process must re-request all resources plus new one • If process requests a resource that it cannot immediately have, see if another waiting process has the resource and take it

32. Deadlock Prevention • No preemption • Problems • Not all resources can be preempted • For example, a printer cannot be preempted • Preemption and resumption of resources is difficult, costly saving states, etc.

33. Deadlock Prevention • Design system so deadlock can not occur by disallowing one of the necessary conditions • Circular wait • Give an order to all resource types • type 1, type 2, type3.....type n • If hold resource of type i, can only request from classes greater than i • Must request resources in an increasing order of enumeration • Assign more expensive resources higher numbers 6/6/2014 33

34. Deadlock Prevention • Circular wait • Problems • Poor resource utilization (resources requested before needed) • Degradation of concurrency • Process may request max needed for each class although not always required • Preventing circular wait has less overhead than preventing the other 3 conditions and is a common preventive technique 6/6/2014 34

35. Deadlock Avoidance • Requires that the system has some additional information up front • Simplest and most useful model requires that each process declare the maximum number of resources of each type that it may need • The deadlock-avoidance algorithm dynamically examines the resource-allocation state to ensure that there can never be a circular-wait condition • Resource-allocation state is defined by the number of available and allocated resources, and the maximum demands of the processes

36. Safe State • Deadlock avoidance means to keep the system in a safe state • Therefore the system must ensure that there is never a circular wait • Safe state • There exists a sequence of processes (P1,P2,...Px) such that each process gets the maximum resources it could possibly want • In other words, a cycle does NOT have the possibility of occurring

37. Basic Facts • If a system is in safe state • No deadlocks • If a system is in unsafe state • Possibility of deadlock • Avoidance • Ensure that a system will never enter an unsafe state

38. Avoidance Algorithms • Single instance of each resource type • Use a resource-allocation graph • Multiple instances of each resource type • Use the banker’s algorithm

39. Resource-Allocation Graph Scheme • Claim edgePi Rj indicated that process Pj may request resource Rj • A claim edge is represented by a dashed line • Resources in the system must be claimed in advance • In other words, before Pi starts executing, all its claim edges must already appear in the resource-allocation graph

40. Resource-Allocation Graph Scheme • Changing from one edge to another • Claim edge converts to request edge when a process requests a resource • Request edge converted to an assignment edge when the resource is allocated to the process • When a resource is released by a process, assignment edge reconverts to a claim edge 6/6/2014 40

41. Resource-Allocation Graph Algorithm • Suppose that process Pi requests a resource Rj • The request can be granted only if converting the request edge to an assignment edge does not result in the formation of a cycle in the resource allocation graph

42. Processes P1, P2 Resources R1, R2 Claim edge P1  R2 P2  R2 Request edge P2  R1 Assignment edge R1  P1 Resource-Allocation Graph

43. Claim edge P1  R2 Request edge P2  R1 Assignment edge R1  P1 R2  P2 Unsafe State In Resource-Allocation Graph

44. R2 should not be allocated to P2, because this will create a cycle A cycle indicates that the system is in an unsafe state If P1 requests R2, and P2 requests P1, then a deadlock will occur Unsafe State In Resource-Allocation Graph 6/6/2014 44

45. Banker’s Algorithm • The Banker’s Algorithm is used when there are multiple instances of a resource type • Originally created by Dijkstra in 1968 • The name was chosen because we can use this algorithm in a banking system to make sure that the bank never distributes its cash, so that it can no longer satisfy the needs of all its customers

46. Banker’s Algorithm • 3 main parts to the Banker’s Algorithm • When a new process enters the system, it must give the maximum number of resource instances that it needs • The system uses this information to check for a safe state before allocating a request • If not a safe state, then a process must wait until it can get all its resources 6/6/2014 46

47. Data Structures for Banker’s Algorithm • Let n = number of processes, and m = number of resources types. • Available: Vector of length m. If available [j] = k, there are k instances of resource type Rjavailable. • Max: n x m matrix. If Max [i,j] = k, then process Pimay request at most k instances of resource type Rj. • Allocation: n x m matrix. If Allocation[i,j] = k then Pi is currently allocated k instances of Rj. • Need: n x m matrix. If Need[i,j] = k, then Pi may need k more instances of Rjto complete its task. • Need [i,j] = Max[i,j] – Allocation [i,j].

48. Safety Algorithm 1. Let Workand Finish be vectors of length m and n, respectively. Initialize: Work = Available Finish [i] = false for i = 0, 1, …, n- 1. 2. Find and i such that both: (a) Finish [i] = false (b) Needi Work If no such i exists, go to step 4. 3. Work = Work + AllocationiFinish[i] = truego to step 2 4. If Finish [i] == true for all i, then the system is in a safe state.

49. Resource-Request Algorithm for Process Pi • Request = request vector for process Pi. If Requesti[j] = k then process Pi wants k instances of resource type Rj. • If Requesti Needigo to step 2. Otherwise, raise error condition, since process has exceeded its maximum claim • If Requesti Available, go to step 3. Otherwise Pi must wait, since resources are not available • Pretend to allocate requested resources to Pi by modifying the state as follows • Available = Available – Request; • Allocationi= Allocationi + Requesti; • Needi= Needi – Requesti; • If safe  the resources are allocated to Pi • If unsafe  Pi must wait, and the old resource-allocation state is restored

50. Example of Banker’s Algorithm • 5 processes P0 through P4 • 3 resource types • A (10 instances), B (5instances), and C (7 instances) • Snapshot at time T0 AllocationMaxAvailable 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