25
© 2004, D. J. Foreman 1 Deadlock

© 2004, D. J. Foreman 1 Deadlock. © 2004, D. J. Foreman 2 Example P1 requests most of real memory Disk block mgr is swapped out ot make room for P1's

Embed Size (px)

Citation preview

© 2004, D. J. Foreman 1

Deadlock

© 2004, D. J. Foreman 2

ExampleP1 requests most of real memoryDisk block mgr is swapped out ot make

room for P1's requestsP1 requests disk block 1Deadlock:

■ disk block mgr cannot come in■ P1 cannot complete to get out

© 2004, D. J. Foreman 3

System ApproachesPreventionAvoidanceDetection & Recovery

Manual mgmt

© 2004, D. J. Foreman 4

Conditions for Deadlock

Mutual exclusion on R1Hold R1 & request on R2CircularityNo preemption – once a R is requested,

the request can't be retracted (because the app is now blocked!

All 4 must apply simultaneouslyNecessary, but NOT sufficient

© 2004, D. J. Foreman 5

PreventionDesign resource mgrs to always prevent at

least ONE such conditionEasy in batch systemsHard/impossible in other systemsHard to apply to EVERY Rmgr

© 2004, D. J. Foreman 6

AvoidancePredict effects of requests

■ refuse if deadlock could occurUnderutilizes REasy for batch systems

■ all requests are pre-defined

© 2004, D. J. Foreman 7

Detection & RecoveryPeriodic (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 mgmtContemporary O/S's include detection &

prevention algorithmsNot 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 Model3 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

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 diagramStart with 1 process, P1, and only one R at a time may be requested.

S0 S1 S2 S3 S4

r r

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.

© 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

© 2004, D. J. Foreman 14

Prevention: Circular WaitDraw system transition diagram or graphLook for a prospective cycleDisallow allocations that cause the cycle

© 2004, D. J. Foreman 15

Prevention: Allow preemptionPn can "back-out" of a request

This is known as preempting the request

sj sk

sm

wn

rn

© 2004, D. J. Foreman 16

Avoidance Similar to PreventionAllows transition if guaranteed to be OKAnalyze new state before enteringSystem always safeUnsafe 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 - 0 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] = 8 - 7 = 1■ avail [1] = 5 - 3 = 2■ avail [2] = 9 - 7 = 2■ avail [3] = 7 - 5 = 2

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

Current (safe) Allocation

Step 1:allocalloc'

Step 2:computations aboveyield: avail=<1,2,2,2>

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

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

Maximum Claims

If no Pi satisfies: maxc - alloc' <= avail,then unsafe <stop>

If alloc'=0 for all Pi <Stop>

© 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

© 2004, D. J. Foreman 21

Banker's Algorithm - Step 4So 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 qch 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

Rhpi Rhpi

State SjState Sk

pi requests q unitsof Rh

q edges

© 2004, D. J. Foreman 24

Transitions

P0

P1

r1

P0

P1

s00 s01

•subscript on state indicates who the requestor was.

•r1 is a transition: request for the resource by P1

© 2004, D. J. Foreman 25

Consumable Resource Graphs

P produces R

P requests R (1 unit)

P requests R (2 unit)