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 Banker’s Algorithm • Deadlock Prevention

3. Operating Systems PrinciplesProcess Management and CoordinationLecture 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; nosharing • 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; nosharing • 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. 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 Cisnot true

10. 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 blockedindefinitely, waiting for each other. • Livelock • Processes (threads) run but make noprogress • An `active’ form of deadlock. • Starvation • Some Processes (threads) get deferredforever. • E.g., one process dominates, not allowing other processes to progress.

11. 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 neverempty • Starvation on Memory Blocks: • Total memory is 200MB • Unbounded stream of 100MB requests may starve a 200MB request

12. Operating Systems PrinciplesProcess Management and CoordinationLecture 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 CoordinationLecture 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. p1 p1 p1 p1 R R R R p2 p2 p2 p2 Acquire R (byp1) Request R (byp1) Release R (byp1) The state transition diagram described below is notcomplete. The actual number of states depends on possible operations of processes. State Transitions by p1 Process S0 S1 S3 S2

17. Request: Create new request edgepiRj pihas no outstanding requests number of edges betweenpiandRjunits inRj Acquisition: Reverserequest edge topiRj All requests ofpiare satisfied pihas no outstanding requests Release: Remove edgepiRj Process Operations on Resources

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 cannotrequest, 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 Nodeadlock state can ever be reached using request, acquire, release.

19. p1 p1: Request(R1); Request(R2); Release(R2); Release(R1); p2: Request(R2); Request(R1); Release(R1); Release(R2); R1 R2 p2 Example p1 and p2 both need R1 and R2.

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

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

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

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

24. p1 R1 R2 p2 Example

25. Example p1is blocked. p2is blocked.

26. No state is safe since the deadlock state is always reachable. Example 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 CoordinationLecture 6: Deadlocks Deadlock Detection

29. Graph Reduction Technique • Graph Reduction: Repeat the following: • Select unblocked process p • Removep and all request and allocation edges • Deadlock Graph notcompletelyreducible. • All reduction sequences lead to the same result.

30. Graph Reduction Technique • Graph Reduction: Repeat the following: • Select unblocked process p • Removep 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 • Removep 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 • Removep 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 • Removep 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 • Removep 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 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. 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 notdeadlocked • Next state T deadlocked only if: • Operation was a request by pand • pis deadlocked inT • Try to reduce T by p

38. p1 p2 p3 p1 p2 p3 R1 R2 R3 R1 R2 R3 p4 p5 p4 p5 • Testing for specific process p • Continuous deadlock detection • Immediate allocations • Single-unit resources Immediate Allocations • All satisfiable requests grantedimmediately • Expedient state = no satisfiable request edges Non-Expedient State Expedient State Granted immediately Satisfiable

39. Testing for specific process p • Continuous deadlock detection • Immediate allocations • Single-unit resources Immediate Allocations • All satisfiable requests grantedimmediately • Expedient state = no satisfiable request edges • Knot K: • Every node in Kreachable from any other node in K • Nooutgoing edges (only incoming) • Knot in expedient state Deadlock • Intuition: • All processes must haveoutstanding requests in K • Expedient state  requestsnotsatisfiable

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

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

42. p1 p1 R1 R2 R1 R2 p2 p2 • 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 Deadlocked Not Deadlocked

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

44. Deadlock Detection in Distributed Systems • Central Coordinator Approach • Distributed Approach

45. M1 M2 p2 p3 p1 p4 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. M1 M1 M2 M2 p2 p2 p3 p3 p1 p1 p4 p4 Due to timeout, p3cancel 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  p1requesting the resource holding byp4causesphantom deadlock. phantom edge

47. M1 M2 p1 p2 p3 p4 p5 M3 M4 p7 p6 Distributed Approach • Detect cycles using probes. • If process piblocked on pj, it launches probe pi pj • pjsends probe pi pj  pkalong 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. M1 M2 p1 p2 p3 p4 p5 M3 M4 p7 p6 Distributed Approach • Detect cycles using probes. • If process piblocked on pj, it launches probe pi pj • pjsends probe pi pj  pkalong 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 CoordinationLecture 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: Temporarilyremove resource (e.g., Memory) • Indirect: Rollback to earlier “checkpoint”