Chapter 3: Deadlocks

Chapter 3
 Overview

 Resources
 Why do deadlocks occur?
 Dealing with deadlocks
 Ignoring them: ostrich algorithm
 Detecting & recovering from deadlock
 Avoiding deadlock
 Preventing deadlock

Chapter 3 2
 Resources

 Resource: something a process uses

 Usually limited (at least somewhat)
 Examples of computer resources
 Printers
 Semaphores / locks
 Tables (in a database)
 Processes need access to resources in reasonable order
 Two types of resources:
 Preemptable resources: can be taken away from a process with no ill
effects
 Nonpreemptable resources: will cause the process to fail if taken away

Chapter 3 3
 When do deadlocks happen?
 Suppose
 Process 1 holds resource A
and requests resource B Process 1 Process 2
 Process 2 holds B and
requests A A
 Both can be blocked, with
neither able to proceed B
 Deadlocks occur when …
 Processes are granted A
exclusive access to devices or
software constructs B
(resources)
 Each deadlocked process
needs a resource held by
another deadlocked process
DEADLOCK!

Chapter 3 4
 Using resources

 Sequence of events required to use a resource

 Request the resource
 Use the resource
 Release the resource
 Can’t use the resource if request is denied
 Requesting process has options
 Block and wait for resource
 Continue (if possible) without it: may be able to use an alternate
resource
 Process fails with error code
 Some of these may be able to prevent deadlock…

Chapter 3 5
 What is a deadlock?

 Formal definition:
“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.”
 Usually, the event is release of a currently held
resource
 In deadlock, none of the processes can
 Run
 Release resources
 Be awakened

Chapter 3 6
 Four conditions for deadlock

 Mutual exclusion
 Each resource is assigned to at most one process
 Hold and wait
 A process holding resources can request more resources
 No preemption
 Previously granted resources cannot be forcibly taken
away
 Circular wait
 There must be a circular chain of 2 or more processes
where each is waiting for a resource held by the next
member of the chain

Chapter 3 7
 Resource allocation graphs: Introduction

 Resource allocation
A B modeled by directed graphs
 Example 1:
 Resource R assigned to
R S process A
 Example 2:
 Process B is requesting /
waiting for resource S
T
 Example 3:
 Process C holds T, waiting
C D for U
 Process D holds U, waiting
U for T
 C and D are in deadlock!
Chapter 3 8
 Dealing with deadlock

 How can the OS deal with deadlock?

 Ignore the problem altogether!
 Hopefully, it’ll never happen…
 Detect deadlock & recover from it
 Dynamically avoid deadlock
 Careful resource allocation
 Prevent deadlock
 Remove at least one of the four necessary conditions
 We’ll explore these tradeoffs

Chapter 3 9
Getting into deadlock
A B C
Acquire R Acquire S Acquire T
Acquire S Acquire T Acquire R
Release R Release S Release T
Release S Release T Release R

A B C A B C A B C

R S T R S T R S T
Acquire R Acquire S Acquire T

A B C A B C A B C

R S T R S T R S T
Deadlock!
Acquire S Acquire T
Acquire R
Chapter 3 10
 Not getting into deadlock…

 Many situations may result in deadlock (but don’t

have to)
 In previous example, A could release R before C requests
R, resulting in no deadlock
 Can we always get out of it this way?
 Find ways to:
 Detect deadlock and reverse it
 Stop it from happening in the first place

Chapter 3 11
 The Ostrich Algorithm

 Pretend there’s no problem

 Reasonable if
 Deadlocks occur very rarely
 Cost of prevention is high
 UNIX and Windows take this approach
 Resources (memory, CPU, disk space) are plentiful
 Deadlocks over such resources rarely occur
 Deadlocks typically handled by rebooting
 Trade off between convenience and correctness

Chapter 3 12
 Detecting deadlocks using graphs

 Process holdings and requests in the table and in the graph

(they’re equivalent)
 Graph contains a cycle => deadlock!
 Easy to pick out by looking at it (in this case)
 Need to mechanically detect deadlock
 Not all processes are deadlocked (A, C, F not in deadlock)
R A B
Process Holds Wants
A R S
B T
C S D T E
C S
D U S,T
E T V F U V
F W S
G V U
W G
Chapter 3 13
 Deadlock detection algorithm

 General idea: try to find For each node N in the graph {

cycles in the resource Set L = empty list
unmark all arcs
allocation graph Traverse (N,L)
}
 Algorithm: depth-first If no deadlock reported by now,
search at each node there isn’t any
 Mark arcs as they’re
define Traverse (C,L) {
traversed If C in L, report deadlock!
 Build list of visited nodes Add C to L
For each unmarked arc from C {
 If node to be added is already
Mark the arc
on the list, a cycle exists! Set A = arc destination
 Cycle == deadlock /* NOTE: L is a
local variable */
Traverse (A,L)
}
}

Chapter 3 14
 Resources with multiple instances

 Previous algorithm only works if there’s one instance

of each resource
 If there are multiple instances of each resource, we
need a different method
 Track current usage and requests for each process
 To detect deadlock, try to find a scenario where all
processes can finish
 If no such scenario exists, we have deadlock

Chapter 3 15
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
Deadlock Avoidance
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 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
Safe State

 When a process requests an available resource, system

must decide if immediate allocation leaves the system
in a safe state
 System is in safe state if there exists a sequence
 <P1, P2, …, Pn> of ALL the processes in the systems
such that for each Pi, the resources that Pi can still
request can be satisfied by currently available resources
+ resources held by all the Pj, with j < I
 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
Avoidance Algorithms

 Single instance of a resource type

 Use a resource-allocation graph

 Multiple instances of a resource type

 Use the banker’s algorithm
Banker’s Algorithm

 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
 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]
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 an 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
Resource-Request Algorithm for Process Pi

Requesti = 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
3. Pretend to allocate requested resources to Pi by
modifying the state as follows:
Available = Available – Requesti;
Allocationi = Allocationi + Requesti;
Needi = Needi – Requesti;
 If safe  the resources are allocated to Pi
 If unsafe  Pi must wait, and the old resource-allocation
state is restored
 Example of Banker’s Algorithm

 5 processes P0 through P4;

3 resource types:
A (10 instances), B (5instances), and C (7
instances)
 Snapshot at time T0:
Allocation Max Available
ABC ABC ABC
P0 0 1 0 753 332
P1 2 0 0 322
P2 3 0 2 902
P3 2 1 1 222
P4 0 0 2 433
 Example (Cont.)
 The content of the matrix Need is defined to be Max –
Allocation

Need
ABC
P0 743
P1 122
P2 600
P3 011
P4 431

 The system is in a safe state since the sequence

 < P1, P3, P4, P2, P0> satisfies safety criteria
Allocation Max Available
ABC ABC ABC
P0 0 1 0 753 332
P1 2 0 0 322
P2 3 0 2 902
P3 2 1 1 222
P4 0 0 2 433
Need ABC
P0 7 4 3
P1 1 2 2
P2 6 0 0
P3 0 1 1
P4 4 3 1

Chapter 3 26
Chapter 3 27
Example: P1 Request (1,0,2)
 If Requesti  Needi then goto step-2 else ERROR
 Check that Request  Available (that is, (1,0,2)  (3,3,2)
 true
Allocation Need Available
ABC ABC ABC
P0 0 1 0 743 230
P1 3 0 2 020
P2 3 0 2 600
P3 2 1 1 011
P4 0 0 2 431
 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?
 Resource-Request Algorithm for Process Pi

Requesti = 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
3. Pretend to allocate requested resources to Pi by
modifying the state as follows:
Available = Available – Requesti;
Allocationi = Allocationi + Requesti;
Needi = Needi – Requesti;
 If safe  the resources are allocated to Pi
 If unsafe  Pi must wait, and the old resource-allocation
state is restored
 Deadlock Detection

 Allow system to enter deadlock state

 Detection algorithm

 Recovery scheme
 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
[i][j] = k, then process Pi is requesting k
more instances of resource type Rj.
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

 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 P i is deadlocked
Algorithm requires an order of O(m x n ) operations to detect
2

whether the system is in deadlocked state

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:

AllocationRequest Available
ABC ABC ABC
P0 010 000 000
P1 200 202
P2 303 000
P3 211 100
P4 002 002

 Sequence <P0, P2, P3, P1, P4> will result in Finish[i] =

true for all i
Example (Cont.)

 P2 requests an additional instance of type C

Request
ABC
P0 0 0 0
P1 2 0 2
P2 0 0 1
P3 1 0 0
P4 0 0 2
 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
Chapter 3 36
 Deadlock detection algorithm

current=avail;
A B C D
for (j = 0; j < N; j++) {
Avail 2 3 0 1 for (k=0; k<N; k++) {
if (finished[k])
continue;
Process A B C D if (want[k] < current) {
1 0 3 0 0 finished[k] = 1;
Hold

current += hold[k];
2 1 0 1 1 break;
3 0 2 1 0 }
4 2 2 3 0 if (k==N) {
printf “Deadlock!\n”;
Process A B C D // finished[k]==0 means process is in
// the deadlock
1 3 2 1 0 break;
Want

2 2 2 0 0 }
}
3 3 5 3 1
4 0 4 1 1 Note: want[j],hold[j],current,avail are arrays!
Chapter 3 37
 Recovering from deadlock

 Recovery through preemption

 Take a resource from some other process
 Depends on nature of the resource and the process
 Recovery through rollback
 Checkpoint a process periodically
 Use this saved state to restart the process if it is found deadlocked
 May present a problem if the process affects lots of “external” things
 Recovery through killing processes
 Crudest but simplest way to break a deadlock: kill one of the
processes in the deadlock cycle
 Other processes can get its resources
 Preferably, choose a process that can be rerun from the beginning
 Pick one that hasn’t run too far already

Chapter 3 38
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?

1. Priority of the process
2. How long process has computed, and how much
longer to completion
3. Resources the process has used
4. Resources process needs to complete
5. How many processes will need to be terminated
6. Is process interactive or batch?
 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
 Resource trajectories

Two process resource trajectories

CS 1550, cs.pitt.edu Chapter 3 41
(originaly modified by Ethan
 Safe and unsafe states
Has Max Has Max Has Max Has Max Has Max

A 3 9 A 3 9 A 3 9 A 3 9 A 3 9
B 2 4 B 4 4 B 0 - B 0 - B 0 -
C 2 7 C 2 7 C 2 7 C 7 7 C 0 -
Free: 3 Free: 1 Free: 5 Free: 0 Free: 7
Demonstration that the first state is safe

Has Max Has Max Has Max Has Max

A 3 9 A 4 9 A 4 9 A 4 9
B 2 4 B 2 4 B 4 4 B 0 -
C 2 7 C 2 7 C 2 7 C 2 7
Free: 3 Free: 2 Free: 0 Free: 4
Demonstration that the second state is unsafe

Chapter 3 42
 Banker's Algorithm for a single resource
Has Max Has Max Has Max

A 0 6 A 1 6 A 1 6
B 0 5 B 1 5 B 2 5
C 0 4 C 2 4 C 2 4
D 0 7 D 4 7 D 4 7
Free: 10 Free: 2 Free: 1
Any sequence finishes C,B,A,D finishes Deadlock (unsafe state)

 Bankers’ algorithm: before granting a request, ensure that a

sequence exists that will allow all processes to complete
 Use previous methods to find such a sequence
 If a sequence exists, allow the requests
 If there’s no such sequence, deny the request
 Can be slow: must be done on each request!
Chapter 3 43
Banker's Algorithm for multiple resources

Example of banker's algorithm with multiple resources

Chapter 3 44
 Preventing deadlock

 Deadlock can be completely prevented!

 Ensure that at least one of the conditions for
deadlock never occurs
 Mutual exclusion
 Circular wait
 Hold & wait
 No preemption
 Not always possible…

Chapter 3 45
 Eliminating mutual exclusion

 Some devices (such as printer) can be spooled

 Only the printer daemon uses printer resource
 This eliminates deadlock for printer
 Not all devices can be spooled
 Principle:
 Avoid assigning resource when not absolutely necessary
 As few processes as possible actually claim the resource

Chapter 3 46
 Attacking “hold and wait”

 Require processes to request resources before starting

 A process never has to wait for what it needs
 This can present problems
 A process may not know required resources at start of run
 This also ties up resources other processes could be using
 Processes will tend to be conservative and request resources they might
need
 Variation: a process must give up all resources before making
a new request
 Process is then granted all prior resources as well as the new ones
 Problem: what if someone grabs the resources in the meantime—how
can the process save its state?

Chapter 3 47
 Attacking “no preemption”
 This is not usually a viable option
 Consider a process given the printer
 Halfway through its job, take away the printer
 Confusion ensues!
 May work for some resources
 Forcibly take away memory pages, suspending the process
 Process may be able to resume with no ill effects

Chapter 3 48
 Attacking “circular wait”
 Assign an order to
resources
 Always acquire resources in D
numerical order
 Need not acquire them all at
once! C
 Circular wait is prevented 3 2
 A process holding resource n
can’t wait for resource m B
if m < n
1
 No way to complete a cycle
 Place processes above the
highest resource they hold A
and below any they’re
requesting
 All arrows point up!

Chapter 3 49
 Deadlock prevention: summary

 Mutual exclusion
 Spool everything
 Hold and wait
 Request all resources initially
 No preemption
 Take resources away
 Circular wait
 Order resources numerically

Chapter 3 50
 Example: two-phase locking

 Phase One
 Process tries to lock all data it needs, one at a time
 If needed data found locked, start over
 (no real work done in phase one)
 Phase Two
 Perform updates
 Release locks
 Note similarity to requesting all resources at once
 This is often used in databases
 It avoids deadlock by eliminating the “hold-and-
wait” deadlock condition
Chapter 3 51
 “Non-resource” deadlocks

 Possible for two processes to deadlock

 Each is waiting for the other to do some task
 Can happen with semaphores
 Each process required to do a down() on two semaphores
(mutex and another)
 If done in wrong order, deadlock results
 Semaphores could be thought of as resources…

Chapter 3 52
 Starvation

 Algorithm to allocate a resource

 Give the resource to the shortest job first
 Works great for multiple short jobs in a system
 May cause long jobs to be postponed indefinitely
 Even though not blocked
 Solution
 First-come, first-serve policy
 Starvation can lead to deadlock
 Process starved for resources can be holding resources
 If those resources aren’t used and released in a timely
fashion, shortage could lead to deadlock

Chapter 3 53