Deadlock © 2004, D. J. Foreman

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

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

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 © 2004, D. J. Foreman

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 © 2004, D. J. Foreman

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

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 © 2004, D. J. Foreman

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 © 2004, D. J. Foreman

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

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 © 2004, D. J. Foreman

A blocked process (P2) sj Circles are states, not processes. Subscripts represent processes. Arrows are transitions. a1 sj r3 r1 Transitions can occur OUT of Sj only via the requests from P1 & P3 or the allocation to P1. © 2004, D. J. Foreman

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. © 2004, D. J. Foreman

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

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

Prevention: Allow preemption Pn can "back-out" of a request This is known as preempting the request rn sj sk wn sm Resource Request Graph © 2004, D. J. Foreman

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 © 2004, D. J. Foreman

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 < n alloc [ i, j ] and hence Rj available Basically examine and enumerate all transitions Classic avoidance algorithm © 2004, D. J. Foreman

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' R0 R1 R2 R3 P0 2 1 P1 P2 4 3 P3 P4 SUM 7 5 Step 2: computations above yield: avail=<1,2,2,2> Current (safe) Allocation © 2004, D. J. Foreman

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> R0 R1 R2 R3 P0 3 2 1 4 P1 5 P2 P3 P4 Maximum Claims © 2004, D. J. Foreman

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 © 2004, D. J. Foreman

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

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

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 © 2004, D. J. Foreman

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 © 2004, D. J. Foreman

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