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 P1 is holding the tape drive and
process P2 is holding the printer. If P1 requests the printer and P2 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 {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 is waiting for a resource that is held by P0.

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, P2, ..., Pn}, the
set consisting of all the active processes in the system, and R = {R 1, R2, ..., Rm), the set
consisting of all resource types in the system.
Request edge: A directed edge from process Pi to resource type Rj, denoted by Pi → Rj,
signifies that process Pi requested an instance of resource type Ri and is currently waiting for
that resource.
Assignment edge: A directed edge from resource type Ri to process Pi, denoted by Rj → Pi,
signifies that an instance of resource type Ri has been allocated to process Pi.
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 = {R1, R2, ..., Rn) 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 Pi → Rj indicates that process Pi may request resource Rj at some time in
the future.
This edge resembles a request edge in direction, but is represented by a dashed line.
When process Pi requests resource Rj, the claim edge Pi → Rj is converted to a request
edge.
When a resource Rj is released by Pi, the assignment edge Rj → Pi is reconverted to a
claim edge Pi → Ri.
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.
Example: R2 if allocated to P2 will result in cycle and therefore deadlock. Hence if P2
requests R2, 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 <P1, P2, ..., Pn> is a safe sequence 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.
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 T0, below table shows
the status of each resources:

Process Max Allocated Need Available

P0 10 5 5 3

P1 4 2 2

P2 9 2 7

At time T1, Sequence <P1,P0,P2> is safe because, P1 will get 2 out of 3, use and release 4.
This 4 plus remaining 1 will be allocated to P0 which will use it and release 10. This 10 will
be allocated to P2.
Whereas, At time T1, sequence <P2,P1,P0> is not safe because, if P2 is allocated 1 out of 3,
and P1 is allocated 2 out of 2, P1 will complete and release 4. But this 4 is insufficient
because P0 needs 5 and P2 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 Needi ≤ Work. If no such i exists, go to step 4.

3. Work := Work + Allocationi 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 Requesti ≤ Available

Available := Available - Requesti;

Allocationi := Allocation + Request;

Needi := Needi - Requesti;

Example

Total <A,B,C> = <10,5,7>

Max Allocation Need Available

Process 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>

Max Allocation Need Available

Process 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>

Max Allocation Need Available

Process 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>

Max Allocation Need Available

Process 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>

Max Allocation Need Available

Process 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>

Max Allocation Need Available

Process 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 Pi to Pj in a wait-for graph implies that process Pi is waiting for process Pj
to release a resource that Pi 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 Needi ≤ Work. If no such i exists, go to step 4.

3. Work := Work + Allocationi 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.