Deadlock CS 450: Operating Systems Sean Wallace - - PowerPoint PPT Presentation

▶
deadlock
SMART_READER_LITE
LIVE PREVIEW

Deadlock CS 450: Operating Systems Sean Wallace - - PowerPoint PPT Presentation

May 02, 2023 267 likes •1.48k views

Deadlock CS 450: Operating Systems Sean Wallace <swallac6@iit.edu> Computer Science Science deadlock | ded lk| noun 1 [ in sing. ] a situation, typically one involving opposing parties, in which no progress can be made: an attempt

slide-1
SLIDE 1

Science Computer Science

Deadlock

CS 450: Operating Systems Sean Wallace <swallac6@iit.edu>

slide-2
SLIDE 2

–New Oxford American Dictionary deadlock |ˈdedˌläk|

noun 1 [ in sing. ] a situation, typically one involving opposing parties, in which no progress can be made: an attempt to break the deadlock.

2

slide-3
SLIDE 3

Traffic Gridlock

3

slide-4
SLIDE 4

Software Gridlock

4

mutex_A.lock() mutex_B.lock() # critical section mutex_B.unlock() mutex_A.unlock() mutex_B.lock() mutex_A.lock() # critical section mutex_B.unlock() mutex_A.unlock()

slide-5
SLIDE 5

Necessary Conditions for Deadlock

5

slide-6
SLIDE 6

That is, what conditions need to be true (of some system) so that deadlock is possible? (Not the same as causing deadlock!)

6

slide-7
SLIDE 7
  • 1. Mutual Exclusion

Resources can be held by process in a mutually exclusive manner

7

slide-8
SLIDE 8
  • 2. Hold & Wait

While holding one resource (in mutex), a process can request another resource

8

slide-9
SLIDE 9
  • 3. No Preemption

One process can not force another to give up a resource; i.e., releasing is voluntary

9

slide-10
SLIDE 10
  • 4. Circular Wait

Resource requests and allocations create a cycle in the resource allocation graph

10

slide-11
SLIDE 11

Resource Allocation Graphs

11

slide-12
SLIDE 12

12

Process: Resource: Request: Allocation:

slide-13
SLIDE 13

13

R1 R2

P1 P2 P3

R3 Circular wait is absent = no deadlock

slide-14
SLIDE 14

14

R1 R2

P1 P2 P3

R3 All 4 necessary conditions in place; Deadlock!

slide-15
SLIDE 15

In a system with only single-instance resources, necessary conditions ⟺ deadlock

15

slide-16
SLIDE 16

16

R1

P1 P2 P3

Cycle without Deadlock!

P2

R2

slide-17
SLIDE 17

Not practical (or always possible) to detect deadlock using a graph —but convenient to help us reason about things

17

slide-18
SLIDE 18

Approaches to Dealing with Deadlock

18

slide-19
SLIDE 19
  • 1. Ostrich algorithm


(Ignore it and hope it never happens)

  • 2. Prevent it from occurring (avoidance)
  • 3. Detection & recovery

19

slide-20
SLIDE 20

Deadlock Avoidance

20

slide-21
SLIDE 21

Approach 1: Eliminate necessary condition(s)

21

slide-22
SLIDE 22
  • Mutual exclusion?
  • Eliminating mutex requires that all resources be

sharable

  • When not possible (e.g., disk, printer), can

sometimes use a spooler process

22

slide-23
SLIDE 23
  • But what about semaphores, file locks, etc.?
  • Not all resources are spoolable
  • Cannot eliminate mutex in general

23

slide-24
SLIDE 24
  • Hold & Wait?
  • Elimination requires resource requests to be all-
  • r-nothing affair
  • If currently holding, needs to release all before

requesting more

24

slide-25
SLIDE 25

In practice, very inefficient & starvation is possible! —cannot eliminate hold & wait

25

slide-26
SLIDE 26
  • No preemption?
  • Alternative: allow process to preempt each other

and “steal” resources

  • Mutex locks can not be counted on to stay

locked!

  • In practice, cannot eliminate this either!

26

slide-27
SLIDE 27

Circular Wait is where it’s at.

27

slide-28
SLIDE 28
  • Simple mechanism to prevent wait cycles:
  • Order all resources
  • Require that processes request resources in
  • rder

28

slide-29
SLIDE 29

But impractical — can not count on processes to need resources in a certain

  • rder

…and forcing a certain order can result in poor resource utilization

29

slide-30
SLIDE 30

Approach 2: Intelligently prevent circular wait

30

slide-31
SLIDE 31

31

R1

P1 P2

R2 Possible to create a cycle (with one edge)?

slide-32
SLIDE 32

32

R1

P1 P2

R2 Possible to create a cycle (with one edge)?

slide-33
SLIDE 33

33

R1

P1 P2

R2 It’s quite possible that P2 won’t need R2, or, maybe P2 will release R1 before requesting R2, but we don’t know if/when…

slide-34
SLIDE 34

34

R1

P1 P2

R2 Preventing circular wait means avoiding a state where a cycle is an imminent possibility

slide-35
SLIDE 35

35

R1

P1 P2

R2 To predict deadlock, we can ask processes to “claim” all resources they need in advance

slide-36
SLIDE 36

36

R1

P1 P2

R2 Graph with “claim edges”

slide-37
SLIDE 37

37

R1

P1 P2

R2 P2 requests R1

slide-38
SLIDE 38

38

R1

P1 P2

R2 Convert to allocation edge; no cycle

slide-39
SLIDE 39

39

R1

P1 P2

R2 P1 requests R2

slide-40
SLIDE 40

40

R1

P1 P2

R2 If we convert to an allocation edge…

slide-41
SLIDE 41

41

R1

P1 P2

R2 Cycle involving claim edges!

slide-42
SLIDE 42

42

R1

P1 P2

R2 Means that if processes fulfill their claims, we can not avoid deadlock!

slide-43
SLIDE 43

43

R1

P1 P2

R2 i.e., P1 → R1, P2 → R2

slide-44
SLIDE 44

44

R1

P1 P2

R2 P1 → R1 should be blocked by the kernel, even if it can be satisfied with available resources

slide-45
SLIDE 45

45

R1

P1 P2

R2 This is a “safe” state…i.e., no way a process can cause deadlock directly (i.e., without OS alloc)

slide-46
SLIDE 46

Idea: if granting an incoming request would create a cycle in a graph with claim edges, deny that request (i.e., block the process) —approve later when no cycle would

  • ccur

46

slide-47
SLIDE 47

47

R1

P1 P2

R2 P2 releases R1

slide-48
SLIDE 48

48

R1

P1 P2

R2 Now OK to approve P1→R2 (unblock P1)

slide-49
SLIDE 49

49

R1

P1 P2

R2 Should we still deny P1→R2?

P3

slide-50
SLIDE 50

Problem: this approach may incorrectly predict imminent deadlock when resources with multiple instances are involved

50

slide-51
SLIDE 51

51

R1

P1 P2

R2 Requires a more general definition of “safe state”

P3

slide-52
SLIDE 52

Banker’s Algorithm

52

(by Edsger Dijkstra)

slide-53
SLIDE 53
  • Basic idea:
  • Define how to recognize system “safety”
  • Whenever a resource request arrives:
  • Simulate allocation & check state
  • Allocate iff simulates state is safe

53

slide-54
SLIDE 54

Some assumption we need to make:

  • 1. A non-blocked process holding a resource will

eventually release it

  • 2. It is know a priori how many instances of each

resource a given process needs

54

slide-55
SLIDE 55

Safe State

  • There exists a sequence <P1, P2, …, Pn>, where

each Pk can complete with:

  • Currently available (free) resources
  • Resources held by P1, …, Pk-1

55

slide-56
SLIDE 56

Data Structures

56

Processes P1, …, Pn, Resources R1, …, Rm:

available[j] = num of Rj available max[i][j] = max num of Rj required by Pi allocated[i][j] = num of Rj allocated to Pi need[i][j] = max[i][j] - allocated [i][j]

slide-57
SLIDE 57

Safety Algorithm

1. finish[i] ← false ∀ i ∈ 1…n
 work ← available 2. Find i : finish[i] = false & need[i][j] ≤ work[j] ∀ j
 If none, go to 4 3. work ← work + allocated[i]; finish[i] ← true
 Go to 2. 4. Safe state iff finish[i] = true ∀ i

57

slide-58
SLIDE 58

Incoming request represented by request array request[j] = num of resource Rj requested (A process can require multiple instances of more than one resource at a time)

58

slide-59
SLIDE 59

Processing Request from Pk

  • 1. If request[j] ≤ need[k][j] ∀ j, continue,

else error

  • 2. If request[j] ≤ available[j] ∀ j, continue,

else block

  • 3. Run safety algorithm with:
  • 1. available ← available - request
  • 2. allocated[k] ← allocated[k] + request
  • 3. need[k] ← need[k] - request

59

slide-60
SLIDE 60

If safety algorithm fails, do not allocate, even if resources are available! —either deny request or block caller

60

slide-61
SLIDE 61

61

3 resources: A (10), B (5), C (7)

Max A B C P0 7 5 3 P1 3 2 2 P2 9 2 P3 2 2 2 P4 4 3 3 Allocated A B C 1 2 3 2 2 1 1 2 Available A B C 3 3 2 Need A B C 7 4 3 1 2 2 6 1 1 4 3 1

  • Safe state: <P1, P3, P0, P2, P4>
  • P3 needs <0, 0, 1> additional
  • P0 needs <0, 3, 0> additional
slide-62
SLIDE 62

Banker’s Algorithm Discussion

62

slide-63
SLIDE 63
  • 1. Efficiency?
  • How fast is it?
  • How often is it run?

63

slide-64
SLIDE 64

64

1. finish[i] ← false ∀ i ∈ 1…n
 work ← available 2. Find i : finish[i] = false & need[i][j] ≤ work[j] ∀ j
 If none, go to 4 3. work ← work + allocated[i]; finish[i] ← true
 Go to 2. 4. Safe state iff finish[i] = true ∀ i

for up to N processes, check M resources loop for N processes

O

  • N · N · M
  • = O
  • N 2 · M
slide-65
SLIDE 65
  • How often to run?
  • Need to run on every resource request
  • Can’t relax this, otherwise system might become

unsafe!

65

slide-66
SLIDE 66
  • 2. Assumption #1: processes will

eventually release resources

66

slide-67
SLIDE 67
  • Assuming well-behaved processes
  • Not 100% realistic, but what else can we do?

67

slide-68
SLIDE 68
  • 3. Assumption #2: a priori knowledge of

max resource requirements

68

slide-69
SLIDE 69
  • Highly unrealistic
  • Process resource needs are dynamic!
  • Without this assumption, deadlock prevention

becomes much harder…

69

slide-70
SLIDE 70

Aside: Decision problems, complexity theory, & the halting problem

70

slide-71
SLIDE 71

71

decision algorithm

input yes no

A decision problem

slide-72
SLIDE 72
  • E.g.:
  • Is X evenly divisible by Y?
  • Is N a prime number?
  • Does string S contain pattern P?

72

slide-73
SLIDE 73

A lot of important problems can be reworded as a decision problem: E.g., traveling salesman problem (find the shortest tour through a graph) ⇒ is there a tour shorter than L?

73

slide-74
SLIDE 74

Complexity theory classifies decision problems by their difficulty, and draws relationships between those problems & classes

74

slide-75
SLIDE 75

Class P: solutions to these problems can be found in polynomial time (e.g., O(N2))

75

slide-76
SLIDE 76

Class NP: solutions to these problems can be verified in polynomial time —but finding solutions may be harder!
 (i.e., superpolynomial)

76

slide-77
SLIDE 77

Big open problem in CS: P = NP?

77

slide-78
SLIDE 78

Why is this important?

78

slide-79
SLIDE 79

All problems in NP can be reduced to another problem in the NP-complete class, and all problem in NP-complete can be reduced to each other

79

slide-80
SLIDE 80

If you can prove that any NP-complete problem is in P , then all NP problems are in P! (More motivation: you also win $1M)

80

slide-81
SLIDE 81

If you can prove that P ≠ NP , we can stop looking for fast solutions to many hard problems (Motivation: you still win $1M)

81

slide-82
SLIDE 82

82

decision algorithm

input yes no

A decision problem

slide-83
SLIDE 83

83

Will the system deadlock?

resources available request & allocations, running programs yes no

Deadlock prevention

slide-84
SLIDE 84

84

Will the system halt (or run forever)?

description of a program and its inputs yes no

The halting problem

slide-85
SLIDE 85

E.g., write the function: half(f) → bool

  • return true if f will halt

  • return false otherwise

85

slide-86
SLIDE 86

86

def halt(f): # your code here def loop_forever() while True: pass def just_return(): return True halt(loop_forever) # => False halt(just_return) # => True

slide-87
SLIDE 87

87

def gotcha(): if halt(gotcha): loop_forever else: just_return halt(gotcha)

!@#$%^&*!!!!

slide-88
SLIDE 88

88

Does this program halt? Yes No

slide-89
SLIDE 89

Proof by contradiction: the halting problem is undecidable

89

slide-90
SLIDE 90

Generally speaking, deadlock prediction can be reduced to the halting problem

90

slide-91
SLIDE 91

I.e., determining if a system is deadlocked is, in general, provably impossible!!!

91

slide-92
SLIDE 92

Deadlock Detection & Recovery

92

slide-93
SLIDE 93

Basic approach: cycle detection

93

slide-94
SLIDE 94

E.g., Tarjan’s strongly connected components algorithm; O(|V|+|E|)

94

slide-95
SLIDE 95

Need only run on mutex resources and “involved” processes …still, would be nice to reduce the size of the resource allocation graph

95

slide-96
SLIDE 96

Actual resources involved are unimportant —only care about relationships between processes

96

slide-97
SLIDE 97

Resource Allocation Graph

97

P1 P2 P2 P2 P2

slide-98
SLIDE 98

“Wait-for” Graph

98

P1 P2 P2 P2 P2

slide-99
SLIDE 99

99

P1 P2 P2 P2 P2 P1 P2 P2 P2 P2

Substantial optimization!

slide-100
SLIDE 100

…but not very useful when we have multi- instance resources (false positives are likely)

100

slide-101
SLIDE 101

Deadlock Detection Algorithm

101

slide-102
SLIDE 102

Important: do away with requirement of a priori resource need declarations

102

slide-103
SLIDE 103

New assumption: processes can complete with current allocation + all pending requests I.e., no future requests Unrealistic!
 (But we don’t have a crystal ball)

103

slide-104
SLIDE 104

Keep track of all pending requests in:

request[i][j] = num of Rj requested by Pi

104

slide-105
SLIDE 105

Detection Algorithm

1. finish[i] ← all_nil?(allocated[i]) ∀ i ∈ 1…n
 work ← available 2. Find i : finish[i] = false & request[i][j] ≤ work[j] ∀ j
 If none, go to 4. 3. work ← work + allocated[i]; finish[i] ← true
 Go to 2. 4. If finish[i] ≠ true ∀ i, system is deadlocked.

105

ignore processes that aren’t allocated anything

slide-106
SLIDE 106

106

3 resources: A (7), B (2), C (6)

Available A B C Request A B C 2 2 1 2

  • Not deadlocked: <P0, P2, P1, P3, P4>
  • P2 requests <0, 0, 1>

Allocated A B C P0 1 P1 2 P2 3 3 P3 2 1 1 P4 2

slide-107
SLIDE 107

Discussion

107

slide-108
SLIDE 108
  • 1. Speed?

108

slide-109
SLIDE 109

109

  • 1. finish[i] ← all_nil?(allocated[i]) ∀ i ∈ 1…n


work ← available

  • 2. Find i : finish[i] = false & request[i][j] ≤ work[j] ∀ j


If none, go to 4.

  • 3. work ← work + allocated[i]; finish[i] ← true


Go to 2.

  • 4. If finish[i] ≠ true ∀ i, system is deadlocked.

Still O(N·N·M) = O(N2·M)

slide-110
SLIDE 110
  • 2. When to run?

110

slide-111
SLIDE 111

…as seldom as possible! Tradeoff: the longer we wait between checks, the messier resulting deadlocks might be

111

slide-112
SLIDE 112
  • 3. Recovery?

112

slide-113
SLIDE 113
  • One or more processes must release resources:
  • Via forced termination
  • Resource preemption
  • System rollback

113

Sure, but how?

slide-114
SLIDE 114
  • Resource preemption only possible with certain

types of resources

  • No intermediate state
  • Can be taken away and returned (while blocking

process)

  • E.g., mapped VM page

114

slide-115
SLIDE 115
  • Rollback requires process checkpointing:
  • Periodically autosave/reload process state
  • Cost depends on process complexity
  • Easier for special-purposes systems

115

slide-116
SLIDE 116
  • How many to terminate/preempt/rollback?
  • At least one for each disjoint cycle
  • Non-trivial to determine how many cycles and

which processes!

116

slide-117
SLIDE 117
  • Selection criteria (who to kill) = minimize cost
  • # of processes
  • Completed run-time
  • # of resources held/needed
  • Arbitrary priority (no killing system process!)

117

slide-118
SLIDE 118

Dealing with deadlock is hard!

118

slide-119
SLIDE 119
  • Moral of this and the concurrency material:
  • Be careful with concurrent resource sharing
  • Use concurrency mechanisms that avoid explicit

locking whenever possible!

119