1. Deadlock
© 2004, D. J. Foreman

2. 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

3. System Approaches Prevention Avoidance Detection & Recovery
Manual mgmt
© 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
© 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
© 2004, D. J. Foreman

6. 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

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

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

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

11. 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

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

13. 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

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

15. 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

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

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

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] = = 1
avail [1] = = 2
avail [2] = = 2
avail [3] = = 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

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] = = 1 ≤ avail[0] ≡ 1
maxc[2, 1] - alloc'[2,1] = = 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

20. Banker's algorithm for P0
maxc[0, 0] - alloc'[0,0] = = 1 ≤ avail[0] ≡ 1
maxc[0, 1] - alloc'[0,1] = = 1 ≤ avail[1] ≡ 2
maxc[0, 2] - alloc'[0,2] = = 0 ≤ avail[2] ≡ 2
maxc[0, 3] - alloc'[0,3] = = 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

21. 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

22. Serially Reusable Resources
P holds R (1 unit) 
P requests R (1 unit)
© 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
q edges pi Rh pi Rh
pi requests q units
State Sk
State Sj
of Rh
RRG=Resource Request Graph
© 2004, D. J. Foreman

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

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