ITEC 202 Operating Systems EASTERN MEDITERRANEAN UNIVERSITY SCHOOL OF COMPUTING AND TECHNOLOGY DEADLOCK ITEC 202 Operating Systems

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 to waiting state.

Deadlock It may happen that waiting processes will never again change state, because the resources they have requested are held by other waiting processes. This situation is called deadlock.

Categories of resources Reusable resources Consumable resources

Reusable resources A reusable resource is one that can be used by only one process at a time These resources are released after used for reuse by other processes Processor Memory I/O Devices

Example of Deadlock (request for main memory) Space is available for allocation of 200K bytes, and the following sequence of events occur P1 … Request 80 Kbytes; Request 60 Kbytes; P2 Request 70 Kbytes; After the first request of P1 and P2 only 50K bytes are available. Deadlock occurs if both processes progress to their second request

Example of Deadlock Deadlock Occurs 200 K 120 K 50 K Available Memory : 200 K 120 K 50 K Process 1 Process 2 Request 70 Kbytes Request 80 Kbytes  Request 80 Kbytes Request 70 Kbytes  Request 60 Kbytes Request 80 Kbytes Deadlock Occurs

Is it possible to avoid Deadlock? Available Memory : 200 K 200 K 60 K Process 1 Process 2 Request 80 Kbytes  Request 80 Kbytes Request 70 Kbytes Request 80 Kbytes Request 60 Kbytes  Request 60 Kbytes

Consumable resources A consumable resource is one that can be created and destroyed. Typically, there is no limit on the number of consumable resources. Once a consumable resource is used (acquired) by the process, it is no longer available for others. Interrupts Messages signals

Resource allocation graphs Within a resource node, a dot is shown for each instance of that resource A graph edge directed form a process to a resource indicates a resource that has been requested by the process but not yet granted A graph edge directed form a reusable resource node dot to a process indicates a request that has been granted; that is, the process has been assigned one unit of that resource.

Circular Wait An example deadlock. There is only one unit each of resources Ra and Rb. Process P1 holds Rb and requests Ra, while P2 holds Ra but requests Rb.

Multiple unit of each resources No deadlock Has the same topology as circular wait, but there is no deadlock because multiple units of each resource are available

Multiple unit of each resources No deadlock

Another deadlock situation In this case, we do not have a simple situation which two processes each have one resource the other needs. Rather, in this case, there is a circular chain of processes and resources that result in deadlock.

Resource-Allocation Graph, cont. 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

Is there any deadlock in the following situation?

Both P2 and P4 have all of their requests so they can run to completion.

When P2 and P4 end, one unit of R1 and R2 are free and can be assigned to P1 and P3.

Hence there is no deadlock in this situation. Since both P1 and P3 have all of their requests, they can now run to completion too. Hence there is no deadlock in this situation.

Example: P is a set of processes. R is a set of resources. E is a set of request or assignment edges. The sets P, R, and E are as follows: P = {P1, P2, P3}, R = {R1,R2,R3} E = {P1R1, P2R3, P3R2, R1P2, R2P2, R2P1, R3P3} R1 has one instance. R2 has two instances. R3 has one instance. (a) Draw the resource-allocation graph. (b) Is there any deadlock in this situation? Briefly Explain.

(a) Draw the resource-allocation graph. P = {P1, P2, P3}, R = {R1,R2,R3} E = {P1R1, P2R3, P3R2, R1P2, R2P2, R2P1, R3P3}

(a) Draw the resource-allocation graph. P = {P1, P2, P3}, R = {R1,R2,R3} E = {P1R1, P2R3, P3R2, R1P2, R2P2, R2P1, R3P3}

(a) Draw the resource-allocation graph. P = {P1, P2, P3}, R = {R1,R2,R3} E = {P1R1, P2R3, P3R2, R1P2, R2P2, R2P1, R3P3}

(b) Is there any deadlock in this situation? Consider the resource-allocation graph. One cycle exist in the system. P1  R1  P2  R3  P3  R2  P1 P1, P2, and P3 are deadlocked

Conditions for deadlock Mutual exclusion Hold and wait No preemption Circular wait All four conditions listed above MUST hold for a deadlock to occur

Conditions for deadlock Mutual exclusion Only one process may use a resource at a time. No process may access a resource unit that has been allocated to another process. Resources cannot be shared

Conditions for deadlock Hold and wait A process may hold allocated resources while awaiting assignment of other resources. A process is both holding a resource and waiting for another resource to become free

Conditions for deadlock No preemption No resource can be forcibly removed from a process holding it. Once a process (thread) gets a resource, it cannot be taken away

Conditions for deadlock Circular wait A closed chain of processes exists, such that each process holds at least one resource needed by the next process in the chain There is a cycle in the graph of who has what and who wants what…

Methods for Handling Deadlocks Deadlock prevention Deadlock avoidance Deadlock detection and recovery Ignore

Methods for Handling Deadlocks Deadlock prevention deadlock can be prevented by removing one deadlock condition design a system in such a way that the possibility of deadlock is excluded

Methods for Handling Deadlocks Deadlock avoidance allows the three necessary conditions, but assures that deadlock point is never reached reject resource requests that might lead to deadlock

Methods for Handling Deadlocks Deadlock detection and recovery detect the deadlock figure out when deadlock has occurred and “deal with it”

Methods for Handling Deadlocks Ignore problem and reboot when necessary… used far too often in practice

Prevention occurrence of a deadlock The strategy of deadlock prevention is to design a system in such a way that the possibility of deadlock is excluded. At least one of the necessary four deadlock conditions should be prevented.

Prevention occurrence of a deadlock Mutual Exclusion: There is no possibility to disallow this condition, as resources needs sharing and mutual exclusion has to be supported by the operating system.

Prevention occurrence of a deadlock Hold and Wait: To prevent this condition, a process should allocate all resources that it needs before starting. Several possibilities to disallow this condition… Never require more than one resource at a time Reject any request that might lead to deadlock Require all resources to be acquired at once Require current resources to be freed and reacquired if need more

Prevention occurrence of a deadlock Problems with avoiding Hold and Wait condition: block the process until all requests can be granted simultaneously resources may be held up for a long time waiting for all its requests resources allocated to a process may remain unused for a long time. These resources could be used by other processes

Prevention occurrence of a deadlock No preemption: if a process is denied a further request, the process must release the original resources if a process requests a resource that is currently held by another process, OS may preempt the second process and require it to release its resources practical only when the state can be easily saved and restored later, such as the processor

Prevention occurrence of a deadlock Circular wait prevented using linear ordering for resources may deny resources unnecessarily

Deadlock Avoidance A decision is made dynamically whether the current resource allocation request will, if granted, potentially lead to a deadlock Requires knowledge of future process request

Two Approaches to Deadlock Avoidance Do not start a process if its demands might lead to deadlock Do not grant an incremental resource request to a process if this allocation might lead to deadlock

Process initiation denial R Resource vector, total amount of each resource in the system V Available resources vector, total amount of resources not allocated to any process C Resource claim matrix, represents requirements of the processes for each resources A Resource allocation matrix, represents current allocations of processes to resources

Process initiation denial Q Request matrix Needs matrix Request matrix = Claim matrix – Allocation matrix Q=C-A

Resource allocation denial (banker’s algorithm) Referred to as the banker’s algorithm State of the system is the current allocation of resources to process Safe state is one in which there is at least one order in which all the processes can run to completion without resulting in deadlock Unsafe state is a state that is not safe

Determination of safe state The question: is this safe state? That is, do we have a state which there is at least one order in which all the processes can be run to completion without resulting in a deadlock? 1 6 2 3 4 Initial State

Determination of a Safe State P2 Runs to Completion by assigning one unit of R3 to process P2, P2 has its maximum required resources allocated and can run to completion. 1 6 3 2 4

Determination of a Safe State P2 Runs to Completion When P2 competes, its resources can be returned to the pool of available resources. 1 2 3 4 6 0 0 0

Determination of a Safe State P1 Runs to Completion 2 1 3 4 7 0 0 0 0 0 0

Determination of a Safe State P3 Runs to Completion 2 4 9 3 0 0 0 0 0 0 0 0 0

Determination of a Safe State P4 Runs to Completion 9 3 6 0 0 0 0 0 0 0 0 0 0 0 0 Processes can complete in the order P2, P1, P3, P4

EX: Suppose that P2 makes a request for one additional unit of R1 and one additional unit of R3. 1 5 2 3 4

Safe Processes can complete in the order P2, P1, P3, P4 6 2 3 4 If we assume that the request is granted, then the resulting state is the initial state given in the previous example. We have already seen that this is a safe state; therefore it is safe to grant the request.

Determination of unsafe state Suppose that P1 makes the request for one additional unit each of R1 and R3 Initial state 1 5 2 3 4

Determination of unsafe state assume that the request is granted Is this a safe state? NO unsafe state 2 1 5 3 4

Deadlock detection Deadlock prevention strategies limits access to resources imposes restrictions on process Deadlock detection strategies do not limit resource access or restrict process actions requested resources are granted to processes whenever possible

Deadlock recovery Once a deadlock has been detected, some strategy is needed for recovery. The followings are possible approaches: Abort all deadlocked processes. This is not the most common strategy but quite effective. Back up each deadlocked process to some previously defined checkpoint, and restart all processes. The potential risk in this approach is that original deadlock may occur again.

Deadlock recovery Successively abort the deadlocked processes until deadlocked is resolved based on minimum cost criterion. Successively preempt (block) resources until deadlock is resolved should be based on minimization of some cost function.

Following techniques can be used for cost minimizing criteria That is choose the process with the: Least amount of time consumed by the process so far. Least amount of output produced so far. Most estimated time remaining (not easy to determine). Least total resources allocated so far. Lowest priority.

Exercise Is this a safe state or not? P1 3 2 1 P2 P3 4 Claim matrix C Allocation matrix A R1 R2 R3 2 1 Available vector V

Is this a safe state or not? P1 1 2 P2 P3 3 C-A (Request matrix, Q) R1 R2 R3 P1 3 2 1 P2 P3 4 Claim matrix C Allocation matrix A R1 R2 R3 2 1 Available vector V Unsafe State

Exercise A system that use Banker’s algorithm for deadlock avoidance has five processes and four types of resources. There are multiple resources of each type. Is the following state safe or not? If it is, show how the processes can complete. If not, show how they deadlock.

Solution: The first step is the calculation of Needs (Request) matrix, that is Q=C-A.

2 2 0 1 Only P5 can run with these available resources, so P5 runs to completion then: 3 2 2 1

Then P3 runs to completion then: 3 2 2 1 Then P3 runs to completion then: 3 3 2 2

Then P4 runs to completion then: 3 3 2 2 Then P4 runs to completion then: 4 3 2 4

Then P1 runs to completion then: 4 3 2 4 Then P1 runs to completion then: 5 4 3 4

Then P2 runs to completion then: 5 4 3 4 Then P2 runs to completion then: 5 4 3 5

Solution: So, the given state is a safe state Solution: So, the given state is a safe state. The safe order which the processes can run is P5, P3, P4, P1 and P2

Summary In summary, a deadlock is when a process has some resource and is waiting to acquire another resource, while that resource is being held by some process that is waiting to acquire the resource that is being held by the original process. We can handle deadlocks in three major ways: We can prevent them, Handle them when we detect them, or simply ignore the whole deadlock issue altogether.

Summary A deadlock needs four conditions to occur Mutual Exclusion 2 processes cannot use a resource at the same time Hold and Wait process holds a resource and requests another No-Preemption of resources the system doesn't take away resources from waiting processes - processes release resources voluntarily after they are finished using them Circular Waiting there must exist a waiting chain such that processes are waiting for other processes that are waiting for the original processes to release some resource

Summary Four techniques for handling deadlock Prevention: Design rules so one condition cannot occur Avoidance: Dynamically deny “unsafe” requests Detection and recovery: Let it happen, notice it, and fix it Ignore: Do nothing, hope it does not happen, reboot often

sct.emu.edu.tr/itec202 Ahmet Rizaner Operating Systems Lecture Notes 5 April 2009