Lecture Notes On

Deadlock

Operating System

Saroj Kanta Misra

Assistant Proffessor

Department of Information & Technology

Gandhi Institute of Engineering & Technology
Gunupur-765 022, Odisha, India

Contents
List of Figures

1
1
2
3
3
4
4
5
6
8
8
9

Introduction to Deadlock
1.0.1 Necessary Conditions for Deadlock .
1.0.2 Resource-Allocation Graph . . . . .
1.1 Methods for Handling Deadlock . . . . . . .
1.2 Deadlock Prevention . . . . . . . . . . . . .
1.3 Deadlock Avoidance . . . . . . . . . . . . .
1.3.1 Safe State . . . . . . . . . . . . . . .
1.3.2 Resource Allocation Graph Algorithm
1.3.3 Bankers Algorithm . . . . . . . . .
1.4 Deadlock Detection and Recovery . . . . . .
1.4.1 Deadlock Detection . . . . . . . . . .
1.4.2 Deadlock Recovery . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

Chapter 1
Introduction to 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. 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.

Defination: A set of processes is said to be in deadlock, when every process in the set
waits for an event that can only be caused by another process in the set.

A process must request a resource before using it, and must release the resource after
using it. Under the normal mode of operation, a process may utilize a resource in only the
following sequence:
1. Request: If the request cannot be granted immediately, then the requesting process
must wait until it can acquire the resource.
2. Use: The process can operate on the resource.
3. Release: The process releases the resource.

1.0.1

Necessary Conditions for Deadlock

A deadlock situation can arise if the following four conditions hold simultaneously
in a system:
Mutual exclusion: At least one resource must be held in a non-sharable 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.
1

 Hold and wait : There must exist a process that is holding at least one resource
and is 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: There must exist 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 , ..., Pn1 is waiting for a resource that is held by Pn , and Pn is
waiting for a resource that is held by P0 .

1.0.2

Resource-Allocation Graph

Deadlocks can be described more precisely in terms of a directed graph called a system resource-allocation graph. The set of vertices V is partitioned into two different
types of nodes P = {P1 , P2 , ....Pn } the set consisting of all the active processes in the
system; and R = {R1 , R2 , .., Rm}, the set consisting of all resource types in the system.
Request Edge: A directed edge from process Pi to resource type R j is denoted by
Pi -> R j , it signifies that process Pi requested an instance of resource type R j and is
currently waiting for that resource.
Assignment Edge: A directed edge from resource type R j to process Pi is denoted
by R j -> Pi it signifies that an instance of resource type Rj has been allocated to
process Pi.

Figure 1.1: Resource Allocation Graph

1.1. METHODS FOR HANDLING DEADLOCK

If the graph contains no cycles, then no process in the system is deadlocked.,on the
other hand, if the graph contains the cycle, then a deadlock may exist.
If each resource type has several instances, then a cycle doesnt implies that a deadlock has occurred.
If each resource type has several instance, then a cycle does not necessarily imply
that a deadlock incurred. In this case, a cycle in the graph is a necessary but not a
sufficient condition for the existence of deadlock.

1.1

Methods for Handling Deadlock

1. Deadlock prevention
2. Deadlock Avoidance
3. Deadlock Detection and Recovery
Deadlock Prevention and Avoidance methods ensures that the system never enter to a
deadlock state, by allocating the resources in such a way that deadlock never occurs. In
deadlock Detection and recovery, resources are allocated to the requesting processes if the
resource is free, and periodically it will check if there is a deadlock in the system and if
there is a deadlock then recover the system from deadlock.
The difference between deadlock prevention and avoidance is, The deadlock prevention
provides a set of methods for ensuring that at least one of the necessary condition of deadlock cannot hold. (by putting restriction on the processes in the way they can request for
a resource). In deadlock avoidance put no restriction on the way the processes request a
resource, but after a request is made the system has to decide whether the request is granted
or the processes has to wait.

1.2

Deadlock Prevention

For a deadlock to occur, each of the four necessary-conditions must hold. By ensuring that
at least on one these conditions cannot hold, we can prevent the occurrence of a deadlock.
Mutual Exclusion
The mutual-exclusion condition must hold for non-sharable resources. For example,
a printer cannot be simultaneously shared by several processes. Sharable resources,
on the other hand, do not require mutually exclusive access, and thus cannot be involved in a deadlock.
Hold and Wait
To ensure that the Hold and Wait never occur in the system we may fallow two approaches:
3

1.3. DEADLOCK AVOIDANCE

1. Each process must request and be allocated all its resources before it begins execution.
2. An alternative protocol allows a process to request resources only when the process has none. A process which is holding some resources can request any additional
resources, however it must release all the resources that it is currently allocated.
No Preemption
If a process that is holding some resources requests another resource that cannot be
immediately allocated to it, then all resources currently being held are preempted.
That is this resources are implicitly released. The preempted resources 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.
Circular Wait Circular-wait 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. Let R = R1, R2, ..., Rn be the set of resource types. We
assign to each resource type a unique integer number, which allows us to compare two
resources and to determine whether one precedes another in our ordering. Formally,
we define a one-to-one function F: R _ N, where N is the set of natural numbers.

1.3

Deadlock Avoidance

An alternative method of Deadlock Prevention is to require additional information about

how resources are to be requested. With the knowledge of the complete sequence of requests and releases for each process we can decide for each request whether or not the
process should wait.
A deadlock-avoidance algorithm dynamically examines the resource-allocation state
to ensure that there can never be a circular wait condition. The resource allocation state is
defined by the number of available and allocated resources,and the maximum demands of
the processes

1.3.1

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. More formally, a system is in a safe state only if
there exists a safe sequence. A sequence of processes <P1, P2, .. Pn> is a safe sequence
for the current allocation state if, for each Pi the resources that Pj 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 the resources that process Pi needs are not immediately available,
then Pi can wait until all Pj have finished. When they have finished, Pi can obtain all of its
needed resources, complete its designated task return its allocated resources, and terminate.
When Pi terminates,Pi + 1 can obtain its needed resources, and so on.
4

1.3. DEADLOCK AVOIDANCE

Note: Single instance of a resource type Use a resource-allocation graph. Multiple

instances of a resource type Use the banker?s algorithm.

1.3.2

Resource Allocation Graph Algorithm

1. If we have a resource-allocation graph with only one instance of each resource

type,then a variant of resource-allocation graph can be used for deadlock avoidance.
2. In addition to request and allocation edge, a new edge called claim edge can be added
in the resource-allocation graph.
3. A claim Edge Pi -> R j indicate that process Pi may request resource R j at some time
in near future. A claim edge is represented by dashed line in the resource-allocation
graph.
4. When process Pi requests resource R j , the claim edge Pi ?> R j is converted to a
request edge. Similarly, when a resource R j is released by Pi , the assignment edge R j
-> Pi is reconverted to a claim edge Pi -> R j .
5. Resources required by each process must be claimed a priori in the system. That
is, before process p starts executing, all its claim edges must already appear in the
resource-allocation graph.
6. Suppose that process Pi requests resource R j . The request can be granted only if
converting the request edge Pi -> R j to an assignment edge R j ?> Pi does not result
in the formation of a cycle in the resource-allocation graph.
7. If no cycle exists, then the allocation of the resource will leave the system in a safe
state. If a cycle is found, then the allocation will put the system in an unsafe state.
Therefore, process Pi will have to wait for its requests to be satisfied.

Figure 1.2: Resource Allocation Graph for deadlock avoidance

8. For example, consider the resource-allocation graph of Figure 1.2. Suppose that P2
requests R2 . Although R2 is currently free, we cannot allocate it to P2 , since this
action will create a cycle in the graph (Fig: 1.3). A cycle indicates that the system is
in an unsafe state
5

1.3. DEADLOCK AVOIDANCE

Figure 1.3: An unsafe state in Resource Allocation Graph

1.3.3

Bankers Algorithm

The bankers 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.
Background: 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.
Several data structures must be maintained to implement the bankers algorithm. Let n
be the number of processes in the system and m be the number of resource types. We need
the following data structures:
Available A vector of length m indicates the number of available resources of each
type. If Availab!c[f] equals k, there are k instances of resource type Ri available.
Max An n x m matrix defines the maximum demand of each process. If Max[i][j]
equals k, then process P may request at most k instances of resource type Rj.
Allocation An n x in matrix defines the number of resources of each type currently
allocated to each process. If Allocation[i][j] equals k, then process Pi is currently
allocated k instances of resource type Rj.
Need An n x m matrix indicates the remaining resource need of each process. If
Need[i][j] equals k, then process P,- may need k more instances of resource type Rto complete its task. Note that Need[i][j] equals Max[i][j] - Allocntion[i][j].

Bankers Algorithm Example:

consider a system with five processes P0 through P4 and three resource types A, B, and C.
Resource type A has seven instances, resource type B has two instances, and resource type
6

1.3. DEADLOCK AVOIDANCE

Algorithm 1.1 Safety Algorithm

Safety algorithm is used for finding out whether or not a system is in a safe state. This
algorithm can be described, as follows:
1: Let Work and Finish be vectors of length m and n, respectively. Initialize:
Work = Available
Finish [i] = false for i = 0, 1, 2, ... , n- 1
2: Find and i such that both:
(a) Finish [i] = false
(b) Needi 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] == true for all i, then the system is in a safe state
Algorithm 1.2 Resource-Request Algorithm
Resource-request algorithm determines if requests can be safely granted.
Let Requesti be the request vector for process Pi If Requesti [ j] == k, then process Pi wants
k instances of resource type R j . When a request for resources is made by process Pi , the
following actions are taken:
1: if Requesti Needi , go to step 2. Otherwise, raise an error condition, since the process
has exceeded its maximum claim.
2: If Requesti Available, go to step 3. Otherwise, Pi must wait, since the resources are
not available.
3: Have the system pretend to have allocated the requested resources to process Pi by
modifying the state as follows:
Available = Available - Requesti
Allocationi = Allocationi +Requesti
Needi = Needi - Requesti ;
If the resulting resource-allocation state is safe, the transaction is completed, and process P; is allocated its resources. However, if the new state is unsafe, then P, must wait
for Request;, and the old resource-allocation state is restored.
C has six instances. Suppose that, at time To, we have the following resource-allocation
state:

1.4. DEADLOCK DETECTION AND RECOVERY

1. Find the Need matrix.

2. Find out if the system is in safe state? If so, what is the safe sequence

1.4
1.4.1

Deadlock Detection and Recovery

Deadlock Detection

If a system does not employ either a deadlock-prevention or a deadlock avoidance algorithm, then a deadlock situation may occur. In this environment, the system must provide:
An algorithm that examines the state of the system to determine whether a deadlock
has occurred.
An algorithm to recover from the deadlock.
Single Instance of Each Resource Type

Figure 1.4: Resource Allocation Graph with corresponding Wait for Graph

If all resources have only a single instance, then we can define a deadlock detection
algorithm that uses a variant of the resource-allocation graph, called a wait-for graph.
We obtain this graph from the resource-allocation graph by removing the nodes of
type resource and collapsing the appropriate edges.
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.

1.4. DEADLOCK DETECTION AND RECOVERY

Several Instances of a Resource Type

The wait-for graph scheme is not applicable to a resource-allocation system with multiple
instances of each resource type. The Deadlock Detection algorithm employs several timevarying data structures:
Available: A vector of length m indicates the number of available resources of each
type.
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 P, is requesting k more instances of resource type Rj.
Algorithm 1.3 Deadlock Detection Algorithm
1: Let Work and Finish be vectors of length m and n, respectively. Initialize Work =
Available. For i = 0 , 1 , . . . , n-1, if Allocation, , 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, 0 < i < n, then the system is in a deadlocked state.
Moreover, if Finish[i] == false, then process Pi is deadlocked.

1.4.2

Deadlock Recovery

When a detection algorithm determines that a deadlock exists, several alternatives exist.
One possibility is to inform the operator that a deadlock has spurred, and to let the operator
deal with the deadlock manually. The other possibility is to let the system recover from
the deadlock automatically. There are two options for breaking a deadlock. One solution is
simply to abort one or more processes to break the circular wait. The second option is to
preempt some resources from one or more of the deadlocked processes.
Process Termination
To eliminate deadlocks by aborting a process, we use one of two methods. In both
methods, the system reclaims all resources allocated to the terminated processes.
1. Abort all deadlocked processes: This method clearly will break the deadlock
cycle, but at a great expense, since these processes may have computed for a
9

1.4. DEADLOCK DETECTION AND RECOVERY

long time, and the results of these partial computations must be discarded, and
probably must be recomputed.
2. 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 a processes
are still deadlocked.
Resource Preemption
To eliminate deadlocks using resource preemption, we successively preempt some resources from processes and give these resources to other processes until he deadlock
cycle is broken. The three issues are considered to recover from deadlock
1. Selecting a victim: Which resources and which processes are to be preempted?
As in process termination, we must determine the order of preemption to minimize cost.
2. Rollback: If we preempt a resource from a process, what should be done with
that process? Clearly, it cannot continue with its normal execution; it is missing
some needed resource. We must roll back the process to some safe state and
restart it from that state.
3. Starvation: How do we ensure that starvation will not occur? That is, how
can we guarantee that resources will not always be preempted from the same
process?

10