Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Operating Systems Principles Process Management and Coordination Lecture 6: Deadlocks 主講人:虞台文 Content Deadlocks with Reusable and Consumable Resources Approaches to the Deadlock Problem System Model – – – Deadlock Detection – – – Reduction of Resource Graphs Special Cases of Deadlock Detection Deadlock Detection in Distributed Systems Recovery from Deadlock Dynamic Deadlock Avoidance – – Resource Graphs State Transitions Deadlock States and Safe States 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 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 Main topic of at the lecture Number of units varies runtime – Process may create new units – Process may consume units (no releasing) Examples: messages, signals – Reusable Resources Example (File Sharing) p1: ... open(f1,w); open(f2,w); ... p2: ... open(f2,w); open(f1,w); ... Deadlock when executed concurrently 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 C is not true Deadlock and livelock will lead to starvation. But, the inverse is not necessary true. Deadlock, Livelock, and Starvation Deadlock – Livelock – – Two or more processes (threads) are blocked indefinitely, waiting for each other. 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. Examples: Starvation Not Due to Deadlock or Livelock 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 – 2. Avoidance (dynamic) – 3. Allow deadlock to happen and eliminate it Runtime checks disallow allocations that might lead to deadlocks 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 The state transition diagram described below is not complete. The actual number of states depends on possible operations of processes. State Transitions by p1 Process p1 p1 R p2 S0 p1 R p2 Request R (by p1) S1 p1 R p2 Acquire R (by p1) S2 R p2 Release R (by p1) S3 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 p1 p1 p1 p1 Release: Remove edge piRj R p2 S0 R p2 Request R (by p1) S1 R p2 Acquire R (by p1) S2 R p2 Release R (by p1) S3 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 p1 and p2 both need R1 and R2. p1 R1 p1: Request(R1); Request(R2); p2: Request(R2); Request(R1); Release(R2); Release(R1); Release(R1); Release(R2); R2 p2 Example p1: Request(R1); Request(R2); p2: Request(R2); Request(R1); Release(R2); Release(R1); Release(R1); Release(R2); Example p1: Request(R1); Request(R2); p2: Request(R2); Request(R1); Release(R2); Release(R1); Release(R1); Release(R2); Example p1: Request(R1); Request(R2); p2: Request(R2); Request(R1); Release(R2); Release(R1); Release(R1); Release(R2); Example p1: Request(R1); Request(R2); p2: Request(R2); Request(R1); Release(R2); Release(R1); Release(R1); Release(R2); Example p1 R1 R2 p2 Example p1 is blocked. p2 is blocked. No state is safe since the deadlock state is always reachable. Example A deadlock state. 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 p1 p2 R1 p3 R2 p4 R3 p5 Graph Reduction Technique Graph Reduction: Repeat the following: 1. Select unblocked process p 2. Remove p and all request and allocation edges p1 p2 R1 p3 R2 p4 R3 p5 Graph Reduction Technique Graph Reduction: Repeat the following: 1. Select unblocked process p 2. Remove p and all request and allocation edges p1 p2 R1 p3 R2 p4 R3 p5 Graph Reduction Technique Graph Reduction: Repeat the following: 1. Select unblocked process p 2. Remove p and all request and allocation edges p1 p2 R1 p3 R2 p4 R3 p5 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 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 All satisfiable requests granted immediately Expedient state = no satisfiable request edges Non-Expedient State p1 p2 R1 Satisfiabl e p3 p1 Granted R3 immediately R2 p4 Expedient State p5 p2 R1 p3 R2 p4 R3 p5 Testing for specific process p Continuous deadlock detection Immediate allocations Single-unit resources Immediate Allocations 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 Testing for specific process p Continuous deadlock detection Immediate allocations Single-unit resources Immediate Allocations Expedient State p1 p2 R1 p3 R2 p4 R3 p5 Testing for specific process p Continuous deadlock detection Immediate allocations Single-unit resources Immediate Allocations Expedient State p1 p2 R1 p3 R2 p4 R3 p5 Knot 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 p1 R1 p2 p1 R2 Not Deadlocked R1 p2 R2 Deadlocked Testing for specific process p Continuous deadlock detection Immediate allocations Single-unit resources 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 M1 M2 p2 p3 p1 p4 Deadlock Due to timeout, p3 cancel the request. But, the message passed to CC is delayed Phantom Deadlocks Central Coordinator (CC) M1 Each machine maintains a local wfg – Changes reported to CC p1 requesting the resource – CC constructs and holding by p4 causes phantom analyzes global wfg – M2 p2 p3 p1 p4 deadlock. Problems – – Coordinator is a performance bottleneck Communication delays may cause phantom deadlocks M1 M2 p2 p1 phantom edge p3 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 p4 p5 p1 M1 p1 M3 M2 p1 p2 p2 p1 p2 p3 p3 p1 p2 p3 p7 p7 p1 p2 p3 p4 p4 p1 p2 p3 p4 p5 p1 p2 p3 p4 p5 p6 p4 p5 p1 p2 p3 p4 p5 p6 M4 p6 Distributed Approach Detect cycles using probes. If process pi blocked on pj , it launches probe pi pj Deadlock pj sends probe pi pj pk along all request edges, etc. detected by Mreturns 1. When probe to pi, cycle is detectedDeadlock detected by M4. p1 p2 p3 p4 p5 p1 M1 p1 M3 M2 p1 p2 p2 p1 p2 p3 p3 p1 p2 p3 p7 p7 p1 p2 p3 p4 p4 p1 p2 p3 p4 p5 p1 p2 p3 p4 p5 p6 p4 p5 p1 p2 p3 p4 p5 p6 M4 p6 Operating Systems Principles Process 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., Memory) Indirect: Rollback to earlier “checkpoint” Operating Systems Principles Process 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) Process indicates maximum resources needed Potential request edge: piRj (dashed) May turn into real request edge p1 R p2 State Transition Using MCG Process indicates maximum resources needed Potential request edge: piRj (dashed) May turn into real request edge p1 p1 R R p2 S0 p1 R p2 Request R (by p2) S1 p1 R p2 Acquire R (by p2) S2 p1 R p2 Request R (by p1) S3 p2 Acquire R (by p1) S4 Testing for safety algorithm (Dijkstra 1968) 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 request: changing pR to Rp – Reduce new claim graph – If it is completely reducible, proceed else reverse acquisition. The Banker’s Algorithm p1 p2 R1 p3 R2 Can p1R1 be safely be granted? Can p2R1 be safely be granted? Can p3R1 be safely be granted? The Banker’s Algorithm p1 p2 R1 p3 R2 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 p1 p2 p3 Temporarily grant R1 R2 Can such an RAG be completely reducible? Can p1R1 be safely be granted? Can p2R1 be safely be granted? Can p3R1 be safely be granted? The Banker’s Algorithm p1 p2 p3 Temporarily grant R1 R2 Can such an RAG be completely reducible? Can p1R1 be safely be granted? Can p2R1 be safely be granted? Can p3R1 be safely be granted? The Banker’s Algorithm p1 p2 p3 granted R1 R2 Can such an RAG be completely reducible? Can p1R1 be safely be granted? Can p2R1 be safely be granted? Can p3R1 be safely be granted? The Banker’s Algorithm p1 p2 R1 p3 R2 Can p1R1 be safely be granted? Can p2R1 be safely be granted? Can p3R1 be safely be granted? The Banker’s Algorithm p1 Temporarily grant p2 R1 p3 R2 Can such an RAG be completely reducible? Can p1R1 be safely be granted? Can p2R1 be safely be granted? Can p3R1 be safely be granted? The Banker’s Algorithm not p granted 2 p1 R1 p3 R2 Can p1R1 be safely be granted? Can p2R1 be safely be granted? Can p3R1 be safely be granted? The Banker’s Algorithm p1 p2 R1 p3 R2 Can p1R1 be safely be granted? Can p2R1 be safely be granted? Can p3R1 be safely be granted? The Banker’s Algorithm p1 p2 R1 Temporarily grant p3 R2 Can such an RAG be completely reducible? Can p1R1 be safely be granted? Can p2R1 be safely be granted? Can p3R1 be safely be granted? The Banker’s Algorithm p1 p2 R1 Temporarily grant p3 R2 Can such an RAG be completely reducible? Can p1R1 be safely be granted? Can p2R1 be safely be granted? Can p3R1 be safely be granted? The Banker’s Algorithm p1 p2 R1 p3 granted R2 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 Prevention Deadlock Detection & Recovery – – Deadlock Avoidance – – Granted resources as long as they are available. OS resolves deadlock if detected. 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. Eliminating any of these conditions would make deadlock impossible. 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 Mutual exclusion Hold and wait No preemption Circular wait Deadlock Prevention 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 Eliminating any of Mutual exclusion Hold and wait No preemption Circular wait Deadlock Prevention 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 Eliminating any of Mutual exclusion Hold and wait No preemption Circular wait Deadlock Prevention 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