Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Successfully reported this slideshow.

Like this presentation? Why not share!

6,132 views

Published on

Published in:
Technology

No Downloads

Total views

6,132

On SlideShare

0

From Embeds

0

Number of Embeds

639

Shares

0

Downloads

278

Comments

0

Likes

4

No embeds

No notes for slide

- 1. Deadlock
- 2. Deadlock <ul><li>Def. A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause. </li></ul><ul><li>Necessary Conditions for Deadlock </li></ul><ul><ul><li>Mutual Exclusion: Processes claim exclusive control of the resources they require. </li></ul></ul><ul><ul><li>Hold and Wait: Processes hold resources already allocated to them while waiting for additional resources. </li></ul></ul><ul><ul><li>No Preemption: Resources cannot be forcibly removed from the process holding them until the resources are used to completion. </li></ul></ul><ul><ul><li>Circular Wait: A circular chain of processes exists such that each process hold one or more resources that are being requested by the next process in the chain. </li></ul></ul>
- 3. Dealing with Deadlock <ul><li>Three principle strategies for dealing with deadlock </li></ul><ul><ul><li>Detection: How can deadlock be identified? </li></ul></ul><ul><ul><li>Recovery: What are the “best” ways to recover from deadlock? </li></ul></ul><ul><ul><li>Prevention (and Avoidance): How can deadlock be prevented in the first place? </li></ul></ul><ul><ul><ul><li>Avoidance: Can we avoid deadlock through careful allocation scheme? </li></ul></ul></ul>
- 4. Relevant Events <ul><ul><li>A process follows the following sequence to use resources: </li></ul></ul><ul><ul><ul><li>Request (resource) </li></ul></ul></ul><ul><ul><ul><li>Use (resource) </li></ul></ul></ul><ul><ul><ul><li>Release (resource) </li></ul></ul></ul><ul><ul><li>The three important events are when the process </li></ul></ul><ul><ul><ul><li>requests , </li></ul></ul></ul><ul><ul><ul><li>acquires , and </li></ul></ul></ul><ul><ul><ul><li>releases </li></ul></ul></ul><ul><ul><ul><li>resources. </li></ul></ul></ul>
- 5. “ Claim” (Future-Request) Edges
- 6. Claim Request
- 7. Request Assignment
- 8. Safe: No Cycle
- 9. A Dangerous Request
- 10. See Any Cycles?
- 11. A System Model <ul><li>A system is a pair ( S , P ) where S is a set of system states {S,T,U,V,...} and P is a set of processes {P 1 ,P 2 ,...} . </li></ul><ul><li>A process P i is a partial function from system states into nonempty subsets of system states, </li></ul><ul><li>P i : S 2 S </li></ul><ul><li>Def. A process P i is blocked in state S if there exists no T such that S i T . (A process is blocked in a given state if it can't change state.) </li></ul><ul><li>Def. A process P i is deadlocked in state S if for all T such that </li></ul><ul><li>S * T , P i is blocked in T . </li></ul><ul><li>Ex1. P 2 is blocked (and deadlocked) in both U and V . </li></ul><ul><li>Ex2. P 1 is blocked but not deadlocked in T . </li></ul><ul><li>Def. A state S is called a deadlock state if there exists a process P i that is deadlocked in S . </li></ul><ul><li>Def. A state S is a safe state if for all T such that S i T , T is not a deadlock state. </li></ul>
- 12. Example V U T S P = {S,T,U,V} P = {P1,P2} P1(S) = {T,U} P1(U) = {V} … P2(S) = {U} … 1 2 1 2 1 1 2
- 13. Resource (Allocation) Graph (RAG) <ul><li>A directed graph is a pair (N,E) , where N is a set of nodes and E is a set of ordered pairs (a,b) , a,b N , called edges. </li></ul><ul><li>Def. A RAG is a directed graph with </li></ul><ul><li>N = P R </li></ul><ul><li>where P = {P 1 ,...,P n } a set of process nodes and R = {R 1 ,...,R m } a set of resource nodes. </li></ul><ul><ul><li>The graph is “bipartite” with respect to P and R . </li></ul></ul><ul><ul><li>An edge (P i ,R j ) is called a request edge (request by P i for 1 unit of R j ). </li></ul></ul><ul><ul><li>An edge (R j ,P i ) is called an assignment edge (allocation of 1 unit of R j to P i ). </li></ul></ul><ul><ul><li>For each resource R i R , there exists a non-negative integer t I denoting the number of units of R i . </li></ul></ul>
- 14. Invariants on RAG <ul><li>Let |(a,b)| be the number of edges directed for node a to node b . </li></ul><ul><li>Then </li></ul><ul><ul><ul><li> j |(R i ,P j )| t i for all i . (No more than t i assignments (allocation) may be made for R i .) </li></ul></ul></ul><ul><ul><ul><li>|(R i ,P j )| + |(P j ,R i )| t i for all i and j . (The sum of the requests and allocation of any process for a particular resource cannot exceed the available units.) </li></ul></ul></ul>
- 15. State Transitions <ul><li>The system state is changed to a new state only as a result of requests, releases, or acquisitions of resources by a single process. </li></ul><ul><ul><li>Request. If a system is in state S and process P i has no requests outstanding (no request edges), then P i may request any # of resources. The system then enters state T , say </li></ul></ul><ul><ul><li>Release. P i can cause a state change from S to T by a release operation iff P i has no requests and some allocations. P i may release any nonempty subset of its resources in this operation. </li></ul></ul>
- 16. <ul><ul><li>Acquisition. A system can change from state S to state T by an acquisition operation by iff P i has outstanding requests and all such requests can be satisfied; for all resources R j such that ( P i , R j ) E , we have </li></ul></ul><ul><li>A process P i is blocked if it is unable to perform any of these operations: 1, 2, or 3. That is, if there exists at least one resource R j such that </li></ul>State Transitions (con’d)
- 17. Reduction on RAG <ul><li>A RAG is reduced by a process P i , which is neither blocked nor an isolated node, by removing all edges to and from P i . </li></ul><ul><li>A RAG is irreducible if the graph cannot be reduced by any process. A RAG is completely reducible if there exists a sequence of reductions that deletes all edges of the graph. </li></ul>
- 18. Theorems <ul><li>Theorem 1: S is a deadlock state iff the RAG of S is not completely reducible. </li></ul><ul><li>Cor. 1: A process P i is not deadlocked iff a series of reductions leaves a state in which P i is not blocked. </li></ul><ul><li>Cor. 2: If S is a deadlock state, then at least two processes are deadlocked in S . </li></ul><ul><li>Theorem 2: A cycle in a RAG is a necessary condition for deadlock. </li></ul><ul><li>Theorem 3: If S is not a deadlock state and then T is a deadlock state iff the operation by P i is a request and P i is deadlocked in T . </li></ul>
- 19. Data structures for RAG <ul><li>RAG can be represented by </li></ul><ul><ul><li>An allocation matrix A, where A ij =| ( P i , R j ) | for i = 1,…,n, j = 1,…,m. </li></ul></ul><ul><ul><li>A request matrix B, where B ij =| ( P i , R j ) | for i = 1,…,n, j = 1,...,m. will use B i to denote i-th row, i.e., B i = ( B i1 ,..., B im ). </li></ul></ul><ul><ul><li>An available vector T, where </li></ul></ul><ul><ul><li>T i = # of available unit for R i , i = 1,...,n. </li></ul></ul>
- 20. Deadlock Detection Algorithm <ul><li>L := {}; repeat L' := L; for i:=1 to n do if Pi not in L and Bi <= T then T := T + Ai; L := L U {Pi}; end if end for until L = L'; Deadlock := not( L = {Pi, ..., Pn}) </li></ul>
- 21. Example <ul><li>A | R1 R2 R3 B | R1 R2 R3 --------------- --------------- P1 | 1 1 1 P1 | 3 2 1 P2 | 1 1 1 P2 | 2 2 1 P3 | 1 1 1 P3 | 1 1 1 P4 | 1 1 1 P4 | 0 0 0 T = (0, 0, 0). </li></ul><ul><li>Inspection order P 1 , P 2 , ... Reduction order P n , P n-1 , ... # of process inspections = n + (n-1) + ... = n(n+1)/2 So worst-case exec. time = O(mn 2 ) </li></ul>
- 22. Recovery <ul><ul><li>Recovery through preemption </li></ul></ul><ul><ul><li>Recovery through rollback </li></ul></ul><ul><ul><li>Recovery through killing processes </li></ul></ul>
- 23. Prevention <ul><ul><li>Eliminate possibilities </li></ul></ul><ul><ul><li>Techniques </li></ul></ul><ul><ul><ul><li>Serialization (Prevention) </li></ul></ul></ul><ul><ul><ul><li>One-shot allocation (Prevention) </li></ul></ul></ul><ul><ul><ul><li>Hierarchical allocation (Prevention) </li></ul></ul></ul><ul><ul><ul><li>Banker’s algorithm (Avoidance) </li></ul></ul></ul>
- 24. Serialization <ul><ul><li>Only one process may hold resources at any time. </li></ul></ul><ul><ul><li>Very inefficient use of resources </li></ul></ul>
- 25. One-shot Allocation <ul><li>A process may only request all its resources at one time. It is blocked until the entire request can be satisfied. </li></ul><ul><li>Resources are locked even if they are not in use. </li></ul><ul><li>This method may be necessary for real-time processes that must be guaranteed not to wait for resource allocation once they are underway. O.w., it is too conservative. </li></ul>
- 26. Hierarchical Allocation <ul><li>Algorithm: </li></ul><ul><ul><li>Resources are grouped into levels. </li></ul></ul><ul><ul><li>A process may only request resources at levels higher than any resource currently held by that process. </li></ul></ul><ul><ul><li>Resources may be released in any order. </li></ul></ul>
- 27. Proof that deadlock cannot occur <ul><li>Proof by Induction: Assume N is highest and 0 is lowest. </li></ul><ul><ul><li>Induction hypothesis: Resources requested at levels i will always be acquired and released in a finite time. (No circular wait is possible.) </li></ul></ul><ul><ul><li>Induction basis: The hypothesis is true for i = highest level N. </li></ul></ul><ul><ul><li>Induction step: </li></ul></ul><ul><ul><li>Suppose a process has requested resources at level i-1 .. </li></ul></ul><ul><ul><li>It will be delayed if other processes have those resources. </li></ul></ul><ul><ul><li>Each of these other processes must release them eventually, or be blocked waiting for resources at level i or higher. </li></ul></ul><ul><ul><li>By induction hypothesis, this blockage cannot last forever. </li></ul></ul>
- 28. Properties <ul><ul><li>When all requests are at the same level, this method is equivalent to one-shot allocation. </li></ul></ul><ul><ul><li>Resources at lower levels are blocked for longer periods, but those at higher levels are shared well. Thus, place the scariest resources at the highest levels so that requests for them will be made only when they are actually needed by a process. </li></ul></ul><ul><ul><li>This method works well when the resources are semaphores. </li></ul></ul><ul><ul><li>semaphore S1,S2,S3 P(S1,S2,S3) P(S1) P(S2) P(S2) P(S3) P(S3) P(S1) V(S1,S2,S3) order of V's doesn't matter </li></ul></ul>
- 29. Avoidance <ul><ul><li>The question is: “Is there an algorithm that can always avoid deadlock by making the right choice all the time?” </li></ul></ul><ul><ul><li>Deadlock is the result of granting a resource. </li></ul></ul><ul><ul><li>Banker’s algorithm </li></ul></ul>
- 30. Banker's Algorithm <ul><ul><li>Each process starts with a claim. A process may never request more than its claim. (However, the sum of the claims of all process may exceed the number of resources.) </li></ul></ul><ul><ul><li>The current allocation state is kept separately for each resource type: (a) For each process: (1) claim (2) holdings (acquired resources) (3) outstanding request (if process is blocked for allocation) (b) Amount of unallocated resources. </li></ul></ul>
- 31. Example
- 32. P1: 2 4
- 33. P1: complete
- 34. P0: 5 10
- 35. P0: complete
- 36. Example (from text)
- 37. P2: 2 3?
- 38. P1: 2 4?
- 39. P1: complete?
- 40. Safe state <ul><ul><li>An allocation state is realizable if (a) each claim maximum available. (b) each process is holding its claim. (c) the total amount of held resources is the total available. Otherwise, the allocation state is unrealizable. </li></ul></ul><ul><ul><li>A realizable state is safe if there is a sequence of processes, P 1 ,...,P n ,(a safe sequence ) such that: P 1 can finish (i.e., there are enough unallocated resources to satisfy its claim.) </li></ul></ul><ul><ul><li>In general, P i can finish if P i-1 releases its current holding. </li></ul></ul><ul><ul><li>The state is safe because we can avoid deadlock at the moment by blocking any new processes (or any new claims) until all the current processes have finished in the safe order. </li></ul></ul>
- 41. Example <ul><ul><li>(One resource class only) </li></ul></ul><ul><ul><li>process holding max claims A 4 6 B 2 7 C 4 11 unallocated: 2 safe sequence: A,B,C </li></ul></ul><ul><ul><ul><li>If B should have a claim of 9 instead of 7, there is no safe sequence. </li></ul></ul></ul>
- 42. Unsafe state <ul><ul><li>An unsafe state is deadlock free if there is a sequence of processes, P 1 ,...,P n , (a deadlock free sequence) such that P 1 might finish. (There are enough unallocated resources to satisfy its current outstanding requests, but not necessarily its entire claim.) </li></ul></ul><ul><ul><li>In general, P i might finish if P i-1 does. </li></ul></ul><ul><ul><li>The state is deadlock free since no process is waiting. However, it may be unsafe because the processes may now request resource that put them in a deadlock state, no matter what action the allocator takes. </li></ul></ul>
- 43. Example <ul><ul><li>process holding max claims outstanding requests A 4 6 2 B 2 9 6 C 4 11 7 unallocated: 2 deadlock-free sequence: A,B,C </li></ul></ul><ul><li>However, this sequence is not safe: if B should have 7 instead of 6 outstanding requests, deadlock exists. </li></ul>
- 44. Banker’s algorithm <ul><ul><li>The Banker's Algorithm: satisfy a request iff the resulting state is safe. </li></ul></ul><ul><ul><li>The Banker's Algorithm is conservative: it cautiously avoids entering an unsafe state even if this unsafe state has no deadlock. It also requires prior claims. </li></ul></ul>deadlock unsafe safe
- 45. Implementation method <ul><ul><li>Find a safe sequence whenever a request is made. If unsuccessful, block the requester. When a resource is released, consider again allocating resources to blocked processes. </li></ul></ul><ul><ul><ul><li>The cost of finding a sequence is O(n 2 ) not O(n!) . </li></ul></ul></ul><ul><ul><ul><li>If more than one resource type, the same sequence must work for resources of all types. </li></ul></ul></ul><ul><ul><ul><li>There is more efficient algorithm by Habermann. </li></ul></ul></ul><ul><ul><li>Example . five processes: P 0 , P 1 , P 2 , P 3 , P 4 three resource types: A, B, C with 10, 5, 7 units. At time T 0 (Max = Allocation + Need) </li></ul></ul>
- 46. Example <ul><li>Allocation Max Need Available A B C A B C A B C A B C P0 0 1 0 7 5 3 7 4 3 3 3 2 P1 2 0 0 3 2 2 1 2 2 P2 3 0 2 9 0 2 6 0 0 P3 2 1 1 2 2 2 0 1 1 P4 0 0 2 4 3 3 4 3 1 safe sequence <P1, P3, P4, P2, P0> Suppose that P1 requests (1,0,2). To decide whether or not to grant this request, Allocation Need P1 3 0 2 0 2 0 2 3 0 Again, safe seq <P1, P3, P4, P0, P2> In this new state, P4 requests (3,3,0) not enough available resources P0 requests (0,2,0) unsafe state? Why? </li></ul>

No public clipboards found for this slide

Be the first to comment