1. © 2004, D. J. Foreman 1 Deadlock

2. © 2004, D. J. Foreman 2 Example  P1 requests most of real memory  Disk block mgr is swapped out ot make room for P1's requests  P1 requests disk block 1  Deadlock: ■ disk block mgr cannot come in ■ P1 cannot complete to get out

3. © 2004, D. J. Foreman 3 System Approaches  Prevention  Avoidance  Detection & Recovery  Manual mgmt

4. © 2004, D. J. Foreman 4 Conditions for Deadlock  Mutual exclusion on R1  Hold R1 & request on R2  Circularity  No preemption – once a R is requested, the request can't be retracted (because the app is now blocked!  All 4 must apply simultaneously  Necessary, but NOT sufficient

5. © 2004, D. J. Foreman 5 Prevention  Design resource mgrs to always prevent at least ONE such condition  Easy in batch systems  Hard/impossible in other systems  Hard to apply to EVERY Rmgr

6. © 2004, D. J. Foreman 6 Avoidance  Predict effects of requests ■ refuse if deadlock could occur  Underutilizes R  Easy for batch systems ■ all requests are pre-defined

7. © 2004, D. J. Foreman 7 Detection & Recovery  Periodic (or manual) check for deadlock ■ implied by response time ■ expensive ■ non-productive until D fixed  D is indicated by non-occurrence ■ is it deadlocked or just waiting normally? ■ analysis of resource types (I/O vs code)  Recovery ■ preempt R from holder ■ delete offending process

8. © 2004, D. J. Foreman 8 Manual mgmt  Contemporary O/S's include detection & prevention algorithms  Not all R are covered due to cost (implementation or to users)  Often, simplest method is reboot

9. © 2004, D. J. Foreman 9 Resource State Diagrams A process P A resource R A request for R R is held by P

10. © 2004, D. J. Foreman 10 The State Transition Model  3 possible events, E ■ request - r i ■ allocate - a i ■ deallocate - d i  P i  P in s j  S  s k  S due to x  E s j s k x

11. © 2004, D. J. Foreman 11 A blocked process (P 2 ) sjsj Circles are states, not processes. Subscripts represent processes. Arrows are transitions. a1a1 r3r3 r1r1 Transitions can occur OUT of S j only via the requests from P 1 & P 3 or the allocation to P 1.

12. © 2004, D. J. Foreman 12 Creating a complete state diagram Start with 1 process, P1, and only one R at a time may be requested. S0S0 S1S1 S2S2 S3S3 S4S4 rr d d a a Now duplicate this diagram for P2. Result is a complex diagram showing all possible states for P1 with all possible states for P2, as well as all the possible transitions.

13. © 2004, D. J. Foreman 13 Prevention via Hold & Wait  Must prevent holding followed by request  Two ways: 1. request everything at once 2. release all before making new requests

14. © 2004, D. J. Foreman 14 Prevention: Circular Wait  Draw system transition diagram or graph  Look for a prospective cycle  Disallow allocations that cause the cycle

15. © 2004, D. J. Foreman 15 Prevention: Allow preemption  P n can "back-out" of a request  This is known as preempting the request sjsj sksk smsm wnwn rnrn

16. © 2004, D. J. Foreman 16 Avoidance  Similar to Prevention  Allows transition if guaranteed to be OK  Analyze new state before entering  System always safe  Unsafe state: no guarantee that deadlock won't occur

17. © 2004, D. J. Foreman 17 The Banker's Algorithm  maxc [ i, j ] is max claim for R j by p i  alloc [ i, j ] is units of R j held by p i  c j is the # of units of j in the whole system  Can always compute ■ avail [ j ] = c j -  0  i  n alloc [ i, j ] ■ and hence R j available  Basically examine and enumerate all transitions Classic avoidance algorithm

18. © 2004, D. J. Foreman 18 Banker's Algorithm - Steps 1& 2  // 4 resource types  C=# avail=  Compute units of R still available (C - col_sum) ■ avail [0] = 8 - 7 = 1 ■ avail [1] = 5 - 3 = 2 ■ avail [2] = 9 - 7 = 2 ■ avail [3] = 7 - 5 = 2 R0R1R2R3 P02011 P10121 P24003 P30210 P41030 SUM7375 Current (safe) Allocation Step 1: alloc  alloc' Step 2: computations above yield: avail=

19. © 2004, D. J. Foreman 19 Banker's Algorithm - Step 3  Avail= = # currently available for all R j  Compute: maxc - alloc for each P i (look for any satisfiable)  alloc' for P2 is (from prev. table)  maxc[2, 0] - alloc'[2,0] = 5 - 4 = 1 ≤ avail[0] ≡ 1  maxc[2, 1] - alloc'[2,1] = 1 - 0 = 1 ≤ avail[1] ≡ 2  etc R0R1R2R3 P03214 P10252 P25105 P31530 P43033 Maximum Claims If no P i satisfies: maxc - alloc' If alloc'=0 for all P i

20. © 2004, D. J. Foreman 20 Banker's algorithm for P0  maxc[0, 0] - alloc'[0,0] = 3 - 2 = 1 ≤ avail[0] ≡ 1  maxc[0, 1] - alloc'[0,1] = 2 - 0 = 1 ≤ avail[1] ≡ 2  maxc[0, 2] - alloc'[0,2] = 1 - 1 = 0 ≤ avail[2] ≡ 2  maxc[0, 3] - alloc'[0,3] = 4 - 1 = 3 ≤ avail[3] ≡ 2  Therefore P0 cannot make a transition to a safe state from the current state.  Likewise for P1

21. © 2004, D. J. Foreman 21 Banker's Algorithm - Step 4  So P2 can claim, use and release all its R i giving a new availability vector: avail2[0]=avail[0]+alloc'[2,0]=1+4=5 avail2[1]=avail[1]+alloc'[2,1]=2+0=2 avail2[2]=avail[2]+alloc'[2,2]=2+0=2 avail2[3]=avail[3]+alloc'[2,3]=2+3=5 avail2= so at least one P can get its max claim satisfied

22. © 2004, D. J. Foreman 22 Serially Reusable Resources  P holds R (1 unit) P requests R (1 unit) 

23. © 2004, D. J. Foreman 23 State Transitions due to Requests  In Sj, pi is allowed to request q  ch units of Rh, provided pi has no outstanding requests.  Sj  Sk, where the RRG for Sk is derived from Sj by adding q request edges from pi to Rh RhRh pipi RhRh pipi State S j State S k p i requests q units of R h q edges

24. © 2004, D. J. Foreman 24 Transitions P0  P1 r1r1  P0  P1  s 00 s 01 subscript on state indicates who the requestor was. r1 is a transition: request for the resource by P1

25. © 2004, D. J. Foreman 25 Consumable Resource Graphs  P produces R P requests R (1 unit)  P requests R (2 unit) 