Operating Systems Principles Process 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 Principles Process Management and Coordination Lecture 6: Deadlocks Deadlocks with Reusable and Consumable Resources

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

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 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 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. 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 Principles Process 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 Principles Process Management and Coordination Lecture 6: Deadlocks System Model

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

State Transitions by p 1 Process R p1p1 p2p2 R p1p1 p2p2 R p1p1 p2p2 R p1p1 p2p2 S0S0 S1S1 S2S2 S3S3 Request R (by p 1 ) Acquire R (by p 1 ) Release R (by p 1 ) 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 p i  R j – p i has no outstanding requests – number of edges between p i and R j  units in R j Acquisition: Reverse request edge to p i  R j – All requests of p i are satisfied – p i has no outstanding requests Release: Remove edge p i  R j

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.

Example R1R1 R2R2 p1p1 p2p2 p 1 and p 2 both need R 1 and R 2. 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 R1R1 R2R2 p1p1 p2p2

p 1 is blocked. p 2 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 Principles Process Management and Coordination Lecture 6: Deadlocks Deadlock Detection

Graph Reduction Technique Graph Reduction: Repeat the following: 1. Select unblocked process p 2. 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 p 2. Remove p and all request and allocation edges p1p1 p2p2 p4p4 p5p5 p3p3 R1R1 R2R2 R3R3

Graph Reduction Technique Graph Reduction: Repeat the following: 1. Select unblocked process p 2. Remove p and all request and allocation edges p1p1 p2p2 p4p4 p5p5 p3p3 R1R1 R2R2 R3R3

Graph Reduction Technique Graph Reduction: Repeat the following: 1. Select unblocked process p 2. Remove p and all request and allocation edges p1p1 p2p2 p4p4 p5p5 p3p3 R1R1 R2R2 R3R3

Graph Reduction Technique Graph Reduction: Repeat the following: 1. Select unblocked process p 2. Remove p and all request and allocation edges p1p1 p2p2 p4p4 p5p5 p3p3 irreducible Deadlock detected R1R1 R2R2 R3R3

Graph Reduction Technique Graph Reduction: Repeat the following: 1. Select unblocked process p 2. Remove p and all request and allocation edges

Special Cases of Deadlock Detection 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 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 deadlocked 2. Next state T deadlocked only if: a. Operation was a request by p and b. 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 Granted immediately Granted immediately Non-Expedient StateExpedient State p1p1 p2p2 p4p4 p5p5 p3p3 R1R1 R2R2 R3R3 p1p1 p2p2 p4p4 p5p5 p3p3 R1R1 R2R2 R3R3 Satisfiabl e

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 p1p1 p2p2 p4p4 p5p5 p3p3 R1R1 R2R2 R3R3

Immediate Allocations Testing for specific process p Continuous deadlock detection Immediate allocations Single-unit resources Expedient State p1p1 p2p2 p4p4 p5p5 p3p3 R1R1 R2R2 R3R3 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 p1p1 p2p2 R1R1 R2R2 p1p1 p2p2 R1R1 R2R2 Deadlocked Not 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 analyzes global wfg Problems – Coordinator is a performance bottleneck – Communication delays may cause phantom deadlocks p2p2 p1p1 M1M1 p3p3 p4p4 M2M2

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 p2p2 p1p1 M1M1 p3p3 p4p4 M2M2 p2p2 p1p1 M1M1 p3p3 p4p4 M2M2  Due to timeout, p 3 cancel the request. But, the message passed to CC is delayed Due to timeout, p 3 cancel the request. But, the message passed to CC is delayed p 1 requesting the resource holding by p 4 causes phantom deadlock. p 1 requesting the resource holding by p 4 causes phantom deadlock. phantom edge Deadlock

Distributed Approach Detect cycles using probes. If process p i blocked on p j, it launches probe p i  p j p j sends probe p i  p j  p k along all request edges, etc. When probe returns to p i, cycle is detected p1p1 p2p2 p3p3 p7p7 p6p6 p4p4 p5p5 M1M1 M2M2 M3M3 M4M4 p1 p2p1 p2 p 1  p 2  p 3 p 1  p 2  p 3  p 4 p 1  p 2  p 3  p 7 p 1  p 2  p 3  p 4  p 5 p 1  p 2  p 3  p 4  p 5  p 1 p 1  p 2  p 3  p 4  p 5  p 6 p 1  p 2  p 3  p 4  p 5  p 6  p 4

Distributed Approach Detect cycles using probes. If process p i blocked on p j, it launches probe p i  p j p j sends probe p i  p j  p k along all request edges, etc. When probe returns to p i, cycle is detected p1p1 p2p2 p3p3 p7p7 p6p6 p4p4 p5p5 M1M1 M2M2 M3M3 M4M4 p1 p2p1 p2 p 1  p 2  p 3 p 1  p 2  p 3  p 4 p 1  p 2  p 3  p 7 p 1  p 2  p 3  p 4  p 5 p 1  p 2  p 3  p 4  p 5  p 1 p 1  p 2  p 3  p 4  p 5  p 6 p 1  p 2  p 3  p 4  p 5  p 6  p 4 Deadlock detected by M 4. Deadlock detected by M 1.

Operating Systems Principles Process Management and Coordination Lecture 6: Deadlocks 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”

Operating Systems Principles Process Management and Coordination Lecture 6: Deadlocks Dynamic 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) p1p1 Process indicates maximum resources needed Potential request edge: p i  R j (dashed) May turn into real request edge R p2p2

State Transition Using MCG Process indicates maximum resources needed Potential request edge: p i  R j (dashed) May turn into real request edge p1p1 R p2p2 S0S0 S1S1 Request R (by p 2 ) S2S2 Acquire R (by p 2 ) S3S3 Request R (by p 1 ) p1p1 R p2p2 p1p1 R p2p2 p1p1 R p2p2 S4S4 Acquire R (by p 1 ) p1p1 R p2p2

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. Testing for safety algorithm (Dijkstra 1968)

The Banker’s Algorithm p1p1 p2p2 p3p3 R1R1 R2R2

R1R1 R2R2 p1p1 p2p2 p3p3 Which of the requests can safely be granted? Can p 1  R 1 be safely be granted? Can p 2  R 1 be safely be granted? Can p 3  R 1 be safely be granted?

The Banker’s Algorithm R1R1 R2R2 Can p 1  R 1 be safely be granted? Can p 2  R 1 be safely be granted? Can p 3  R 1 be safely be granted? p1p1 p2p2 p3p3 Temporarily grant Can such an RAG be completely reducible?

The Banker’s Algorithm R1R1 R2R2 Can p 1  R 1 be safely be granted? Can p 2  R 1 be safely be granted? Can p 3  R 1 be safely be granted? p1p1 p2p2 p3p3 Temporarily grant Can such an RAG be completely reducible?

The Banker’s Algorithm R1R1 R2R2 Can p 1  R 1 be safely be granted? Can p 2  R 1 be safely be granted? Can p 3  R 1 be safely be granted? p1p1 p2p2 p3p3 granted Can such an RAG be completely reducible?

The Banker’s Algorithm R1R1 R2R2 p1p1 p2p2 p3p3 Can p 1  R 1 be safely be granted? Can p 2  R 1 be safely be granted? Can p 3  R 1 be safely be granted?

The Banker’s Algorithm R1R1 R2R2 Can p 1  R 1 be safely be granted? Can p 2  R 1 be safely be granted? Can p 3  R 1 be safely be granted? Can such an RAG be completely reducible? p1p1 p2p2 p3p3 Temporarily grant 

The Banker’s Algorithm R1R1 R2R2 p1p1 p2p2 p3p3 Can p 1  R 1 be safely be granted? Can p 2  R 1 be safely be granted? Can p 3  R 1 be safely be granted?  not granted

The Banker’s Algorithm R1R1 R2R2 p1p1 p2p2 p3p3 Can p 1  R 1 be safely be granted? Can p 2  R 1 be safely be granted? Can p 3  R 1 be safely be granted? 

The Banker’s Algorithm R1R1 R2R2 Can p 1  R 1 be safely be granted? Can p 2  R 1 be safely be granted? Can p 3  R 1 be safely be granted?  p1p1 p2p2 p3p3 Can such an RAG be completely reducible? Temporarily grant

The Banker’s Algorithm R1R1 R2R2 Can p 1  R 1 be safely be granted? Can p 2  R 1 be safely be granted? Can p 3  R 1 be safely be granted?  p1p1 p2p2 p3p3 Can such an RAG be completely reducible? Temporarily grant

The Banker’s Algorithm Can p 1  R 1 be safely be granted? Can p 2  R 1 be safely be granted? Can p 3  R 1 be safely be granted?  p1p1 p2p2 p3p3 R1R1 R2R2 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 Principles Process Management and Coordination Lecture 6: Deadlocks 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