Resource Allocat ion and Deadlock Handling What s in a deadlock - - PowerPoint PPT Presentation

Resource Allocat ion and Deadlock Handling

2

What ’s in a deadlock

Deadlock: A set of blocked pr ocesses each wait ing f or an event (e.g. a r esour ce t o become available) t hat only anot her pr ocess in t he set can cause

3

Examples of (pot ent ial) Deadlocks in Resour ce Allocat ion

• semaphores A and B, init ialized t o 1 (or: syst em has 2 t ape drives; P

0 and

P

1 each hold one t ape drive and each needs anot her one)

P P

1

wait (A); wait (B); wait (B); wait (A)

• 200Kbyt es memory-space is available

P P

1

request (80Kbyt es); request (80Kbyt es); … … request (70Kbyt es); request (70Kbyt es); deadlock might occur if bot h processes progress t o t he second request

• message-passing wit h blocking receive

P P

1

receive(P

1);

receive(P

0);

send(P

1, M1);

send(P

0 , M0);

4

Bridge Crossing Example

• Traf f ic only in one direct ion.
• Each “half ” of t he bridge can be viewed as a resource.
• I f a deadlock occurs, it can be resolved if one car backs up (preempt

resources and rollback).

– several cars may have t o be backed up – st arvat ion is possible.

5

Condit ions f or Deadlock

• Mutual exclusion: only one pr ocess at a t ime can use a r esour ce.
• Hold and wait: a pr ocess holding some r esour ce can r equest

addit ional r esour ces and wait f or t hem if t hey ar e held by ot her pr ocesses.

• No preemption: a r esour ce can only be r eleased volunt ar ily by

t he pr ocess holding it , af t er t hat pr ocess has complet ed it s t ask.

– Q: examples preempt able/ non-preemt able resources?

• Circular wait: t her e exist s a cir cular chain of 2 or mor e blocked

pr ocesses, each wait ing f or a r esour ce held by t he next pr ocess in t he chain

[Cof f man-et al 1971] 4 conditions must hold simultaneously f or a deadlock t o occur:

6

Resource Allocat ion & Handling of Deadlocks

• St r uct ur ally r est r ict t he way in which pr ocesses r equest

r esour ces

– deadlock prevent ion: deadlock is not possible

• Requir e pr ocesses t o give advance inf o about t he (max) r esour ces

t hey will r equir e; t hen schedule pr ocesses in a way t hat avoids deadlock.

– deadlock avoidance: deadlock is possible, but OS uses advance inf o t o avoid it

• Allow a deadlock st at e and t hen r ecover
• I gnor e t he pr oblem and pr et end t hat deadlocks never occur in t he

syst em (can be a “solut ion” somet imes?!… )

7

Resource Allocat ion wit h Deadlock Prevent ion

• Mutual Exclusion – (cannot do much here …

)

• Hold and Wait – must guarant ee t hat when a process request s a resource,

it does not hold any ot her resources. – Require process t o request and be allocat ed all it s resources at once or allow process t o request resources only when t he process has none. – Low resource ut ilizat ion; st arvat ion possible.

• No Preemption – I f a process holding some resources request s anot her

resource t hat cannot be immediat ely allocat ed, it releases t he held resources and has t o request t hem again (risk f or st arvat ion).

• Circular Wait – impose t ot al ordering of all resource t ypes, and require

t hat each process request s resources in an increasing order of enumerat ion (e.g f irst t he t ape, t hen t he disk).

• Examples?

Rest rain t he ways request s can be made; at t ack at least one of t he 4 condit ions, so t hat deadlocks are impossible t o happen:

8

Fight t he circular wait : Dining philosophers example

r equest f or ks in incr easing f or k-id var f [0..n]: bin-semaphor e / init all 1 /

P_i: (i!=n) Repeat

Wait (f [i]) Wait (f [(i+1)modn]) Eat Signal(f [(i+1)modn]) Signal(f [i]) Think

f or ever Pn Repeat

Wait (f [(i+1)modn]) Wait (f [i]) Eat Signal(f [i]) Signal(f [(i+1)modn]) Think

f or ever

9

Fight t he hold and wait : Dining philosophers example

semaphor e S[N] int st at e[N] Pi: do

< t hink> t ake_f or ks(i) < eat > leave_f or ks(i) f or ever

take_f orks(i)

wait (mut ex) st at e(i) := HUNGRY t est (i) signal(mut ex) wait (S[i])

leave_f orks(i)

wait (mut ex) st at e(i) := THI NKI NG t est (lef t (i)) t est (r ight (i) signal(mut ex)

test(i)

if st at e(i) ==HUNGRY && st at e(lef t (i) ) != EATI NG && st at e(lef t (i) ) != EATI NG t hen st at e(i) := EATI NG signal(S[i])

10

Fight t he no-preempt ion: Dining philosophers example

var f [0..n]: r ecor d s: bin-semaphor e available: boolean / init all 1 /

P_i: Repeat

While < not holding bot h f or ks> do

Lock(f [i]) I f !t rylock(f [(i+1)modn]) t hen release f [i];

• d

Eat

Release(f [i]) Release(f [(i+1)modn]) Think

f or ever

t rylock(f ork) wait (f ork.s) I f f ork.available t hen f ork.available := f alse ret := t rue else ret := f alse Ret urn(ret ) Signal(f ork.s) Lock(f ork) Repeat Unt il (t rylock(f ork))

11

Syst em Model

• Resource t ypes R1, R2, . . ., Rm

– e.g. CPU, memory space, I / O devices, f iles

– each resource t ype Ri has Wi inst ances.

• Each process ut ilizes a resource as f ollows:

– request – use – release

Resour ce-Allocat ion Gr aph

A set of vert ices V and a set of edges E.

– V is part it ioned int o t wo set s:

• P= {P

1, P 2, …

, P

n} t he set of processes

• R = {R1, R2, …

, Rm} t he set of resource t ypes – request edge: P

i  Rj

– assignment edge: Rj  P

i

12

Example of a Resour ce Allocat ion Gr aph

13

Resour ce Allocat ion Gr aph Wit h A Deadlock

14

Resour ce Allocat ion Gr aph Wit h A cycle but no Deadlock

15

Basic Fact s

• gr aph cont ains no cycles  no deadlock.

(i.e. cycle is always a necessary condit ion f or deadlock)

• I f gr aph cont ains a cycle 

– if one inst ance per resource t ype, t hen deadlock. – if several inst ances per resource t ype, t hen possibilit y of deadlock

• Thm: if immediat e-allocat ion-met hod, t hen knot  deadlock.

– Knot = knot – st rongly connect ed subgraph (no sinks) wit h no out going edges

16

Resource Allocat ion wit h Deadlock Avoidance

Deadlock- avoidance algo:

• examines t he resource-allocat ion st at e…

– available and allocat ed resources – maximum possible demands of t he processes.

• …

t o ensure t here is no pot ent ial f or a circular-wait : – saf e st at e  no deadlocks in t he horizon. – unsaf e st at e  deadlock might occur (lat er… ) – Q: how t o do t he saf et y check?

• Avoidance = ensure t hat syst em will not ent er an unsaf e

st at e. I dea: I f sat isf ying a request will result in an unsaf e st at e, t he request ing process is suspended unt il enough resources are f ree-ed by processes t hat will t erminat e in t he meanwhile. Requires a priori inf ormat ion available.

• e.g.: each process declares maximum number of resources of each t ype

t hat it may need (e.g memory/ disk pages).

17

Enhanced Resource Allocat ion Graph f or Deadlock Avoidance

• Claim edge P

i  Rj : P j may r equest r esour ce Rj

– represent ed by a dashed line.

• Claim edge conver t s t o r equest edge when a pr ocess r equest s a

r esour ce.

• When a r esour ce is r eleased by a pr ocess, assignment edge

r econver t s t o a claim edge.

• Resour ces must be claimed a pr ior i in t he syst em.

18

Example Resour ce-Allocat ion Gr aph For Deadlock Avoidance: Saf e St at e

19

Example Resour ce-Allocat ion Gr aph For Deadlock Avoidance: Unsaf e St at e

20

Saf et y checking: Mor e on Saf e St at e

saf e state = t her e exist s a saf e sequence <

P

1, P 2, …

, P

n>

• f

t er minat ing all pr ocesses:

f or each P

i, t he r equest s t hat it can st ill make can be gr ant ed by

cur r ent ly available r esour ces + t hose held by P

1, P 2, …

, P

i-1

• The syst em can schedule t he pr ocesses as f ollows:

– if P

i ‘s r esour ce needs ar e not immediat ely available, t hen it can

• wait unt il all P

1, P 2, …

, P

i-1 have f inished

• obt ain needed resources, execut e, release resources, t erminat e.

– t hen t he next pr ocess can obt ain it s needed r esour ces, and so

• n.

21

Banker’s Algorit hm f or Resource Allocat ion wit h Deadlock Avoidance

Data Structures:

• Max: n x m mat rix.

– Max [i,j ] = k: P

i may request max k inst ances of resource t ype Rj.

• Allocat ion: n x m mat rix.

– Allocat ion[i,j ] = k: P

i is current ly allocat ed k inst ances of Rj .

• Available: lengt h m vect or

– available [j ] = k : k inst ances of resource t ype Rj available.

• Need: n x m mat rix:

– Need [i,j ] = Max[i,j ] – Allocat ion[i,j ]: pot ent ial max request by P

i f or

resource t ype Rj RECALL: Avoidance = ensure t hat syst em will not ent er an unsaf e st at e. I dea: I f sat isf ying a request will result in an unsaf e st at e, t hen request ing process is suspended unt il enough resources are f ree-ed by processes t hat will t erminat e in t he meanwhile.

22

Banker’s algorit hm: Resource Allocat ion

For each new Request i do / *Request i [j ] = k: P

i want s k inst ances of Rj . */

/ * Check consequence if r equest is gr ant ed */ r emember t he cur r ent r esour ce-allocat ion st at e; Available := Available - Request i; Allocat ioni := Allocat ioni + Request i; Needi := Needi – Request i;; I f saf et y-check OK  t he r esour ces ar e allocat ed t o P

i.

Else ( unsaf e )  P

i must wait and

t he old r esour ce-allocat ion st at e is r est or ed;

23

Banker’s Algorit hm: saf et y check

• Wor k and Finish: auxiliar y vect or s of lengt h m and n, r espect ively.
• I nit ialize:

Wor k := Available Finish [i] = f alse f or i = 1,2, … , n.

• While t her e exist s i such t hat bot h

do

Wor k := Wor k + Allocat ioni Finish[i] := t r ue

• I f Finish [i] = t r ue f or all i, t hen t he syst em is in a saf e st at e

else st at e is unsaf e

(a) Finish [i] = f alse (b) Needi  Work.

24

Ver y simple example execut ion of Banker s Algo (snapshot 1)

Allocat ion Max Need Available A B A B A B A B P

1

1 0 1 1 0 1 0 1 P

2

0 0 1 1 1 1

• The syst em is in a saf e st at e since t he sequence <

P

1, P 2>

sat isf ies saf et y crit eria. A B

25

Ver y simple example execut ion of Banker s Algo (snapshot 2)

Allocat ion Max Need Available A B A B A B A B P

1

1 0 1 1 0 1 0 0 P

2

0 1 1 1 1 0

• Allocat ing B t o P

2 leaves t he syst em in an unsaf e st at e since t here is no

sequence t hat sat isf ies saf et y crit eria (Available vect or is 0 !). A B

26

Anot her example of Banker ’s Algor it hm

• 5 processes P

0 t hrough P 4; 3 resource t ypes A (10 inst ances),

B (5 inst ances), and C (7 inst ances).

• Snapshot at t ime T0:

Allocat ion Max Need Available A B C A B C A B C A B C P 0 1 0 7 5 3 7 4 3 3 3 2 P

1

2 0 0 3 2 2 1 2 2 P

2

3 0 2 9 0 2 6 0 0 P

3

2 1 1 2 2 2 0 1 1 P

4

0 0 2 4 3 3 4 3 1

• The syst em is in a saf e st at e since t he sequence <

P

1, P 3, P 4, P 2, P 0>

sat isf ies saf et y crit eria.

27

Anot her example (Cont .): P

1 r equest (1,0,2)

• Check t hat Request  Available (t hat is, (1,0,2)  (3,3,2)  t rue.

Allocat ion Need Available A B C A B C A B C P 0 1 0 7 4 3 2 3 0 P

1

3 0 2 0 2 0 P

2

3 0 1 6 0 0 P

3

2 1 1 0 1 1 P

4

0 0 2 4 3 1

• Execut ing saf et y algorit hm shows t hat sequence <

P

1, P 3, P 4, P 0, P 2>

sat isf ies saf et y requirement .

• Can request f or (3,3,0) by P

4 be grant ed?

• Can request f or (0,2,0) by P

0 be grant ed?

28

Saf et y check using t he ENHANCED r esour ce allocat ion gr aph:

an algor it hm t hat sear ches f or cycles (knot s) in t he r esour ce- allocat ion gr aph:

• No cycles =>

saf e

• Knot =>

unsaf e (mult iple inst ances per r esour ce pr oblem)

29

Deadlock Det ect ion & Recovery

• Allow syst em t o ent er deadlock st at e
• Det ect ion algor it hm

– Using resource-allocat ion graphs – Using Banker’s algo idea

• Recover y scheme

30

Deadlock Det ect ion using Graphs

an algor it hm t hat sear ches f or cycles (knot s) in t he r esour ce- allocat ion gr aph:

• No cycles =>

no deadlock

• Knot =>

deadlock (mult iple inst ances per r esour ce pr oblem)

31

Deadlock Det ect ion wit hout Gr aphs

Note:

• similar as det ect ing unsaf e st at es using Banker’s algo
• Q: how is similarit y explained?
• Q: if t hey cost t he same why not use avoidance inst ead of

det ect ion&recovery? Dat a st ruct ures:

• Available: vect or of lengt h m: number of available resources of each

t ype.

• Allocat ion: n x m mat rix: number of resources of each t ype current ly

allocat ed t o each process.

• Request : n x m mat rix: current request of each process. Request

[ij ] = k: P

i is request ing k more inst ances of resource t ype Rj.

32

Det ect ion Algorit hm

• 1. Let Work and Finish be auxiliary vect ors of lengt h m and n,

respect ively. I nit ialize:

(a) Work := Available (b) For i = 1,2, … , n, if Allocat ioni  0, t hen Finish[i] := f alse; ot herwise, Finish[i] := t rue.

2.Find i such t hat bot h:

(a) Finish[i] = f alse (b) Request i  Work I f no such i exist s, go t o st ep 4.

3.Work := Work + Allocat ioni Finish[i] := t rue go t o st ep 2. 4.I f Finish[i] = f alse, f or some i, 1  i  n, t hen t he syst em is in deadlock st at e and P

i is deadlocked.

33

Example of Det ect ion Algorit hm

• Five processes P

0 t hrough P 4; t hree resource t ypes

A (7 inst ances), B (2 inst ances), and C (6 inst ances).

• Snapshot at t ime T0:

Allocat ion Request Available A B C A B C A B C P 0 1 0 0 0 0 0 0 0 P

1

2 0 0 2 0 2 P

2

3 0 3 0 0 0 P

3

2 1 1 1 0 0 P

4

0 0 2 0 0 2

• Sequence <

P

0, P 2, P 3, P 1, P 4>

will result in Finish[i] = t rue f or all i.

34

Example (Cont .)

• P

2 request s an addit ional inst ance of t ype C.

Request A B C P 0 0 0 P

1

2 0 1 P

2

0 0 1 P

3

1 0 0 P

4

0 0 2

• St at e of syst em?

– Can reclaim resources held by process P

0, but insuf f icient resources t o

f ulf ill ot her processes’ request s. – Deadlock exist s, consist ing of processes P

1, P 2, P 3, and P 4.

35

Det ect ion-Algorit hm Usage

• When, and how of t en, t o invoke depends on:

– How of t en a deadlock is likely t o occur? – How many processes will need t o be rolled back?

• I f algor it hm is invoked ar bit r ar ily, t her e may be many cycles in t he

r esour ce gr aph  we would not be able t o t ell which of t he many deadlocked pr ocesses “caused” t he deadlock.

36

Recovery f rom Deadlock: (1) Process Terminat ion

• Abor t all deadlocked pr ocesses.
• Abor t one pr ocess at a t ime unt il deadlock is eliminat ed.
• I n which or der should we choose t o abor t ? Cr it er ia?

– ef f ect of t he process’ comput at ion (breakpoint s & rollback) – Priorit y of t he process. – How long process has comput ed, and how much longer t o complet ion. – Resources t he process has used/ needs t o complet e. – How many processes will need t o be t erminat ed.

37

Recovery f rom Deadlock: (2) Resource Preempt ion

• Select a vict im

– minimize cost .

• Rollback – r et ur n t o some saf e st at e, r est ar t pr ocess f r om t hat

st at e

– Must do checkpoint ing f or t his t o be possible.

• Wat ch f or st ar vat ion – same pr ocess may always be picked as

vict im, include number of r ollbacks in cost f act or .

38

Combined Approach t o Deadlock Handling

• Combine t he t hr ee basic appr oaches (pr event ion, avoidance,

det ect ion), allowing t he use of t he opt imal appr oach f or each t ype of r esour ces in t he syst em: – Par t it ion r esour ces int o hier ar chically ordered classes (deadlocks may ar ise only wit hin each class, t hen) – use most appr opr iat e t echnique f or handling deadlocks wit hin each class, e.g:

• int ernal (e.g. int eract ive I / O channels): prevent ion by ordering
• process resources (e.g. f iles): avoidance by knowing max needs
• main memory: prevent ion by preempt ion
• swap space (blocks in disk, drum, …

): prevent ion by preallocat ion

39

RA & Deadlock Handling in Dist ribut ed Syst ems

• Not e: no cent r alized cont r ol her e!

– Each sit e only knows about it s own resources – Deadlock may involve dist ribut ed resources

40

Resource Allocat ion in Message-Passing Syst ems

Prevention (r ecall st r at egies: no cycles; r equest all r esour ces at once; apply pr eempt ive st r at egies) (apply in gen. din.phil)

• using pr ior it ies/ hier ar chical or der ing of r esour ces

– Use resource-managers (1 proc/ resource) and request resource f rom each manager (in t he hierarchy order) – Use mut ex (each f ork is a mut ex, execut e Rikart &Agrawala f or each)

• No hold&wait :

– Each process is mut ually exclusive wit h bot h it s neighbours => each group of 3 neighbours is 1 Rikart &Agrawala ”inst ance”

• No Preemption – I f a pr ocess holding some r esour ces r equest s

anot her r esour ce t hat cannot be immediat ely allocat ed, it r eleases t he held r esour ces and has t o r equest t hem again (r isk f or st ar vat ion:cf Pet er sonSt yer algo f or avoiding st ar vat ion).

41

Dist r ibut ed R.A. wit h Deadlock Avoidance

• r Deadlock Det ect ion&Recover y
• Cent r alized cont r ol – one sit e is r esponsible f or saf et y check or

deadlock det ect ion

– Can be a bot t leneck (in perf ormance and f ault -t olerance)

• Dist r ibut ed cont r ol – all pr ocesses cooper at e in t he saf et y check or

deadlock det ect ion f unct ion

– need of consist ent global st at e – st raight f orward (expensive) approach: all processes t ry t o learn global st at e – less expensive solut ions t end t o be complicat ed and/ or unrealist ic

• Dist r ibut ed deadlock avoidance or det ect ion&r ecover y

is not ver y pr act ical

– Checking global st at es involves consider able pr ocessing

• ver head f or a dist r ibut ed syst em wit h a lar ge number of

pr ocesses and r esour ces

– Also: who will check if procs are all blocked?!