Operating Systems. Deadlocks. Stephan Sigg. November 30, Distributed and Ubiquitous Systems Technische Universität Braunschweig

Transcription

1 Operating Systems Deadlocks Stephan Sigg Distributed and Ubiquitous Systems Technische Universität Braunschweig November 30, 2010 Stephan Sigg Operating Systems 1/86

2 Overview and Structure Introduction to operating systems History Architectures Processes Processes, Threads, IPC, Scheduling Synchronisation Deadlocks Memory management Paging Segmentation Filesystems Security and Protection Distributed systems Cryptography Stephan Sigg Operating Systems 2/86

3 Outline Deadlocks 1 Deadlocks System model Deadlock characterisation Resource allocation graph Handling of deadlocks Deadlock prevention Deadlock avoidance Deadlock detection Recovery from deadlock Stephan Sigg Operating Systems 3/86

4 Introduction Several processes compete for finite number of resources Processes request resources When resources not available, process enters waiting state When resources are held by other waiting processes, the process might wait indefinitely This situation is called a deadlock Stephan Sigg Operating Systems 4/86

5 Introduction Example When two trains approach each other at a crossing, both shall come to a full stop and neither shall start up again until the other has gone a a Excerpt from a low passed by the Kansas legislature early in the 20th century Stephan Sigg Operating Systems 5/86

6 Introduction Several methods to detect, prevent or deal with deadlocks exist Operating systems typically do not provide deadlock-prevention facilities Programmer has to ensure deadlock-free programs Stephan Sigg Operating Systems 6/86

7 Outline Deadlocks 1 Deadlocks System model Deadlock characterisation Resource allocation graph Handling of deadlocks Deadlock prevention Deadlock avoidance Deadlock detection Recovery from deadlock Stephan Sigg Operating Systems 7/86

8 System model System model Processes request resources before using them Processes release resources after using them A process may request as many resources as it requires Stephan Sigg Operating Systems 8/86

9 System model System model A process utilises a resource in the following sequence Request Process the resource. If resource is not available, requesting process must wait Use Process operates on the resource Release The process releases the resource Stephan Sigg Operating Systems 9/86

10 Outline Deadlocks 1 Deadlocks System model Deadlock characterisation Resource allocation graph Handling of deadlocks Deadlock prevention Deadlock avoidance Deadlock detection Recovery from deadlock Stephan Sigg Operating Systems 10/86

11 Deadlock Characterisation Necessary conditions for a deadlock Mutual exclusion Hold and wait No preemption holds holds Circular wait Stephan Sigg Operating Systems 11/86

12 Deadlock Characterisation Mutual exclusion Resources held exclusively by one process at most Other processes requesting the resource are delayed until the resource is released holds Stephan Sigg Operating Systems 12/86

13 Deadlock Characterisation Hold and wait A process must hold at least one resource and wait to acquire additional resources holds holds These additional resources are currently held by other processes Stephan Sigg Operating Systems 13/86

14 holds holds Deadlocks Deadlock Characterisation No preemption Resources cannot be preempted A resource is released by a process only after that process has completed its task Stephan Sigg Operating Systems 14/86

15 Deadlocks Deadlock Characterisation Circular wait A set P0,..., Pn of waiting processes must exist Stephan Sigg ai ts w holds holds w ai ts Operating Systems holds Such that Pi is waiting for a resource held by P(i+1) mod n wa its 15/86

16 Outline Deadlocks 1 Deadlocks System model Deadlock characterisation Resource allocation graph Handling of deadlocks Deadlock prevention Deadlock avoidance Deadlock detection Recovery from deadlock Stephan Sigg Operating Systems 16/86

17 Resource allocation graph Resource allocation graph Deadlocks can be described in terms of a directed graph Vertexes are partitioned into two types of nodes: P = {P 1,..., P n } (processes) R = {R 1,..., R m } (resources) Directed edge P i R j indicates that P i and waits for R j Directed edge R j P i indicates, that P i holds R j P i P i R j R j Stephan Sigg Operating Systems 17/86

18 Resource allocation graph Example P = {P 1, P 2, P 3 } R = {R 1, R 2, R 3, R 4 } E = {P 1 R 1, P 2 R 3, R 1 P 2, R 2 P 2, R 2 P 1, R 3 P 3, } Resource instances One instance of resource R 1 Two instances of resource R 2 One instance of resource R 3 Three instances of resource R 4 Process state: P 1 holds an instance of R 2 and waits for R 1 P 2 holds an instance of R 1 and waits for R 3 P 3 holds an instance of R 3 Stephan Sigg Operating Systems 18/86

19 Resource allocation graph R 1 R 2 P 1 R 2 P 2 P 3 R 4 R 4 R 4 R 3 Stephan Sigg Operating Systems 19/86

20 Resource allocation graph R... 1 R 2 P 1 P 2 P 3... R 4 R 3. Stephan Sigg Operating Systems 20/86

21 Resource allocation graph Deadlock detection If the graph contains no cycles, no process is deadlocked Otherwise a deadlock may exist When each resource type has one instance, a cycle implies that a deadlock occurred Otherwise, a deadlock exists, if all resource types in the cycle are exclusively allocated to processes in the cycle R... 1 R2 R... 1 R2 P R P 2 P 3 R3. P R P 2 P 3 R3. Stephan Sigg Operating Systems 21/86

22 Outline Deadlocks 1 Deadlocks System model Deadlock characterisation Resource allocation graph Handling of deadlocks Deadlock prevention Deadlock avoidance Deadlock detection Recovery from deadlock Stephan Sigg Operating Systems 22/86

23 Deadlocks Handling of deadlocks Three possible approaches to handle deadlocks: Use a protocol that prevents or avoids deadlocks so that a deadlocked state is never reached Detect deadlocks at their occurrence and recover Stephan Sigg qu re re qu ts es Operating Systems es ts qu re ts es holds es ts holds re qu holds ts es qu re holds re qu es ts holds Ignore the problem 23/86

24 holds holds Deadlocks Handling of deadlocks The last solution is actually implemented most often in operating systems Including UNIX and Windows systems Deadlock occurrence is very rare Therefore, the cost of addressing this problem is often seen as not critical Stephan Sigg Operating Systems 24/86

25 holds Deadlocks Handling of deadlocks To ensure that a deadlock never occurs, the system can use Deadlock prevention schemes Ensure that at least one of the necessary conditions is not met Deadlock avoidance schemes Schedule resource utilisation by processes Based on additional knowledge on processes e.g. Resources requested e.g. lifetime Stephan Sigg Operating Systems 25/86

26 Stephan Sigg Operating Systems 26/86 holds holds Deadlocks Handling of deadlocks When no deadlock prevention or deadlock avoidance scheme is employed, a deadlock may occur In this case, the system requires algorithms to detect whether a deadlock has occurred recover from the deadlock

27 holds holds Deadlocks Handling of deadlocks When the system can not detect or recover from deadlocks, the system might be unable to recognise the problem The performance of the system will deteriorate More and more processes enter a deadlocked state as they require a resource that is never released Eventually the system will stop functioning Manual restart is required Stephan Sigg Operating Systems 27/86

28 Deadlocks Deadlock prevention Deadlock prevention For a deadlock to occur, each of the following conditions must hold Mutual exclusion Hold and wait No preemption Circular wait qu re w ts es Operating Systems ai ts w holds es ts holds re qu ts es holds qu re holds es ts holds holds ts es holds qu re Stephan Sigg re qu ai ts holds By ensuring that at least one of these conditions cannot hold, occurrence of deadlocks is prevented w ait s 28/86

29 Deadlock prevention Deadlock prevention Mutual exclusion Mutual exclusion must hold for nonsharable resources Some resources, e.g. a read-only-file do not require to meet this condition In general, however, we cannot prevent deadlocks by denying mutual exclusion as some resources are nonsharable holds Stephan Sigg Operating Systems 29/86

30 holds holds Deadlocks Deadlock prevention Deadlock prevention Hold and wait In order to prevent hold and wait condition, we must guarantee that A process requesting a resource does not hold any other resources Possible implementations: System calls requesting resources must precede all other system calls A process may request one or many resources only when it holds none Stephan Sigg Operating Systems 30/86

31 holds holds Deadlocks Deadlock prevention Deadlock prevention Hold and wait Disadvantages of these solutions Resource utilisation may be low since resources may be allocated for a long period Starvation is possible when popular resources are repeatedly allocated to other processes Stephan Sigg Operating Systems 31/86

32 holds holds Deadlocks Deadlock prevention Deadlock prevention No preemption The following protocol can prevent the no-preemption-condition: Processes that wait on a request for additional resources, allow preemption of their currently hold resources Resources are preempted only if requested by other processes Feasible for resources whose state can be easily saved and restored (e.g. CPU registers, memory space) Not applicable for some resources e.g. printers, tape drives Stephan Sigg Operating Systems 32/86

33 Deadlocks Deadlock prevention Deadlock prevention - Circular wait Avoidance of circular wait: Total ordering of resource types Resources requested in an increasing order by a process All resources of one resource type must be requested at once Stephan Sigg ai ts w holds holds w ai ts Operating Systems holds With this protocol, a cycle in the resource graph is impossible w ai ts 33/86

34 Deadlock avoidance Deadlock avoidance Deadlock prevention has negative side-effects: Low device utilisation Reduced system throughput Alternative: Avoid deadlocks with the help of additional information Order in which processes request resources Resource types and count required by processes Typically: Ensure that deadlock can not occur by analysing the resource allocation state Available resources Allocated resources Maximum resource demand Stephan Sigg Operating Systems 34/86

35 Deadlock avoidance Safe state A state is safe, if the system can allocate resources to each process in some order and still avoid a deadlock System is in a safe state if it exists a safe sequence (that does not end in a deadlock) A sequence of processes P 1,..., P n is safe, if for each P i all resource can be fulfilled in order If no such sequence exists, the state is unsafe As long as the state is safe, the system can avoid deadlocks Stephan Sigg Operating Systems 35/86

36 Stephan Sigg Operating Systems 36/86 Deadlocks Deadlock avoidance Safe state Example Max. Need Allocated free P P P free 3

37 Stephan Sigg Operating Systems 37/86 Deadlocks Deadlock avoidance Safe state Example Max. Need Allocated free P P P free 1

38 Stephan Sigg Operating Systems 38/86 Deadlocks Deadlock avoidance Safe state Example Max. Need Allocated free P P P free 5

39 Stephan Sigg Operating Systems 39/86 Deadlocks Deadlock avoidance Safe state Example Max. Need Allocated free P P P free 0

40 Stephan Sigg Operating Systems 40/86 Deadlocks Deadlock avoidance Safe state Example Max. Need Allocated free P P P free 10

41 Stephan Sigg Operating Systems 41/86 Deadlocks Deadlock avoidance Safe state Example Max. Need Allocated free P P P free 3

42 Stephan Sigg Operating Systems 42/86 Deadlocks Deadlock avoidance Safe state Example Max. Need Allocated free P P P free 12

43 Deadlock avoidance Safe state When resources are differently allocated, a deadlock may occur: Example Max. Need Allocated free P P P free 3 Stephan Sigg Operating Systems 43/86

44 Deadlock avoidance Safe state When resources are differently allocated, a deadlock may occur: Example Max. Need Allocated free P P P free 2 Stephan Sigg Operating Systems 44/86

45 Deadlock avoidance Deadlock avoidance algorithms try to prevent circular wait This is achieved, when the safe system state is never left Whenever a process a resource, the algorithm checks, if the system would then traverse to an unsafe state The resource is granted only when the safe state is not left Otherwise, the process has to wait No deadlock is possible under this precondition Stephan Sigg Operating Systems 45/86

46 Deadlock avoidance Resource allocation algorithm One instance of each resource: Avoid deadlocks with resource-allocation graph We introduce claim edges P i R j indicates that process P i might request R j in the future Represented by dashed line Resource request: Verify if allocation results in circle If not, the resource is allocated Else, deadlock would result from allocation: process waits Resource allocation graphs An unsafe state A safe state R 1. P 1 P 2 R 2. R 1. P 1 P 2 R 2. Stephan Sigg Operating Systems 46/86

47 Deadlock avoidance Resource allocation graphs R 1. Resource allocation algorithm Resource-allocation algorithm not applicable when multiple instances per resource type exist Calculation of circles: O ( V 2) An unsafe state A safe state P 1 P 2 R 2. R 1. P 1 P 2 R 2. Stephan Sigg Operating Systems 47/86

48 Deadlock avoidance Banker s algorithm When more than one instance of each resource type exists, the banker s algorithm can be applied The banker s algorithm The name was chosen because the algorithm could be used in a banking system to ensure that the bank never allocated its available cash in such a way that it could no longer satisfy the needs of all its customers. a a A. Silberschatz, P.PB Galvin, G. Gagne, Operating System Concepts, 2010 This algorithm is less efficient than the resource-allocation algorithm Stephan Sigg Operating Systems 48/86

49 Deadlock avoidance Banker s algorithm When a new process enters the system, it must declare the maximum number of instances of each resource it might request This number may not exceed the maximum number of instances of these resource types At resource, the system determines wether allocation would result in a safe state. If not, the process waits until sufficient number of resources have been released Stephan Sigg Operating Systems 49/86

50 Stephan Sigg Operating Systems 50/86 Deadlocks Deadlock avoidance Resources Banker s algorithm Variables: Number of processes: n Number of resource types: m Data structures required: Available[j] Max[i][j] Allocation[i][j] Need[i][j] Running processes Requesting processes

51 Deadlock avoidance Banker s algorithm Available[j] : Vector of length m Indicates the number of available resources of each resource type Additional notation for vectors : X Y X [i] Y [i]; i {0,..., n 1} X < Y X Y Y X Stephan Sigg Operating Systems 51/86

52 Deadlock avoidance Banker s algorithm Max[i][j] : Max i : n m matrix Defines the maximum demand of each process If Max[i][j] = k, process P i max request up to k instances of resource type R j Specifies the i-th row in Max[i][j] Stephan Sigg Operating Systems 52/86

53 Deadlock avoidance Banker s algorithm Allocation[i][j] : Allocation i : n m matrix Defines the number of resources of each type currently allocated to processes If Allocation[i][j] = k, process P i is currently allocated k instances of resource type R j Specifies the i-th row in Allocation[i][j] Stephan Sigg Operating Systems 53/86

54 Deadlock avoidance Banker s algorithm Need[i][j] : Need i : n m matrix Indicates the remaining resource needs of each process If Need[i][j] = k, process P i may need further k instances of resource type R j Specifies the i-th row in Need[i][j] Stephan Sigg Operating Systems 54/86

55 Deadlock avoidance Safety algorithm The safety algorithm determines if a system is in a safe state: 1 Initialise vectors: Work=Available Finish[i]=false for i=0,1,...,n-1 2 Find an index i such that 1 Finish[i] == false 2 Need i Work If no such i exists, go to step 4 3 Complete the following allocations 1 Work = Work + Allocation i 2 Finish[i]=true Go to step 2 4 If Finish[i] == true for all i, state is safe Stephan Sigg Operating Systems 55/86

56 Stephan Sigg Operating Systems 56/86 Deadlocks Deadlock avoidance Resources Safety algorithm The safetey algorithm runs in time O ( m n 2) Running processes Requesting processes

57 Deadlock avoidance Resource request algorithm determines insecure transitions: Let Request i be the request vector If Request i [j] == k, process P i k instances of R j When resource requested the following actions are taken: 1 If Request i Need i Go to step 2 Otherwise: error, since process has exceeded maximum claim 2 If Request i Available Go to step 3 Otherwise P i must wait since no resources are available 3 Modify the state as follows Available = Available Request i Allocation i = Allocation i + Request i Need i = Need i Request i Only if resulting state is safe, transaction is executed. Stephan Sigg Operating Systems 57/86

58 Deadlock avoidance Example Processes: P 0, P 1, P 2, P 3, P 4 Resource types: A (10 instances); B (5 instances); C (7 instances) The system at T 0 : Allocation Max Need Available A B C A B C A B C A B C P P P P P Stephan Sigg Operating Systems 58/86

59 Deadlock avoidance Example Allocation Max Need Available A B C A B C A B C A B C P P P P P The system is in a safe state, since the sequence P 1, P 3, P 4, P 2, P 0 is possible Stephan Sigg Operating Systems 59/86

60 Deadlock avoidance Example Allocation Max Need Available A B C A B C A B C A B C P P P P P Assume the request Request 1 = (1, 0, 2) Stephan Sigg Operating Systems 60/86

61 Deadlock avoidance Example Allocation Max Need Available A B C A B C A B C A B C P P P P P First: Test Request 1 Available (1, 0, 2) (3, 3, 2) true Stephan Sigg Operating Systems 61/86

62 Deadlock avoidance Example The resulting state would be: Allocation Max Need Available A B C A B C A B C A B C P P P P P The safety algorithm determines that the sequence P 1, P 3, P 4, P 0, P 2 leads to a safe state Stephan Sigg Operating Systems 62/86

63 Deadlock avoidance Example Assume a further request Request 4 = (3, 3, 0): Allocation Max Need Available A B C A B C A B C A B C P P P P P Stephan Sigg Operating Systems 63/86

64 Deadlock avoidance Example The resulting state would be: Allocation Max Need Available A B C A B C A B C A B C P P P P P The safety algorithm determines that this state would not be safe. The allocation is not granted Stephan Sigg Operating Systems 64/86

65 Stephan Sigg Operating Systems 65/86 Deadlocks Deadlock avoidance Resources Often, algorithms for deadlock avoidance can not be applied in operating systems Processes are often not aware which resources are required during their execution Therefore, Deadlock detection and recovery strategies might be more feasible solutions Running processes Requesting processes

66 Outline Deadlocks 1 Deadlocks System model Deadlock characterisation Resource allocation graph Handling of deadlocks Deadlock prevention Deadlock avoidance Deadlock detection Recovery from deadlock Stephan Sigg Operating Systems 66/86

67 holds Deadlocks Deadlock detection Deadlock detection A system that does not inherit deadlock-prevention or -avoidance method may provide An algorithm that determines if a deadlock has occurred An algorithm to recover from the deadlock A detection and recovery scheme has additional overhead Run-time cost to maintain necessary information Execution of the detection algorithm Potential losses as a result of deadlock recovery Stephan Sigg Operating Systems 67/86

68 holds Deadlocks Deadlock detection Single instance of resource types If all resources have only one instance we can detect a deadlock again on the resource-allocation graph The algorithm searches for cycles in the graph A cycle indicates a deadlock Stephan Sigg Operating Systems 68/86

69 Deadlock detection Multiple instance of resource types When resource types with multiple instances exist, a different algorithm has to be applied: Variables: Number of processes: n Number of resource types: m Data structures required: Available[j]: Vector of length m that indicates the number of available resources of each type Allocation[i][j]: An n m matrix that defines the number of resources currently allocated Request[i][j]: An n m matrix that defines the number of resources currently requested Stephan Sigg Operating Systems 69/86

70 Deadlock detection Safetey algorithm determines if system is in unsafe state: 1 Initialise vectors: Work=Available For i=0,...,n-1: If Allocation i 0 then Finish[i]=false, else Finish[i]=true 2 Find an index i such that 1 Finish[i] == false 2 Request i Work If no such i exists, go to step 4 3 Complete the following allocations 1 Work = Work + Allocation 2 Finish[i]=true Go to step 2 4 If Finish[i] == false for some i, the system is in a deadlocked state and P i is deadlocked. The runtime of the algorithm is O ( m n 2) Stephan Sigg Operating Systems 70/86

71 Deadlock detection Multiple instance of resource types Example Processes: P 0, P 1, P 2, P 3, P 4 Resource types: A (7 instances); B (2 instances); C (6 instances) The system at T 0 : Allocation RequestMax Available A B C A B C A B C P P P P P Stephan Sigg Operating Systems 71/86

72 Deadlock detection Multiple instance of resource types Example Allocation RequestMax Available A B C A B C A B C P P P P P The state is not deadlocked: The sequence P 0, P 2, P 3, P 1, P 4 can be executed successfully Stephan Sigg Operating Systems 72/86

73 Deadlock detection Multiple instance of resource types Assume that process P 2 makes one additional request for an instance of type C: Example Allocation RequestMax Available A B C A B C A B C P P P P P Stephan Sigg Operating Systems 73/86

74 Deadlock detection Assume that process P 2 makes one additional request for an instance of type C: Example Allocation RequestMax Available A B C A B C A B C P P P P P The state is now deadlocked Number of resources reclaimed from P 0 is not sufficient A deadlock exists that contains the processes P 1, P 2, P 3, P 4 Stephan Sigg Operating Systems 74/86

75 Outline Deadlocks 1 Deadlocks System model Deadlock characterisation Resource allocation graph Handling of deadlocks Deadlock prevention Deadlock avoidance Deadlock detection Recovery from deadlock Stephan Sigg Operating Systems 75/86

76 Recovery from deadlock Detection algorithm usage The frequency by which the detection algorithm should be invoked depends on 1 The frequency by which deadlocks occur 2 The number of processes that will be affected by a deadlock The more often the algorithm is invoked, the less do we expect the impact of system performance deterioration However, this has to be balanced with the runtime-cost of the algorithm Stephan Sigg Operating Systems 76/86

77 holds holds Deadlocks Recovery from deadlock Recovery from deadlock When a deadlock is detected, several alternatives for recovery are available Inform an operator of the deadlock occurrence Try to recover 1 Process termination 2 Preemption of resources Stephan Sigg Operating Systems 77/86

78 holds holds Deadlocks Recovery from deadlock Process termination One or more processes in the circular wait are aborted Abort all deadlocked processes Breaks deadlock cycle but it is more likely, that lengthy computations need to be recomputed Abort one process at a time After each aborted process, deadlock detection invoked. This might induce considerable overhead. Stephan Sigg Operating Systems 78/86

79 holds holds Deadlocks Recovery from deadlock Process termination Problems upon process termination If the process was in the middle of updating a file, the file may then be in an incorrect state Similarly: Printer access Stephan Sigg Operating Systems 79/86

80 holds holds Deadlocks Recovery from deadlock Resource preemption Resources from processes are successively preempted until deadlock is broken Aspects to consider: Process that is impacted Rollback Starvation Stephan Sigg Operating Systems 80/86

81 holds holds Deadlocks Recovery from deadlock Resource preemption Process impacted Which resources and which processes are preempted? Minimum cost (process priority, current computation time,...) Consider number of resources a process is holding Stephan Sigg Operating Systems 81/86

82 holds holds Deadlocks Recovery from deadlock Resource preemption Rollback The process from which the resource was taken can not continue normal execution We must roll back to some safe state Simplest solution: Total rollback Otherwise all running processes must provide more information on their state Stephan Sigg Operating Systems 82/86

83 holds holds Deadlocks Recovery from deadlock Resource preemption Starvation Can we ensure that no starvation occurs? Can we guarantee that not always the resources from the same processes are preempted? Most common solution: Number of rollbacks as one cost factor Stephan Sigg Operating Systems 83/86

84 Outline Deadlocks 1 Deadlocks System model Deadlock characterisation Resource allocation graph Handling of deadlocks Deadlock prevention Deadlock avoidance Deadlock detection Recovery from deadlock Stephan Sigg Operating Systems 84/86

85 Questions, discussion, remarks Questions? Stephan Sigg Operating Systems 85/86

86 Literature Recommended literature A. Tanenbaum, Moderne Betriebssysteme, 2nd edition, Prentice Hall, A. Tanenbaum, Modern operating systems, 3rd edition, Prentice Hall, A. Silberschatz et al. Operating system concepts, Wiley, W. Stallings, Operating systems, 6th edition, Prentice Hall, Stephan Sigg Operating Systems 86/86