Deadlock

1. Deadlock

2. Examples • P1 requests most of real memory • Disk block mgr is swapped out to make room for P1's requests • P1 requests disk block 1, which is held by p2 (& vice-versa for another block) • Deadlock: • disk block mgr cannot come in • P1 cannot complete to get out

3. System Approaches • Prevention • Avoidance • Detection & Recovery • Manual mgmt

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

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. Avoidance • Predict effects of requests • refuse if deadlock could occur • Underutilizes R • Easy for batch systems • all requests are pre-defined

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. 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. Resource State Diagrams A process P A resource R A request for R R is held by P

10. The State Transition Model • 3 possible events, E • request - ri • allocate - ai • deallocate - di • Pi  P in sj S  sk S due to x  E sj sk x

11. A blocked process (P2) Circles are states, not processes. Subscripts represent processes.Arrows are transitions. a1 sj r3 r1 Transitions can occur OUT of Sjonly via the requests from P1 & P3or the allocation to P1.

12. Creating a complete state diagram Start with 1 process, P1, and only one R at a time may be requested. d d S0 S1 S2 S3 S4 r a r 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. Prevention : Hold & Wait • Must prevent holding followed by request • Two ways: • request everything at once • release all before making new requests

14. Prevention: Circular Wait • Draw system transition diagram or graph • Look for a prospective cycle • Disallow allocations that cause the cycle

15. Prevention: Allow preemption • Pn can "back-out" of a request • This is known as preempting the request State transitions e.g.; a move is possible from Sj to Sk when request n is honored rn sj sk dn rm sm Resource Request Graph

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. The Banker's Algorithm • maxc [ i, j ] is max claim for Rj by pi • alloc [ i, j ] is units of Rj held by pi • cj is the # of units of j in the whole system • Can always compute • avail [ j ] = cj - S0 i < nalloc [ i, j ] • and hence Rj available • Basically examine and enumerate all transitions Classic avoidance algorithm

18. Banker's Algorithm - Steps 1& 2 • // 4 resource types • C=# avail=<8, 5, 9, 7> • 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 Step 1:allocalloc' Step 2:computations above yield: avail=<1,2,2,2> Current (safe) Allocation

19. Banker's Algorithm - Step 3 • Avail=<1,2,2,2> = # currently available for all Rj • Compute: maxc - alloc for each Pi (look for any satisfiable) • alloc' for P2 is <4,0,0,3> (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 If no Pi satisfies: maxc - alloc' <= avail,then unsafe <stop> If alloc'=0 for all Pi <Stop> Maximum Claims

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. Banker's Algorithm - Step 4 • So P2 can claim, use and release all its Rigiving 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=<5,2,2,5> so at least one P can get its max claim satisfied

22. Serially Reusable Resources e.g.; disks, networks, CPUs P holds R (1 unit)  A resource A process P requests R (1 unit)  A resource A process

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 q edges pi Rh pi Rh pi requests q units State Sk State Sj of Rh RRG=Resource Request Graph

24. Transitions P0 P0 • subscript on state indicates who the requestor was. • r1 is a transition: request for the resource by P1 r1     P1 P1 s00 s01

25. Consumable Resource Graphs P produces R  P requests R (1 unit)  P requests R (2 unit) 