1. Operating Systems Principles Process Management and Coordination Lecture 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 Banker’s Algorithm
Deadlock Prevention

3. Deadlocks with Reusable and Consumable Resources
Operating Systems Principles Process 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)
...
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.
Example (Message Passing)
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, Livelock, and Starvation
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. Examples: Starvation Not Due to Deadlock or Livelock
Deadlock and livelock will lead to starvation.
But, the inverse is not necessary true.
Examples: Starvation Not Due to Deadlock or Livelock
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. Approaches to the Deadlock Problem
Operating Systems Principles Process 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 allocations that might lead to deadlocks
Prevention (static)
Restrict type of request and acquisition to make deadlock impossible

14. Operating Systems Principles Process 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.
State Transitions by p1 Process R p1 p2 R p1 p2 R p1 p2 R p1 p2
Request R
(by p1)
Acquire R
(by p1)
Release R
(by p1) 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
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. p1: Request(R1); Request(R2);
Release(R2);
Release(R1);
p2:
Request(R2);
Request(R1);
Release(R1);
Release(R2); R1 R2 p1 p2

20. Example p1: Request(R1); Request(R2); Release(R2); Release(R1); p2:

21. Example p1: Request(R1); Request(R2); Release(R2); Release(R1); p2:

22. Example p1: Request(R1); Request(R2); Release(R2); Release(R1); p2:

23. Example p1: Request(R1); Request(R2); Release(R2); Release(R1); p2:

24. Example R1 R2 p1 p2

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 Principles Process Management and Coordination Lecture 6: Deadlocks
Deadlock Detection

29. Graph Reduction Technique
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
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
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
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
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
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
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
Continuous Deadlock Detection
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
Immediate Allocations
All satisfiable requests granted immediately
Expedient state = no satisfiable request edges
Non-Expedient State
Expedient State
Granted
immediately p1 p2 p4 p5 p3 R1 R2 R3 p1 p2 p4 p5 p3 R1 R2 R3
Satisfiable

39. Immediate Allocations
Testing for specific process p
Continuous deadlock detection
Immediate allocations
Single-unit resources
Immediate Allocations
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
Sufficient condition for deadlock.

40. Sufficient Condition for Deadlock
Testing for specific process p
Continuous deadlock detection
Immediate allocations
Single-unit resources
Sufficient Condition for Deadlock
Expedient State p1 p2 p4 p5 p3 R1 R2 R3

41. Sufficient Condition for Deadlock
Testing for specific process p
Continuous deadlock detection
Immediate allocations
Single-unit resources
Sufficient Condition for Deadlock
Expedient State p1 p2 p4 p5 p3 R1 R2 R3
Knot

42. Sufficient Condition for Deadlock
Testing for specific process p
Continuous deadlock detection
Immediate allocations
Single-unit resources
Sufficient Condition for Deadlock
Expedient State p1 p2 p4 p5 p3 R1 R2 R3

43. Sufficient Condition for Deadlock
Testing for specific process p
Continuous deadlock detection
Immediate allocations
Single-unit resources
Sufficient Condition for Deadlock
Expedient State p1 p2 p4 p5 p3 R1 R2 R3
Knot

44. Knot is Not Necessary for Deadlock
Testing for specific process p
Continuous deadlock detection
Immediate allocations
Single-unit resources
Knot is Not Necessary for Deadlock
Expedient State p1 p2 p4 p5 p3 R1 R2 R3
Deadlock on a condition w/o a knot.

45. Single-Unit Resources
Testing for specific process p
Continuous deadlock detection
Immediate allocations
Single-unit resources
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 p1 p2 R1 R2 p1 p2 R1 R2
Not Deadlocked
Deadlocked

46. Single-Unit Resources
Testing for specific process p
Continuous deadlock detection
Immediate allocations
Single-unit resources
Single-Unit Resources
Wait-For Graph (wfg): Show only processes

47. Deadlock Detection in Distributed Systems
Central Coordinator Approach
Distributed Approach

48. 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 p2 p1 M1 p3 p4 M2

49.  Phantom Deadlocks Central Coordinator (CC) Problems
Due to timeout, p3 cancel the request.
But, the message passed to CC is delayed
Deadlock
Phantom Deadlocks
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 p2 p1 M1 p3 p4 M2 
p1 requesting the resource
holding by p4 causes phantom deadlock. p2 p1 M1 p3 p4 M2
phantom
edge

50. 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 p7 p6 p4 p5 M1 M2 M3 M4
p1 p2
p1  p2  p3
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

51. 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 p7 p6 p4 p5 M1 M2 M3 M4
p1 p2
p1  p2  p3
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

52. Recovery from Deadlock
Operating Systems Principles Process Management and Coordination Lecture 6: Deadlocks
Recovery from Deadlock

53. 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”

54. Dynamic Deadlock Avoidance
Operating Systems Principles Process Management and Coordination Lecture 6: Deadlocks
Dynamic
Deadlock Avoidance

55. Deadlock Avoidance Deadlock Detection & Recovery Deadlock Avoidance
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.

56. 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.

57. Maximum Claim Graph (MCG)
Process indicates maximum resources needed
Potential request edge: piRj (dashed)
May turn into real request edge p1 R p2

58. State Transition Using MCG
Process indicates maximum resources needed
Potential request edge: piRj (dashed)
May turn into real request edge p1 R p2 p1 R p2 p1 R p2 p1 R p2 p1 R p2 S1
Request R
(by p2) S2
Acquire R
(by p2) S3
Request R
(by p1) S4
Acquire R
(by p1) S0

59. The Banker’s Algorithm
Testing for safety algorithm (Dijkstra 1968)
The Banker’s Algorithm
Theorem: Prevent acquisitions from producing a irreducible claim graph  All state are safe.
Banker’s 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.

60. The Banker’s Algorithmp1 p2 p3 R1 R2

61. The Banker’s Algorithm
Can p1R1 be safely be granted?
Can p2R1 be safely be granted?
The Banker’s Algorithm
Can p3R1 be safely be granted? p1 p2 p3 R1 R2
Which of the requests can safely be granted?

62. The Banker’s Algorithm
Can p1R1 be safely be granted?
Can p2R1 be safely be granted?
The Banker’s Algorithm
Can p3R1 be safely be granted? p1 p2 p3
Temporarily
grant R1 R2
Can such an RAG be completely reducible?

63. The Banker’s Algorithm
Can p1R1 be safely be granted? 
Can p2R1 be safely be granted?
The Banker’s Algorithm
Can p3R1 be safely be granted? p1 p2 p3
Temporarily
grant R1 R2
Can such an RAG be completely reducible?

64. The Banker’s Algorithm
Can p1R1 be safely be granted? 
Can p2R1 be safely be granted?
The Banker’s Algorithm
Can p3R1 be safely be granted? p1 p2 p3
granted R1 R2
Can such an RAG be completely reducible?

65. The Banker’s Algorithm
Can p1R1 be safely be granted? 
Can p2R1 be safely be granted?
The Banker’s Algorithm
Can p3R1 be safely be granted? p1 p2 p3 R1 R2

66. The Banker’s Algorithm
Can p1R1 be safely be granted? 
Can p2R1 be safely be granted? 
The Banker’s Algorithm
Can p3R1 be safely be granted?
Temporarily
grant p1 p2 p3 R1 R2
Can such an RAG be completely reducible?

67. The Banker’s Algorithm
Can p1R1 be safely be granted? 
Can p2R1 be safely be granted? 
The Banker’s Algorithm
Can p3R1 be safely be granted?
not
granted p1 p2 p3 R1 R2

68. The Banker’s Algorithm
Can p1R1 be safely be granted? 
Can p2R1 be safely be granted? 
The Banker’s Algorithm
Can p3R1 be safely be granted? p1 p2 p3 R1 R2

69. The Banker’s Algorithm
Can p1R1 be safely be granted? 
Can p2R1 be safely be granted? 
The Banker’s Algorithm
Can p3R1 be safely be granted?
Temporarily
grant p1 p2 p3 R1 R2
Can such an RAG be completely reducible?

70. The Banker’s Algorithm
Can p1R1 be safely be granted? 
Can p2R1 be safely be granted? 
The Banker’s Algorithm
Can p3R1 be safely be granted? 
Temporarily
grant p1 p2 p3 R1 R2
Can such an RAG be completely reducible?

71. The Banker’s Algorithm
Can p1R1 be safely be granted? 
Can p2R1 be safely be granted? 
The Banker’s Algorithm
Can p3R1 be safely be granted?  p1 p2 p3
granted R1 R2

72. 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. 

73. Operating Systems Principles Process Management and Coordination Lecture 6: Deadlocks
Deadlock Prevention

74. Deadlock Prevention Deadlock Detection & Recovery Deadlock Avoidance
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.

75. Conditions for a Deadlock
Eliminating any of these conditions would make deadlock impossible.
Conditions for a Deadlock
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.

76. Deadlock Prevention Eliminating the `Mutual Exclusion’ Condition
Hold and wait
No preemption
Circular wait
Eliminating any of
Deadlock Prevention
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

77. Deadlock Prevention Eliminating the `Hold and Wait’ Condition
Mutual exclusion
Hold and wait
No preemption
Circular wait
Eliminating any of
Deadlock Prevention
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

78. Deadlock Prevention Eliminating the `Circular Wait’ Condition
Mutual exclusion
Hold and wait
No preemption
Circular wait
Eliminating any of
Deadlock Prevention
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.

79. Comparisons