Chapter 7: Deadlocks
Chapter 7: Deadlocks
 The Deadlock Problem
 System Model
 Deadlock Characterization
 Methods for Handling Deadlocks
 Deadlock Prevention
 Deadlock Avoidance
 Deadlock Detection
 Recovery from Deadlock
7.2/61
Chapter Objectives
 To develop a description of deadlocks,
which prevent sets of concurrent
processes from completing their tasks
 To present a number of different methods
for preventing or avoiding deadlocks in a
computer system.
7.3/61
The Deadlock Problem
 A set of blocked processes each holding a resource
and waiting to acquire a resource held by another
process in the set.
 多个进程因竞争资源而造成的一种僵局，若无外力作用
，这些进程都将永远不能再向前推进。
 Example

System has 2 disk drives.

P1 and P2 each hold one disk drive and each needs
another one.
P245
7.4/61
The Deadlock Problem
 Example

semaphores A and B, initialized to 1
P0
P1
wait (A);
wait(B)
wait (B);
wait(A)
7.5/61
Bridge Crossing Example
 Traffic only in one direction.
 Each section of a bridge can be viewed as a resource.
 If a deadlock occurs, it can be resolved if one car backs up
(preempt resources and rollback).
 Several cars may have to be backed up if a deadlock
occurs.
 Starvation is possible.
7.6/61
System Model
 Resource types R1, R2, . . ., Rm
CPU cycles, memory space, I/O devices
 Each resource type Ri has Wi identical instances.
 If a process requests an instance of a resource
type, the allocation of any instance of the type will
satisfy the request.
 Each process utilizes a resource as follows:
 request
 use

release
P245
7.7/61
Possibility of deadlock
 a deadlock involving the same resource type

a system with three CDRW drive. Suppose each of
three processes holds one of these CDRW drives.
If each process now requests another drive, the
three processes will be in a deadlock state.
 a deadlock involving the different resource types

a system with one printer and one DVD drive.
Suppose that the process Pi is holding the DYD
and process Pj is holding the printer. If Pi requests
the printer and Pj requests DVD drive, a deadlock
occurs.
P247
7.8/61
Multithreaded programming
 A programmer who is developing multithreaded
applications must pay particular attention to this
problem.
 Multithreaded programs are good candidates for
deadlock because multiple threads can compete for
shared resources.
7.9/61
Deadlock Characterization
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, …, Pn} 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.
P247-249
7.10/61
Resource-Allocation Graph
A set of vertices V and a set of edges E.
 V is partitioned into two types:

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 P1  Rj
 assignment edge – directed edge Rj  Pi
P249
7.11/61
Resource-Allocation Graph (Cont.)
 Process
 Resource Type with 4 instances
 Pi requests instance of Rj
 Pi is holding an instance of Rj
7.12/61
Pi
Pi
Rj
Rj
Example of a Resource Allocation Graph
7.13/61
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.
P250
7.14/61
Resource Allocation Graph With A Deadlock
7.15/61
Graph With A Cycle But No Deadlock
7.16/61
Methods for Handling Deadlocks
 Ensure that the system will never enter a deadlock
state.
 Allow the system to enter a deadlock state and
then recover.
 Ignore the problem and pretend that deadlocks
never occur in the system.
Which is most likely in existing operating system?
P252
7.17/61
Deadlocks Never Occur
 Deadlock prevention provides a set of methods for
ensuring that at least one of the necessary conditions
cannot hold. These methods prevent deadlocks by
constraining how requests for resources can be made.
 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, it 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.
P252
7.18/61
Deadlocks Occur
 If a system does not employ either a deadlock-prevention or
a deadlock avoidance algorithm, then a deadlock situation
may arise.
 In this environment, the system can provide an algorithm
that examines the state of the system to determine whether
a deadlock has occurred and an algorithm to recover from
the deadlock
 If a system neither ensures that a deadlock never occur or
provides a mechanism for deadlock detection and recovery,
then we may arrive at a situation where the system is in a
deadlocked state yet has no way of recognizing what has
happened.
7.19/61
Deadlocks Occur
 the undetected deadlock will result in deterioration of the
system 's performance, because resources are being held
by processes that can not run and because more and more
processes, as they make requests for resources, will enters
a deadlock state. Eventually, the system will stop
functioning and need to be restarted manually.
 In many systems, deadlocks occur infrequently (say, once
per year), thus, this method is cheaper than the prevention,
avoidance, or detection and recover methods, which must
be used constantly.
 Also, in some circumstances, a system is in a frozen state
but not in a deadlocked state.
7.20/61
Deadlock Prevention
 for a deadlock to occur, each of the four necessary
conditions must hold. By ensuring that at least one of
these conditions cannot hold, we can prevent the
occurrence of a deadlock.
----------------------------------------------------------------- Mutual Exclusion – not required for sharable
resources; must hold for non-sharable resources.
P253
7.21/61
Deadlock Prevention
 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. Before it can request any additional
resources, however, it must release all the resources that
it is currently allocated.
------------------------------------------------------------------
Low resource utilization; starvation possible.
7.22/61
Deadlock Prevention
 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.
------------------------------------------------------------

starvation possible.
7.23/61
Deadlock Prevention
 Circular Wait – impose a total ordering of all resource
types, and require that each process requests
resources in an increasing order of enumeration.

P255 example
--------------------------------------------------------------
Proper order is very difficult to define to meet every
process
7.24/61
Deadlock Avoidance
 Possible side effects of preventing deadlocks by this
method, however, are low device utilization and reduced
system throughput.
 With this knowledge of the complete sequence of
requests and releases for each process, the system can
decide for each request whether or not the process
should wait in order to avoid a possible future deadlock.
 Each request requires that in making this decision the
system consider the resources currently available, the
resources currently allocated to each process, and the
future requests and releases of each process.
P256
7.25/61
Deadlock Avoidance
 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 resource-allocation 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.
7.26/61
Safe State
 When a process requests an available resource, system
must decide if immediate allocation leaves the system in a
safe state.
 A state is safe if the system can allocate resources to each
process (up to its maximum) in some order and still avoid a
deadlock.
 More formally, a system is in a safe state only if there exists
a safe sequence. A sequence of processes
 (P1, P2, ..., Pn> is a safe sequence for the current allocation
state if, for each Pi, the resource requests that Pi, can still
make can be satisfied by the currently available resources
plus the resources held by all Pj, with j < i.
7.27/61
Safe State
 That is:
 If
Pi resource needs are not immediately
available, then Pi can wait until all Pj have
finished.
 When
Pj is finished, Pi can obtain needed
resources, execute, return allocated
resources, and terminate.
 When
Pi terminates, Pi +1 can obtain its
needed resources, and so on.
7.28/61
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.
7.29/61
Safe, Unsafe , Deadlock State
7.30/61
Example
 a system with 12 magnetic tape drives and three
processes: P0,P1 and P2. Process P0 requires 10
tape drives, process P1 may need as many as 4 tape
drives, and process P2 may need up to 9 tape drives.
 Suppose that, at time t0, process P0 is holding 5 tape
drives, process P1 is holding 2 tape drives, and
process P2 is holding 2 tape drives. (Thus, there are
3 free tape drives.)
P257
7.31/61
Example
 At time t0, the system is in a safe state. The sequence <
P1, P0, P2> satisfies the safety condition.
 at time t1 , process P2 requests and is allocated one
more tape drive. The system is no longer in a sate
state. Why?
7.32/61
Avoidance algorithms
 Single instance of a resource type. Use a
resource-allocation graph
 Multiple instances of a resource type. Use
the banker’s algorithm
7.33/61
Resource-Allocation Graph Scheme
 Claim edge Pi  Rj indicated that process Pj may
request resource Rj; represented by a dashed line.
 Claim edge converts to request edge when a process
requests a resource.
 Request edge converted to an assignment edge when
the resource is allocated to the process.
 Resources must be claimed a priori in the system.
P258
7.34/61
Resource-Allocation Graph
7.35/61
Resource-Allocation Graph Algorithm
 Suppose that process P2 requests a resource R2
 The request can be granted only if converting the
request edge to an assignment edge does not result in
the formation of a cycle in the resource allocation
graph
 If no cycle exists, then the allocation of the resource
will leave the system in a safe state. If a cycle is
found, then the allocation will put the system in an
unsafe state. Therefore, process P2, will have to wait
for its requests to be satisfied.
7.36/61
Unsafe State In Resource-Allocation Graph
7.37/61
Banker’s Algorithm
 For resources of multiple instances.
 the bank never allocated its available cash in such a way
that it could no longer satisfy the needs of all its customers.
 When a new process enters the system, it must declare the
maximum number of instances of each resource type that it
may need. This number may not exceed the total number of
resources in the system.
 When a user requests a set of resources, the system must
determine whether the allocation of these resources will
leave the system in a safe state. If it will, the resources are
allocated; otherwise, the process must wait until some other
process releases enough resources.
P259
7.38/61
Data Structures for the Banker’s Algorithm
Let n = number of processes, and m = number of resources types.
 Available: Vector of length m. If available [j] = k,
there are k instances of resource type Rj available.
 Max: n x m matrix. If Max [i,j] = k, then process Pi
may request at most k instances of resource type Rj.
 Allocation: n x m matrix. If Allocation[i,j] = k then Pi
is currently allocated k instances of Rj.
 Need: n x m matrix. If Need[i,j] = k, then Pi may need
k more instances of Rj to complete its task.
Need [i,j] = Max[i,j] – Allocation [i,j].
7.39/61
Safety Algorithm
1. Let Work and Finish be vectors of length m and n,
respectively. Initialize:
Work = Available
Finish [i] = false for i = 0, 1, …, n- 1.
2. Find and i such that both:
(a) Finish [i] = false
(b) Needi  Work
If no such i exists, go to step 4.
3. Work = Work + Allocationi
Finish[i] = true
go to step 2.
4. If Finish [i] == true for all i, then the system is in a
safe state.
7.40/61
example
 假定系统中有5个进程{P0，P1，P2，P3，P4}和3种
类型的资源{A，B，C}，每一种资源的数量分别为10
、5、7，在T0时刻的资源分配情况如下：
P0
Max
Allocation
A B C A
B
C
7 5 3 0 1
0
Need
A B
7 4
C
3
P1
3 2
2 2
0
0
1
2
2
P2
9 0
2 3
0
2
6
0
0
P3
2 2
2 2
1
1
0
1
1
P4
4 3
3 0
0
2
4
3
1
7.41/61
Available
A
B
C
3 3
2
example
安全性检查算法的执行结果如下：
Work
ABC
P1 3 3 2
Need
Allocation
AB C AB C
122
20 0
Work+Allocation
A B C
5 3 2
Finish
P3 5 3 2
011
21 1
7 4 3
True
P4 7 4 3
431
00 2
7 4 5
True
P0 7 4 5
743
01 0
7 5 5
True
P2 7 5 5
600
30 2
10 5 7
True
安全序列：P1、P3、P4、P0、P2
7.42/61
True
Resource-Request Algorithm for Process Pi
Request = request vector for process Pi. If Requesti
[j] = k then process Pi wants k instances of resource
type Rj.
1. If Requesti  Needi go to step 2. Otherwise, raise
error condition, since process has exceeded its
maximum claim.
2. If Requesti  Available, go to step 3. Otherwise Pi
must wait, since resources are not available.
7.43/61
Resource-Request Algorithm for Process Pi
3. Pretend to allocate requested resources to Pi by
modifying the state as follows:
Available = Available – Request;
Allocationi = Allocationi + Requesti;
Needi = Needi – Requesti;
safe  the resources are allocated to Pi.
 If unsafe  Pi must wait, and the old resourceallocation state is restored
 If
7.44/61
Example: P1 Request (1,0,2)
 Check that Request Need((1,0,2) (1,2,2)  true.)
 Check that Request  Available (that is, (1,0,2) 
(3,3,2)  true.)
 Pretend to allocate:
Allocation Need Available
ABC
ABC
ABC
P0 0 1 0
743
230
P1 3 0 2
020
P2 3 0 1
600
P3 2 1 1
011
P4 0 0 2
431
7.45/61
Example: P1 Request (1,0,2)
 Executing safety algorithm shows that sequence <
P1, P3, P4, P0, P2> satisfies safety requirement.

见下页
 Can request for (3,3,0) by P4 be granted?
 Can request for (0,2,0) by P0 be granted?
7.46/61
Example: P1 Request (1,0,2)
Work
A B
Need
C A B
Allocation Work+Allocation Finish
C A B
C
A B
C
P1 2
3
0 0
2
0 3
0
2
5
3
2
True
P3 5
3
2 0
1
1 2
1
1
7
4
3
True
P4 7
4
3 4
3
1 0
0
2
7
4
5
True
P0 7
4
5 7
4
3 0
1
0
7
5
5
True
P2 7
5
5 6
0
0 3
0
2
10 5
7
True
安全序列：P1、P3、P4、P0、P2
7.47/61
Deadlock Detection
 Allow system to enter deadlock state
 Detection algorithm
 Recovery scheme
P262
7.48/61
Single Instance of Each Resource Type
 Maintain wait-for graph

Nodes are processes.

Pi  Pj if Pi is waiting for Pj.
 Periodically invoke an algorithm that searches for a
cycle in the graph. If there is a cycle, there exists a
deadlock.
 An algorithm to detect a cycle in a graph requires an
order of n2 operations, where n is the number of
vertices in the graph.
7.49/61
Resource-Allocation Graph and Wait-for Graph
Corresponding wait-for graph
Resource-Allocation Graph
7.50/61
Several Instances of a Resource Type
 Available: A vector of length m indicates the
number of available resources of each type.
 Allocation: An n x m matrix defines the
number of resources of each type currently
allocated to each process.
 Request: An n x m matrix indicates the
current request of each process. If Request
[ij] = k, then process Pi is requesting k more
instances of resource type. Rj.
P263
7.51/61
Detection Algorithm
1. Let Work and Finish be vectors of length m and n,
respectively Initialize:
(a) Work = Available
(b)For i = 1,2, …, n, if Allocationi  0, then
Finish[i] = false;otherwise, Finish[i] = true.
2. Find an index i such that both:
(a)Finish[i] == false
(b)Requesti  Work
If no such i exists, go to step 4.
7.52/61
Detection Algorithm (Cont.)
3. Work = Work + Allocationi
Finish[i] = true
go to step 2.
4. If Finish[i] == false, for some i, 1  i  n, then the
system is in deadlock state. Moreover, if Finish[i]
== false, then Pi is deadlocked.
Algorithm requires an order of O(m x n2) operations
to detect whether the system is in deadlocked
state.
7.53/61
Example of Detection Algorithm
 Five processes P0 through P4; three resource types
A (7 instances), B (2 instances), and C (6 instances).
 Snapshot at time T0:
Allocation Request Available
ABC
ABC
ABC
P0 0 1 0
000
000
P1 2 0 0
202
P2 3 0 3
000
P3 2 1 1
100
P4 0 0 2
002
 Sequence <P0, P2, P3, P1, P4> will result in Finish[i] =
true for all i.
7.54/61
Example (Cont.)
 P2 requests an additional instance of type C.
Request
ABC
P0 0 0 0
P1 2 0 1
P2 0 0 1
P3 1 0 0
P4 0 0 2
7.55/61
Example (Cont.)
 State of system?

Can reclaim resources held by process P0, but
insufficient resources to fulfill other processes;
requests.

Deadlock exists, consisting of processes P1, P2, P3,
and P4.
7.56/61
Detection-Algorithm Usage
 When should we invoke the detection algorithm
depends on:

How often a deadlock is likely to occur?

How many processes will be affected by deadlock
when it happens?
 If deadlocks occur frequently, then the detection
algorithm should be invoked frequently. resources
allocated to deadlocked processes will be idle until the
deadlock can be broken. In addition, the number of
processes involved in the deadlock cycle may grow.
P265
7.57/61
When to Invoke Detection-Algorithm
 we can invoke the deadlock detection algorithm every time a
request for allocation cannot be granted immediately. In this
case, we can identify not only the deadlocked set of
processes but also the specific process that "caused" the
deadlock.

a considerable overhead in computation time.
 once per hour
 whenever CPU utilization drops below 40 percent.
7.58/61
Recovery from Deadlock: Process Termination
 Abort all deadlocked processes.
 Abort one process at a time until the deadlock cycle is
eliminated.
 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 7.59/61
batch?
P266
Recovery from Deadlock: Resource Preemption
 Selecting a victim – minimize cost.
 Rollback – return to some safe state, restart
process for that state.
 Starvation – same process may always be picked
as victim, include number of rollback in cost factor.
7.60/61
Homework：1、2、11
End of Chapter 7