1 / 78

Chapter 10: Deadlock

Chapter 10: Deadlock. Prof. Steven A. Demurjian, Sr. † Computer Science & Engineering Department The University of Connecticut 191 Auditorium Road, Box U-155 Storrs, CT 06269-3155. steve@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818.

elroy
Download Presentation

Chapter 10: Deadlock

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Chapter 10: Deadlock Prof. Steven A. Demurjian, Sr. † Computer Science & Engineering Department The University of Connecticut 191 Auditorium Road, Box U-155 Storrs, CT 06269-3155 steve@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818 † These slides have been modified from a set of originals by Dr. Gary Nutt.

  2. Purpose of this Chapter • What is Deadlock? • General Problem • Deadlock/Concurrency Control in Databases • What are Strategies for Handling Deadlock? • Prevention • Avoidance • Detection and Recovery • What are Formal Models Used by OS to Handle Deadlock? • Why are Formal Models Needed? • Focus on Avoidance & Detection and Recovery

  3. General Problem: A Deadly Embrace Process 3 Resource 3 Process 1 Process 2 Resource 1 Resource 2

  4. Deadlock in Databases Transaction 1 Transaction 2 Transaction 3 Shared Database • Databases Must Control Access to Information by Multiple Concurrent Transactions (Processes) • How do we Prevent Simultaneous Updates of Database by Concurrent Transactions (Processes)? • Data is the Resource in Database System

  5. Addressing Deadlock • Deadlock is Global Condition! • Need to Analyze All Processes that Need All Resources • Can’t Make Local Decision Based on Needs of One Process • Four Deadlock Approaches: • Prevention: Never Allow Deadlock to Occur • Avoidance: System Makes Decision to Head Off Future Deadlock State • Detection & Recovery: Check for Deadlock (Periodically or Sporadically), Then Recover • Manual Intervention: Operator Reboot if System Seems Too Slow

  6. Prevention: A First Look • Design the System So that Deadlock is Impossible • Deadlock Only Occurs If All Following TRUE!! • Mutual Exclusion: Allocated Resources are Exclusive Property of Process • Hold and Wait: Process Can Hold Resource While Waiting for Another Resource • Circular Waiting: Classic Example in Slide 10.3 • No Preemption: Only Process Can Release Resources or Withdraw Resource Request • All Four Necessary for Deadlock to Exist • Prevention Requires Resource Manager to Violate at Least One Condition at All Times!

  7. Avoidance: A First Look • Construct a Formal Model of System States • Via Model, Choose a Strategy that Will Not Allow the System to Go to a Deadlock State • Predictive Approach: Requires Processes to Declare Intent re. Resources in Advance • Process X Needs 3 of A, 2 of B, 0 of C, 4 of D • Represents “Maximum Claim” on Resources • Process X Won’t Proceed Until all Resources Available • May Require “Long” Waits • Amenable to Formal Solution/Algorithm

  8. Detection and Recovery: A First Look • When Deadlock Occurs, Can we Detect and Recover? • Two Phases to Algorithm • Detection: Is there Deadlock? • Recovery: Preempt Resources from Processes • Detection Algorithm • When is it Executed? • What is its Overhead? • Too Often - Wastes Resources • Too Infrequent - Blocked Processes Don’t Do Enough Work • Dominant Commercial Solution

  9. Deadlock in Databases • Concurrent Access to Database Information • Optimistic Concurrency Control • Assume Problems Infrequent (ATM Example) • Maintain Transaction Log • Detect and Correct Errors in System via Log “Long-After” Their Occurrence • Similar to What in OS? Deadlock Concepts? • Pessimistic Concurrency Control • Assume Problems will Occur (Airline Example) • Require Transactions to Lock Portions of Data for Read and Write Requests • Similar to What in OS? Deadlock Concepts?

  10. Deadlock and Concurrency in Distributed Applications • Client/Server and Multi-Tiered Architectures Rely Heavily on Concurrency Control • At Client/Middle-Server Side • Programming Language Support to Allow Concurrent Operations • Specialized Processes for Managing Access to Shared Data/Resources • Both in Addition to OS Capabilities • Database Servers and Management Systems Provide Own Concurrency Control andDeadlock Avoidance, Detection, Prevention

  11. Concurrency in Programming Languages(Circa 1995) C-BasedC++Based Distributed OOL Others Concurr Cob ABC++ Amber A’UM cooC AKC++ Argus Beta PROCOL Charm++ Con Meld Blaze 2 Comp C++ DC++ CLIX Small-Talk Concert C++ DOWL Clueter86 ConSmalltalk Conc C++ DROL Ellie CST COOOL Dsmalltalk Fleng++ ESP Eden Hybrid Actor-Based HPC++ Emerald Java ABCL+ MPC++ Flame (C++) Lamina Acore Mentat Guile NEXUS ACT++ PARMACS Heraklit O-CPU Act1,2,3 PRESTO KITARA Orient 84 Actalk pC++ Must PO Actra UC++ Orca POOL-T/I ALBA WARASA SINA A-NETL ADA95 Solve Cantor, Janus Extended Eiffel Plasma-II, Rosette

  12. Recall MBDSConcurrency Control Process B3 A1 K12 Request Preparation Post Processing C4 K12 D6 Put Msg. Get Msg. F15 From Other Backend E15 To Backend(s) Get Msg. Put Msg. K12 D6,F15 E15 Record Processing I16 Directory Management J23 H22 Concurrency Control G21 Disk I/O • CC Controls Access to Indices, Records, Attributes, etc., All Simultaneously Needed by User Requests

  13. CT Insurance Department: CC/DeadlockManaged by Commercial Applications Database Server Running Oracle Initial Data Entry Operator (Scanning & Posting) Advanced Data Entry Operators Analyst Manager 10-100MB Network RMI Registry Document Server Stored Images/CD RMI Act. Obj/Server RMI Act. Obj/Server Functional Server

  14. RMI: Unicast Remote Objects Don’t Interact with One Another Adv. Data Entry Analyst Manager rmid rmiregistry Server Activation Object ActivatableImplementation.java Unicast Remote Object LicensingImpl Unicast Remote Object LicensingImpl Unicast Remote Object LicensingImpl rmiregistry 1100 rmiregistry 1101 rmiregistry 1102 Document Server Stored Images/CD Database Server Running Oracle

  15. A Formal Model for Deadlock • P = {p1, p2, …, pn} be a set of n Processes • R = {R1, R2, …, Rm} be a set of m Resources • C = {c1,c2, …, cm), where cj = Number of units of Rj in the System • S = {S0, S1, …} be a set of States Representing the Assignment of Resource Rj to Process pi • State Changes whenever Processes Take Action • This Allows Us to Identify • Situations Where Processes are Blocked (e.g. Require Another Process to do Something) • Deadlock Situation in the Operating System • Formal Model Based on State-Transition Diagram • Recall FSM from CSE230

  16. State Transitions xi Sj Sk • System Changes State Due to Action of Process pi • There are Three Pertinent Actions: • Request: • Request One or More Units of a Resource • Transition Between States Labeled (“ri”) • Allocation: • All Outstanding Process Requests for a Given Resource are Satisfied (Transition “ai”) • Deallocation : • Process Releases Units of a Resource (Transition “di”)

  17. Properties of States a1 r3 Sj r1 • Define Deadlock w.r.t. Patterns of Transitions • Define: pi is Blocked in Sj if pi Cannot Cause a Transition out of Sj • Whyis p2 blocked in Sj ? • p2 Can’t Leave on Own • Requires Action by Either p1 or by p3 • Can’t Control Destiny! • If pi is Blocked in Sj, and will also be Blocked in every Sk Reachable from Sj, then pi is Deadlocked • Sj is Called a Deadlock State

  18. Example • One Process, Two Units of One Resource • Can Request One Unit at a Time • r for Request • a for Allocated • d for Deallocate • Two Alternatives • Process Can Request, Alloc, Dealloc Twice • Process can Request, Alloc, R, A, D, D • Eventually Returns to State S0 d d r a r a S0 S1 S2 S3 S4

  19. Extension of Example • Consider Two Processes Competing for 2 Units of Single Resource • Process Limited to Requesting One Unit at Time • Process Can’t ask for More than 2 Units • How is Prior State Diagram Restructured? • Let Sij Refer to P0 in Si and P1 in Sj • All States Not Possible • S24, S34, S42, S43, S44 • Some are Unfeasible (S24 - P0 has 1 Unit, P1 has 2) • What Does Resulting State Diagram Resemble?

  20. Extension of Example d0 d0 r0 a0 r0 a0 S00 S10 S20 S30 S40 r1 r1 r1 r1 r1 d0 d0 r0 a0 r0 a0 S01 S11 S21 S31 S41 d1 d1 d1 d1 a1 a1 a1 a1 d0 r0 a0 r0 S02 S12 S22 S32 r1 r1 d0 r1 r1 r0 a0 r0 S03 S13 S23 S33 d1 d1 a1 a1 r0 S04 S14 • What Does S33 Represent? • Impact of More Ps and Rs?

  21. Prevention • Necessary Conditions for Deadlock • Mutual Exclusion • Hold and Wait • Circular Waiting • No Preemption • Ensure that at Least One of the Necessary Conditions is False at All Times • Why Must Mutual Exclusion Hold at All Times? • Some Resources (Tape Drive) Must be Exclusively Held by a Process • How Can a Prevention Strategy be Designed to Guarantee Failure of One of Other Conditions?

  22. Hold and Wait • Invalidate: Hold and Wait: Process Can Hold Resource While Waiting for Another Resource • Approach 1: Targeted to Batch Systems • Process Must Request All Resources it Needs • Process Competes for All Resources Even if Needs Only One Resource at Time • Holds Resources “Done” With • Approach 2: Targeted to Timesharing • For Process to Acquire a Resource • Must Release All Held Resources • Reacquire All (Released &New) Resources Needed • Overhead to Reacquire Held Resources • Could Encourage Starvation

  23. Circular Wait Ri R P Pi P holds R P R P requests R • Classic Problem: K Processes Holding Units of K Resources • K Processes Want Held Resource from Other K-1 Processes • Search for Cycles in Graph

  24. Circular Wait (Continued) • Identifiable Whenever there is a Cycle in the Graph of Processes and Resources • What Resource Request Strategy Guarantees No Cycles (i.e., Invalidates Circular Wait)? • Total Order of All System Resources! • Unique/Numbered System • Formally: • Total Order on All Resources is Sequencing • Process Can Only Ask for Rj If Ri < Rj for All Ri the Process is Currently Holding • No Need to Request All at Once • However, Can’t go Back to Get One “Missed”

  25. Revisit Dining Philosophers Problem philosopher(int i) { while(TRUE) { // Think // Eat P(fork[i]); P(fork[(i+1) mod 5]); eat(); V(fork[(i+1) mod 5]); V(fork[i]); } } semaphore fork[5]=(1,1,1,1,1); fork(philosopher, 1, 0); fork(philosopher, 1, 1); fork(philosopher, 1, 2); fork(philosopher, 1, 3); fork(philosopher4, 0); philosopher4() { while(TRUE) { // Thinking ... P(fork[0]); P(fork[4]); eat(); V(fork[4]); V(fork[0]); } }

  26. Allowing Preemption ru Si Sj wu dv ru Sk • Invalidate Preemption: Allow a Process to Time-out on a Blocked Request • Thus, Process Withdraws the Request If It Fails • Consider State Transition Diagram Below • Technique Prevents Deadlock via Withdrawal • Allows Other Processes that Might Need ru to Go • May Result in Livelock Where Processes are Requesting & Withdrawing without Useful Work

  27. Avoidance • Requires a Multi-Phase Approach • Construct a Model of System States • Choose a Strategy that Guarantees that the System Will Not Go to a Deadlock State • Service Processes in Some Order, Not Necessarily Order Received • Requires Extra Information for Each Process • Maximum Claim - Maximum Number of Units of Every Resource Process Will Ever Request • Resource Manager Sees the Worst Case and can Allow Transitions Based on that Knowledge • Goal: To Maintain “Safe” State

  28. Safe vs. Unsafe States • Defining a Safe State: • There is Guaranteed to be a Sequence of Transitions that Leads Back to the Initial State • Even If All Process Exercise their Maximum Claim, there is an Allocation Strategy by Which All Claims Can Be Met • Defining an Unsafe State: • System Cannot Guarantee there is Such a Sequence • Unsafe State Can Lead to a Deadlock State if too Many Processes Exercise Their Maximum Claim at Once • What is Global Perspective of Concepts?

  29. More on Safe & Unsafe States Likely to be in a safe state Normal Execution No Request Max Claim Yes Execute, then release Probability of being in unsafe state increases

  30. More on Safe & Unsafe States Normal Execution No Request Max Claim Yes Execute, then release • Suppose all Processes take “yes” Branch • Avoidance Strategy is to Allow this to Happen, yet Still be Safe • Some Sequence of Allocs and Deallocs to Allow Processes to do Maximum Claims

  31. More on Safe & Unsafe States Safe States Unsafe States Deadlock States

  32. Banker’s AlgorithmDefinitions • Let maxc[i, j] be a 2-D Array that Contains the Maximum Claim for Resource Rj by Process pi • Let alloc[i, j] be a 2-D Array that Contains the Number of Units of Resource Rj held by Process pi • Let C[j] be Units of Resource Rj • Given maxc and alloc, we Can Always Compute: • System Resource Units - Resource Units Held • avail[j] = cj -  0i< n (alloc[i,j]) • Represents Available Units of Rj • Given “Available Units”, is there a Process that can Execute (i.e., is this a Safe State)? If So, • Execute Process, Dealloc Resources, Adjust Arrays, and Recalculate and Iterate

  33. Banker’s Algorithm 1. Copy the alloc[i,j] Table to alloc’[i,j] 2. Given C, maxc, and alloc’, Compute avail Vector 3. Find pi: maxc[i,j] - alloc’[i,j]  avail[j]for 0  j < m and 0  i < n If no such pi Exists, the State is Unsafe - Halt If alloc’[i,j] is 0 for all i and j, the State is Safe - Halt: Algorithm Done - All Processes Executed 4. Set alloc’[I,j] to 0; Deallocate all Resources held by pi; go to Step 2

  34. Example: Start with maxc, alloc, C C = <8, 5, 9, 7> Maximum Claim Process R0 R1 R2 R3 p0 3 2 1 4 p1 0 2 5 2 p2 5 1 0 5 p3 1 5 3 0 p4 3 0 3 3 Allocated Resources Process R0 R1 R2 R3 p0 2 0 1 1 p1 0 1 2 1 p2 4 0 0 3 p3 0 2 1 0 p4 1 0 3 0

  35. Example C = <8, 5, 9, 7> Maximum Claim Process R0 R1 R2 R3 p0 3 2 1 4 p1 0 2 5 2 p2 5 1 0 5 p3 1 5 3 0 p4 3 0 3 3 • Compute Total Held = <7,3,7,5> Allocated Resources Process R0 R1 R2 R3 p0 2 0 1 1 p1 0 1 2 1 p2 4 0 0 3 p3 0 2 1 0 p4 1 0 3 0 Sum 7 3 7 5

  36. Example C = <8, 5, 9, 7> Maximum Claim Process R0 R1 R2 R3 p0 3 2 1 4 p1 0 2 5 2 p2 5 1 0 5 p3 1 5 3 0 p4 3 0 3 3 • Compute Total Held = <7,3,7,5> • Find Available Units (C-Held) avail = <8-7, 5-3, 9-7, 7-5> = <1, 2, 2, 2> Allocated Resources Process R0 R1 R2 R3 p0 2 0 1 1 p1 0 1 2 1 p2 4 0 0 3 p3 0 2 1 0 p4 1 0 3 0 Sum 7 3 7 5

  37. Example C = <8, 5, 9, 7> Maximum Claim Process R0 R1 R2 R3 p0 3 2 1 4 p1 0 2 5 2 p2 5 1 0 5 p3 1 5 3 0 p4 3 0 3 3 • Compute Total Held = <7,3,7,5> • Find Available Units (C-Held) avail = <8-7, 5-3, 9-7, 7-5> = <1, 2, 2, 2> • Can p0’s maxc be met? maxc[0,0]-alloc’[0,0] = 3-2 = 11 = avail[0] maxc[0,1]-alloc’[0,1] = 2-0 = 22 = avail[1] maxc[0,2]-alloc’[0,2] = 1-1 = 02 = avail[2] maxc[0,3]-alloc’[0,3] = 4-1 = 32 = avail[3] Allocated Resources Process R0 R1 R2 R3 p0 2 0 1 1 p1 0 1 2 1 p2 4 0 0 3 p3 0 2 1 0 p4 1 0 3 0 • Process p0 Fails on avail[3] Sum 7 3 7 5

  38. Example C = <8, 5, 9, 7> Maximum Claim Process R0 R1 R2 R3 p0 3 2 1 4 p1 0 2 5 2 p2 5 1 0 5 p3 1 5 3 0 p4 3 0 3 3 • Compute Total Held = <7,3,7,5> • Find Available Units (C-Held) avail = <8-7, 5-3, 9-7, 7-5> = <1, 2, 2, 2> • Can p1’s maxc be met? maxc[1,0]-alloc’[1,0] = 0-0 = 01 = avail[0] maxc[1,1]-alloc’[1,1] = 2-1 = 12 = avail[1] maxc[1,2]-alloc’[1,2] = 5-2 = 32 = avail[2] maxc[1,3]-alloc’[1,3] = 2-1 = 12 = avail[3] Allocated Resources Process R0 R1 R2 R3 p0 2 0 1 1 p1 0 1 2 1 p2 4 0 0 3 p3 0 2 1 0 p4 1 0 3 0 • Process p1 Fails on avail[2] Sum 7 3 7 5

  39. Example C = <8, 5, 9, 7> Maximum Claim Process R0 R1 R2 R3 p0 3 2 1 4 p1 0 2 5 2 p2 5 1 0 5 p3 1 5 3 0 p4 3 0 3 3 • Compute Total Held = <7,3,7,5> • Find Available Units (C-Held) avail = <8-7, 5-3, 9-7, 7-5> = <1, 2, 2, 2> • Can p2’s maxc be met? maxc[2,0]-alloc’[2,0] = 5-4 = 11 = avail[0] maxc[2,1]-alloc’[2,1] = 1-0 = 12 = avail[1] maxc[2,2]-alloc’[2,2] = 0-0 = 02 = avail[2] maxc[2,3]-alloc’[2,3] = 5-3 = 22 = avail[3] Allocated Resources Process R0 R1 R2 R3 p0 2 0 1 1 p1 0 1 2 1 p2 4 0 0 3 p3 0 2 1 0 p4 1 0 3 0 Sum 7 3 7 5

  40. Example C = <8, 5, 9, 7> Maximum Claim Process R0 R1 R2 R3 p0 3 2 1 4 p1 0 2 5 2 p2 5 1 0 5 p3 1 5 3 0 p4 3 0 3 3 • Compute Total Held = <7,3,7,5> • Find Available Units (C-Held) avail = <8-7, 5-3, 9-7, 7-5> = <1, 2, 2, 2> • Can p2’s maxc be met? maxc[2,0]-alloc’[2,0] = 5-4 = 11 = avail[0] maxc[2,1]-alloc’[2,1] = 1-0 = 12 = avail[1] maxc[2,2]-alloc’[2,2] = 0-0 = 02 = avail[2] maxc[2,3]-alloc’[2,3] = 5-3 = 22 = avail[3] Allocated Resources Process R0 R1 R2 R3 p0 2 0 1 1 p1 0 1 2 1 p2 4 0 0 3 p3 0 2 1 0 p4 1 0 3 0 • Yes! Redo avail/Update alloc’ avail[0] = avail[0]+alloc’[2,0] = 1+4 = 5 avail[1] = avail[1]+alloc’[2,1] = 2+0 = 2 avail[2] = avail[2]+alloc’[2,2] = 2+0 = 2 avail[3] = avail[3]+alloc’[2,3] = 2+3 = 5 Sum 7 3 7 5

  41. Example C = <8, 5, 9, 7> Maximum Claim Process R0 R1 R2 R3 p0 3 2 1 4 p1 0 2 5 2 p2 5 1 0 5 p3 1 5 3 0 p4 3 0 3 3 • Recompute Total Held=<3,3,7,2> • Find Available Units (C-Held) avail = <8-3, 5-3, 9-7, 7-2> = <5, 2, 2, 5> • Can anyone’s maxc be met? maxc[4,0]-alloc’[4,0] = 5-1 = 45 = avail[0] maxc[4,1]-alloc’[4,1] = 0-0 = 02 = avail[1] maxc[4,2]-alloc’[4,2] = 3-3 = 02 = avail[2] maxc[4,3]-alloc’[4,3] = 3-0 = 35 = avail[3] Allocated Resources Process R0 R1 R2 R3 p0 2 0 1 1 p1 0 1 2 1 p2 0 0 0 0 p3 0 2 1 0 p4 1 0 3 0 Sum 3 3 7 2

  42. Example C = <8, 5, 9, 7> Maximum Claim Process R0 R1 R2 R3 p0 3 2 1 4 p1 0 2 5 2 p2 5 1 0 5 p3 1 5 3 0 p4 3 0 3 3 • Recompute Total Held=<3,3,7,2> • Find Available Units (C-Held) avail = <8-3, 5-3, 9-7, 7-2> = <5, 2, 2, 5> • Can anyone’s maxc be met? maxc[4,0]-alloc’[4,0] = 5-1 = 45 = avail[0] maxc[4,1]-alloc’[4,1] = 0-0 = 02 = avail[1] maxc[4,2]-alloc’[4,2] = 3-3 = 02 = avail[2] maxc[4,3]-alloc’[4,3] = 3-0 = 35 = avail[3] Allocated Resources Process R0 R1 R2 R3 p0 2 0 1 1 p1 0 1 2 1 p2 0 0 0 0 p3 0 2 1 0 p4 1 0 3 0 • P4 can exercise max claim avail[0] = avail[0]+alloc’[4,0] = 5+1 = 6 avail[1] = avail[1]+alloc’[4,1] = 2+0 = 2 avail[2] = avail[2]+alloc’[4,2] = 2+3 = 5 avail[3] = avail[3]+alloc’[4,3] = 5+0 = 5 Sum 3 3 7 2

  43. Example C = <8, 5, 9, 7> Maximum Claim Process R0 R1 R2 R3 p0 3 2 1 4 p1 0 2 5 2 p2 5 1 0 5 p3 1 5 3 0 p4 3 0 3 3 • Recompute Total Held=<2,3,4,2> • Find Available Units (C-Held) avail = <8-2, 5-3, 9-4, 7-2> = <6, 2, 5, 5> • Can anyone’s maxc be met? • Yes, any of them can! • Choose p0 Allocated Resources Process R0 R1 R2 R3 p0 2 0 1 1 p1 0 1 2 1 p2 0 0 0 0 p3 0 2 1 0 p4 0 0 0 0 Sum 2 3 4 2

  44. Example C = <8, 5, 9, 7> Maximum Claim Process R0 R1 R2 R3 p0 3 2 1 4 p1 0 2 5 2 p2 5 1 0 5 p3 1 5 3 0 p4 3 0 3 3 • Recompute Total Held=<0,3,4,2> • Find Available Units (C-Held) avail = <8-0, 5-3, 9-4, 7-2> = <8, 2, 5, 5> • Can anyone’s maxc be met? • Yes, any of them can! • Choose p1 Allocated Resources Process R0 R1 R2 R3 p0 0 0 0 0 p1 0 1 2 1 p2 0 0 0 0 p3 0 2 1 0 p4 0 0 0 0 Sum 0 3 4 2

  45. Example C = <8, 5, 9, 7> Maximum Claim Process R0 R1 R2 R3 p0 3 2 1 4 p1 0 2 5 2 p2 5 1 0 5 p3 1 5 3 0 p4 3 0 3 3 • Recompute Total Held=<0,2,1,0> • Find Available Units (C-Held) avail = <8-0, 5-2, 9-1, 7-0> = <8, 3, 8, 7> • Can anyone’s maxc be met? • Yes, Choose p3 Allocated Resources Process R0 R1 R2 R3 p0 0 0 0 0 p1 0 0 0 0 p2 0 0 0 0 p3 0 2 1 0 p4 0 0 0 0 Sum 0 2 1 0

  46. Alloc’ Now Zeroed Safe State with All Processes Completed Halt Algorithm with Success Process Order of p2, p4, p0, p1, p3 Safe Execution All Maximum Claims Satisfied in Some Order No Deadlock or Unsafe State Example: Summary Maximum Claim Process R0 R1 R2 R3 p0 3 2 1 4 p1 0 2 5 2 p2 5 1 0 5 p3 1 5 3 0 p4 3 0 3 3 Allocated Resources Process R0 R1 R2 R3 p0 0 0 0 0 p1 0 0 0 0 p2 0 0 0 0 p3 0 0 0 0 p4 0 0 0 0 Sum 0 0 0 0

  47. Detection & Recovery • Check for Deadlock (Periodically or Sporadically), Then Recover • Resource Manager Can Be Far More Aggressive With Allocation • No Maximum Claim, No Safe/Unsafe States • Differentiate Between • Serially Reusable Resources: • Unit Must Be Allocated Before Being Released • Strict Time-Multiplexing Sharing Approach • Consumable Resources: • Never Release Acquired Resources • Resource Count is Number Currently Available

  48. Reusable Resource Graphs (RRGs) • Micro Model to Describe a Single State • Nodes = {p0, p1, …, pn}  {R1, R2, …, Rm} • Processes are Circles; Resources are Boxes • Edges Connect pi to Rj or Rj to pi • (pi, Rj) is Request Edge for one Unit of Rj • If pi Needs Multiple Rjs, Multiple Request Edges • (Rj, pi) is Assignment Edge of one Unit of Rj • If pi Uses Multiple Rjs, Multiple Assignment Edges • For each Rj there is a Count, cj of Units Rj • Number of Units of Rj Allocated to pi Plus the Number Requested by pi Cannot Exceed cj • Process Cannot Request 10 R1 if Only 8 Units

  49. Note Arrow From Token (Resource) to Process Represents Resource Being Used by Process Overall: Represents a Deadlock State Example R p P holds one unit of R P requests one unit of R p R

  50. Example Why is Above Not a Deadlock State? What has Happened to Transition to Above?

More Related