UNIT-3 DEADLOCKS Deadlocks: System Model - Deadlock Characterization - Methods for Handling Deadlocks - Deadlock Prevention. Deadlock Avoidance - Deadlock Detection - Recovery from Deadlock DEADLOCKS Definition: Deadlock is defined as a situation in which waiting processes request the resources that are held by other waiting processes. 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. SYSTEM MODEL A process must request a resource (mentioning the no. of instances of the resource required) before using it, and must release the resource after using it. Examples for resources include physical resources (printers, tape drives, memory space, and CPU) and logical resources (files, semaphores, and monitors). If a system has 2 Printer, then the resource Printer has two instances. A system may have two printers. These two printers may be defined to be same resource if no one cares which printer prints which output. However, if one printer is on the ninth floor and the other is in the basement, then people on the ninth floor may not see both printers as equivalent, each printer will be defined as a separate resource. The number of resources requested may not exceed the total number of resources available in the system. For example, a process cannot request 3 printers if the system has only 2.
A process utilizes a resource in the following sequence: 1. Request: If the request cannot be granted immediately (for example, the resource is being used by another process), then the requesting process must wait until it can acquire the resource. 2. Use: The process can operate on the resource (for example, if the resource is a printer, the process can print on the printer). 3. Release: The process releases the resource. OS uses a system table to record whether each resource is free or allocated, and, if a resource is allocated, to which process is it allocated. If a process requests a resource that is currently allocated to another process, it can be added to a queue of processes waiting for this resource. A set of processes is in a deadlock state when every process in the set is waiting for an event (acquisition and release of a resource) that can be caused only by another process in the set. Deadlock can be illustrated in 2 cases: 1. Deadlocks may also involve same resource types: Consider a system with three tape drives. Suppose each of three processes holds one of these tape drives. If each process now requests another tape drive, the three processes will be in a deadlock state. Each is waiting for the event "tape drive is released," which can be caused only by one of the other waiting processes. 2. Deadlocks may also involve different resource types: Consider a system with one printer and one tape drive. Suppose that process P 1 is holding the tape drive and process P 2 is holding the printer. If P 1 requests the printer and P 2 requests the tape drive, a deadlock occurs.
DEADLOCK CHARACTERIZATION Necessary Conditions for Deadlock A deadlock situation can arise if the following 4 conditions hold simultaneously in a system: 1. Mutual exclusion: A resource is non-sharable and that only one process at a time can use the resource. If another process requests that resource, the requesting process must be delayed until the resource has been released. 2. Hold and wait: A process must be holding at least one resource and waiting to acquire additional resources that are currently being held by other processes. 3. No preemption: Resources cannot be preempted; that is, a resource can be released only voluntarily by the process holding it, after that process has completed its task. 4. Circular wait: A set {P 0, P 1,..., P n,) of waiting processes must exist 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 is waiting for a resource that is held by P 0. Deadlocks and Resource-Allocation Graph Deadlocks can be described more precisely in terms of a directed graph called a system Resource-Allocation graph. This graph consists of a set of vertices V and a set of edges E. The set of vertices V is partitioned into two different types of nodes P = {P 1, P 2,..., P n }, the set consisting of all the active processes in the system, and R = {R 1, R 2,..., R m ), the set consisting of all resource types in the system. Request edge: A directed edge from process P i to resource type R j, denoted by P i R j, signifies that process P i requested an instance of resource type R i and is currently waiting for that resource. Assignment edge: A directed edge from resource type R i to process P i, denoted by R j P i, signifies that an instance of resource type R i has been allocated to process P i. When process Pi requests an instance of resource type Rj, a request edge is inserted in the resource-allocation graph. When this request can be fulfilled, the request edge is instantaneously transformed to an assignment edge.
When the process no longer needs access to the resource it releases the resource, and as a result the assignment edge is deleted. Different cases of Resource-Allocation graph: 1. If the graph contains no cycles, then no process in the system is deadlocked and if the graph does contain a cycle, then a deadlock may exist. 2. If each resource type has exactly one instance, then a cycle implies that a deadlock has occurred. Or otherwise, If the cycle involves only a set of resource types, each of which has only a single instance, then a deadlock has occurred. 3. If each resource type has several instances, then a cycle does not necessarily imply that a deadlock has occurred. In this case, a cycle in the graph is a necessary but not a sufficient condition for the existence of deadlock. A cycle in the graph is a necessary but not a sufficient condition for the existence of deadlock. Figure: Case 1 Figure: Case 2 Figure: Case 3
METHODS FOR HANDLING DEADLOCKS Deadlock prevention: Deadlock prevention is a set of methods for ensuring that at least one of the necessary conditions cannot hold. Deadlock avoidance: Deadlock avoidance, requires that the operating system be given in advance additional information concerning which resources a process will request and use during its lifetime. With this additional knowledge, OS can decide for each request whether or not the process should wait. To decide whether the current request can be satisfied or must be delayed, the system must consider the resources currently available, the resources currently allocated to each process, and the future requests and releases of each process. Deadlock detection and recovery: OS provides an algorithm that examines the state of the system to determine whether a deadlock has occurred, and an algorithm to recover from the deadlock Ignore deadlock: The undetected deadlock will result in the deterioration of the system performance and eventually, the system will stop functioning and will need to be restarted manually. Useful in cases where deadlocks occur infrequently (say, once per year) This method is cheaper than the costly deadlock-prevention, deadlock-avoidance, or deadlock-detection and recovery methods that must be used constantly.
DEADLOCK PREVENTION Deadlock prevention is a set of methods for ensuring that at least one of the necessary conditions cannot hold. Mutual Exclusion Sharable resources do not require mutually exclusive access and thus cannot be involved in a deadlock. Read-only files are a good example of a sharable resource. If several processes attempt to open a read-only file at the same time, they can be granted simultaneous access to the file. Hold and Wait Request and get all required resources, use and release. Example: Consider a process that copies data from a tape drive to a disk file and then prints a printer. Request all resources at the beginning of the process, use and release all. It will hold the printer for its entire execution, even though it needs the printer only at the end. Request a resource only when none is allocated i.e. use a resource, release it and then request for another resource Example: Consider a process that copies data from a tape drive to a disk file and then prints a printer. Request tape, read data and release tape Request disk, write data and release disk Request printer, print and release printer No Preemption If a process is holding some resources and requests another resource that cannot be immediately allocated to it (that is, the process must wait), then all resources currently being held are preempted.
Circular Wait A total ordering of all resource types should be imposed and each process requests resources in an increasing. Let R = {R 1, R 2,..., R n ) be the set of resource types. Assign to each resource type a unique integer number. For example, R={tape drives, disk drives, and printers}, then the function F might be defined as follows: F(tape drive) = 1, F(disk drive) = 5, F(printer) = 12. If the below 2 protocols are used, then the circular-wait condition cannot hold. Each process can request resources only in an increasing order of enumeration i.e. A process, holding resource type Ri, can request instances of resource type Rj if and only if F(Rj) > F(Ri). A process requests resource type Rj if it has released any resources Ri.
DEADLOCK AVOIDANCE Deadlock avoidance, requires that the operating system be given in advance additional information concerning which resources a process will request and use during its lifetime. With this additional knowledge, OS can decide for each request whether or not the process should wait. To decide whether the current request can be satisfied or must be delayed, the system must consider the resources currently available, the resources currently allocated to each process, and the future requests and releases of each process. Resource allocation graph algorithm (only one instance of each resource type) A claim edge P i R j indicates that process P i may request resource R j at some time in the future. This edge resembles a request edge in direction, but is represented by a dashed line. When process P i requests resource R j, the claim edge P i R j is converted to a request edge. When a resource R j is released by P i, the assignment edge R j P i is reconverted to a claim edge P i R i. before process Pi starts executing, all its claim edges must already appear in the resourceallocation graph Suppose that process P i requests resource R j. The request can be granted only if converting the request edge P i R j to an assignment edge R j P i does not result in the formation of a cycle in the resource-allocation graph. Example: R 2 if allocated to P 2 will result in cycle and therefore deadlock. Hence if P 2 requests R 2, it should not be granted.
Safe state An OS is in safe state if it can allocate resources to each and still avoid a deadlock. A sequence of processes <P 1, P 2,..., P n > is a safe sequence if, for each P i, the resources that P i can still request can be satisfied by the currently available resources plus the resources held by all the P j, with j < i. If no such sequence exists, then the system state is said to be unsafe. Example: Assume that there are 12 instances of a resource and at time T 0, below table shows the status of each resources: Process Max Allocated Need Available P 0 10 5 5 3 P 1 4 2 2 P 2 9 2 7 At time T 1, Sequence <P 1,P 0,P 2 > is safe because, P 1 will get 2 out of 3, use and release 4. This 4 plus remaining 1 will be allocated to P 0 which will use it and release 10. This 10 will be allocated to P 2. Whereas, At time T 1, sequence <P 2,P 1,P 0 > is not safe because, if P 2 is allocated 1 out of 3, and P 1 is allocated 2 out of 2, P 1 will complete and release 4. But this 4 is insufficient because P 0 needs 5 and P 2 needs 6 more. Hence, while resource allocation is done, safe state should be ensured.
Banker s algorithm Data structures available[m] : no. of instances of each m resource type available max[n][m] : max. no. of instances of resource type m required by process n allocation[n][m]: no. of instances of resource type m allocated to process n need[n][m] : no. of instances of resource type m still needed by process n n : no. of process m : no. of resource type Safety algorithm 1. Work := Available and Finisk[i] :=false for i = 1,2,..., n. 2. Find an i' such that Finish[i] =false and Need i Work. If no such i exists, go to step 4. 3. Work := Work + Allocation i and Finish[i] := true, go to step 2. 4. If Finish[i] = true for all i, then the system is in a safe state. Resource request algorithm if Request i Available Available := Available - Request i ; Allocation i := Allocation + Request; Need i := Need i - Request i ;
Example Total <A,B,C> = <10,5,7> Process Max Allocation Need Available Finish A B C A B C A B C A B C P0 7 5 3 0 1 0 7 4 3 F P1 3 2 2 2 0 0 1 2 2 F P2 9 0 2 3 0 2 6 0 0 F 3 3 2 P3 2 2 2 2 1 1 0 1 1 F P4 4 3 3 0 0 2 4 3 1 F Step 1: <P1> Process Max Allocation Need Available Finish A B C A B C A B C A B C P0 7 5 3 0 1 0 7 4 3 F P1 3 2 2 3 2 2 0 0 0 T P2 9 0 2 3 0 2 6 0 0 F 5 3 2 P3 2 2 2 2 1 1 0 1 1 F P4 4 3 3 0 0 2 4 3 1 F
Step 2: <P1,P3> Process Max Allocation Need Available Finish A B C A B C A B C A B C P0 7 5 3 0 1 0 7 4 3 F P1 3 2 2 3 2 2 0 0 0 T P2 9 0 2 3 0 2 6 0 0 F 7 4 3 P3 2 2 2 2 2 2 0 0 0 T P4 4 3 3 0 0 2 4 3 1 F Step 3: <P1,P3,P4> Process Max Allocation Need Available Finish A B C A B C A B C A B C P0 7 5 3 0 1 0 7 4 3 F P1 3 2 2 3 2 2 0 0 0 T P2 9 0 2 3 0 2 6 0 0 F 7 4 5 P3 2 2 2 2 2 2 0 0 0 T P4 4 3 3 4 3 3 0 0 0 T
Step 4: <P1,P3,P4,P2> Process Max Allocation Need Available Finish A B C A B C A B C A B C P0 7 5 3 0 1 0 7 4 3 F P1 3 2 2 3 2 2 0 0 0 T P2 9 0 2 9 0 2 0 0 0 T 10 4 7 P3 2 2 2 2 2 2 0 0 0 T P4 4 3 3 4 3 3 0 0 0 T Step 5: <P1,P3,P4,P2,P0> Process Max Allocation Need Available Finish A B C A B C A B C A B C P0 7 5 3 7 5 3 0 0 0 T P1 3 2 2 3 2 2 0 0 0 T P2 9 0 2 9 0 2 0 0 0 T 10 5 7 P3 2 2 2 2 2 2 0 0 0 T P4 4 3 3 4 3 3 0 0 0 T Safe sequence = <P1,P3,P4,P2,P0>
DEADLOCK DETECTION Single Instance of Each Resource Type (all resources have only a single instance) Wait-for graph Remove the nodes of resource type and collapsing the appropriate edges. An edge from P i to P j in a wait-for graph implies that process P i is waiting for process P j to release a resource that P i needs. A deadlock exists in the system if and only if the wait-for graph contains a cycle. Several Instances of a Resource Type (all resources have more than one instances) Safety algorithm 1. Work := Available and Finisk[i] :=false for i = 1,2,..., n. 2. Find an i' such that Finish[i] =false and Need i Work. If no such i exists, go to step 4. 3. Work := Work + Allocation i and Finish[i] := true, go to step 2. 4. If Finish[i] = true for all i, then the system is in a safe state.
DEADLOCK RECOVERY Process Termination Abort all deadlocked processes Break the deadlock cycle, but at a great expense Processes may have computed for a long time but the results of these partial computations must be discarded and probably recomputed later. Abort one process at a time until the deadlock cycle is eliminated This method incurs considerable overhead, since, after each process is aborted, a deadlock-detection algorithm must be invoked to determine whether any processes are still deadlocked. Determination of which process (or processes) should be terminated: What the priority of the process is How long the process has computed, and how much longer the process will compute before completing its designated task How many and what type of resources the process has used (for example, whether the resources are simple to preempt) How many more resources the process needs in order to complete How many processes will need to be terminated Whether the process is interactive or batch Resource Preemption Select a victim process Roll back the process to some safe state, and later restart it from that state. Ensure that starvation will not occur. Reference A. Silberschatz, P.B. Galvin & G. Gagne, Operating system concepts, Sixth Edition John Wiley, 2005.