Operating Systems

Certificate Program in Software Development

CSE-TC and CSIM, AIT
September -- November, 2003

6. Deadlock
(Ch. 7, S&G)
ch 8 in the 6th ed.
 Objectives
– describe deadlock, and forms of prevention,
avoidance, detection, and recovery

OSes: 6. Deadlock 1
 Contents

1. What is Deadlock?
2. Dealing with Deadlock
3. Deadlock Prevention
4. Deadlock Avoidance
5. Deadlock Detection
6. Deadlock Recovery

OSes: 6. Deadlock 2
 1. What is Deadlock?

 An example from US Kansas law:

– “When two trains approach each other at a
crossing, both shall come to a full stop and
neither shall start up again until the other has
gone.”

OSes: 6. Deadlock 3
 In Picture Form: VUW CS 305

Neither truck can proceed.

OSes: 6. Deadlock 4
 1.1. System Deadlock

 A process must request a resource before

using it, and must release the resource after
finishing with it.

 A set of processes is in a deadlock state

when every process in the set is waiting for
a resource that can only be released by
another process in the set.
OSes: 6. Deadlock 5
 1.2. Necessary Conditions for Deadlock

 Mutual Exclusion
– at least one resource must be held in
non-shareable mode

 Hold and Wait

– a process is holding a resource and waiting
for others

OSes: 6. Deadlock
continued 6
  No Preemption
– only the process can release its held resource

 Circular Wait
– {P0, P1, …, Pn}
– Pi is waiting for the resource held by Pi+1;
Pn is waiting for the resource held by P0

OSes: 6. Deadlock 7
 1.3. Resource Allocation Graph

 A set of processes {P0, P1, …}

Pj

 A set of resource types {R1, R2, …},

together with instances of those types.

Rk

OSes: 6. Deadlock 8
 Edge Notation

 Pi  R j
– process i has requested an instance of resource j
– called a request edge

 Rj  P i
– an instance of resource j has been assigned to
process i
– called an assignment edge

OSes: 6. Deadlock 9
 Example Graph Fig. 7.1, p.211

R1 R3

P1 P2 P3

R4
R2

OSes: 6. Deadlock 10
 Finding a Deadlock

 If the graph has no cycles then there are no

deadlock processes.

 If there is a cycle, then there may be a

deadlock.

OSes: 6. Deadlock 11
 Graph with a Deadlock Fig. 7.2, p.212

R1 R3

P1 P2 P3

R4
R2

OSes: 6. Deadlock 12
 Graph without a Deadlock
Fig. 7.3, p.213
R1
P2

P1 P3

R2

P4
OSes: 6. Deadlock 13
 2. Deadling with Deadlocks

 Stop a deadlock ever occuring

– deadlock prevention
 disallow at least one of the necessary conditions

– deadlock avoidance
 see a deadlock coming and alter the
process/resource allocation strategy

OSes: 6. Deadlock
continued 14
  Deadlock detection and recovery

 Ignore the problem

– done by most OSes, including UNIX
– cheap solution
– infrequent, manual reboots may be acceptable

OSes: 6. Deadlock 15
 3. Deadlock Prevention

 Eliminate one (or more) of:

– mutual exclusion
– hold and wait
– no preemption (i.e. have preemption)
– circular wait

OSes: 6. Deadlock 16
 3.1. Eliminate Mutual Exclusion

 Shared resources do not require mutual

exclusion
– e.g. read-only files

 But some resources cannot be shared (at the

same time)
– e.g. printers

OSes: 6. Deadlock 17
 3.2. Eliminate Hold & Wait

 One approach requires that each process be

allocated all of its resources before it begins
executing
– eliminates the wait possibility

 Alternatively, only allow a process to

request resources when it currently has none
– eliminates the hold possibility

OSes: 6. Deadlock 18
 3.3. Eliminate “No Preemption”

 Make a process automatically release its

current resources if it cannot obtain all the
ones it wants
– restart the process when it can obtain everything

 Alternatively, the desired resources can be

preempted from other waiting processes

OSes: 6. Deadlock 19
 3.4. Eliminate Circular Wait

 Impose a total ordering on all the resource

types, and force each process to request
resources in increasing order.

 Another approach: require a process to

release larger numbered resources when it
obtains a smaller numbered resource.

OSes: 6. Deadlock 20
 4. Deadlock Avoidance

 In deadlock avoidance, the necessary

conditions are untouched.

 Instead, extra information about resources

is used by the OS to do better forward
planning of process/resource allocation
– indirectly avoids circular wait

OSes: 6. Deadlock 21
 4.1. Safe States
 An OS is in a safe state if there is a
safe sequence of process executions
<P1, P2, …, Pn>.

 In a safe sequence, each Pi can satisfy its

resource requests by using the currently
available resources and (if necessary) the
resources held by Pj (j < i)
– only when Pj has finished
OSes: 6. Deadlock 22
 Safe State Implications Fig. 7.4, p.218

 A safe state cannot lead to deadlock. Deadlock

Unsafe
 An unsafe state may lead to deadlock.
Safe
 Deadlock is avoided by always
keeping the system in a safe state
– this may reduce resource utilization

OSes: 6. Deadlock 23
 Example 1 p.218

 Max no. of resources: 12 tape drives

 Max needs Current Allocation
P0 10 5
P1 4 2
P2 9 2

 Currently, there are 3 free tape drives

 The OS is in a safe state, since <P1, P0, P2> is

a safe sequence.
OSes: 6. Deadlock 24
 Example 2

 Same as last slide, but P2 now has 3 tape drives

allocated currently.

 Max needs Current Allocation

P0 10 5
P1 4 2
P2 9 3

 The OS is in an unsafe state.

OSes: 6. Deadlock 25
 4.2. Using Resource Allocation Graphs

 Assume a resource type only has one

instance.

 Add a claim edge:

– Pi  Rj
– process Pi may request a resource Rj in the future
– drawn as a dashed line

OSes: 6. Deadlock
continued 26
  When the resource is actually requested,
the claim edge is changed to a request
edge.

 When an assignment is released, the

assignment edge is changed back to a
claim edge.

OSes: 6. Deadlock
continued 27
  All resources must be claimed before
system start-up.

 An unsafe state is caused by a cycle in the

resource allocation graph.

OSes: 6. Deadlock 28
 Example Figs 7.5, 7.6, p.220-221

R1 R1

P1 P2 P1 P2

R2 R2

R2 allocation to P2
creates an unsafe state
OSes: 6. Deadlock 29
 4.3. Banker’s Algorithm

 Assume that:
– a resource can have multiple instances
– the OS has N processes, M resource types

 Initially, each process must declare the

maximum no. of resources it will need.

 Calculate a safe sequence if possible.

OSes: 6. Deadlock 30
 Banker Data Structures
 Available[M]
– no. of available resource instances for each
resource type
– e.g. Available[j] == k means K Rj’s

 Max[N][M]
– max demand of each process
– e.g. max[i][j] == k means Pi wants k Rj’s

OSes: 6. Deadlock
continued 31
  Work[M]
– no. of resource instances available for work
(by all processes)
– e.g. Work[j] == k means K Rj’s are available

 Finish[N]
– record of finished processes
– e.g. Pi is finished if Finish[i] == true

OSes: 6. Deadlock
continued 32
  Allocation[N][M]
– no. of resource instances allocated to each process
– e.g. Allocation[i][j] == k
means Pi currently has k Rj’s

 Need[N][M]
– no. of resource instances still needed by each process
– e.g. Need[i][j] == k
means Pi still needs k Rj’s
– Need[i][j] == Max[i][j] - Allocation[i][j]

OSes: 6. Deadlock
continued 33
  Request[N][M]
– no. of resource instances currently requested by
each process
– e.g. Request[i][j] == k
means Pi has requested k Rj’s

OSes: 6. Deadlock 34
 Vectors shorthand for
referring to the
 Allocation[i] 2D data structures

– resources currently allocated to Pi

 Need[i]
– resources still needed by Pi

 Request[i]
– resources currently requested by Pi

OSes: 6. Deadlock 35
 The Safety Algorithm VUW CS 305;
p221-222

1 Vector Copy: Work := Available; Finish := false

2 Find i such that Pi hasn’t finished but could:
Finish[i] == false
Need[i] <= Work
If no suitable i, go to step 4.
3 Assume Pi completes:
Work := Work + Allocation[i]
Finish[i] := true
go to step 2
4 If for all i Finish[i] == true then Safe-State
OSes: 6. Deadlock 36
 Safety Example p.222

 Resource Type Instances

A 10
B 5
C 7

OSes: 6. Deadlock
continued 37
 Allocation Max Available Need
A B CA B C A B C A B C
P0 0 1 0 7 5 3 3 3 2 7 4 3
P1 2 0 0 3 2 2 1 2 2
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1

 The OS is in a safe state since

<P1, P3, P4, P2, P0> is a safe sequence.

OSes: 6. Deadlock 38
 VUW CS 305;
Request Resource Algorithm p.222

1 If (Need[i] < Request[i]) then max-error

2 While (Available < Request[i]) do wait
3 Construct a new state by:
Available = Available - Request[i]
Allocation[i] = Allocation[i] + Request [i]
Need[i] = Need[i] - Request [i]
4 If (new state is not safe) then
restore and wait
OSes: 6. Deadlock 39
 Request Example 1

 At some time, P1 requests an additional

1 A instance and 2 C instances
– i.e. Request[1] == (1, 0, 2)

 Does this lead to a safe state?

– Available >= Request[1] so continue
– generate new state and test for safety

OSes: 6. Deadlock 40
 Allocation Max Available Need
A B CA B C A B C A B C
P0 0 1 0 7 5 3 2 3 0 7 4 3
P1 3 0 2 3 2 2 0 2 0
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 3

 The OS is in a safe state since

<P1, P3, P4, P0, P2> is a safe sequence.

OSes: 6. Deadlock 41
 Further Request Examples

 From this state, P4 requests a further (3,3,0)

– cannot be granted, since insufficient resources

 Alternatively, P0 requests a further (0,2,0)

– should not be granted since the resulting state is
unsafe

OSes: 6. Deadlock 42
 5. Deadlock Detection

 If there are no prevention or avoidance

mechanisms in place, then deadlock may occur.

 Deadlock detection should return enough

information so the OS can recover.

 How often should the detection algorithm be

executed?
OSes: 6. Deadlock 43
 5.1. Wait-for Graph
 Assume that each resource has only one
instance.

 Create a wait-for graph by removing the

resource types nodes from a resource
allocation graph.

 Deadlock exists if and only if the wait-for

graph contains a cycle.
OSes: 6. Deadlock 44
 Example Fig. 7.7, p.225

P5

R1 R3 R4 P5

P1 P2 P3 P1 P2 P3

R2 P4 R5 P4

OSes: 6. Deadlock 45
 5.2. Banker’s Algorithm Variation

 If a resource type can have multiple

instances, then an algorithm very similar to
the banker’s algorithm can be used.

 The algorithm investigates every possible

allocation sequence for the processes that
remain to be completed.

OSes: 6. Deadlock 46
 VUW CS 305;
Detection Algorithm p.225

1 Vector Copy: Work := Available; Finish := false

2 Find i such that Pi hasn’t finished but could:
Finish[i] == false
Request[i] <= Work
If no suitable i, go to step 4.
3 Assume Pi completes:
Work := Work + Allocation[i]
Finish[i] := true
go to step 2
4 If Finish[i] == false then Pi is deadlocked
OSes: 6. Deadlock 47
 Example 1 p.226

 Resource Type Instances

A 7
B 2
C 6

OSes: 6. Deadlock
continued 48
 Allocation Request Available
A B CA B C A B C
P0 0 1 0 0 0 0 0 0 0
P1 2 0 0 2 0 2
P2 3 0 3 0 0 0
P3 2 1 1 1 0 0
P4 0 0 2 0 0 2

 The OS is not in a deadlocked state since

<P0, P2, P3, P1, P4> is a safe sequence.

OSes: 6. Deadlock 49
 Example 2
 Change P2 to request 1 C instance
Allocation Request Available
A B CA B C A B C
P0 0 1 0 0 0 0 0 0 0
P1 2 0 0 2 0 2
P2 3 0 3 0 0 1
P3 2 1 1 1 0 0
P4 0 0 2 0 0 2

 The OS is deadlocked.
OSes: 6. Deadlock 50
 6. Deadlock Recovery

 Tell the operator

 System-based recovery:
– abort one or more processes in the circular wait

– preempt resources in one or more deadlocked

processes

OSes: 6. Deadlock 51
 6.1. Process Termination

 Abort all deadlocked processes, or

 Abort one process at a time until the

deadlocked cycle disappears
– not always easy to abort a process
– choice should be based on minimum cost

OSes: 6. Deadlock 52
 6.2. Resource Preemption

 Issues:
– how to select a resource
(e.g. by using minimum cost)

– how to rollback the process which has just lost

its resources

– avoiding process starvation

OSes: 6. Deadlock 53