J.E.D.I.

1 Deadlocks
1.1

Objectives

This chapter discusses deadlocks. We will discuss what deadlocks are and under what
conditions deadlocks occur. Then we will discuss how deadlocks can be prevented, avoided,
and what can be done to recover from them.

1.2

Chapter Outline

Introduction

Resource Allocation Graphs

Conditions for Deadlocks

Deadlock Prevention

Deadlock Avoidance

Deadlock Recovery

1.3

Introduction

Processes require resources in order to finish the work assigned to them. In a multitasking
environment, multiple processes would have to compete for a limited number of resources.
This means that there is a chance that a process would not be able to get a resource when it
needs it. A process that can not get the resource it needs would need to enter a wait state
until the resource becomes available.
However, there is a chance that a process never leaves the wait state because the resource it
is requesting is being held by other processes also in a wait state. This situation is called a
deadlock.
Consider the following example.
Alice and Bob are two friends who carpool. One day, Alice was in the office wanting to go
home. She has the car keys but doesn't have the car. On the other hand, Bob was at home
wanting to go to the office. He has the car but does not have the car keys.
Alice and Bob need both resources (car and car keys) to complete their task. Both of them are
in possession of one resource and is waiting for each other to get the other resource. In the
end, none of them get to go where they want to.

1.3.1

Resource Allocation Graphs

To give a better idea of what deadlocks are, we will now discuss resource allocation graphs. A
resource allocation graph shows what processes are in possession and/or are requesting which
resources.
The following is a resource allocation graph. Processes are represented by circles while
resources are represented by squares.

Operating Systems

J.E.D.I.

A process that is requesting a resource has an arrow pointing from the process circle to the
resource square, this is called a request edge. A process that owns a resource has an arrow
pointing from the resource square to the process circle, this is called an assignment edge.

Some resources may have more than one instance. For example, a process is requesting for a
printer. It turns out that there are three printers in the office and the process may be content
with any of these printers. If that is the case, then the resource square has dots which
represent the number of instances of that resource. A process that owns an instance of that
resource has an arrow pointing from the instance dot to the process.
The following diagram shows the resource allocation graph of Alice and Bob.

Operating Systems

J.E.D.I.

We can see that the resource allocation graph for Alice and Bob has a clearly defined cycle. In
fact, any such cycle of resource requests and resource allocation describes a deadlock if each
resource has only one instance. If a resource has multiple instances, then the chance of a
deadlock still exists.

1.3.2

Conditions for Deadlocks

There are four conditions required for deadlocks to occur.

Mutual exclusion a resource can only be allocated to a single process. If a process

requires a resource that is allocated to another process, then that process must wait
until the other process is finished with that resource.

Hold and wait a process that is requesting a resource and is denied does not let go of
resources allocated to it.

No preemption a process cannot be forced to let go of a resource allocated to it

Circular wait there exists a circular order of waiting processes. For example, P1 is
waiting for a resource held by P2 which is waiting for a resource held by P3 which is
waiting for a resource held by P1.

1.3.3

Deadlock handling

Operating systems address the deadlock issue in the following ways

Deadlock prevention totally prevent deadlocks by eliminating one of the necessary

deadlock conditions from ever occurring.

Deadlock avoidance the system does not totally prevent deadlocks but is able to
detect if granting a process a resource pushes the system into an unsafe state where
deadlocks are possible.

Deadlock recovery the system does not prevent or avoid deadlocks but, when a
deadlock is detected, provides a way to recover from it.

Deadlock ignorance simply ignore the fact that deadlocks occur. Although this may
seem counter-intuitive, operating systems that place emphasis on speed rather than
reliability may find the algorithms needed for prevention, avoidance or recovery may
cause performance degradation. Worse comes to worst, a deadlock can simply be
resolved with a quick reboot.

1.4

Deadlock Prevention

All four conditions must be present in the system for a deadlock to occur. Deadlock prevention
means having a scheme which prevents any one of these conditions from being present in the
system.

1.4.1

Mutual Exclusion Prevention

A mutually exclusive resource is a necessary condition for a deadlock. A printer cannot be

shared while a process is using it. However, additional printer instances (such as a different
printer down the hall) could be allocated to requesting resources while the main printer is in
use. The mutual exclusion condition can be prevented by simply providing additional resource
instances.
However, some resources are inherently unsharable. For instance, only a single process can be
made to write or read from the keyboard at a time.
Operating Systems

J.E.D.I.

1.4.2

Hold and wait Prevention

The hold and wait condition exists in the system if a process, while waiting for a resource to
become available, does not let go of the resources it already owns. There is a way to prevent
this condition from happening. For instance, if a process requests for additional resources , it
must let go of the resources it already has. Another protocol is for a process to initially declare
all the resources it will ever need, and the operating system will let this process run after all
the resources are made available to it.

1.4.3

No-preemption Prevention

One way to prevent deadlocks is to allow resources to be forcibly deallocated from a process in
order to be assigned to another. This would allow any process to get all the resources it needs
at any given time even if they are in use by other processes. No deadlocks will occur because
processes would not have to wait for resources.
However, not all resources can be easily be switched to other processes. Consider mechanical
devices such as printers or disks. A printer that is switched to another process in the middle of
a job would end up printing the first part of a page from the first process and end up with the
bottom of the page from the second process.

1.4.4

Circular wait prevention

Preventing circular wait means establishing an order by which processes request for resources.
For example, we can setup a value system for each resource. For example, the printer could
have value 10, tape drive value 20, floppy disk value 50 and hard disk 100.
Once we have established this, a process can only request a resource in increasing order. If it
has to request a lower valued resource, then it would have to release all lower valued
resources it contains.
If a process requires the floppy and the hard disk then it must request the floppy first and then
request for the hard disk. Now that it owns the floppy disk (50) and hard disk (100). Then it
requires the tape drive. Since its a lower numbered resource, it would have to release 50 and
100 before getting 10.
We can establish that no circular wait occurs via a proof by contradiction. 1 For example, we
have Pi as part of a circular wait of processes {P0, P1, ... Pn}. Pi would be waiting for Pi+1 to
release Ri. However, Pi+1 should be waiting for resource Ri+1.
As we can only request resources in increasing order, then F(0) < ... F(Ri) < F(Ri+1) < F(Rn)
< F(0). By transitivity, we cannot have F(0) < F(0). Therefore, there is no circular wait.

1.5

Deadlock Avoidance

In deadlock avoidance, the system is not kept deadlock free. However, any new process
request is first checked by the system in order to make sure that, when the resource is
allocated, the system does not enter a deadlock state. To do this, the system needs
information on the maximum amount of resources a process would need before hand. The
system would use this information together with information from other processes to give a
judgement call whenever a process requests for a resource.

1.5.1

Safe State

Given a set of processes and resources, then the set of all possible states of the system would
fall under three categories:
1 SilberScahz, Galvin. Opearting Systems Concepts
Operating Systems

J.E.D.I.

Safe state the resource allocation of the system is not in a deadlock state. A safe
state means that the maximum resource need of a process can be met by the reserve
resources of the system, or by resources currently held by other processes whose
maximum needs can also be met.

Unsafe state the resource allocation of the system is not in a deadlock state but has
the potential to enter a deadlock state. This is because the maximum resource need of
a process cannot be met by the reserve resources of the system, or through the
resources held by other processes.

Deadlock state

In a safe state, the maximum resource need of a process can be met either by the reserve
resources of the system or from resources being held by processes whose maximum needs can
be met.
In an unsafe state, the maximum resource needed by a process cannot be met because there
are not enough reserve resources. On top of that, the resources held by other processes can
not be used because their maximum needs can not be met. The deadlock does not occur until
the process requests for additional resources.

1.5.2

Resource Allocation Graph

The operating system tries to keep resource allocation in a safe state by filtering additional
resource requests. One way to do this is by checking if a granted resource allocation results in
a cycle in the resource allocation graph.
To do this, we add an additional concept to our resource allocation graph, the claim edge. A
claim edge appears in our resource allocation graph to indicate that a process would be
requesting that edge some time in the future. This is in contrast to the request edge, where
the process is already asking for the resource and will not continue processing until the
resource is allocated to it.

When a process starts running, it immediately tells the operating system all the possible
resources it would be using, which would appear in the resource allocation graph as claim
edges. During the process' lifetime, claim edge would transform to request edges when the

Operating Systems

J.E.D.I.

process actually needs that resource. If a process' request is granted, then that request edge
would be transformed into an assignment edge.
Knowing all the claim edges at the start, the operating system would be able to judge whether
or not assigning a resource to a process would potentially cause a cycle in the future. This
knowledge keeps the system in a safe state.

1.5.3

Banker's Algorithm

The resource allocation graph strategy can only be made to work if all resources are single
instance resources. The banker's algorithm can be made to run even if the resources have
multiple instances.
In the banker's algorithm , a process must initially indicate the maximum number of instances
of each resource type it would need during the course of its execution.
For example, consider a system having three resource types, A, B and C with maximum
instances of 15, 6, and 10 respectively.

Available
A

15

10

Processes P1 through P5 indicate the maximum amount of resources they would need through
an array called Max
Max
A

P1

P2

P3

P4

P5

10

During process execution, a process would be allocated a certain number of resources. This
would be placed in an array called allocated. The remaining resources needed by the process
(i.e. Max Allocated) is placed in the Need array. Of course our available table changes to
reflect the allocated processes.

Max

Allocated

Need

Available

P1

P2

P3

P4

P5

10

Now we are all set for our banker's algorithm.

Operating Systems

J.E.D.I.

A process is able to terminate if the number of available resources is enough to meet its needs.
When this happens, then the resources it currently has can be added to the available pool.
The system is in a safe state if all processes are able to meet their needs and deallocate their
assigned resources.
In summary, give the process everything that it needs so that it will be able to pay everything
back. If all processes can pay back , then the system is in a safe state.
We will try to run our banker's algorithm on our test data.
First, we try to look for any process whose need can be met by the available resources. We can
see that we can meet P2's need. We then give P2 all its needs so it can finish execution and
the allocated resources returned to the pool.

Max

Allocated

Need

Available

P1

P2

P3

P4

P5

10

ok!

We can also meet P4's needs:

Max

Allocated

Need

Available

P1

P2

P3

P4

P5

10

ok!
ok!

We can also meet P1's needs:

Max

Allocated

Need

Available

P1

ok!

P2

ok!

P3

P4

P5

10

ok!

Then P3's needs:

Max
P1

Allocated

Need

Available

Operating Systems

ok!

10

9
7

J.E.D.I.

P2

ok!

P3

ok!

P4

ok!

P5

10

Finally P5's needs

Max

Allocated

Need

Available

P1

ok!

P2

ok!

P3

ok!

P4

ok!

P5

10

ok!

15

10

Since all processes have been able to pay back their resources, we can say that the system is
in a safe state. For each step , no particular order of processes is necessary as long as the
available resources can meet the process' needs.
The operating system assigns resources to a process only if, after the assignment, the system
is still in a safe state. Of course, any resource request must first meet the specified maximum
resource allocation (you cannot owe more than your maximum).
For example, P1 requests for 2 additional A resource, or (2,0,0). We will first allocate the
resource and try to see if the system is still in a safe state.

Allocated

Need

Available

P1

initial

P2

P2 needs met

P3

P4 needs met

P4

P1 needs met

P5

10

P3 needs met

15

10

P5 needs met
Safe state

Since the system is in a safe state then we can successfully allocate the requested resource.
However, there is a chance that a resource won't be allocated because the system enters an
unsafe state. Consider an additional request by P1 for 2 additional C resources, or (0,0,2)

Allocated
P1

Need

Available

Operating Systems

initial

J.E.D.I.

P2

P2 needs met

P3

P4 needs met

P4

P5

No other processes needs met!

Not being able to complete the algorithm means that not all resource needs can be allocated.
The system will be in an unsafe state if the resource request is granted. Therefore, the
operating system denies the request by P1 until other processes return their resources.

1.6

Deadlock Detection and Recovery

If the system does not prevent or avoid deadlocks, then the system can enter a deadlock
state. If this happens, then the system must first find out that it is in a deadlock state, and
once it does, recover from it.

1.6.1

Deadlock detection

To find out if a process is deadlocked, the system can maintain a version of the resource
allocation graph with resources removed. This is called a wait for graph. There would exist a
directed edge between Pi and Pj in the wait-for graph if in the resource allocation graph, Pi is
waiting for a resource R which belongs to Pj

Operating Systems

J.E.D.I.

A deadlock exists if there is a cycle in the wait-for graph.

For multiple resource instances, we have a modified banker's algorithm. Instead of considering
a Max or a Need column, we consider a request column, meaning, that the process would need
these resources at this point in time to continue processing.
A process can finish running if the available resources are able to meet its current request,
then adding its allocated resources into the available pool. This is the main difference with the
original banker's algorithm. We are optimistic that the process would be able to release its
allocated resources if we meet (only) its current need.
The system is not in a deadlock state if all processes are able to meet their request from the
available pool and release their resources. If this doesn't happen, then those processes with
unaddressed requests are in the deadlock cycle
For example, we are given the following system status:

Allocated

Request

Available

P1

P2

P3

P4

P5

Currently, we don't have enough available resources to satisfy requests. But we assume that
processes currently having resources will be kind enough to release them once we meet their
request. We now run this modified banker's algorithm:

Allocated

Request

Available

P1

intial

P2

P1's request met!

P3

P3's request met!

P4

P5's request met!

P5

P4's request met!

P2's request met

No deadlock

A deadlock occurs if not all of the process' requests are granted. Processes involved in the
deadlock are those whose requests are not met.
Consider the following scenario and the banker's algorithm execution
Allocated
A

Operating Systems

Request
C

Available
C

10

J.E.D.I.

P1

intial

P2

P1's request met!

P3

P3's request met!

P4

We cannot grant the request of P2,P4, P5!

P5

P2, P4, P5 are deadlocked

These algorithms should be run periodically to check if the system is in a deadlock state. Once
a deadlock has been determined, the system can now choose a recovery strategy.

1.6.2

Process Termination

We can break a deadlock by terminating processes involved in the deadlock. We can terminate
one process at a time until the deadlock breaks, or simply terminate all processes. Terminating
a process may have dire consequences. For example, if a process is in the middle of writing to
a file when it is terminated, then the file may be left in an inconsistent state,thus destroying
it. We would also need to determine a criteria for choosing a victim. For instance, we could
terminate recently started processes first, as it would be easy to just restart them. We could
also choose to terminate lower priority processes first.

1.6.3

Resource Preemption

An alternative to terminating processes is to remove allocated resources from processes in

order to break the deadlock. However, when a resource is removed from a process by an
external source, the process can no longer proceed as usual.
Consider a process that opens a file and has code that saves data to the file. If file access is
revoked, then what would happen to the file save instructions when they are run? One way is
to rollback execution to the code just before the revoked resource was requested and have the
program run once again from that point, requesting for the resource once more. However, this
requires information on what state the process was at that point, and in some cases it would
just be simpler to do a total rollback, or just restart the process.

Operating Systems

11