View
229
Download
0
Category
Preview:
Citation preview
Operating Systems PrinciplesProcess Management and Coordination
Lecture 6: Deadlocks
主講人:虞台文
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
Operating Systems PrinciplesProcess Management and Coordination
Lecture 6: Deadlocks
Deadlocks with
Reusable and
Consumable Resources
Deadlocks
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
Reusable/Consumable Resources
Reusable Resources– Number of units is “constant”– Unit is either free or allocated; no sharing– Process requests, acquires, releases unitsExamples: (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
Reusable/Consumable Resources
Reusable Resources– Number of units is “constant”– Unit is either free or allocated; no sharing– Process requests, acquires, releases unitsExamples: (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
Main topic of the lecture
Reusable Resources
Example (File Sharing)
p1: ... open(f1,w); open(f2,w); ...
p1: ... open(f1,w); open(f2,w); ...
p2: ... open(f2,w); open(f1,w); ...
p2: ... open(f2,w); open(f1,w); ...
Deadlock when executed concurrently
Example (Message Passing)
p1: ... if(C)send(p2,m); while(1){ recv(p3,m); ... send(p2,m); }
p1: ... if(C)send(p2,m); while(1){ recv(p3,m); ... send(p2,m); }
Deadlock when C is not true
p2: ... while(1){ recv(p1,m); ... send(p3,m); }
p2: ... while(1){ recv(p1,m); ... send(p3,m); }
p3: ... while(1){ recv(p2,m); ... send(p1,m); }
p3: ... while(1){ recv(p2,m); ... send(p1,m); }
Assume that send/recv are blocking operations.
Deadlock, Livelock, and Starvation
Deadlock– Two or more processes (threads) are blocked in
definitely, 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.
Deadlock and livelock will lead to starvation.But, the inverse is not necessary true.
Deadlock and livelock will lead to starvation.But, the inverse is not necessary true.
Examples:Starvation Not Due to Deadlock or Livelock
Deadlock and livelock will lead to starvation.But, the inverse is not necessary true.
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
Operating Systems PrinciplesProcess Management and Coordination
Lecture 6: Deadlocks
Approaches to the
Deadlock Problem
Approaches to Deadlock Problem
1. Detection and Recovery– Allow deadlock to happen and eliminate it
2. Avoidance (dynamic)– Runtime checks disallow allocations
that might lead to deadlocks
3. Prevention (static)– Restrict type of request and acquisition
to make deadlock impossible
Operating Systems PrinciplesProcess Management and Coordination
Lecture 6: Deadlocks
System Model
Resource Graph
Process = CircleResource = Rectangle with small circles for each unit
Resource Request = Edge from process to resource classResource Allocation = Edge from resource unit to process
State Transitions by p1 Process
R
p1
p2
R
p1
p2
R
p1
p2
R
p1
p2
S0 S1 S2 S3
Request R
(by p1)
Acquire R
(by p1)
Release R
(by p1)
The state transition diagram described below is not complete.The actual number of states depends on possible operations of processes.
Process Operations on Resources
Request: Create new request edge piRj
– pi has no outstanding requests– number of edges between pi and Rj units in Rj
Acquisition: Reverse request edge to piRj
– All requests of pi are satisfied– pi has no outstanding requests
Release: Remove edge piRj
R
p1
p2
R
p1
p2
R
p1
p2
R
p1
p2
R
p1
p2
R
p1
p2
R
p1
p2
R
p1
p2
R
p1
p2
S0 S1 S2 S3
Request R
(by p1)
Request R
(by p1)
Acquire R
(by p1)
Acquire R
(by p1)
Release R
(by p1)
Release R
(by p1)
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 StateA state contains a deadlocked process.
Safe StateNo deadlock state can ever be reached using request, acquire, release.
Example
R1 R2
p1
p2
p1 and p2 both need R1 and R2.
p1: Request(R1); Request(R2);
Release(R2); Release(R1);
p1: Request(R1); Request(R2);
Release(R2); Release(R1);
p2: Request(R2); Request(R1);
Release(R1); Release(R2);
p2: Request(R2); Request(R1);
Release(R1); Release(R2);
Example
p1: Request(R1); Request(R2);
Release(R2); Release(R1);
p1: Request(R1); Request(R2);
Release(R2); Release(R1);
p2: Request(R2); Request(R1);
Release(R1); Release(R2);
p2: Request(R2); Request(R1);
Release(R1); Release(R2);
Example
p1: Request(R1); Request(R2);
Release(R2); Release(R1);
p1: Request(R1); Request(R2);
Release(R2); Release(R1);
p2: Request(R2); Request(R1);
Release(R1); Release(R2);
p2: Request(R2); Request(R1);
Release(R1); Release(R2);
Example
p1: Request(R1); Request(R2);
Release(R2); Release(R1);
p1: Request(R1); Request(R2);
Release(R2); Release(R1);
p2: Request(R2); Request(R1);
Release(R1); Release(R2);
p2: Request(R2); Request(R1);
Release(R1); Release(R2);
Example
p1: Request(R1); Request(R2);
Release(R2); Release(R1);
p1: Request(R1); Request(R2);
Release(R2); Release(R1);
p2: Request(R2); Request(R1);
Release(R1); Release(R2);
p2: Request(R2); Request(R1);
Release(R1); Release(R2);
Example
R1 R2
p1
p2
Example
p1 is blocked.
p2 is blocked.
Example
A deadlock state.
No state is safe since the deadlock state is always reachable.
Necessary Condition for Deadlock
A cycle in the resource graph is a necessary condition for
deadlock.
Operating Systems PrinciplesProcess Management and Coordination
Lecture 6: Deadlocks
Deadlock
Detection
Graph Reduction Technique
Graph Reduction:Repeat the following:
1. Select unblocked process p2. Remove p and all request and allocation edges
Deadlock Graph not completely reducible.
All reduction sequences lead to the same result.
Graph Reduction Technique
Graph Reduction:Repeat the following:
1. Select unblocked process p2. Remove p and all request and allocation edges
p1 p2
p4 p5
p3
R1 R2 R3
Graph Reduction Technique
Graph Reduction:Repeat the following:
1. Select unblocked process p2. Remove p and all request and allocation edges
p1 p2
p4 p5
p3
R1 R2 R3
Graph Reduction Technique
Graph Reduction:Repeat the following:
1. Select unblocked process p2. Remove p and all request and allocation edges
p1 p2
p4 p5
p3
R1 R2 R3
Graph Reduction Technique
Graph Reduction:Repeat the following:
1. Select unblocked process p2. Remove p and all request and allocation edges
p1 p2
p4 p5
p3
irreducibleirreducible
Deadlock detectedDeadlock detectedR1 R2 R3
Graph Reduction Technique
Graph Reduction:Repeat the following:
1. Select unblocked process p2. Remove p and all request and allocation edges
Special Cases of Deadlock Detection
Testing for specific process pContinuous deadlock detection Immediate allocationsSingle-unit resources
Testing for specific process
Testing for specific process p:– Reduce until p is removed or graph
irreducible
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:1. Current state not deadlocked2. Next state T deadlocked only if:
a. Operation was a request by p andb. p is deadlocked in T
3. Try to reduce T by p
Testing for specific process p Continuous deadlock detection Immediate allocations Single-unit resources
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
Grantedimmediately
Grantedimmediately
Non-Expedient State Expedient State
p1 p2
p4 p5
p3
R1 R2 R3
p1 p2
p4 p5
p3
R1 R2 R3
SatisfiableSatisfiable
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
Immediate Allocations
Testing for specific process p Continuous deadlock detection Immediate allocations Single-unit resources
Expedient State
p1 p2
p4 p5
p3
R1 R2 R3
Immediate Allocations
Testing for specific process p Continuous deadlock detection Immediate allocations Single-unit resources
Expedient State
p1 p2
p4 p5
p3
R1 R2 R3
Knot
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
p1
p2
R1 R2
p1
p2
R1 R2
DeadlockedNot Deadlocked
Single-Unit Resources
Testing for specific process p Continuous deadlock detection Immediate allocations Single-unit resources
Wait-For Graph (wfg): Show only processes
Deadlock Detection in Distributed Systems
Central Coordinator Approach
Distributed Approach
Central Coordinator Approach
Central Coordinator (CC)– Each machine maintains a
local wfg– Changes reported to CC– CC constructs and analyze
s global wfg
Problems– Coordinator is a performa
nce bottleneck– Communication delays m
ay cause phantom deadlocks
p2
p1
M1
p3
p4
M2
Phantom Deadlocks
Central Coordinator (CC)– Each machine maintains a
local wfg– Changes reported to CC– CC constructs and analyze
s global wfg
Problems– Coordinator is a performa
nce bottleneck– Communication delays m
ay cause phantom deadlocks
p2
p1
M1
p3
p4
M2
p2
p1
M1
p3
p4
M2
Due to timeout, p3 cancel the request.
But, the message passed to CC is delayed
Due to timeout, p3 cancel the request.
But, the message passed to CC is delayed
p1 requesting the resourceholding by p4 causes phantom deadlock.
p1 requesting the resourceholding by p4 causes phantom deadlock.
phantomedge
Deadlock
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
p7 p6
p4 p5
M1 M2
M3 M4
p1 p2p1 p2 p3 p1 p2 p3 p4
p1 p2 p3 p7
p1 p2 p3 p4 p5
p1 p2 p3 p4 p5 p1
p1 p2 p3 p4 p5 p6p1 p2 p3 p4 p5 p6 p4
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
p7 p6
p4 p5
M1 M2
M3 M4
p1 p2p1 p2 p3 p1 p2 p3 p4
p1 p2 p3 p7
p1 p2 p3 p4 p5
p1 p2 p3 p4 p5 p1
p1 p2 p3 p4 p5 p6p1 p2 p3 p4 p5 p6 p4
Deadlock detected by M4.
Deadlock detected by M4.
Deadlock detected by M1.
Deadlock detected by M1.
Operating Systems PrinciplesProcess Management and Coordination
Lecture 6: Deadlocks
Recovery from
Deadlock
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., Memor
y)– Indirect: Rollback to earlier “checkpoint”
Operating Systems PrinciplesProcess Management and Coordination
Lecture 6: Deadlocks
Dynamic
Deadlock Avoidance
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.
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.
Maximum Claim Graph (MCG)
p1
Process indicates maximum resources needed Potential request edge: piRj (dashed) May turn into real request edge
R
p2
State Transition Using MCG
Process indicates maximum resources needed Potential request edge: piRj (dashed) May turn into real request edge
p1
R
p2
S0 S1Request R
(by p2)S2
Acquire R
(by p2)S3
Request R
(by p1)
p1
R
p2
p1
R
p2
p1
R
p2
S4Acquire R
(by p1)
p1
R
p2
The Banker’s Algorithm
Theorem: Prevent acquisitions from producing a irreducible claim graph All state are safe.
Banker’s algorithm:– Given a satisfiable request, pR, temporarily grant req
uest: changing pR to Rp
– Reduce new claim graph– If it is completely reducible, proceed
else reverse acquisition.
Testing for safety algorithm (Dijkstra 1968)
The Banker’s Algorithm
p1 p2 p3
R1 R2
The Banker’s Algorithm
R1 R2
p1 p2 p3
Which of the requests can safely be granted?
Can p1R1 be safely be granted?
Can p2R1 be safely be granted?
Can p3R1 be safely be granted?
The Banker’s Algorithm
R1 R2
Can p1R1 be safely be granted?
Can p2R1 be safely be granted?
Can p3R1 be safely be granted?
p1 p2 p3
Temporarilygrant
Can such an RAG be completely reducible?
The Banker’s Algorithm
R1 R2
Can p1R1 be safely be granted?
Can p2R1 be safely be granted?
Can p3R1 be safely be granted?
p1 p2 p3
Temporarilygrant
Can such an RAG be completely reducible?
The Banker’s Algorithm
R1 R2
Can p1R1 be safely be granted?
Can p2R1 be safely be granted?
Can p3R1 be safely be granted?
p1 p2 p3
granted
Can such an RAG be completely reducible?
The Banker’s Algorithm
R1 R2
p1 p2 p3
Can p1R1 be safely be granted?
Can p2R1 be safely be granted?
Can p3R1 be safely be granted?
The Banker’s Algorithm
R1 R2
Can p1R1 be safely be granted?
Can p2R1 be safely be granted?
Can p3R1 be safely be granted?
Can such an RAG be completely reducible?
p1 p2 p3
Temporarilygrant
The Banker’s Algorithm
R1 R2
p1 p2 p3
Can p1R1 be safely be granted?
Can p2R1 be safely be granted?
Can p3R1 be safely be granted?
notgranted
The Banker’s Algorithm
R1 R2
p1 p2 p3
Can p1R1 be safely be granted?
Can p2R1 be safely be granted?
Can p3R1 be safely be granted?
The Banker’s Algorithm
R1 R2
Can p1R1 be safely be granted?
Can p2R1 be safely be granted?
Can p3R1 be safely be granted?
p1 p2 p3
Can such an RAG be completely reducible?
Temporarilygrant
The Banker’s Algorithm
R1 R2
Can p1R1 be safely be granted?
Can p2R1 be safely be granted?
Can p3R1 be safely be granted?
p1 p2 p3
Can such an RAG be completely reducible?
Temporarilygrant
The Banker’s Algorithm
Can p1R1 be safely be granted?
Can p2R1 be safely be granted?
Can p3R1 be safely be granted?
p1 p2 p3
R1 R2
granted
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.
Operating Systems PrinciplesProcess Management and Coordination
Lecture 6: Deadlocks
Deadlock
Prevention
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.
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.
Eliminating any of these conditions would make deadlock impossible.
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
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
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.
Comparisons
Recommended