COMP 3713 Operating Systems Slides Part 3. Jim Diamond CAR 409 Jodrey School of Computer Science Acadia University

Transcription

1 COMP 3713 Operating Systems Slides Part 3 Jim Diamond CAR 409 Jodrey School of Computer Science Acadia University

2 Acknowledgements These slides borrow from those prepared for Operating System Concepts (eighth edition) by Silberschatz, Galvin and Gagne. These slides borrow lightly from those prepared for COMP 3713 by Dr. Darcy Benoit.

3 Chapter 7 Deadlocks

4 Chapter The Deadlock Problem A deadlock occurs when a set of processes are blocked, each waiting for a resource held by another process in that set more

5 Chapter The Deadlock Problem A deadlock occurs when a set of processes are blocked, each waiting for a resource held by another process in that set Example: system has 2 optical drives P 1 and P 2 each hold one optical drive and each needs another one more

6 Chapter The Deadlock Problem A deadlock occurs when a set of processes are blocked, each waiting for a resource held by another process in that set Example: system has 2 optical drives P 1 and P 2 each hold one optical drive and each needs another one Example: semaphores A and B, initialized to 1 P 1 : wait(a) ; wait(b) P 2 : wait(b) ; wait(a)

7 Chapter Deadlock Example Consider two-way traffic on an east-west road with a one-lane bridge (the bridge is a resource which can t be concurrently used by cars travelling in opposite directions) Suppose C e enters bridge heading E, C w enters bridge heading W neither can complete trip to other side, so both are blocked more

8 Chapter Deadlock Example Consider two-way traffic on an east-west road with a one-lane bridge (the bridge is a resource which can t be concurrently used by cars travelling in opposite directions) Suppose C e enters bridge heading E, C w enters bridge heading W neither can complete trip to other side, so both are blocked To get out of this situation, either C e or C w must back up this may require other cars to back up as well more

9 Chapter Deadlock Example Consider two-way traffic on an east-west road with a one-lane bridge (the bridge is a resource which can t be concurrently used by cars travelling in opposite directions) Suppose C e enters bridge heading E, C w enters bridge heading W neither can complete trip to other side, so both are blocked To get out of this situation, either C e or C w must back up this may require other cars to back up as well Starvation is possible! more

10 Chapter Deadlock Example Consider two-way traffic on an east-west road with a one-lane bridge (the bridge is a resource which can t be concurrently used by cars travelling in opposite directions) Suppose C e enters bridge heading E, C w enters bridge heading W neither can complete trip to other side, so both are blocked To get out of this situation, either C e or C w must back up this may require other cars to back up as well Starvation is possible! Most OSes do not prevent or deal with deadlocks so you have to be careful all by yourself!

11 Chapter Model There are resource types R 1, R 2,..., R m e.g., CPU cycles, memory space, I/O devices Each resource type R i has W i instances Each process utilizes a resource as follows: request use release

12 Chapter Deadlock Characterization Deadlock can arise if four conditions hold simultaneously: Mutual exclusion: only one process at a time can use a resource more

13 Chapter Deadlock Characterization Deadlock can arise if four conditions hold simultaneously: Mutual exclusion: only one process at a time can use a resource Hold and wait: a process holding at least one resource is waiting to acquire additional resources held by other processes more

14 Chapter Deadlock Characterization Deadlock can arise if four conditions hold simultaneously: Mutual exclusion: only one process at a time can use a resource Hold and wait: a process holding at least one resource is waiting to acquire additional resources held by other processes No preemption: a resource can be released only voluntarily by the process holding it, after that process has completed its task more

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

16 Chapter Resource-Allocation Graph Idea: a precise way of representing the deadlock problem A resource-allocation graph is a set of vertices V and a set of edges E V is partitioned into two types of vertices: P = {P 1, P 2,..., P n }, the set consisting of all the processes in the system R = {R 1, R 2,..., R m }, the set consisting of all the resource types in the system more

17 Chapter Resource-Allocation Graph Idea: a precise way of representing the deadlock problem A resource-allocation graph is a set of vertices V and a set of edges E V is partitioned into two types of vertices: P = {P 1, P 2,..., P n }, the set consisting of all the processes in the system R = {R 1, R 2,..., R m }, the set consisting of all the resource types in the system There are two types of edges: request edge a directed edge P i R j assignment edge a directed edge R j P i

18 Chapter Resource-Allocation Graph Example Processes are represented with circles Resource are represented with rectangles the number of dots inside the rectangles represent the number of instances of that resource An edge from a process to a resource means the process has requested an instance of that resource An edge from a resource to a process means the process is holding an instance of that resource

19 Chapter Resource-Allocation Graph Example: Deadlock P 1 wants R 1, P 2 wants R 3 and P 3 wants R 2 P 1 can t get R 1 until P 2 releases it P 2 won t release R 1 until it gets R 3 P 3 won t release R 3 until it gets R 2 Neither P 1 nor P 2 will release R 2 until they get R 1 or R 3, respectively There are two cycles in this graph: P 1, R 1, P 2, R 3, P 3, R 2, P 1 P 2, R 3, P 3, R 2, P 2 and Q: does a cycle in a graph mean there is a deadlock?

20 Chapter Resource-Allocation Graph Example: Deadlock A cycle: P 1, R 1, P 3, R 2, P 1 But there is no deadlock: P 4 has all resources it needs allocated, and will (presumably) eventually release R 2, allowing P 1 to proceed similar for P 2, R 1 and P 3 Conclusions: with no cycle, there is no deadlock with a cycle, there may be a deadlock if only one instance per resource type, deadlock if more than one instance per resource type, maybe deadlock

21 Chapter Handling Deadlocks Avoid them in the first place Ha! more

22 Chapter Handling Deadlocks Avoid them in the first place Ha! If a deadlock is entered, recover from this somehow more

23 Chapter Handling Deadlocks Avoid them in the first place Ha! If a deadlock is entered, recover from this somehow Bury your head in the sand and pretend it never happens more

24 Chapter Handling Deadlocks Avoid them in the first place Ha! If a deadlock is entered, recover from this somehow Bury your head in the sand and pretend it never happens The third choice is the popular one (!)

25 Chapter Preventing Deadlocks: 1 We mentioned four conditions that must hold for a deadlock to occur; if we avoid any one of them, no deadlocks possible solution: constrain the ways resource requests can be made more

26 Chapter Preventing Deadlocks: 1 We mentioned four conditions that must hold for a deadlock to occur; if we avoid any one of them, no deadlocks possible solution: constrain the ways resource requests can be made Mutual exclusion countermeasure: mutual exclusion is not required for sharable resources (e.g., read-only files), but it must be required for non-sharable resources so we can t avoid this potential problem in all cases more

27 Chapter Preventing Deadlocks: 1 We mentioned four conditions that must hold for a deadlock to occur; if we avoid any one of them, no deadlocks possible solution: constrain the ways resource requests can be made Mutual exclusion countermeasure: mutual exclusion is not required for sharable resources (e.g., read-only files), but it must be required for non-sharable resources so we can t avoid this potential problem in all cases Hold and wait countermeasure: require that whenever a process requests a resource, it does not hold any other resources require a process to request and be allocated all its resources before it begins execution, or allow process to request resources only when the process has none problem: possible low resource utilization: processes may hold resources for much longer than they need them problem: starvation is possible

28 Chapter Preventing Deadlocks: 2 No preemption countermeasure: if a process that is holding some resources requests another resource that cannot be immediately allocated to it, then all resources currently being held are released preempted resources are added to the list of resources for which the process is waiting process will be restarted only when it can regain its old resources, as well as the new ones that it is requesting how practical is this?? more

29 Chapter Preventing Deadlocks: 2 No preemption countermeasure: if a process that is holding some resources requests another resource that cannot be immediately allocated to it, then all resources currently being held are released preempted resources are added to the list of resources for which the process is waiting process will be restarted only when it can regain its old resources, as well as the new ones that it is requesting how practical is this?? Circular wait countermeasure: impose a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration GEQ: how might this affect overall resource utilization?

30 Chapter Deadlock Avoidance Requires that the system has some additional a priori information available The 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 The resource-allocation state is defined by the number of available and allocated resources, and the maximum demands of the processes

31 Chapter Safe State When a process requests an available resource, system must decide if immediate allocation leaves the system in a safe state The system is in a safe state if there exists a sequence < P 1, P 2,..., P n > of ALL the processes in the system such that for each P i, the resources that P i can still request can be satisfied by currently available resources + resources held by all the P j, for j < i more

32 Chapter Safe State When a process requests an available resource, system must decide if immediate allocation leaves the system in a safe state The system is in a safe state if there exists a sequence < P 1, P 2,..., P n > of ALL the processes in the system such that for each P i, the resources that P i can still request can be satisfied by currently available resources + resources held by all the P j, for j < i That is: if P i s resource needs are not immediately available, then P i can wait until all P j (for j < i) have finished when P j is finished, P i can obtain needed resources, execute, return allocated resources, and terminate when P i terminates, P i+1 can obtain its needed resources, and so on Note: if such a sequence exists, P 1 either has all the resources it needs or can get them without waiting for another process to release them

33 Chapter Safe State Facts of Life If a system is in safe state, then there are no deadlocks If a system is in unsafe state, then there is the possibility of deadlock Avoidance: ensure that a system will never enter an unsafe state

34 Chapter Avoidance Algorithms Single instance of a resource type use a resource-allocation graph (next slides) Multiple instances of a resource type use the banker s algorithm see textbook for the details

35 Chapter Resource-Allocation Graph Scheme A claim edge P i R j indicates that process P j may request resource R j (represented by a dashed line) A claim edge converts to a request edge when a process requests a resource A request edge converts to an assignment edge when the resource is allocated to the process When a resource is released by a process, an assignment edge reconverts to a claim edge Resources must be claimed a priori in the system

36 Chapter Example of Unsafe State In Resource-Allocation Graph more

37 Chapter Example of Unsafe State In Resource-Allocation Graph Resource-Allocation Graph Algorithm: suppose that process P i requests a resource R j (e.g., on prev slide P 2 requests R 2 ) 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

38 Chapter Deadlock Detection Rather than avoiding it, wait until it happens and then deal with it First: detect that deadlock happened Second: recover from the deadlock

39 Chapter Detection: Single Instance of Each Resource Type Maintain a wait-for graph vertices are processes we have the edge P i P j if P i is waiting for P j to release a resource it needs Periodically, invoke an algorithm that searches for a cycle in the graph: if there is a cycle, there exists a deadlock An algorithm to detect a cycle in a graph requires O( V + E ) operations

40 Chapter Resource Allocation Graph vs. Wait-for Graph

41 Chapter Detection-Algorithm Usage When, and how often, to invoke the detection algorithm depends on: how often is a deadlock likely to occur? how many processes will need to be rolled back? (A: one for each disjoint cycle, but how many cycles?) more

42 Chapter Detection-Algorithm Usage When, and how often, to invoke the detection algorithm depends on: how often is a deadlock likely to occur? how many processes will need to be rolled back? (A: one for each disjoint cycle, but how many cycles?) If the algorithm is invoked every time a resource is requested, deadlock will be detected immediately and it is possible to determine which process caused the deadlock (or, at least which one was the last contributor) this could be computationally expensive how many allocatable resources on your system? how many processes are there which allocate resources? more

43 Chapter Detection-Algorithm Usage When, and how often, to invoke the detection algorithm depends on: how often is a deadlock likely to occur? how many processes will need to be rolled back? (A: one for each disjoint cycle, but how many cycles?) If the algorithm is invoked every time a resource is requested, deadlock will be detected immediately and it is possible to determine which process caused the deadlock (or, at least which one was the last contributor) this could be computationally expensive how many allocatable resources on your system? how many processes are there which allocate resources? If the detection algorithm is invoked at arbitrary times, there may be many cycles in the resource graph and so we would not be able to tell which of the many deadlocked processes caused the deadlock

44 Chapter Recovery from Deadlock: Process Termination Abort all deadlocked processes generally too much of a BFI solution more

45 Chapter Recovery from Deadlock: Process Termination Abort all deadlocked processes generally too much of a BFI solution Abort one process at a time until the deadlock cycle is eliminated in which order should we choose to abort? priority of the process? how long has the process computed, and how much longer to completion? resources the process has used? resources the process needs to complete? how many processes will need to be terminated? is process interactive or batch?

46 Chapter Recovery from Deadlock: Resource Preemption Selecting a victim: minimize cost need to define a cost function! more

47 Chapter Recovery from Deadlock: Resource Preemption Selecting a victim: minimize cost need to define a cost function! Rollback: return to some safe state, restart process from that state can t always do this GEQ: why not? more

48 Chapter Recovery from Deadlock: Resource Preemption Selecting a victim: minimize cost need to define a cost function! Rollback: return to some safe state, restart process from that state can t always do this GEQ: why not? Starvation: a particular process may repeatedly be picked as the victim, so include the number of previous rollbacks in cost factor