Operating Systems Principles Process Management and Coordination Lecture 6: Deadlocks

1
Operating Systems PrinciplesProcess Management
and CoordinationLecture 6 Deadlocks

• ??????

2
Content

• Deadlocks with Reusable and Consumable Resources
• Approaches to the Deadlock Problem
• System Model
• Resource Graphs
• State Transitions
• Deadlock States and Safe States
• Deadlock Detection
• Reduction of Resource Graphs
• Special Cases of Deadlock Detection
• Deadlock Detection in Distributed Systems
• Recovery from Deadlock
• Dynamic Deadlock Avoidance
• Claim Graphs
• The Bankers Algorithm
• Deadlock Prevention

3
Operating Systems PrinciplesProcess Management
and Coordination Lecture 6 Deadlocks

• Deadlocks with Reusable and Consumable Resources

4
Deadlocks
5
Deadlocks

• Informal definition Process is blocked on
  resource that will never be released.
• Deadlocks waste resources
• Deadlocks are rare
• Many systems ignore them
• Resolved by explicit user intervention
• Critical in many real-time applications
• May cause damage, endanger life

6
Reusable/Consumable Resources

• Reusable Resources
• Number of units is constant
• Unit is either free or allocated no sharing
• Process requests, acquires, releases units
• Examples (h/w) memory, devices (s/w) files,
  tables
• Consumable Resources
• Number of units varies at runtime
• Process may create new units
• Process may consume units (no releasing)
• Examples messages, signals

7
Reusable/Consumable Resources

• Reusable Resources
• Number of units is constant
• Unit is either free or allocated no sharing
• Process requests, acquires, releases units
• Examples (h/w) memory, devices (s/w) files,
  tables
• Consumable Resources
• Number of units varies at runtime
• Process may create new units
• Process may consume units (no releasing)
• Examples messages, signals

Main topic of the lecture Reusable Resources
8
Example (File Sharing)
p1 ... open(f1,w) open(f2,w) ...
p2 ... open(f2,w) open(f1,w) ...
Deadlock when executed concurrently
9
Example (Message Passing)
Assume that send/recv are blocking operations.
p1 ... if(C)send(p2,m) while(1)
recv(p3,m) ... send(p2,m)
p2 ... while(1) recv(p1,m) ...
send(p3,m)
p3 ... while(1) recv(p2,m) ...
send(p1,m)
Deadlock when C is not true
10
Deadlock, Livelock, and Starvation
Deadlock and livelock will lead to
starvation. But, the inverse is not necessary
true.

• Deadlock
• Two or more processes (threads) are blocked
  indefinitely, waiting for each other.
• Livelock
• Processes (threads) run but make no progress
• An active form of deadlock.
• Starvation
• Some Processes (threads) get deferred forever.
• E.g., one process dominates, not allowing other
  processes to progress.

11
ExamplesStarvation Not Due to Deadlock or
Livelock
Deadlock and livelock will lead to
starvation. But, the inverse is not necessary
true.

• Higher-Priority Process dominates
• ML scheduling where one queue is never empty
• Starvation on Memory Blocks
• Total memory is 200MB
• Unbounded stream of 100MB requests may starve a
  200MB request

12
Operating Systems PrinciplesProcess Management
and Coordination Lecture 6 Deadlocks

• Approaches to the Deadlock Problem

13
Approaches to Deadlock Problem

• Detection and Recovery
• Allow deadlock to happen and eliminate it
• Avoidance (dynamic)
• Runtime checks disallow allocationsthat might
  lead to deadlocks
• Prevention (static)
• Restrict type of request and acquisitionto make
  deadlock impossible

14
Operating Systems PrinciplesProcess Management
and Coordination Lecture 6 Deadlocks

• System Model

15
Resource Graph
Process Circle Resource Rectangle with small
circles for each unit Resource Request Edge
from process to resource class Resource
Allocation Edge from resource unit to process
16
State Transitions by p1 Process
The state transition diagram described below is
not complete. The actual number of states depends
on possible operations of processes.
S0
S1
S2
S3
17
Process Operations on Resources

• Request Create new request edge pi?Rj
• pi has no outstanding requests
• number of edges between pi and Rj ? units in Rj
• Acquisition Reverse request edge to pi?Rj
• All requests of pi are satisfied
• pi has no outstanding requests
• Release Remove edge pi?Rj

18
Deadlock States and Safe States

• A process is blocked in state S if it cannot
  cause a transition to a new state, i.e.,
• it cannot request, acquire, or release any
  resource.
• A Process is Deadlocked in state S if it blocked
  now and remains blocked forever.
• Deadlock State
• A state contains a deadlocked process.
• Safe State
• No deadlock state can ever be reached using
  request, acquire, release.

19
Example
p1 and p2 both need R1 and R2.
20
Example
21
Example
p1 Request(R1) Request(R2)
Release(R2) Release(R1)
22
Example
p1 Request(R1) Request(R2)
Release(R2) Release(R1)
23
Example
p1 Request(R1) Request(R2)
Release(R2) Release(R1)
p2 Request(R2) Request(R1)
Release(R1) Release(R2)
24
Example
25
Example
p1 is blocked.
p2 is blocked.
26
Example
No state is safe since the deadlock state is
always reachable.
A deadlock state.
27
Necessary Condition for Deadlock
A cycle in the resource graph is a necessary
condition for deadlock.
28
Operating Systems PrinciplesProcess Management
and Coordination Lecture 6 Deadlocks

• Deadlock Detection

29
Graph Reduction Technique

• Graph Reduction
• Repeat the following
• Select unblocked process p
• Remove p and all request and allocation edges
• Deadlock ? Graph not completely reducible.
• All reduction sequences lead to the same result.

30
Graph Reduction Technique

• Graph Reduction
• Repeat the following
• Select unblocked process p
• Remove p and all request and allocation edges

p1
p2
p3
R1
R2
R3
p4
p5
31
Graph Reduction Technique

• Graph Reduction
• Repeat the following
• Select unblocked process p
• Remove p and all request and allocation edges

p1
p2
p3
R1
R2
R3
p4
p5
32
Graph Reduction Technique

• Graph Reduction
• Repeat the following
• Select unblocked process p
• Remove p and all request and allocation edges

p1
p2
p3
R1
R2
R3
p4
p5
33
Graph Reduction Technique

• Graph Reduction
• Repeat the following
• Select unblocked process p
• Remove p and all request and allocation edges

p1
p2
p3
irreducible
R1
R2
R3
Deadlock detected
p4
p5
34
Graph Reduction Technique

• Graph Reduction
• Repeat the following
• Select unblocked process p
• Remove p and all request and allocation edges

35
Special Cases of Deadlock Detection

• Testing for specific process p
• Continuous deadlock detection
• Immediate allocations
• Single-unit resources

36
Testing for specific process

• Testing for specific process p
• Continuous deadlock detection
• Immediate allocations
• Single-unit resources

• Testing for specific process p
• Reduce until p is removed or graph irreducible

37
Continuous Deadlock Detection

• Testing for specific process p
• Continuous deadlock detection
• Immediate allocations
• Single-unit resources

• Testing for specific process p
• Reduce until p is removed or graph irreducible
• Continuous deadlock detection
• Current state not deadlocked
• Next state T deadlocked only if
• Operation was a request by p and
• p is deadlocked in T
• Try to reduce T by p

38
Immediate Allocations

• Testing for specific process p
• Continuous deadlock detection
• Immediate allocations
• Single-unit resources

• All satisfiable requests granted immediately
• Expedient state no satisfiable request edges

Non-Expedient State
Expedient State
Granted immediately
Satisfiable
39
Immediate Allocations

• Testing for specific process p
• Continuous deadlock detection
• Immediate allocations
• Single-unit resources

• All satisfiable requests granted immediately
• Expedient state no satisfiable request edges
• Knot K
• Every node in K reachable from any other node in
  K
• No outgoing edges (only incoming)
• Knot in expedient state ? Deadlock
• Intuition
• All processes must have outstanding requests in K
• Expedient state ? ? requests not satisfiable

40
Immediate Allocations

• Testing for specific process p
• Continuous deadlock detection
• Immediate allocations
• Single-unit resources

Expedient State
41
Immediate Allocations

• Testing for specific process p
• Continuous deadlock detection
• Immediate allocations
• Single-unit resources

Expedient State
Knot
42
Single-Unit Resources

• Testing for specific process p
• Continuous deadlock detection
• Immediate allocations
• Single-unit resources

• For single-unit resource, cycle ? deadlock
• Every p must have a request edge to R
• Every R must have an allocation edge to p
• R is not available and thus p is blocked

Deadlocked
Not Deadlocked
43
Single-Unit Resources

• Testing for specific process p
• Continuous deadlock detection
• Immediate allocations
• Single-unit resources

• Wait-For Graph (wfg) Show only processes

44
Deadlock Detection in Distributed Systems

• Central Coordinator Approach
• Distributed Approach

45
Central Coordinator Approach

• Central Coordinator (CC)
• Each machine maintains a local wfg
• Changes reported to CC
• CC constructs and analyzes global wfg
• Problems
• Coordinator is a performance bottleneck
• Communication delays may cause phantom deadlocks

46
Phantom Deadlocks
Due to timeout, p3 cancel the request. But, the
message passed to CC is delayed
Deadlock

• Central Coordinator (CC)
• Each machine maintains a local wfg
• Changes reported to CC
• CC constructs and analyzes global wfg
• Problems
• Coordinator is a performance bottleneck
• Communication delays may cause phantom deadlocks

?
p1 requesting the resource holding by p4 causes
phantom deadlock.
phantom edge
47
Distributed Approach

• Detect cycles using probes.
• If process pi blocked on pj , it launches probe
  pi ? pj
• pj sends probe pi ? pj ? pk along all request
  edges, etc.
• When probe returns to pi, cycle is detected

p1 ? p2 ? p3 ? p4 ? p5 ? p1
p1 ? p2 ? p3
p1? p2
p1 ? p2 ? p3 ? p4
p1 ? p2 ? p3 ? p4 ? p5
p1 ? p2 ? p3 ? p4 ? p5 ? p6? p4
p1 ? p2 ? p3 ? p4 ? p5 ? p6
p1 ? p2 ? p3 ? p7
48
Distributed Approach

• Detect cycles using probes.
• If process pi blocked on pj , it launches probe
  pi ? pj
• pj sends probe pi ? pj ? pk along all request
  edges, etc.
• When probe returns to pi, cycle is detected

Deadlock detected by M1.
Deadlock detected by M4.
p1 ? p2 ? p3 ? p4 ? p5 ? p1
p1 ? p2 ? p3
p1? p2
p1 ? p2 ? p3 ? p4
p1 ? p2 ? p3 ? p4 ? p5
p1 ? p2 ? p3 ? p4 ? p5 ? p6? p4
p1 ? p2 ? p3 ? p4 ? p5 ? p6
p1 ? p2 ? p3 ? p7
49
Operating Systems PrinciplesProcess Management
and Coordination Lecture 6 Deadlocks

• Recovery from Deadlock

50
Recovery from Deadlock

• Process termination
• Kill all processes involved in deadlock or
• Kill one at a time. In what order?
• By priority consistent with scheduling or
• By cost of restart length of recomputation or
• By impact on other processes CS,
  producer/consumer
• Resource preemption
• Direct Temporarily remove resource (e.g.,
  Memory)
• Indirect Rollback to earlier checkpoint

51
Operating Systems PrinciplesProcess Management
and Coordination Lecture 6 Deadlocks

• Dynamic
• Deadlock Avoidance

52
Deadlock Avoidance

• Deadlock Detection Recovery
• The resources requested by processes are granted
  as long as they are available.
• OS resolves deadlock if detected.
• Deadlock Avoidance
• Prevent deadlocks from developing by delaying
  acquisition of resources that might cause
  deadlock in the future.
• Deadlock cannot occur.

53
The Prior Knowledge for Deadlock Avoidance

• Deadlock avoidance requires some future knowledge
  of requests for resources from each of the
  participating processes.
• The precise knowledge is usually not available in
  advance.
• Processes specify maximum claim, i.e., the
  largest number of units of each resource needed
  at any one time.

54
Maximum Claim Graph (MCG)

• Process indicates maximum resources needed
• Potential request edge pi?Rj (dashed)
• May turn into real request edge

p1
p2
55
State Transition Using MCG

• Process indicates maximum resources needed
• Potential request edge pi?Rj (dashed)
• May turn into real request edge

S0
56
The Bankers Algorithm
Testing for safety algorithm (Dijkstra 1968)

• Theorem Prevent acquisitions from producing a
  irreducible claim graph ? All state are safe.
• Bankers algorithm
• Given a satisfiable request, p?R, temporarily
  grant request changing p?R to R?p
• Reduce new claim graph
• If it is completely reducible, proceed
• else reverse acquisition.

57
The Bankers Algorithm
58
The Bankers Algorithm
Can p1?R1 be safely be granted?
Can p2?R1 be safely be granted?
Can p3?R1 be safely be granted?
Which of the requests can safely be granted?
59
The Bankers Algorithm
Can p1?R1 be safely be granted?
Can p2?R1 be safely be granted?
Can p3?R1 be safely be granted?
Temporarily grant
Can such an RAG be completely reducible?
60
The Bankers Algorithm
Can p1?R1 be safely be granted?
?
Can p2?R1 be safely be granted?
Can p3?R1 be safely be granted?
p1
p2
p3
Temporarily grant
Can such an RAG be completely reducible?
61
The Bankers Algorithm
Can p1?R1 be safely be granted?
?
Can p2?R1 be safely be granted?
Can p3?R1 be safely be granted?
granted
Can such an RAG be completely reducible?
62
The Bankers Algorithm
Can p1?R1 be safely be granted?
?
Can p2?R1 be safely be granted?
Can p3?R1 be safely be granted?
63
The Bankers Algorithm
Can p1?R1 be safely be granted?
?
Can p2?R1 be safely be granted?
?
Can p3?R1 be safely be granted?
Temporarily grant
Can such an RAG be completely reducible?
64
The Bankers Algorithm
Can p1?R1 be safely be granted?
?
Can p2?R1 be safely be granted?
?
Can p3?R1 be safely be granted?
not granted
65
The Bankers Algorithm
Can p1?R1 be safely be granted?
?
Can p2?R1 be safely be granted?
?
Can p3?R1 be safely be granted?
66
The Bankers Algorithm
Can p1?R1 be safely be granted?
?
Can p2?R1 be safely be granted?
?
Can p3?R1 be safely be granted?
Temporarily grant
Can such an RAG be completely reducible?
67
The Bankers Algorithm
Can p1?R1 be safely be granted?
?
Can p2?R1 be safely be granted?
?
Can p3?R1 be safely be granted?
?
Temporarily grant
p1
p2
p3
Can such an RAG be completely reducible?
68
The Bankers Algorithm
Can p1?R1 be safely be granted?
?
Can p2?R1 be safely be granted?
?
Can p3?R1 be safely be granted?
?
granted
69
Special Case Single-Unit Resource

• Check for cycles after tentative acquisition
• Disallow if cycle is found
• If claim graph contains no undirected cycles,all
  states are safe
• No directed cycle can ever be formed. ?

70
Operating Systems PrinciplesProcess Management
and Coordination Lecture 6 Deadlocks

• Deadlock Prevention

71
Deadlock Prevention

• Deadlock Detection Recovery
• Granted resources as long as they are available.
• OS resolves deadlock if detected.
• Deadlock Avoidance
• Os performs runtime checks to ensure the system
• never enters unsafe state.
• Deadlock cannot occur.
• Deadlock Prevention
• All processes must follow certain rules for
  requesting and releasing resources.
• Deadlock is impossible to occur.

72
Conditions for a Deadlock
Eliminating any of these conditions would make
deadlock impossible.

• Mutual exclusion
• Resources are not sharable.
• Hold and wait
• Process must be holding one resource while
  requesting another.
• No preemption
• No resource is preemptable.
• Circular wait
• A closed chain of processes exists, such that
  each process holds at least one resources needed
  by the next process in the chain.

73
Deadlock Prevention

• Mutual exclusion
• Hold and wait
• No preemption
• Circular wait

Eliminating any of

• Eliminating the Mutual Exclusion Condition
• Not possible in most cases
• E.g., data files and databases for write access
  are not sharable.
• Spooling makes I/O devices sharable
• Virtual devices

74
Deadlock Prevention

• Mutual exclusion
• Hold and wait
• No preemption
• Circular wait

Eliminating any of

• Eliminating the Hold and Wait Condition
• Request all resources at once
• Release all resources before a new request
• Eliminating the No preemption Condition
• Release all resources if current request blocks

75
Deadlock Prevention

• Mutual exclusion
• Hold and wait
• No preemption
• Circular wait

Eliminating any of

• Eliminating the Circular Wait Condition
• Impose a total ordering of all resource types,
  and require that each process requests resources
  in an increasing order of enumeration.

Fact A cycle in the resource graph can develop
only when processes request the same resources in
the different order.
76
Comparisons