Deadlocks

System Model
• System consists of finite number of resources distributed among a number of
processes.
• Resources are partitioned into several types, each consisting of some number of
identical instances
CPU cycles, memory space, I/O devices – resource types
• Each resource type Ri has Wi instances.
• If a system has 2 CPUs, then the resource type CPU has 2 instances.
• Similarly, the resource type printer may have 5 instances.
• If process request an instance of resource type, the allocation of any instance of
the type will satisfy the request.
• If it will not, then the instances are not identical, and resource type classes have
not been defined properly.
Ex: A system may have 2 printers. If one printer is on ninth floor and the other is in
the basement. Then people on the ninth floor may not see both printers as
equivalent and separate resource classes may need to be defined for each printer.
 System Model
• A process must request a resource before using it and must release the resource
after using it.
• A process may request as many resources as it requires to carry out its
designated task.
• The number of resources requested may not exceed the total number of
resources available in the system.
Ex: A process can not request 3 printers if the system has 1 printer
• Each process utilizes a resource in the following sequence:
1. Request : If the request cannot be granted immediately(ex: 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(ex: the process can print on
the printer)
3. Release: The process releases the resource.
 System Model
• The request and release of resources are system calls and that are not managed
by OS, can be accomplished through wait() and signal() operations on
semaphores or acquisition and release of mutex lock.
• A set of processes is in a deadlock state, when every process in the set is waiting
for an event that can be caused only by another process in the set.
Ex:
1. Consider a system with 3 CD RW drives. Suppose each of 3 processes, hold one
of these CD RW drives. If each process now requests another drive, the three
process will be in a deadlock state. Each is waiting for the event “CD RW is
released” which can be caused only by one of the other waiting processes.
• Deadlock may also involve different resource types.
2. Consider a system with one printer and one DVD drive. Suppose that process Pi
is holding the DVD and process Pj is holding the printer. If Pi requests the printer
and Pj requests the DVD drive, a deadlock occurs.
 Deadlock Characterization
Features that characterize deadlocks:-
1. Necessary Conditions:
Deadlock can arise if four conditions hold simultaneously in a system
1. Mutual exclusion: only one process at a time can use a resource. If another
process request 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 i.e. a resource can be
released only voluntarily by the process holding it, after that process has
completed its task
4. Circular wait: there exists a set {P0, P1, …, Pn} of waiting processes 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.
 Deadlock Characterization
2.Resource allocation Graph:
• Deadlocks can be described more precisely in terms of a directed graph called
system resource allocation Graph.
• A set of vertices V and a set of edges E.
• V is partitioned into two different types of nodes:
• P = {P1, P2, …, Pn}, the set consisting of all the processes in the system
• R = {R1, R2, …, Rm}, the set consisting of all resource types in the system
request edge – A directed edge from process Pi to resource Rj is denoted by
Pi → Rj , it signifies that process Pi has requested an instance of resource type Rj
and is currently waiting for the resource. A directed edge Pi → Rj is called request
edge.
assignment edge – A directed edge from resource type Rj to process Pi is denoted
by Rj → Pi , it signifies that an instance of resource type Rj has been allocated to
process Pi. A directed edge Rj → Pi is called an assignment edge.
• Pictorially, process represented by circle, resource type as a rectangle and
instances of resource as a dots within rectangle.
 Deadlock Characterization
• Request edge only points to the rectangle whereas an assignment edge must
designates one of the dots in the rectangle.
• Process

• Resource Type with 4 instances

• Pi requests instance of Rj Pi

• Pi is holding an instance of Rj Pi
 Deadlock Characterization
• The sets P, R and E;
• P={P1,P2,P3}
• R={R1, R2, R3, R4}
• E={P1 → R1 , P2 → R3 , R1 → P2 , R2 → P2 ,
R2 → P1 , R3 → P3 }
• Resource instances:
• One instance of resource type R1
• Two instances of resource type R2
• One instance of resource type R3
• Three instance of resource type R4
• Process states:
• Process P1 is holding an instance of resource type R2 and is waiting for an
instance of resource type R1.
• Process P2 is holding an instance of resource type R1 and an instance of resource
R2 and is waiting for an instance of resource type R3.
• Process P is holding an instance of resource type R
 Deadlock Characterization
• If the graph contains no cycles, then no process in the system is deadlocked.
• If the graph contain a cycle, then deadlock may exist.
• If each resource type has exactly one instance, then cycle implies that a deadlock
has occured. Each process involved in the cycle is deadlocked. In this case, a
cycle in the graph is both necessary and sufficient condition for the existence of
deadlock.
• 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.
Ex: In the graph shown, suppose that process
P3 requests an instance of resource type
R2 . Since no resource instance is currently
available, a request edge P3 → R2 is
added to the graph.
• At this point, two minimal cycles exist in
System:
 Deadlock Characterization
1.P1 → R1 → P2 → R3 → P3 → R2 → P1
2.P2 → R3 → P3 → R2 → P2
• Process P1 , P2 , P3 are deadlocked. Process P2 is waiting for resource R3 , which is
held by process P3 . Process P3 is waiting for either process P1 or process P2 to
release resource R2
Ex: In this graph also there is a cycle.
P1 → R1 → P3 → R2 → P1
• But there is no deadlock. The process P4 may
release its instances of resource type R2.
• That resource can then be allocated to P3 ,
breaking the cycle.
Summary:
• 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
 Methods for Handling Deadlocks
We can deal with the deadlock problem in one of three ways:
1.Ensure that the system will never enter a deadlock state using :
• Deadlock prevention
• Deadlock avoidance
• Deadlock prevention provides a set of methods for ensure that at least one of the
necessary conditions cannot hold.
• Deadlock avoidance requires that the OS be given in advance additional information
concerning which resource 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.
2.Allow the system to enter a deadlock state and then recover: If a system does not
employ either a deadlock prevention or deadlock avoidance algorithm, the system
can provide an algorithm that examines the state of the system to determine
whether a deadlock has occurred and an algorithm to recover from the deadlock.
3.Ignore the problem and pretend that deadlocks never occur in the system: used
by most operating systems, including UNIX and Windows.
 Deadlock Prevention
• For a deadlock to occur, each of the four necessary conditions must hold. By
ensuring that at least one of these conditions cannot hold, we can prevent the
occurrence of a deadlock.
1. Mutual Exclusion – not required for sharable resources. Ex: read-only files- If
several processes attempt to open a read only file at the same time, they can be
granted simultaneous access to the file. A process never needs to wait for a sharable
resource. But this condition must hold for non-sharable resources. Ex: A printer
cannot be simultaneously shared by several processes.
• In general, we cannot prevent deadlocks by denying the mutual exclusion, because
some resources are intrinsically non-sharable.
2. Hold and Wait – must guarantee that whenever a process requests a resource, it
does not hold any other resources
• One protocol: Requires each process to request and be allocated all its resources
before it begins execution.
• An alternative protocol: Allow process to request resources only when the
process has none allocated to it. Before it can request any additional resources,
it must release all the resources that it is currently allocated.
 Deadlock Prevention
Ex: Consider a process that copies data from a DVD drive to a file on disk, sort the
file and prints the results to a printer.
First protocol: If all resources must be requested at the beginning of process, then
the process must initially request the DVD drive, disk file and printer. It will hold
the printer for its entire execution, even though it needs the printer only at the
end.
Second protocol: allows the process to request initially only the DVD drive and
disk file. It copies from the DVD drive to the disk and then releases both the DVD
drive and the disk file. The process must then again request the disk file and the
printer. After copying the disk file to the printer, it releases these two resources
and terminates.
• Both these protocols have two main disadvantages:
Low resource utilization: since resources may be allocated but unused for a long
period.
Starvation possible: A process that needs several resources may have to wait
indefinitely.
 Deadlock Prevention
3. No Preemption – of resources that have already been allocated. To ensure that
this condition does not hold, the following protocol can be used.
• Deadlock arises due to the fact that a process can't be stopped once it
starts(resources are released only voluntarily by the process) .
• So all the resources currently being held(preempted resources) are released
(take away from the process which is causing deadlock) and 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
4. Circular Wait – One way to ensure that this condition never holds is to decide a
total ordering of all resource types, and require that each process requests
resources in an increasing order of enumeration.
• Let R={R1, R2, …., Rm} be the set of resource types and F: R → N is one-to-one
function where N is the set of natural numbers.
 Deadlock Prevention
Ex: If the set of resource type R includes tape drives, disk drives and printers, then the
function F might be defined as F(tape drive) =1, F(disk drive)=5, F(printer)=12.
• Protocol to prevent deadlocks: Each process can request resources only in an
increasing order of enumeration. i.e process can initially request any number of
instances of a resource type say Ri . After that the process can request instances of
resource type R j if and only if F(R j) > F(R i).
Ex: A process that wants to use the tape drive and printer at the same time, must
request first the tape drive and then request the printer.
• If this protocol is used, then the circular condition cannot hold.
Proof by contradiction(assuming that a circular wait exist): Let the set of processes
involved in circular wait be P={P1,P2,…,Pn}, where Pi is waiting for a resource Ri, which
is held by process Pi+1. (Modulo arithmetic is used on the indexes, so that Pn is waiting
for a resource Rn held by P0). Then, since process Pi+1 is holding resource Ri while
requesting resource Ri+1 , we must have F(Ri)<F(Ri+1) for all i. This means that F(R0) <
F(R1) < …<F(Rn) < F(R0). By transitivity, F(R0)<F(R0) which is impossible. Therefore,
there can be no circular wait.
 Deadlock Detection
• If a system does not employ either a deadlock-prevention or deadlock avoidance
algorithm, then deadlock situation may occur. In this environment a system may
provide :
• An algorithm that examines the state of the system to determine whether a
deadlock has occurred.
• An algorithm to recover from deadlock.
Elaboration of these two requirements on systems with only a single instance of
each resource type, as well as system with several instances of each resource type.
Single Instance of Each Resource Type:
• If all the resources have only a single instance, then deadlock detection algorithm
uses a variant of the Resource-Allocation-Graph(RAG) called a wait-for graph.
• This graph obtained from resource-allocation-graph by removing the resource nodes
and collapsing appropriate edges.
• An edge from Pi to Pj in wait-for graph implies that process Pi is waiting for process
Pj to release a resource that Pi needs.
• An edge Pi → Pj exists in a wait-for graph if and only if the corresponding Resource
Allocation Graph contains two edges Pi → Rq and Rq → Pj for some resource Rq.
 Deadlock Detection
• Below figure present a resource allocation graph and the corresponding wait-
for graph.

• A deadlock exists in the system if and only if the wait-for graph contains a cycle.
• To detect deadlocks, the system needs to maintain the wait-for graph and
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 an order of n2 operations,
where n is the number of vertices in the graph
 Deadlock Detection
Several Instances of a Resource Type:
• The wait-for graph scheme is not applicable to a resource allocation scheme
with multiple instances of each resource type.
• Now a deadlock detection algorithm is applicable to such a system.
• The algorithm employs below data structures:
Available: A vector of length m indicates the number of available resources of
each type. If Available[j] = k, there are k instances of resource type Rj available.
Allocation: An n x m matrix defines the number of resources of each type
currently allocated to each process
Request: An n x m matrix indicates the current request of each process. If
Request [i][j] = k, then process Pi is requesting k more instances of resource type
Rj.
• Let X and Y be vectors of length n, then X ≤ Y if and only if X[i] ≤ Y[i] for all i = 1,
2, ..,n.
• Rows in the matrices Allocation and Request as vectors and refer to them
Allocationi and Requesti.
 Deadlock Detection Algorithm
1. Let Work and Finish be vectors of length m and n, respectively. Initialize:
(a) Work = Available
(b) For i = 1,2, …, n, if Allocationi  0, then
Finish[i] = false; otherwise, Finish[i] = true
2. Find an index i such that both:
(a)Finish[i] == false
(b)Requesti  Work
If no such i exists, go to step 4
3. Work = Work + Allocationi
Finish[i] = true
go to step 2
4. If Finish[i] == false, for some i, 1  i  n, then the system is in deadlock state.
Moreover, if Finish[i] == false, then Pi is deadlocked
Algorithm requires an order of O(m x n2) operations to detect whether the
system is in deadlocked state
 Example of Deadlock Detection Algorithm
1. Five processes P0 through P4; three resource types A (7 instances), B (2 instances),
and C (6 instances)

Snapshot at time T0:

Allocation Request Available
A B C A B C A B C

P0 0 1 0 0 0 0 0 0 0

P1 2 0 0 2 0 2

P2 3 0 3 0 0 0

P3 2 1 1 1 0 0

P4 0 0 2 0 0 2
 Example of Deadlock Detection Algorithm
In this, Work = Available = [0,0,0] and Finish = [false, false, false, false, false]
1. i=0 is selected as both Finish[0] = false and [0,0,0]  [0,0,0] ( Request0  Work )
2. Work = [0,0,0] + [0,1,0] => [0,1,0] and Finish = [true, false, false, false, false]
3. i=2 is selected as both Finish[2] = false and [0,0,0] <= [0,1,0]
4. Work = [0,1,0] + [3,0,3] => [3,1,3] and Finish = [true, false, true, false, false]
5. i=1 is selected as both Finish[1] = false and [2,0,2] <= [3,1,3]
6. Work = [3,1,3] + [2,0,0] => [5,1,3] and Finish = [true, true, true, false, false]
7. i=3 is selected as both Finish[3] = false and [1,0,0] <= [5,1,3]
8. Work = [5,1,3] + [2,1,1] => [7,2,4] and Finish = [true, true, true, true, false]
9. i=4 is selected as both Finish[4] = false and [0,0,2] <= [7,2,4]
10. Work = [7,2,4] + [0,0,2] => [7,2,6] and Finish = [true, true, true, true, true]
Sequence <P0, P2, P3, P1, P4> will result in Finish[i] = true for all i.
Since finish is a vector of all true it means there is no deadlock in this example.
 Example of Deadlock Detection Algorithm
• Suppose now process P2 requests an additional instance of type C
Request
A B C
P0 0 0 0
P1 2 0 2
P2 0 0 1
P3 1 0 0
P4 0 0 2
• The system is now deadlocked.
• The deadlock exists, consisting of processes P1, P2, P3, and P4
Example of Deadlock Detection Algorithm

O O O O O O O A B O O

P0 P1 P3 P4
P2

C O O O O O O

Resource Allocation Graph

 Example of Deadlock Detection Algorithm
Ex. 2. Consider the following snapshot of a system in which five resources A, B, C,
D and E are available. The system contains a total of 2 instances of A, 1 of
resource B, 1 of resource C, 2 resource D and 1 of resource E.

Allocation Request Available

A B C D E A B C D E A B C D E
P0 1 0 1 1 0 0 1 0 0 1 2 1 1 2 1
P1 1 1 0 0 0 0 0 1 0 1
P2 0 0 0 1 0 0 0 0 0 1
P3 0 0 0 0 0 1 0 1 0 1

i. Use the deadlock detection algorithm to determine whether the system

contains a deadlock. Which processes are involved in the deadlock?
ii. Convert this matrix representation to a resource allocation graph.
 Example of Deadlock Detection Algorithm
Ex. 3:

P4

R3
R1 R2
O O O

P1 P2 P3

R4 R5
O
O P5

i. Convert it to the matrix representation (i.e., Allocation, Request and Available)

ii. Is there a deadlock? If there is a deadlock, which processes are involved?
 Example of Deadlock Detection Algorithm
Answer: The matrix representation of the given resource allocation graph is shown
below:

Allocation Request Available

R1 R2 R3 R4 R5 R1 R2 R3 R4 R5 R1 R2 R3 R4 R5
P1 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0
P2 1 0 0 0 0 0 1 1 0 1
P3 0 0 1 0 0 0 0 0 0 1
P4 0 1 0 0 0 0 0 0 0 0
P5 0 0 0 0 1 0 0 0 1 0
 Recovery from Deadlock
Deadlock recovery involves breaking the deadlock by releasing the resources held
by the processes in the deadlock using methods such as
1. Process termination (Abort two or more processes to break the circular
wait)
2. Resource preemption (Preempt some resources from one or more of
the deadlocked processes)
1. Process Termination: To eliminate deadlocks by aborting a process, use one of
two methods. In both methods, the system reclaims all resources allocated to
the terminated processes.
i. Abort all deadlocked processes:
• This method break the deadlock cycle at great expense ; the deadlocked
processes may have to computed for a long time, and the results of these
partial computations must be discarded and probably will have to be
recomputed later.
 Recovery from Deadlock: Process Termination
ii. 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.
• Aborting a process may not be easy. If the process was in the midst of printing
data on the printer, the system must reset the printer to a correct state before
printing the next job.
• Determination of which deadlocked process should be terminated, is a policy
decision, similar to CPU scheduling decisions.
• Many factors may affect which process is chosen including:
➢ Priority of the process
➢ How long process has computed, and how much longer to completion
➢ Resources the process has used
➢ Resources process needs to complete
➢ How many processes will need to be terminated
➢ Is process interactive or batch?
 Recovery from Deadlock: Resource preemption
2. Resource preemption: To eliminate deadlocks using resource preemption,
successively preempt some resources from processes and give these resources
to other processes until the deadlock cycle broken.
• Three issues needs to be addresses, if preemption is required to deal with
deadlocks:
i. Selecting a victim: Determine which resources and which processes are
to be preempted and the order of preemption to minimize cost. Cost
factor include number of resources a deadlocked process is holding and
the amount of time the process consumed during its execution.
ii. Rollback: Determine what should be done with the process from which
resources are preempted. One simple idea is total rollback. That means
aborting the process and restarting it.
iii. Starvation: In a system, it may happen that the same process is always
picked as a victim. As a result, that process will never complete its
designated task. This situation is called Starvation and must be avoided.
One solution is that a process must be picked as a victim only a finite
number of times.