Betriebssysteme ws2000/2001
Prof. H. D. Clausen 1
S 2004 CS 325 1
Deadlock ProblemsDeadlock Problems
Chapter 6
Deadlock Situations Deadlock Situations –– ExamplesExamplesA Systems ModelA Systems ModelSerially Reusable ResourcesSerially Reusable ResourcesDeadlock DetectionDeadlock DetectionRecovery and PreventionRecovery and PreventionConsumable ResourcesConsumable ResourcesResource GraphsResource GraphsDynamic Addition and RemovalDynamic Addition and Removal
S 2004 CS 325 2
Policy versus MechanismPolicy versus Mechanism
• Separate what is allowed to be done with how it is done– a process knows which of its children threads are important
and need priority
• Requests for resources
• Scheduling of requests
• Allocation of resources
• Release of resources
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 2
S 2004 CS 325 3
Deadlock Deadlock –– reasons, occurrencesreasons, occurrences
• Processes compete for “resources”
• Sharing of resources among competitors
• Sequence of allocations can lead to blocking
• Dynamic resource sharing, parallel programming and communicating processes are critical
S 2004 CS 325 4
Deadlock Deadlock –– “deadly embrace”“deadly embrace”
• Resource: reusable, scarce, stable commodity (hw,sw)– serially reusable: * request * use* release
on a serial basis
– consumable: * producer * “message-send/receive”* consumer
resource with a short lifetime
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 3
S 2004 CS 325 5
“deadly embrace” “deadly embrace” -- deadlockdeadlock
p1: : p2: :: :
Request(D); Request(T);
r1: Request(T); :
: r2: Request(D);
: ::
Release(T); Release(D);
Release(D); Release(T);
: :
S 2004 CS 325 6
Reusable Resources Reusable Resources
• Reusable resources are permanent objects
* The number of units within a class is constant
* Each unit is either available, or is allocated to one and only one process
* A process must first request and acquire a resource unit before it can release that unit
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 4
S 2004 CS 325 7
Consumable Resources Consumable Resources
• Reusable resources are produced and consumed dynamically
* The number of units within a class varies at runtime
* A process may increase the number of units of a resource class by releasing one or more units without acquiring them first
* A process may decrease the number of units of a resource class by requesting and acquiring one or more units
S 2004 CS 325 8
Deadlock on Deadlock on FielFiel AccessAccess
p1: p2:
: :
: :
a: open(f1, w); c: open(f2, w);
b: open(f2, w); d: open(f1, w);
: :
: :
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 5
S 2004 CS 325 9
“deadly embrace” “deadly embrace” -- deadlockdeadlock
p1: p2: p3:: : :: : :if (C) send(p2,m);LOOP { LOOP { LPOOP {receive(p3,m); receive(p1,m); receive(p2,m);: : :: : :send(p2,m); send(p3,m); send(p1,m);
S 2004 CS 325 10
Deadlock on Memory AllocationDeadlock on Memory Allocation
p1: p2:
: :
: :
a: Get Mem(2); c: Get Mem(1);
b: Get Mem(2); d: Get Mem(2);
: :
: :
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 6
S 2004 CS 325 11
Strategies Strategies -- Approaches Approaches
• Ignore
• Handle
– Detect & recover
– Avoid
– Prevent
S 2004 CS 325 12
Conditions for DeadlocksConditions for Deadlocks
1. Mutual exclusion condition: each resource is either currently assigned to exactly one process or it is available.
2. Hold and Wait condition: processes currently holding resources allocated earlier can request new resources.
3. No preemption condition: resources previously acquired cannot be forcibly taken away from processes; they must be explicitly released by the process holding them.
4. Circular wait condition: there must be a circular chain of two or more processes, each of which is waiting for a resource held by the next member of the chain.
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 7
S 2004 CS 325 13
Resources Resources
• Two basic categories
– “reusable” resources – e.g. peripherals, printer
– “consumable” resources – e.g. messages
• Two basic operations
– request/allocate
– release
S 2004 CS 325 14
Resource GraphsResource Graphs
• Elements and Relationships– Resources– Processes – Resource Requests– Resource Allocations
• Notational Elements– Vertices– Edges
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 8
S 2004 CS 325 15
p3
p2
p1
R
R
Resource GraphsResource Graphs
R
(a) Process holding a resource
(b) Process requestinga resource
p4
R
(c) Deadlocked processes
S 2004 CS 325 16
p3
example of a resource graph
deadlock with SR resources
p2p1
R R
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 9
S 2004 CS 325 17
p3p1
Deadlock Occurrence Deadlock Occurrence
p1:requests R1requests R2releases R1releases R2
p2
p2:requests R2requests R3releases R2releases R3
p3:requests R3requests R1releases R3releases R1
3 concurrent processes accessing common resources
S 2004 CS 325 18
p3p1
R1
Deadlock Occurrence Deadlock Occurrence –– sequence 1 sequence 1
p1requests
R1
p2
R2 R3
p2requests
R2
p3requests
R3
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 10
S 2004 CS 325 19
p3p1
R1
Deadlock Occurrence Deadlock Occurrence –– sequence 1 sequence 1
p1requests
R2
p2
R2 R3
p2requests
R3
p3requests
R1
S 2004 CS 325 20
p3p1
R1
Deadlock Occurrence Deadlock Occurrence –– sequence 2 sequence 2
p1requests
R1
p2
R2 R3
p3requests
R3
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 11
S 2004 CS 325 21
p3p1
R1
Deadlock Occurrence Deadlock Occurrence –– sequence 2 sequence 2
p2
R2 R3
p3requests
R1
p1releases
R2
p1releases
R2
p3 allocates R1 and runs to completion
S 2004 CS 325 22
Deadlock Strategies Deadlock Strategies
1. Just ignore the problem – hopefully it ignores us too.
2. Detection and recovery: let deadlocks occur, then detect them and take action.
3. Dynamic avoidance by careful resource allocation.
4. Prevention by structurally negating on of the four conditions necessary for a deadlock.
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 12
S 2004 CS 325 23
p3
(a) simple example of adeadlock situation
deadlock with SR resources
R1
p2p1
p2p1
R2 allocationrequest
R(b) single resource sharing (n=3, m=2)
allocation request
S 2004 CS 325 24
States and TransitionsStates and Transitions
• Requests
• Acquisitions
• Releases
• Deadlock states and safe states
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 13
S 2004 CS 325 25
p1 p1 p1 p1
p2 p2 p2 p2
R R R R
S T U V1 1 1
process operations
Request Acquisition Release
S 2004 CS 325 26
R1
S0
State transitions caused by process p1
request R1
release R2
R2
p1 p1 p1 p1 p1
p1 p1 p1 p1 p1
acquire R1 acquire R2 acquire R2
release R1
S1 S2 S3 S4
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 14
S 2004 CS 325 27
S 2004 CS 325 28
Research on DeadlocksResearch on Deadlocks
Quotes from Andrew Tanenbaum:“If there ever was a subject that was investigated mercilessly during the early days of computing, it was deadlocks. … Deadlock detection is a nice little graph theory problem that one mathematically inclined graduate student can get his jaws around and chew on for 3 or 4 years. All kinds of algorithms were devised, each one more exotic and less practical than the previous one. …When an operating system wants to do deadlock detection or prevention, which few of them do, they use one of the methods discussed”
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 15
S 2004 CS 325 29
Research on DeadlocksResearch on Deadlocks
Final quote from Andrew Tanenbaum:
“There is still a little research on distributed deadlock detection. …
None of it is even remotely practical in real systems. Its main function seems to be keeping otherwise unemployed graph theorists off the streets.”
S 2004 CS 325 30
Deadlock states and safe statesDeadlock states and safe states
• Blocked processes
• Deadlocked processes
• Deadlock states
• Safe states
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 16
S 2004 CS 325 31
Compute and IO ProcessCompute and IO Process
: :
pc: Request(M, all); pio: Request(IO_request);
Release(IO_request); :
rc: Request(IO_completion); rio: Request(D);
: :
: :
Release(M, all); Perform_IO;
Release(IO_completion);
: :
S 2004 CS 325 32
Message PassingMessage Passing
Safe order of operations:
pi: Release(Si); Request (Sj);
Unsafe order of operations:
p1: . . . Request(S3); Release(S1); . . . .
p2: . . . Request(S1); Release(S2); . . . .
p3: . . . Request(S2); Release(S3); . . . .
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 17
S 2004 CS 325 33
p3
(a) SR an CR resource sharing
deadlock with CR resources
M
piopc
p2
p1
produce
R
(b) single resource sharing
. . .
IO completion
S2
S3 S1
“granularity”
S 2004 CS 325 34
System ModelSystem Model
• System of states σ {S, T, U, V, . . . } and a set π of processes {p1, p2, . . . }
• A process pi : σ { σ }– pi : S –i W; S –* W;– pi is blocked not∃ S ––i T A process pi is deadlocked,∀T: S ––i T pi is blocked.
S is a deadlock state if a process pi is deadlocked in S.
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 18
S 2004 CS 325 35
S
1
1
1
2
1
1 1
2112 UTSW V
T
U V
2 2
examples of systems
(a) system with deadlock states:
(b) system with deadlock and safe states
p1 is blocked here
p2 is deadlocked in U and in V since it is blocked in either one;
deadlock state safe
statesnot safe
S 2004 CS 325 36
Insert tif of Fig. 4-4
system state changes in file sharing example
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 19
S 2004 CS 325 37
Serially Reusable ResourcesSerially Reusable Resources
• A SR resource is a finite set of identical units:– The number of units is constant– Each unit is either available or allocated to one an only one
process – no sharing is allowed.
– A process may release a unit only if it has previously acquired that unit.
• Representation by a process-resource graph (reusableresource graph)– A set of two mutually exclusive subsets of process and
resource nodes [containing one or more units]
– The graph is bipartite– The edges are directed [allocated/requested] and limited
S 2004 CS 325 38
Deadlock DetectionDeadlock Detection• Process progression – investigate the most favorable
state changes• Is there a sequence of operations such that the system
will NOT deadlock• Simulate the most favorable execution of each unblocked
process in a sequential mode:– An unblocked process acquires all resources it needs, then
releases all of its resources and remains dormant thereafter
– The released resources might wake up some previously blocked processes
– Continue in this way until there are no more unblocked processes
– If at termination there remain some blocked processes the original state is a deadlock state;
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 20
S 2004 CS 325 39
p3
example of a resource graph reduction
Graph reduction - 1
p2p1
R R
p5p4
R
S 2004 CS 325 40
p3
example of a resource graph reduction
Graph reduction - 2
p2
R R
p5p4
R
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 21
S 2004 CS 325 41
p3
example of a resource graph reduction
Graph reduction - 3
R R
p5
R
S 2004 CS 325 42
p2
p1
p1
p2
R1R2
another sequence of reductions
R1 R2
Reduced by p1
Reduced by p2
unblocked
unblocked
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 22
S 2004 CS 325 43
p1
p2
another sequence of reductions
R1 R2
p1
p2
R1 R2
Reduced by p1
Reduced by p2
unblockedsafe
S 2004 CS 325 44
Deadlock TheoremDeadlock Theorem
• Necessary and sufficient condition:• A state S is a deadlock state IFF the reusable
resource graph is NOT completely reducible;• Based on the observation (Lemma 1) that all reduction
sequences lead to the same irreducible graph.• If Reach(n) is the set of nodes reachable from node n
then the graph contains a cycle if n ∋ Reach(n);• A cycle in a graph is a necessary condition for deadlock. • A knot is a subset of nodes which are reachable from
every node inside but no outside nodes are reachable.• Reducible resource graphs can be represented in matrix
or list form (compression techniques to save storage).
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 23
S 2004 CS 325 45
a
Knot K = {b, c, d, e}
illustration of cycles and knots
Example of a knot - and a cycle b
d
ce
S 2004 CS 325 46
Deadlock DetectionDeadlock Detection
• Reduction of resource graphs
• Special cases– Testing for a specific process– Continuous deadlock detection– Immediate allocation (knots)– Single unit resources
• Deadlock detection in distributed systems– Central coordinator– Distributed coordination
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 24
S 2004 CS 325 47
Recovery from DeadlockRecovery from Deadlock
• Recovery through preemption
• Recovery through rollback (checkpoints)
• Recovery through process termination
S 2004 CS 325 48
Recovery from DeadlockRecovery from Deadlock
• 2 general approaches– Process termination– Resource preemption
• Termination costs:– Process priority– Restarting and re-running the process– “external” costs
• Termination schemes:– least expensive process– minimum cost process– Apply resource preemption
Betriebssysteme ws2000/2001
Prof. H. D. Clausen 25
S 2004 CS 325 49
Dynamic Deadlock AvoidanceDynamic Deadlock Avoidance
• Claim graphs
• Banker’s Algorithm
S 2004 CS 325 50
End End