Chapter 8 Deadlocks
Chapter 8: Deadlocks
System Model
Deadlock Characterization
Methods for Handling Deadlocks
Deadlock Prevention
Deadlock Avoidance
Deadlock Detection
Recovery from Deadlock
Page 2
System Model
§8.1
A system consists of a finite number
of resources to be distributed among
competing processes.
Resources are partitioned into
several types, each of which consists
of multiple identical instances.
CPU cycles, memory space, files, I/O
devices, object locks
Page 3
System Model
Each process utilizes a resource as
following sequence:
request
• If the request cannot be granted
immediately, then the requesting process
must wait until it can acquire the resource.
use
• The process can operate on the resource.
release
• The process releases the resource.
Page 4
Deadlock Characterization
§8.2
Deadlock can arise if four conditions hold simultaneously.
Mutual exclusion: only one process at a time can use a
resource.
Hold and wait: a process holding at least one resource
is waiting to acquire additional resources held by other
processes.
No preemption: a resource can be released only
voluntarily by the process holding it, after that process
has completed its task.
Circular wait: there exists a set {P0, P1, …, P0} 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, …, Pn–1 is waiting for a resource that is held by Pn,
and Pn is waiting for a resource that is held by P0.
Page 5
Deadlock Characterization
§8.2
Deadlock can arise if four conditions hold simultaneously.
Mutual exclusion:
only
one process at a time can use a
Multiple
Choices
Question:
resource.
(Hold)and
If the
processes
the system
canresource
be
wait:
a process in
holding
at least one
is waiting
to acquire additional
resources
by other
preempted,
no deadlock
can held
happen.
processes.
No preemption: a resource can be released only
Answer: ○
voluntarily
by the process holding it, after that process
has completed its task.
Circular wait: there exists a set {P0, P1, …, P0} 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, …, Pn–1 is waiting for a resource that is held by Pn,
and Pn is waiting for a resource that is held by P0.
Page 6
Resource-Allocation Graph
§8.2.2
A set of vertices V and a set of edges E.
V is partitioned into two types of nodes:
P = {P1, P2, …, Pn}, the set consisting of all the
processes in the system.
R = {R1, R2, …, Rm}, the set consisting of all
resource types in the system.
Request edge – directed edge Pi  Rj
Assignment edge – directed edge Rj  Pi
Page 7
Resource-Allocation Graph
Process
Resource Type with 4 instances
P
Pi requests instance of Rj
Pi is holding an instance of Rj
i
Rj
Pi
Rj
A request edge points to only the
square Rj, whereas an assignment
edge must also designate one of
the dots in the square.
Page 8
Resource Allocation Graph
Example:
Page 9
Resource Allocation Graph
Deadlocked:
Page 10
Resource Allocation Graph
With Cycle but
No Deadlock:
Page 11
Resource Allocation Graph
With Cycle but
No Deadlock:
Short Answer Question:
Please add two edges to the resource
allocation graph show below to make
it deadlocked.
Page 12
Basic Facts
If graph contains no cycles  no
deadlock.
If graph contains a cycle 
if only one instance per resource type,
then deadlock.
if several instances per resource type,
possibility of deadlock.
Page 13
Basic Facts
IfTrue-False
graph contains
Question: no cycles  no
deadlock.
( ) In order to prevent deadlock, we
must contains
ensure that a
nocycle
cycle can
If graph

happen in the resource allocation
if only one instance per resource type,
graph associated with this system.
then deadlock.
Answer: ×
if several instances per resource type,
possibility of deadlock.
Page 14
Methods for Handling
Deadlocks
§8.3
Use a protocol to ensure that the system will
never enter a deadlock state.
Allow the system to enter a deadlock state and
Deadlock
Prevention:
(§8.4)
Deadlock
avoidance:
(§8.5)an
then
recover.
The system
can provide
a set of methods
forOS
ensuring
information
algorithm
that give
examines
the stateabout
of the system
to determine
whether
aand
deadlock
hasforoccurred,
that at least
one of the
processes
resources
and
an algorithm
to recover
from the or
deadlock.
necessary
conditions
cannot
the decision
of satisfying
Ignore
the problem
and(§8.5)
pretend
that deadlocks
hold.
delaying
the requests.
Deadlock
Detection:
never occur in the
system.Recovery: (§8.7)
Deadlock
Page 15
Methods for Handling
Deadlocks
§8.3
True-False Question:
Use a protocol to ensure that the system will
( ) If
a system
has deadlock
never
enter
a deadlock
state.
Allowprevention
the system scheme
to enter available,
a deadlockno
state and
then recover.
system or
canavoidance
provide an
deadlockThe
detection
algorithm
that examines the state of the system
are required.
to determine whether a deadlock has occurred,
Answer:
○
and
an algorithm
to recover from the deadlock.
Ignore the problem and pretend that deadlocks
never occur in the system.
Page 16
Methods for Handling
Deadlocks
§8.3
True-False
Question:
True-False
Question:
Use a protocol
to ensure that the system will
( ( ) )If
a system
has deadlock
never
enter
a deadlock
state.
Usually
deadlock
recovery
scheme
available,
no
Allowprevention
the
system
to enter
a deadlock
state and
method
should
be invoked
after
then recover.
The
system or
canavoidance
provide an
deadlock
detection
deadlock
detection.
algorithm
that examines the state of the system
are required.
to determine whether a deadlock has occurred,
and
an algorithm
to recover from the deadlock.
Answer:
○
Ignore the problem and pretend that deadlocks
never occur in the system.
Page 17
Methods for Handling
Deadlocks
If no prevention, no avoidance, no detection and
no recovery schemes, then the system may
reach a deadlock state and eventually need to
be restarted manually.
Although does not seem to be viable, it is used in
most OS, including UNIX.
In many systems, deadlocks occur infrequently;
thus it is cheaper to use this method.
JVM does nothing to manage deadlocks, it is up
to the application developer to write programs
that are deadlock-free.
Page 18
Methods for Handling
Deadlocks
Question:
IfTrue-False
no prevention,
no avoidance, no detection and
no
schemes,
then the systems
system may
( recovery
) Although
the operating
reachtoday
a deadlock
state
and eventually
need to
are very
sophisticated,
most
be restarted
of themmanually.
has no deadlock
Although
does not seem
to beavailable.
viable, it is used in
manipulation
schemes
most OS, including UNIX.
○
InAnswer:
many systems,
deadlocks occur infrequently;
thus it is cheaper to use this method.
JVM does nothing to manage deadlocks, it is up
to the application developer to write programs
that are deadlock-free.
Page 19
Deadlock Prevention
§8.4
By ensuring that at least one of the
conditions (§8.2) cannot hold, we can
prevent the occurrence of a deadlock.
1. Mutual Exclusion – not required for
sharable resources, but must hold for
nonsharable resources (printers,
synchronized method)
Page 20
Deadlock Prevention
§8.4
By ensuring that at least one of the
True-False
Question:
conditions
(§8.2)
cannot hold, we can
(
)
Mutual
exclusion
is
not
required
prevent the occurrence of a deadlock.
for nonsharable resources in a
1. Mutual multi-threaded
Exclusion – not
required for
environment.
sharable resources, but must hold for
nonsharable resources (printers,
Answer: ×
synchronized
method)
Page 21
Deadlock Prevention
2. Hold and Wait – must guarantee that
whenever a process requests a
resource, it does not hold any other
resources.
Require process to request and be
allocated all its resources before it begins
execution, or allow process to request
resources only when the process has
none… release all the resources that is is
currently allocated before requesting
additional resources.
Low resource utilization; starvation possible.
Impractical in Java (difficult to implement
these protocols with synchronized
methods or blocks).
Page 22
Deadlock Prevention
2. Hold and Wait – must guarantee that
whenever a process requests a
resource, it does not hold any other
resources.
Require process to request and be
allocated all its resources before it begins
execution, or allow process to request
resources only when the process has
none… release all the resources that is is
currently allocated before requesting
additional resources.
Low resource utilization; starvation possible.
Impractical in Java (difficult to implement
these protocols with synchronized
methods or blocks).
Page 23
Deadlock Prevention
2. Hold and Wait – must guarantee that
whenever a process requests a
resource, it does not hold any other
resources.
Require process to request and be
allocated all its resources before it begins
execution, or allow process to request
resources only when the process has
none… release all the resources that is is
currently allocated before requesting
additional resources.
Low resource utilization; starvation possible.
Impractical in Java (difficult to implement
these protocols with synchronized
methods or blocks).
Page 24
Deadlock Prevention
2. Hold and Wait – must guarantee that
whenever a process requests a
resource, it does not hold any other
resources.
Require process to request and be
allocated all its resources before it begins
execution, or allow process to request
resources only when the process has
none… release all the resources that is
currently allocated before requesting
additional resources.
Low resource utilization; starvation possible.
Impractical in Java (difficult to implement
these protocols with synchronized
THINK
methods or blocks).
Page 25
Deadlock Prevention
2. Hold and Wait – must guarantee that
whenever
process
requests a
MultipleaChoices
Question:
resource,
it doesthe
not“Hold
hold any
other
( ) Breaking
and wait”
resources.
condition in a multi-threaded
Require
process
request and be
system
maytocause
allocated
all its resources
beforeexclusive
it begins
(a) deadlock
(b) mutual
execution,
or allow process
to request
(c) starvation
(d) implementation
resources only when the process has
problem
none… release all the resources that is
currently
before requesting
Answer:allocated
c
additional resources.
Low resource utilization; starvation possible.
Page 26
Deadlock Prevention (Cont.)
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 released.
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.
Often applied to resources whose state can be
easily saved and restored later, such as CPU
registers and memory space. It cannot be
applied to resources such as printers and tape
drives.
Page 27
Deadlock Prevention (Cont.)
Circular Wait – impose a total ordering of
all resource types, and require that each
process requests resources in an
increasing order of enumeration.
Let R={R1,R2, …, Rm} be the set of resource types.
F:R→N
Should be defined according to
F(type drive) =1
the normal order of usage of the
F(disk drive) = 5
resources in a system.
F(printer) = 12
A process owning resource type Ri can continue to request
type Rj iff F(Rj)>F(Ri)
or
Whenever a process requests an instance of resource type
Rj, it has released any resources Ri such that F(Ri) >=F(Rj).
Page 28
Proof by contradiction
Assume circular wait exists in
{P0, P1, ..., Pn}, where Pi is waiting for
a resource Ri, which is held by
process Pi+1.
F(Ri) < F(Ri+1)
=>
F(R0) < F(R1) < ... <F(Rn) <F(R0)
=> F(R0) < F(R0)
Impossible
Page 29
Deadlock Avoidance
§8.5
Requires that the system has some additional a priori information
available.
Simplest and most useful model requires that
each process declare the maximum number
of resources of each type that it may need.
The deadlock-avoidance algorithm
dynamically examines the resourceallocation state to ensure that there can
never be a circular-wait condition.
Resource-allocation state is defined by the
number of available and allocated resources,
and the maximum demands of the processes.
Page 30
Safe State
§8.5.1
A state is safe if the system can allocate
resources to each process in some order
and still avoid a deadlock.
Safe sequence <P1, P2, ..., Pn> :
if, for each Pi, the resources that Pi can
still request can be safisfied by the
currently available resources plus the
resources held by all the Pj with j < i.
If no such sequence exists, then the
system is said to be unsafe.
Page 31
Safe State
A safe state is not a deadlock state.
A deadlock state is an unsafe state.
Not all unsafe states are deadlocks.
An unsafe state may lead to a
deadlock.
In unsafe state, OS cannot prevent
processes from requesting resources
and cause deadlock: the behavior of
the processes controls unsafe state.
Page 32
Safe State
Example: 12 tape drives, 3
processes.
max needs
current holding
P0
10
5
P1
4
2
P2
9
2
Safe for <P1,P0,P2>
If P2 request one more, system go
into unsafe state.
Page 33
Basic Facts
If a system is in safe
state  no deadlocks.
If a system is in
unsafe state 
possibility of deadlock.
Avoidance  ensure
that a system will
never enter an unsafe
state.
Page 34
Basic Facts
If a system is in safe
state
 noQuestion:
deadlocks.
True-False
) It is notisnecessary
that a system
If( a system
in
willstate
become
unsafe
 deadlocked even
when the
system reaching a
possibility
of deadlock.
unsafe state.
Avoidance
 ensure
that a system will
never enter an unsafe
state.
Answer: ○
Page 35
Resource-Allocation Graph
Algorithm
§8.5.2
Claim edge Pi  Rj indicated that process Pi
may request resource Rj at some time in the
future. It is represented by a dashed line.
Claim edge converts to request edge when a
process requests a resource.
When the resource is allocated to the process,
assignment edge is added.
When a resource is released by a process,
assignment edge reconverts to a claim edge.
P1
R1
Page 36
Safe State
A request can be granted only if converting the
request edge to assignment edge does not result
in the formation of a cycle in the resourceallocation graph.
If no cycle exists, then the allocation of the
resource will leave the system in a safe state.
Otherwise, process have to wait.
Page 37
Banker’s Algorithm (From SHAY)
§8.5.3
Multiple instances.
Each process must a priori claim
maximum use.
When a process requests a resource
it may have to wait.
When a process gets all its
resources it must return them in a
finite amount of time.
Page 38
Example 1
Maximum Number
Current Number
of pages allocated of pages needed
Process 1
Process 2
Process 3
Process 4
2
3
1
4
4
6
6
8
14 pages in the system
4 pages are unallocated
• Safe
• Process 1,2, or 4 could request its maximum
number of pages and finish
• For example: process 1 finish
Page 39
Example 1
Maximum Number
Current Number
of pages allocated of pages needed
Process 1
Process 2
Process 3
Process 4
2
3
1
4
4
6
6
8
14 pages in the system
6 pages are unallocated
• Now any process could request pages up to
its maximum and finish
• Suppose process 3 finish
Page 40
Example 1
Maximum Number
Current Number
of pages allocated of pages needed
Process 1
Process 2
Process 3
Process 4
2
3
1
4
4
6
6
8
14 pages in the system
7 pages are unallocated
• Any one can finish.
• However, a sequence of requests that allowed
all processes to finish does not indicate a
safe state.
Page 41
Example 1
Maximum Number
Current Number
of pages allocated of pages needed
Process 1
Process 2
Process 3
Process 4
2
3
1
4
5
4
6
6
8
14 pages in the system
0 pages are unallocated
• If process 3 requests the 4 available pages,
and each process subsequently requests 1
more page, the system is deadlocked
• However, it doesn't necessarily occur. ....A
unsafe state doesn't mean that the deadlock
will occur inevitably.
Page 42
Current Number
of pages allocated
Process 1
Process 2
Process 3
Process 4
1
2
2
1
Maximum Number
of pages needed
2
4
7
6
Example 2
7 pages in the system
1 pages are unallocated
Page 43
Current Number
of pages allocated
Maximum Number
of pages needed
Process 1
Process 2
Process 3
Process 4
1
2
2
1
2
4
7
6
Process 1
Process 2
Process 3
Process 4
1
2
2
1
2
4
7
6
Example 2
7 pages in the system
1 pages are unallocated
7 pages in the system
2 pages are unallocated
Page 44
Current Number
of pages allocated
Maximum Number
of pages needed
Process 1
Process 2
Process 3
Process 4
1
2
2
1
2
4
7
6
Process 1
Process 2
Process 3
Process 4
1
2
2
1
2
4
7
6
Process 1
Process 2
Process 3
Process 4
1
2
2
1
2
4
7
6
Example 2
7 pages in the system
1 pages are unallocated
7 pages in the system
2 pages are unallocated
7 pages in the system
4 pages are unallocated
If each process asserts its claim,
deadlock will occur
Unsafe !
Page 45
Banker’s Algorithm
Allocation
ABC
P0
P1
P2
P3
P4
0
2
3
2
0
1
0
0
1
0
0
0
2
1
2
Max
ABC
7
3
9
2
4
5
2
0
2
3
3
2
2
2
3
§8.5.3
Need
ABC
Available
ABC
3 3 2
P0
P1
P2
P3
P4
7
1
6
0
4
4
2
0
1
3
3
2
0
1
1
Safe state. <P1, P3, P4, P2, P0>
If request1=(1,0,2)
Page 46
Banker’s Algorithm
Allocation
ABC
P0
P1
P2
P3
P4
0
3
3
2
0
1
0
0
1
0
0
2
2
1
2
Max
ABC
7
3
9
2
4
5
2
0
2
3
3
2
2
2
3
§8.5.3
Need
ABC
Available
ABC
2 3 0
P0
P1
P2
P3
P4
7
0
6
0
4
4
2
0
1
3
3
0
0
1
1
Safe state. <P1, P3, P4, P2, P0>
If request1=(1,0,2)
Still safe with < P1, P3, P4, P0, P2 >
Page 47
Banker’s Algorithm
Allocation
ABC
P0
P1
P2
P3
P4
0
3
3
2
0
1
0
0
1
0
0
2
2
1
2
Max
ABC
7
3
9
2
4
5
2
0
2
3
3
2
2
2
3
§8.5.3
Need
ABC
Available
ABC
2 3 0
P0
P1
P2
P3
P4
7
0
6
0
4
4
2
0
1
3
3
0
0
1
1
Safe state. <P1, P3, P4, P2, P0>
Request4=(3,3,0)
Cannot be granted. No resources.
Page 48
Banker’s Algorithm
Allocation
ABC
P0
P1
P2
P3
P4
0
3
3
2
0
1
0
0
1
0
0
2
2
1
2
Max
ABC
7
3
9
2
4
5
2
0
2
3
3
2
2
2
3
§8.5.3
Need
ABC
Available
ABC
2 3 0
P0
P1
P2
P3
P4
7
0
6
0
4
4
2
0
1
3
3
0
0
1
1
Safe state. <P1, P3, P4, P2, P0>
Request0 =(0,2,0)
Will result in unsafe state.
Page 49
Deadlock Detection
§8.6
Allow system to enter deadlock state
System should provide:
An algorithm that examines the state of the
system to determine whether a deadlock has
occurred.
An algorithm to recover from the deadlock.
It requires overhead that includes
maintaining necessary information
executing the detection algorithm
potential losses when recovering
Page 50
Deadlock Detection
§8.6
Allow system to enter deadlock state
True-False
Question:
System
should
provide:
( An) Deadlock
prevention
is the
not state of the
algorithm that
examines
system
to determine
whether
required
for a system
that a deadlock has
occurred.
equipped with proper deadlock
Andetection
algorithmscheme.
to recover from the deadlock.
It requires overhead that includes
maintaining necessary information
executing
Answer:
× the detection algorithm
potential losses when recovering
Page 51
Single Instance of Each Resource Type
§8.6.1
Maintain wait-for graph: obtained from the
resource-allocation graph by removing the
nodes of type resource and collapsing the
appropriate edges.
Nodes are processes.
Pi  Pj if Pi is waiting for Pj. to release a
resource that Pi needs.
Needs to maintain the wait-for graph and
periodically invoke an algorithm that
searches for a cycle in the graph.
An algorithm to detect a cycle in a graph
requires an order of O(n2) operations,
where n is the number of vertices in the
graph.
Page 52
Resource-Allocation Graph
And Wait-for Graph
Resource-Allocation Graph
Corresponding wait-for graph
Page 53
Detection-Algorithm Usage
When, and how often, to invoke depends
on:
How often a deadlock is likely to occur?
How many processes will need to be rolled
back?
• one for each disjoint cycle
If deadlocks occur frequently, then the
detection algorithm should be invoked
frequently.
In the extreme, we could invoke the
deadlock-detection algorithm every time a
request for allocation cannot be granted
immediately.
Expensive
Page 54
Detection-Algorithm Usage
When, and how often, to invoke depends
on:
True-False Question:
often a deadlock is likely to occur?
( How
) Deadlock
detection algorithm
How many processes will need to be rolled
should be invoked only when the
back?
is deadlocked.
• system
one for each
disjoint cycle It therefore
examinesoccur
the system
allocation
If deadlocks
frequently,
then the
situation
and prepare
for be
a roll
detection
algorithm
should
invoked
back.
frequently.
InAnswer:
the extreme,
we could invoke the
×
deadlock-detection algorithm every time a
request for allocation cannot be granted
immediately.
Expensive
Page 55
Detection-Algorithm Usage
Less expensive alternative:invoke
the algorithm at less frequent
intervals.
If detection algorithm is invoked
arbitrarily, there may be many cycles
in the resource graph and so we
would not be able to tell which of the
many deadlocked processes “caused”
the deadlock.
Page 56
Several Instances of a Resource
§8.6.2
Type
Allocation
ABC
P0
P1
P2
P3
P4
0
2
3
2
0
1
0
0
1
0
0
0
3
1
2
Request
ABC
0
2
0
1
0
0
0
0
0
0
0
2
0
0
2
Available
ABC
0 0 0
Not deadlocked. <P0, P2, P3, P1, P4>
If P2 make request (0, 0, 1),
Deadlocked between P1, P2, P3, P4.
Page 57
Several Instances of a Resource
§8.6.2
Type
Allocation
ABC
P0
P1
P2
P3
P4
0
2
3
2
0
1
0
0
1
0
0
0
3
1
2
Request
ABC
0
2
0
1
0
0
0
0
0
0
0
2
1
0
2
Available
ABC
0 0 0
Not deadlocked. <P0, P2, P3, P1, P4>
If P2 make request (0, 0, 1),
Deadlocked between P1, P2, P3, P4.
Page 58
Recovery from Deadlock:
Process Termination
§8.7
Abort all deadlocked processes.
Expensive to discard and re-compute
partial computation.
Abort one process at a time until the
deadlock cycle is eliminated.
overhead for invoking deadlockdetection algorithm after each process
is aborted.
Page 59
Recovery from Deadlock:
Process Termination
We should abort those processes that will
incur the minimum cost when terminated.
In which order should we choose to abort?
Priority of the process.
How long process has computed, and how
much longer to completion.
Resources the process has used.
Resources process needs to complete.
How many processes will need to be
terminated.
Is process interactive or batch?
Page 60
Recovery from Deadlock:
Resource Preemption
Successively preempt some resources from
processes and give these resources to other
processes until the deadlock cycle is broken.
Three matters addressed:
Selecting a victim – Which resources and which
processes are to be preempted? We must determine
the order to minimize cost. Factors include:
• Number of resources a deadlock process is holding
• the amount of time a deadlocked process has consumed
Rollback – return to some safe state, restart process fro
that state. Requires the system to keep more
information about the state of all the running processes.
Starvation – same process may always be picked as
victim. Should include number of rollback in cost factor.
Page 61