Operating Systems
COMP 4850/CISG 5550
Deadlock Avoidance
Dr. James Money
Introduction to Deadlocks
• Deadlocks are formally defined by
– 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
• Since they are all waiting, none of them
will wake up
• Assumption of no interrupts and single
threads
Conditions for Deadlock
1. Mutual Exclusion – each resource is either
2.
3.
4.
currently assigned to one process or is
available
Hold and Wait – processes currently holding
resources can request new resources
No preemption – Resources previously granted
cannot forcibly be taken away from the
process. They must be released by the process
Circular Wait – there must be a circular chain
of 2+ processes, each whom is waiting for a
resource held by the next member of the chain
Conditions for Deadlock
• All four conditions must exist for a
deadlock to occur
• If one is absent, deadlock cannot occur
• Many of these are related to system policy
choices
Dealing with Deadlocks
• Ignore the problem, maybe it will ignore
you?
– Used by UNIX and Windows
• Detection and Recovery
• Dynamic avoidance by careful resource
allocation
• Prevention by structurally negating one of
the four conditions for deadlocks
Deadlock Avoidance
• In deadlock detection, we assumed all
resources were requested simultaneously
• However, in reality, we request them one
at a time
• The system must decide if granting the
resource is safe or not
• We consider careful resource allocation
now
Resource Trajectories
• The main algorithm is based on the idea
of safe states
• We first consider a graphic version of this
model first
• The does not immediately turn into an
algorithm, but provide a good intuition
into the problem
Resource Trajectories
• The following slide shows a model for
dealing with two processes and two
resources
• The horizontal axis represents number of
instructions executed for process A
• The vertical axis represents number of
instructions executed for process B
Resource Trajectories
• At I1, A requests a printer and at I2, A
requests a plotter
• The printer and plotter are released at I3
and I4, respectively
• Process B needs the plotter from I5 to I7
and the printer from I6 to I8
Resource Trajectories
Resource Trajectories
• Every point in the picture represents a
joint state of the two processes
• Initially, the state is p, with nothing having
been executed
• If the scheduler runs A first, then we get
to point q
• Then process B runs, and we get to r
Resource Trajectories
• When A cross the line for I1, it requests
and it granted the printer
• When B reaches t, it requests the plotter
• The shaded regions are of particular
interest for deadlocks
Resource Trajectories
• The slanted lines from southwest to
northeast is when both processes have the
printer
• The slanted lines from northwest to
southeast is when both processes have
the plotter
• Both of these are deadlock regions
because of mutual exclusion
Resource Trajectories
• If the system enters the box bounded by
I1, I2, I5, and I6, it will eventually deadlock
when it reaches the intersection of I2 and
I6
• The entire box is unsafe
• At point t, the only safe course of action is
to run process A until it gets to I4
• Any trajectory outside of this box to u will
do
Resource Trajectories
• The important thing to notice at point t, is
that process B is requesting a resource
• The system must decide to grant it or not
• If it is granted, it enters an unsafe region
and a possible deadlock
• To avoid this, we should suspect process A
until is requests and releases the plotter
Safe and Unsafe States
• We will use the vectors and matrices from
deadlock detection
• A state is said to be safe if it is not
deadlocked and there is some scheduling
order so that each process can run to
completion even if they requests their
maximum number of resources
immediately
Safe and Unsafe States
Safe and Unsafe States
Safe and Unsafe States
• The prior example is safe since there is a
sequence of allocations that allows the
processes to complete
• Now, let us consider an unsafe example
Safe and Unsafe States
Safe and Unsafe States
• So, the decision to go from (a) to (b) in the prior
•
•
•
•
slide moves us from a safe state to an unsafe
state
We should have not granted process A’s request
to prevent a possible deadlock
Note: An unsafe state is not necessarily a
deadlock!
Only a safe state guarantees all processes will
finish
In an unsafe state, it may or may not finish
Banker’s Algorithm for Single
Resource
• The scheduling algorithm for handling
single resources is due to Dijkstra(1965)
and is known as the banker’s algorithm
• It is an extension of the deadlock
detection algorithm
• It is modeled similar to the way a small
town banker deals with customers whom
he has given a line of credit
Banker’s Algorithm for Single
Resource
• The algorithm checks to see if granting a
resource leads to a safe or unsafe state
• The banker gives out the various credit
limits, which add up to 22
• However, s/he can only lend out 10 units
at a time
• The units can be tape drives, the
customers are processes and the banker is
the OS
Banker’s Algorithm for Single
Resource
Banker’s Algorithm for Single
Resource
• In (b), the state is safe
• In (c) is unsafe
• In (b), if anyone but C requests a
resource, it can be delayed until C is
finished
• (c) does not have to result in a deadlock,
but we want to avoid this state
Banker’s Algorithm for Single
Resource
• The algorithm considers each request as it
•
•
•
•
•
occurs and checks to see if it leads to a safe
state
If it does, the request is granted
If it does not, the request is postponed
To check safety, we see if we have enough
resources to satisfy some process
The resources are released, and the next closest
customer of the limit is checked, and so on
All processes must be able to finish to be safe
Banker’s Algorithm for Multiple
Resources
• We can now generalize the banker’s
algorithm for multiple resources
• This time we use a matrix of assigned and
request resources similar to before
Banker’s Algorithm for Multiple
Resources
Banker’s Algorithm for Multiple
Resources
1. Look at a row, R, whose unmet resource needs
2.
3.
are smaller than or equal to A(R<=A). If no
row exists, the system will eventually deadlock
Assume the process of the chosen row
requests its resources and finishes. Mark the
process as terminated and add its resources to
vector A
Repeat 1 and 2 until either all the processes
are marked as terminated, which means the
state is safe, or until a deadlock occurs, which
means the state is unsafe
Banker’s Algorithm for Multiple
Resources
• The current state is safe in the figure
• Suppose process B requests a scanner
– This is granted since the resulting state is safe
– Process D, then process A or E finishes,
followed by the rest
Banker’s Algorithm for Multiple
Resources
• After B is granted one of the two
remaining scanners, suppose E wants the
last printer
– This reduces A=(1 0 0 0)
– This leads to a potential deadlock
– This request must be deferred
Houston, we have a problem!
• This has been highly studied
• However, it suffers from a major flaw:
– It is useless
– It needs to know the total resource needs of a
program in advance
– In addition, the number of processes is
dynamic