Deadlock

Examples You can't get a job without experience; you can't get experience without a job. 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 P 1 and P 2 each hold one disk drive and each needs another one Example semaphores A and B, initialized to 1 P 0 P 1 wait (A);wait(B) wait (B);wait(A)

Deadlock In a multiprogramming environment, several processes may compete for a finite number of resources. A process requests resources; if the resources are not available at that time, the process enters a wait state. Waiting processes may never again change state, because the resources they have requested are held by other waiting processes. This situation is called a deadlock.

Resource types R 1, R 2,..., R m CPU cycles, memory space, I/O devices Each resource type R i has W i instances.

Under the normal mode of operation, a process may utilize a resource in only the following sequence: 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. Use: The process can operate on the resource (for example, if the resource is a printer, the process can print on the printer). Release: The process releases the resource.

Deadlock Characteristics NECESSARY CONDITIONS All of these four must happen simultaneously for a deadlock to occur: Mutual exclusion: At least one resource must be held in a nonsharable mode; that is, 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. 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. 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. Circular wait: A set {P0, P1,..., Pn) of waiting processes must exist such that P0 is waiting for a resource that is held by P1, P1 is waiting for a resource that is held by P2,..., Pn-1 is waiting for a resource that is held by Pn and Pn is waiting for a resource that is held by P0.

7 DEADLOCKS A visual ( mathematical ) way to determine if a deadlock has, or may occur. G = ( V, E ) The graph contains nodes and edges. V Nodes consist of processes = { P1, P2, P3,...} and resource types { R1, R2,...} E Edges are ( Pi, Rj ) or ( Ri, Pj ) An arrow from the process to resource indicates the process is requesting the resource. An arrow from resource to process shows an instance of the resource has been allocated to the process. Process is a circle, resource type is square; dots represent number of instances of resource in type. Request points to square, assignment comes from dot. RESOURCE ALLOCATION GRAPH PiPi RjRj PiPi RjRj PiPi

8 DEADLOCKS A visual ( mathematical ) way to determine if a deadlock has, or may occur. G = ( V, E ) The graph contains nodes V and edges E. V is partitioned into two types: – 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 resource types in the system request edge – directed edge P i  R j assignment edge – directed edge R j  P i An arrow from the process to resource indicates the process is requesting the resource. An arrow from resource to process shows an instance of the resource has been allocated to the process. Process is a circle, resource type is square; dots represent number of instances of resource in type. Request points to square, assignment comes from dot. RESOURCE ALLOCATION GRAPH PiPi RjRj PiPi RjRj PiPi

Resource-Allocation Graph Process Resource Type with 4 instances P i requests instance of R j P i is holding an instance of R j PiPi PiPi RjRj RjRj

7: Deadlocks10 If the graph contains no cycles, then no process is deadlocked. If there is a cycle, then: a) If resource types have multiple instances, then deadlock MAY exist. b) If each resource type has 1 instance, then deadlock has occurred. DEADLOCKS RESOURCE ALLOCATION GRAPH Resource allocation graph P2 Requests P3 R3 Assigned to P3

7: Deadlocks11 DEADLOCKS RESOURCE ALLOCATION GRAPH Resource allocation graph with a deadlock. Resource allocation graph with a cycle but no deadlock.

Methods for handling deadlock We can deal with the deadlock problem in one of three ways: We can use a protocol to prevent or avoid deadlocks, ensuring that the system will never enter a deadlock state. We can allow the system to enter a deadlock state, detect it, and recover. We can ignore the problem overall, and pretend that deadlocks never occur in the system. This solution is used by most operating systems, including UNIX.

To ensure that deadlocks never occur, the system can use either a deadlock prevention or a deadlock-avoidance scheme. Deadlock prevention is a set of methods for ensuring that at least one of the necessary conditions cannot hold. These methods prevent deadlocks by constraining how requests for resources can be made.

14 Mutual exclusion: 1.The mutual-exclusion condition must hold for nonsharable resources. For example, a printer cannot be simultaneously shared by several processes. 2.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. In general, it cannot prevent deadlocks by denying the mutual-exclusion condition because Some resources are intrinsically nonsharable. Hold and wait: 1.To ensure that the hold-and-wait condition never occurs in the system, we must guarantee that, whenever a process requests a resource, it does not hold any other resources. One protocol that can be used requires each process to request and be allocated all its resources before it begins execution. (Collect all resources before execution.) An alternative protocol allows a process to request resources only when the process has none. A process may request some resources and use them. Before it can request any additional resources, however, it must release all the resources that it is currently allocated.( Utilization is low, starvation possible.) Deadlock Prevention

15 No preemption: The third necessary condition is that there be no preemption of resources that have already been allocated. To ensure that this condition does not hold, we can use the following protocol. If a process requests some resources, we first check whether they are available. If they are, we allocate them. If they are not available, we check whether they are allocated to some other process that is waiting for additional resources. If so, we preempt the desired resources from the waiting process and allocate them to the requesting process. If the resources are not either available or held by a waiting process, the requesting process must wait. Circular wait: One way to ensure that this condition never holds is to impose a total ordering of all resource types, and to require that each process requests resources in an increasing order of enumeration. (Number resources and only request in ascending order.) EACH of these prevention techniques may cause a decrease in utilization and/or resources. For this reason, prevention isn't necessarily the best technique. Prevention is generally the easiest to implement. Deadlock Prevention

Deadlock Avoidance Avoiding deadlocks is to require additional information about how resources are to be requested. Each request requires that the system consider the resources currently available, the resources currently allocated to each process, and the future requests and releases of each process, to decide whether the current request can be satisfied or must wait to avoid a possible future deadlock.

Deadlock Avoidance Requires that the system has some additional a priori information available (possible solution) 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

Safe State A state is safe if the system can allocate resources to each process (up to its maximum) in some order and still avoid a deadlock. A system is in a safe state only if there exists a safe sequence. A sequence of processes is a safe sequence for the current allocation state if, for each Pi, the resources that Pi can still request can be satisfied by the currently available resources plus the resources held by all the Pj, with j < i. In this situation, if – If P i resource needs are not immediately available, then P i can wait until all P j 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

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.

Safe, Unsafe, Deadlock State

Avoidance algorithms Single instance of a resource type – Use a resource-allocation graph Multiple instances of a resource type – Use the banker’s algorithm

Resource-Allocation Graph Scheme In resource allocation graph, normally request edge and assignment edge is used. In addition to the request and assignment edges, introduce a new type of edge, called a claim edge. A claim edge Pi  Rj indicates that process Pi may request resource Rj at some time in the future. It is represented by a dashed line. When process Pi requests resource Rj, the claim edge Pi  Rj is converted to a request edge. Similarly, when a resource Rj is released by Pi, the assignment edge Rj  Pi is reconverted to a claim edge Pi  Rj. We note that the resources must be claimed a priori in the system. That is, before process Pi starts executing, all its claim edges must already appear in the resource- allocation graph. Suppose that process Pi requests resource Rj. The request can be granted only if converting the request edge Pi  Rj to an assignment edge Rj  Pi does not result in the formation of a cycle in the resource-allocation graph. Note that we check for safety by using a cycle-detection algorithm. An algorithm for detecting a cycle in this graph requires an order of n2 operations, where n is the number of processes in the system.

Resource-Allocation Graph Claim edge Assignment edge Request edge

Safe states in Resource-Allocation Graph

Unsafe State In Resource-Allocation Graph

Banker’s Algorithm Applicable for multiple instances of each resource type. The name was chosen because this algorithm could be used in a banking system to ensure that the bank never allocates its available cash such that it can no longer satisfy the needs of all its customers. When a new process enters the system, it must declare the maximum number of instances of each resource type that it may need. This number may not exceed the total number of resources in the system. When a user requests a set of resources, the system must determine whether the allocation of these resources will leave the system in a safe state. If it will, the resources are allocated; otherwise, the process must wait until some other process releases enough resources.

Data Structures for the Banker’s Algorithm Let n = number of processes, and m = number of resources types. Available: Vector of length m indicates the number of available resources of each type. If Available [j] = k, there are k instances of resource type R j available Max: n x m matrix define maximum demand of each process. If Max [i,j] = k, then process P i may request at most k instances of resource type R j Allocation: n x m matrix define number of resources of each type currently allocated to each process. If Allocation[i,j] = k then P i is currently allocated k instances of resource type R j Need: n x m matrix indicates the remaining reource need of each process. If Need[i,j] = k, then P i may need k more instances of resource type R j to complete its task Need [i,j] = Max[i,j] – Allocation [i,j]

Safety Algorithm 1.Let Work and Finish be vectors of length m and n, respectively. Initialize: Work = Available Finish [i] = false for i = 0, 1, …, n- 1 2.Find an i such that both: (a) Finish [i] = false (b) Need i  Work If no such i exists, go to step 4 3. Work = Work + Allocation i 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 for Process P i Request i = request vector for process P i. If Request i [j] = k then process P i wants k instances of resource type R j. When a request for resources is made by process pi, the following action are taken: 1.If Request i  Need i go to step 2. Otherwise, raise error condition, since process has exceeded its maximum claim. 2.If Request i  Available, go to step 3. Otherwise P i must wait, since resources are not available. 3.Have the system pretend to allocate requested resources to P i by modifying the state as follows: Available = Available – Request; Allocation i = Allocation i + Request i ; Need i = Need i – Request i ; l If safe  the resources are allocated to Pi l If unsafe  Pi must wait, and the old resource-allocation state is restored

Example of Banker’s Algorithm 5 processes P 0 through P 4 ; 3 resource types: A (10 instances), B (5instances), and C (7 instances) Snapshot at time T 0 : Allocation MaxAvailable A B C A B C A B C P P P P P

Example (Cont.) The content of the matrix Need is defined to be Max – Allocation Need A B C P P P P P The system is in a safe state since the sequence satisfies safety criteria

Example: P 1 Request (1,0,2) Check that Request  Available (that is, (1,0,2)  (3,3,2)  true AllocationNeedAvailable A B CA B CA B C P P P P P Executing safety algorithm shows that sequence satisfies safety requirement Can request for (3,3,0) by P 4 be granted? Can request for (0,2,0) by P 0 be granted?

Deadlock Detection Single Instance of Each Resource Type Wait for graph Several Instances of a Resource Type

Resource-Allocation Graph and Wait-for Graph Resource-Allocation GraphCorresponding wait-for graph

Recovery from Deadlock Process Termination – Abort all deadlocked processes – Abort one process at a time until the deadlock cycle is eliminated Resource Preemption