MTU

4. DEADLOCKS

OVERVIEW

A Deadlock is a situation where a group of processes are permanently blocked as a result of

each process having acquired a subset of the resources needed for its completion and
waiting for release of the remaining resource held by others in the same group.

Deadlock occurs when two or more processes are each waiting for an event that will never
occur, since it can only be generated by another process in that set.

A set of blocked processes each holding a resource and waiting to acquire a resource held by
another process in the set.

A set of processes is deadlocked if each process in the set is waiting for an event that only
another process in the set can cause.

 Deadlock happens when processes have been granted exclusive access to resources such
as devices, files, and so forth.
 A resource is anything that can only be used by a single process at any instance.

There are two types of resources

 Preemptable: Can be taken away from a process.

 Non-preemptable: (Cannot be taken away from its current owner without
causing the computation to fail). If a process has begun to burn a CD-ROM,
suddenly taking the CD recorder away from it and giving it to another process
will result in a garbled (distorted/confused/corrupted) CD.

In general deadlock involves non-preemptable resources.

Example: Suppose that process A asks for CD-ROM drive and gets it. A moment later,
process B asks for the flatbed plotter and gets it, too. Now process A asks for the plotter and
blocks waiting for it. Finally process B asks for CD-ROM drive and also blocks. This
situation is called a deadlock.

SYSTEM MODEL

Finite number of resources is available in the system. These resources are distributed among
a number of competing processes. Two general categories of resources can be
distinguished.
Reusable Sources: It can be safely used by only one process at a time and is not depleted or
reduced or run down by that use. Processes obtain resource units that they later release for
reuse by other processes.
Deadlock Page: 1
Reusable Sources include Processors, I/O channels, I/O devices, primary and secondary
memory, files, databases, semaphores etc.

Consumable Sources: It can be created and destroyed. There is no limit on the number of
consumable resources of a particular type. Consumable resources include interrupts, signals,
messages and information in I/O buffers.

A Process must request a resource before using it, and must release the resource after using
it. A process may utilize a resource in only in the following sequence.

Request: If the request cannot be granted immediately, then the requesting process must
wait until it can acquire or get the resources.
Use: The process can operate the resource.
Release: The process releases the resources.

INTRODUCTION:

Imagine two processes, PA and PB running simultaneously. Half way through, PA requests
the Operating System for a file on the tape drive, and PB requests the Operating System for
the printer. Let us assume that both the requests are granted. After a while, PA requests for
the printer without giving up the tape drive. Similarly, PB requests for the tape drive
without giving up the control of the printer. Assuming that the system has only one tape
drive and one printer, what will happen? It is clear that both the processes cannot proceed.
PA will wait until PB releases the printer. But that can happen only if PB can proceed
further and finish off its processing with the printer. And this can happen only if PB gets the
tape drive that PA is holding. PB can get the tape drive only if PA can proceed further and
completes its work with the tape drive. That cannot happen too unless PA gets the printer
which PB is holding. This situation is called a deadlock.

GRAPHICAL REPRESENTATION OF A DEADLOCK

To represent the relationship between process and resources, a certain graphical notation is
used.

R1 P1

(a)

R2 P2

(b)

Relationship between resources and processes

Above figure shows square boxes as resources named R1 and R2. Similarly, processes
shown as hexagons are named P1 and P2. The arrows show the relationship. For instance,
Deadlock Page: 2
in part (a) of the figure, resource R1 is allocated to process P1, or in other words, P1 holds
R1. In part (b) of the figure, process P2 wants resource R2, but it has not yet got it. It is
waiting for it.
These graphs are called Directed Resource Allocation Graphs (DRAG). They help
us in understanding the process of detection of a deadlock, as we shall see.
Now let us imagine a typical scenario for the deadlock.
 P1 holds R1 but demands R2.
 P2 holds R2 but demands R1.
P1

R1 R2

P2

A deadlock or circular wait

You will notice that there is a closed loop involved. Therefore, this situation is called a
Circular wait condition. We should not get confused by the shape of the graph.

P1 P2

R1 R2

Another version of Circular wait

DEADLOCK PREREQUISITES/DEADLOCK CHARACTERIZATION:

Coffman, Elphick and Shoshani in 1971 have shown that there are four conditions all of
which must be satisfied for a deadlock to take place. These conditions are given below.

(i) Mutual Exclusion Condition:

Resources must be allocated to processes at any time in an exclusive manner and not on a
shared basis for a deadlock to be possible. For instance, a disk drive can be shared by two
processes simultaneously. This will not cause a deadlock. But printers, tape drives, plotters,
etc., have to be allocated to a process in an exclusive manner until the process completely

Deadlock Page: 3
finishes its work with it (which normally happens when the process ends). This is the cause
of the trouble.

(ii) Wait for condition

Even if a process holds certain resources at any moment, it should be possible for it to
request for new ones. It should not have to give up the already held resources to be able to
request for new ones. It should not have to give up the already held resources to be able to
request for new ones. If this is not true, a deadlock can never take place.

(iii) No preemption Condition

If a process holds certain resources, no other process should be able to take them away from
it forcibly. Only the process holding them should be able to release them explicitly.

(iv)Circular Wait Condition

Processes (P1, P2…) and Resources (R1, R2…) should form a circular list as expressed in
the form of a graph (DRAG). In short, there must be a circular (logically, and not in terms
of the shape) chain of multiple resources and multiple processes forming a closed loop as
discussed earlier.
It is necessary to understand that all these four conditions have to be satisfied
simultaneously for the existence of a deadlock. If any one of them does not exist, a
deadlock can be avoided.

DEADLOCK STRATEGIES

Various strategies have been followed by different Operating Systems to deal with the
problem of a deadlock. These are listed below.

 Ignore it.
 Detect it.
 Recover from it.
 Prevent it.
 Avoid it.

1. Ignore a Deadlock:

There are many approaches one can take to deal with deadlocks. One of them, and of course
the simplest, is to ignore them. Pretend as if you are totally unaware of them. (This is the
reason why it is called, interestingly, as Ostrich algorithm).

People who like exactitude and predictability do not like this approach, but there is a
very valid reason to ignore a deadlock. Firstly, the deadlock detection, recovery and
prevention algorithms are complex to write, test and debug. Secondly, they slow down the
system considerably. As against that, if a deadlock occurs very rarely, you may have to
restart the jobs but then the time may be lost quite infrequently and may not be significantly
large.

Deadlock Page: 4
2. Detect a Deadlock:

The graphs (DRAG) provide good help in doing this, as we have seen. However, normally,
a realistic DRAG is not as straightforward as a DRAG between two processes (P1, P2) and
two resources (R1 and R2) as depicted in the above figure. In reality, there could be a
number of resource types such as printers, plotters, tapes, and so on.

We will denote multiple instances of the same resource type by means of multiple symbols
within the square. For example, consider the DRAG as an example as shown in this fig.

P1

( ) R10
( ) R20
R1 ( ) R11 R2

P2

Multiple resources for a type

R1 is a resource type, say, a tape drive of a certain kind, and let us assume that there are two
tape drives R10 and R11 of the same kind known to the system. R2 may be a printer of a
certain type and there may be only one of that type available in the system, say, R20. The
DRAG shows the possibility of an apparent circular wait, but it is actually not so.
Therefore, it is NOT a deadlock situation. In the figure, R10 is allocated to P1. P1 is
waiting for R20. R20 is allocated to P2. Now comes the question of the last leg in the
diagram. Let us assume that R11 is free and P2 wants it. In this case, P2 can actually grab
R11. And if it does so, an arrow will be actually drawn from R11 to P2 as shown in below
fig. If you traverse from a node, following the arrows, you would not arrive at the starting
node. This violates the rules for the circular wait.

P1

( ) R10
( ) R20
( ) R11
R1 R2

P2

No Deadlock Situation
Deadlock Page: 5
Therefore, P2 in this case need not wait for R11. It can go to completion. The point is that
the visual illusion of the cycle should not deceive us. It is not a circular wait condition. If
R11 however, is also not free and is already grabbed by, say P1, it can lead to a deadlock if
P2 requests for R11.

The Operating System, in this case, could do the following to detect a deadlock.

(i) Number all processes as p0, P1… PN.

(ii) Number each resource separately using a meaningful coding scheme. For instance,
the first character could always be “R” denoting a resource. The second character
could denote the resource type (0 = tape, 1 = Printer, etc.) and the third character
could denote the resource number or an instance within the type, e.g. R00, R01,
R02,… could be different tape drives of the same type; R10, R11, R12… could be
different printers of the same type with the assumption that resources belonging to the
same type are interchangeable. The Operating System could pick up any of the
available resources within a given type and allocate it without any difference. If this
is not true with certain resources, the Operating System should treat them as different
resource types such that the principle of interchangeability of resources within the
same resource type holds true.

(iii) One is a resource wise table giving, for each resource, its type, allocation status, the
process to which it is allocated and the processes that are waiting for it. In fact, we
know in Device Management that the Operating System maintains the information
about the process currently holding the device in the Device Control Block (DCB)
maintained for each device. We also know that for each process waiting for the
device, there is a data structure called an Input Output Request Block or IORB, which
is linked to the DCB.

Another table is a process wise table giving, for each process, the resources
held by it and the resources it is waiting for. This is normally held along with PCB.
Logically, it is a part of PCB, but an Operating System could choose to maintain it in
a separate table liked to the PCB for that process. Therefore, if DCB and PCB data
structures are properly designed, all information needed by the Operating System to
allocate/de-allocate resources to various processes will be already available. The
Operating System could use this information to detect any deadlock.

Deadlock Page: 6
 Process to
Resource Resource Waiting
Status which
Type Number Processes
allocated
Tape R00 Free - -
(0) R01 Allocated P1 -
R02 Allocated P2 P3, P4
Printer R10 Allocated P1 P5
(1)
Plotter R20 Allocated P5 P1, P2
(2) R21 Free - -
R23 Allocated P4 P2, P5
: : : : :
: : : : :

Resource wise Table

Process Allocated Resources the

Number Resources Process is waiting for
P0 - -
P1 R01, R10 R20
P2 R02 R20
P3 - R02
P4 R23 R02
P5 R20 R10, R23

Process wise Table

(iv) Whenever a process requests the Operating System for a resource, the request is
obviously for a resource belonging to a resource type. The user would not really care
which one is exactly allocated (if he did, a new resource type should have to be
created). The Operating System then goes through the resource wise table to see if
there is any free resource of that type, and if there is any, allocates it to the process.
After this, it updates both these tables appropriately.
If no free resource of that type is available, the Operating System keeps that
process waiting on one of the resources for that type. (For instance, it could add the
process to the waiting queue for a resource, where the wait list is the shortest). This
also will necessitate updating of both tables. When a process releases a resource,
again both tables will be updated accordingly.

Deadlock Page: 7
(v) At any time, the Operating System can use these tables to detect a circular wait or a
deadlock. Typically, whenever a resource is demanded by a process, before actually
allocating it, the Operating System could use this algorithm to see whether the
allocating can potentially lead to a deadlock or not.

The working is as follows:

(a) Go through the resource wise table entries one by one, each time storing the values
processed. This is useful in detecting a circular wait, i.e., in finding out whether we
have reached the same node or not.

(b) Ignore entries for free resources.

(c) For all other entries, access the process to which the resource is allocated (e.g.,
resource R01 is allocated to process P1 in Fig. Resource wise table. In this case,
store the numbers R01 and P1 in separate lists called resource list and process list
respectively.

(d) Access the entry in the process wise table for that process (P1 in this case).

(e) Access one by one the resources this process (P1) is waiting for. For example, P1 is
waiting for resource R20. Check if this is the same as the one already encountered,
i.e. if R20 is the same as R01 stored in step (c). In short, check if circular wait is
already encountered. If yes, the deadlock is detected. If no, store this resource (e.g.
R20) in the resource list. This list will now contain R01 and R20. The process list
still contains only P1. Check from Process wise table whether there is any other
resource apart from R20 that process P1 is waiting for. If there is any, this procedure
will have to be repeated. In this example, there is no such resource. Therefore, the
Operating System goes to the next step.

(f) Go to the entry in the resource wise table for the next resource in the resource list
after R01. This is resource R20, in the case. We find that R20 is allocated to P5.

(g) Check if this process (i.e. P5) is the one already encountered in the process list (e.g. if
P5 is the same as P1). If it is the same, a deadlock is confirmed. In this case, P5 is
not the same as P1. So only store P5 after P1 in the process list and proceed. The
process list now contains P1 and P5. The resource list is still R01, R20 as in step (e).
After this, the Operating System will have to choose R10 and R23 as they are the
resources process P5 is waiting for. It finds that R10 is allocated to P1. And P1
already existed in the process list. Hence, a deadlock (P1 R20  P5  R10  P1)
has been detected.

Therefore, the Operating System will have to maintain two lists one list of
resources already encountered and a second list of all the waiting processes already
encountered. Any time the Operating System hits either a resource or a process
which already exists in the appropriate list while going through the algorithm, the
deadlock is confirmed.
Deadlock Page: 8
(h) If a deadlock is not confirmed, continue this procedure for all the permutations and
combinations, e.g. for all the resources that a process is waiting for and then for each
of the resources, the processes to which they are allocated. This procedure has to be
repeated until both the lists are exhausted one by one. If all the paths lead to
resources which are free and allocable, there is no deadlock. If all the paths make the
Operating System repeatedly go through the same process or resource (check if
already encountered), it is a deadlock situation.

3. Recover from a Deadlock:

When the system detects a deadlock, it needs to recover from it. However deadlock
recovery becomes more complex due to the fact that some processes definitely lose
something in the bargain. Basically, there are two approaches to solve this problem;
suspending a process or killing it. We will consider these one by one.

(i) Suspend/Resume a Process:

A process is selected based on a variety of criteria (low priority, for instance) and it is
suspended for a long time. The resources are reclaimed from the process and then allocated
to other processes that are waiting for them. When one of the waiting processes gets over,
the original suspended process is resumed.

(ii) Kill a Process:

The Operating System decides to kill one or more processes and reclaim all their resources
after ensuring that such action will solve the Deadlock. The Operating System can use the
DRAG and deadlock detection algorithms to ensure that after killing a specific process, there
will not be a deadlock. This solution is simple, but involves loss of at least one process.
There are two methods to implement this approach. First and crude method is to kill
all the deadlocked processes. The method looks very simple and effective, but the operation
of killing a number of processes and starting them all over again is very costly.
Second method involves the following steps:

1. Kill one process

2. Check the state of the system.
3. If the deadlock is resolved, exit. Otherwise go back to step 1.

4. Prevent a Deadlock:

This strategy aims at creating the circumstances so that deadlocks are prevented. A study of
Coffman’s four conditions discussed in Deadlock prerequisites show that if any of these
conditions is not met, there cannot be a deadlock. This strategy was first suggested by
Havender.

Deadlock Page: 9
(i) Mutual Exclusion Condition

If every resource in the system were sharable by multiple processes, deadlocks would never
occur. However, such sharing is not practicable. For instance, a tape drive, a plotter or a
printer cannot be shared amongst several processes. At best, what one can do is to use the
spooling techniques for the printer, where all the printing requests are handled by a separate
program, therefore, eliminating the very need for sharing. When the spooler is holding the
printer, no other processes is even allowed to request for a printer, leave alone get it. All
that a process is allowed to do is to add the data to the spooler to be printed subsequently.

(ii) Wait for Condition:

By prohibiting a process to wait for more resources while already holding certain resources,
we can prevent a deadlock.
The Operating System must make a process requesting for some resources to give up
the already held resources first and then try for the requested resources. Only if the attempt
is successful, can the relinquished resources be re-allocated to that process, so that it can
run. However, if the attempt fails, the relinquished resources are regained and the process
waits until those resources are available. Every time a check is made, the existing, already
held resources are relinquished so that the deadlock can never take place.

(iii) No Preemption Condition:

Guaranteeing a situation so that the “no preemption” condition is not met is very difficult. If
we allow the resources allocated to a process to be taken away forcibly form it, it may solve
the problem of a deadlock, but it will give rise to worse problems. Taking away the tape
drive forcibly form an incomplete process which has processed only part of the records on a
tape drive, because, some other process requires it, will definitely be an unacceptable
situation due to the problems of mounting/dismounting, positioning, and so on. With
printers, the situation is worse.

(iv) Circular Wait Condition:

It is obvious that attacking the first three conditions is very difficult. Only the last one
remains. If the circular wait condition is prevented, the problem of the deadlock can be
prevented too.
One way in which this can be achieved is to force a process to hold only one resource
at a time. If it requires another resource, it must first give up the one that is held by it and
then request for another. This obviously has the same flaws as discussed above while
preventing condition (iii). If a process P1 holds R1 and wants R2, it must give up R1 first,
because another process P2 should be able to get it (R1). We are again faced with a problem
of assigning a tape drive to P2 after P1 has processed only half the records. This, therefore,
is also an unacceptable solution.

Deadlock Page: 10
5. Avoid a Deadlock:

Deadlock prevention was concerned with imposing certain restrictions on the environment
or processes so that deadlocks can never occur. But we found out in the last section the
difficulties involved in deadlock prevention. Therefore, a compromise is sought by the
Operating System. The Operating System aims at avoiding at avoiding a deadlock rather
than preventing one. What is the exact different between the two? The difference is quite
simple. Deadlock avoidance is concerned with starting with an environment where a
deadlock is theoretically possible (it is not prevented), but by some algorithm in the
Operating System, it is ensured, before allocating any resource that after allocating it, a
deadlock can be avoided.

Banker’s Algorithm:

Dijkstra was the first person to propose an algorithm in 1965 for deadlock avoidance. This
is known as Banker’s Algorithm, due to its similarity in solving a problem of a banker
wanting to disburse loans to various customers within limited resources.
This algorithm in the Operating System is such that it can calculate in advance before
a resource is allocated to a process, whether it can lead to a deadlock (“unsafe state”) or it
can certainly manage to avoid it (“safe state”).
Banker’s algorithm maintains two matrices on a dynamic basis. Matrix A consists of
the resources allocated to different processes at a given time. Matrix B maintains the
resources still needed by different processes at the same time. These resources could be
needed one after the other or simultaneously. The Operating System has no way of knowing
this. Both these matrices are shown in the following figure.

Process Tape Drive Printers Plotters Process Tape Drive Printers Plotters
P0 2 0 0 P0 1 0 0
P1 0 1 0 P1 1 1 0
P2 1 2 1 P2 2 1 1
P3 1 0 1 P3 1 1 1
Matrix A Matrix B
Resources assigned Resources still required
Vectors
Total Resources (T) = 543
Held Resources (H) = 432
Free Resources (F) = 111
Banker’s algorithm

Matrix A shows that process P0 is holding 2 tape drives at a given time. At the same
moment, process P1 is holding 1 printer and so on. If we add these figures vertically, we get
a vector of Held Resources (H) = 432. This is shown as the second row in the rows for
vectors. This says that at a given moment, total resources held by various processes are: 4
tape drives, 3 printers and 2 plotters. This should not be confused with the decimal number
432. That is why it is called a vector. By the same logic, the figure shows that the vector for

Deadlock Page: 11
the Total Resources (T) is 543. This means that in the whole system, there are physically 5
tape drives, 4 printers and 3 plotters. These resources are made known to the Operating
System at the time of system generation. By subtraction of (H) from (T) column wise, we
get a vector (F) of free resources which is 111. This means that the resources available to
the Operating System for further allocation are; 1 tape drive, 1 printer and 1 plotter at that
juncture.

Matrix B gives process wise additional resources that are expected to be required in
due course during the execution of these processes. For instance, process P2 will require 2
tape drives, 1 printer and 1 plotter, in addition to the resources already held by it. It means
that process P2 requires in all 1 +2 = 3 tape drives, 2+1 = 3 printers and 1+1 = 2 plotters. If
the vector of all the resources required by all the processes (vector addition of Matrix A and
Matrix B) is less than the vector T for each of the resources, there will be no contention and
therefore, no deadlock. However, if that is not so, a deadlock has to be avoided.

Having maintained these two matrices, the algorithm for the deadlock avoidance
works as follows:

(i) Each process declares the total required resources to the Operating System at the
beginning. The Operating System puts these figures in Matrix B (resources required for
completion) against each process. For a newly created process, the row in Matrix A is all
zeros to begin with, because no resources are yet assigned for that process. For instance, at
the beginning of process P2, the figures for the row for P2 in Matrix A will be all 0 s; and
those in Matrix B will be 3, 3 and 2, respectively.

(ii) When a process requests the Operating System for a resource, the Operating System
finds out whether the resource is free and whether it can be allocated by using the vector F.
If it can be allocated, the Operating System does so, and updates Matrix A by adding 1 to the
appropriate slot. It simultaneously subtracts 1 from the corresponding slot of Matrix B. For
instance, starting from the beginning, if the Operating System allocates a tape drive to P2,
the row for P2 in Matrix a will become 1, 0 and 0. The row for P2 in Matrix B will
correspondingly become 2, 3 and 2. At any time, the total vector of these two rows, i.e.
addition of the corresponding numbers in the two rows, is always constant and is equivalent
to the total resources needed by P2, which in this case will be 3, 3 and 2.

(iii) However, before making the actual allocation, whenever, a process makes a request
to the Operating System for any resource, the Operating System goes through the Banker’s
algorithm to ensure that after the imaginary allocation, there should not be a deadlock, i.e.
after the allocation, the system will still be in a ‘safe state’. The Operating System actually
allocates the resource only after ensuring this. If it finds that there can be a deadlock after
the imaginary allocation at some point in time, it postpones the decision to allocate that
resource. It calls this state of the system that would result after the possible allocation as
‘unsafe state’.

Remember: the unsafe state is not actually a deadlock. It is a situation of a potential

deadlock with the arithmetic comparison.

Deadlock Page: 12