You are on page 1of 5

UCLA CS111

Operating Systems (Spring 2003, Section 1)


Deadlock
Instructor
Andy Wang (awang@cs.ucla.edu)
Office: 3732J Boelter all
Office ours: !"#3$ W"#2$ %&2#3$ and 'y a((oint)ent
************************************************************************
ackgro!nd
+oug&ly s(ea,ing$ a deadlock occurs w&en t&reads are waiting for resources (e.g.$
de-ices and files) wit& circular de(endencies. .eadloc,s generally in-ol-e
nonpreemptable resources (e.g.$ storage allocated to a file$ a loc, for )utual e/clusion)$
w&ic& cannot 'e ta,en away fro) its current t&read wit&out causing t&e co)(utation to
fail. .eadloc,s t&at in-ol-e preemptable resources (e.g.$ 012) can usually 'e resol-ed
'y reallocating resources fro) one t&read to anot&er. +ecall t&at starvation is a condition
w&ere a t&read waits indefinitely. A deadloc, i)(lies star-ation.
Thread A Thread B
P(x); P(y);
P(y); P(x);
A deadloc, won3t always &a((en wit& t&is code$ 'ut it )ig&t.
Deadlocks, Deadlocks "#ery$%ere&
A deadloc, can &a((en wit& any ,ind of resource. .eadloc,s can also occur wit&
)ulti(le resources$ and you cannot sol-e t&e deadloc, for eac& resource inde(endently.
4or e/a)(le$ one t&read can gra' all t&e )e)ory5 anot&er gra's all t&e dis, s(ace$ and
yet anot&er gra's all t&e ta(e storage. 6ac& t&read )ay need to wait for ot&er to release.
+ound#ro'in 012 sc&eduling cannot (re-ent deadloc,s (or star-ation) fro) &a((ening.
.eadloc, can occur w&ene-er t&ere is waiting. 4or e/a)(le$ t&ere are fi-e dining
lawyers. 6ac& needs two c&o(stic,s to eat. If eac& gra's t&e c&o(stic, on t&e rig&t first$
and all gra' at t&e sa)e ti)e$ we &a-e a deadloc,. (alt&oug& (ersonally I (refer to star-e
t&an s&aring c&o(stic,s7)
semaphore chopstick[5] = {1, 1, 1, 1, 1};
a!yer(i"t #) {
!hie (T$%&) {
P(chopstick[#]);
P(chopstick[(# ' 1) mod 5);
(( &at
)(chopstick[(# ' 1) mod 5]);
)(chopstick[#]);
}
}
Conditions 'or Deadlocks
4ortunately$ so)eone &as identified four necessary ('ut not sufficient) conditions for a
deadloc, to occur. Wit&out all of t&ese four conditions$ a deadloc, cannot occur:
". 8i)ited access (loc,#(rotected resources)
2. 9o (ree)(tion (if so)eone &as t&e resource$ it can3t 'e ta,en away)
3. Wait w&ile &olding (&olding a resource w&ile re:uesting and waiting for t&e
ne/t resource).
;. 0ircular c&ain of re:uests
Deadlock (re#ention
1re-enting deadloc,s in-ol-es re)o-ing one of t&e four conditions.
(a) Infinite resources ('uy a -ery large dis,)
(') 9o s&aring (totally inde(endent t&reads)
(c) 9o waiting ((&one co)(any)
(d) 1ree)(t resources (co(ying )e)ory content to dis,)
(e) Allocate all resources at t&e 'eginning (if you need 2 c&o(stic,s$ gra' 'ot& at
t&e sa)e ti)e)
(f) !a,e e-eryone use t&e sa)e ordering in accessing resources. (all t&reads
)ust gra' se)a(&ores in t&e order of P(x) and P(y)).
(g) A co)'ination of tec&ni:ues
anker)s Algorit%m
One e/a)(le of (re-ention algorit&) (e) is t&e Bankers algorithm$ allows t&e su) of
)a/i)u) resource needs of all t&reads to 'e greater t&an t&e total resources$ as long as
t&ere is so)e way for all t&reads to finis& wit&out getting into deadloc,.
". A t&read states its )a/i)u) resource needs in ad-ance.
2. %&e O< allocates resources dyna)ically w&en resource is needed. A t&read
waits if its granting re:uest would leads to deadloc, (a re:uest can 'e granted
if so)e se:uential ordering of t&reads is deadloc, free.)
4or e/a)(le$ you can allow a t&read to (roceed if t&e total a-aila'le resources are greater
t&an or e:ual to t&e )a/i)u) re)aining resources t&at )ig&t 'e needed 'y t&is t&read.
%o 'e s(ecific$ su((ose two single#t&readed (rocesses are running on a )ac&ine wit& 2=>
!'ytes of (&ysical +A!$ and eac& (rocess re:uires a )a/i)u) of "=? !'ytes of
)e)ory. Also$ su((ose eac& (rocess &as already allocated "?? !'ytes (2?? out of 2=>
!'ytes of (&ysical )e)ory are allocated 'y 'ot& (rocesses). Alt&oug& t&e co)'ined
)a/i)u) (3?? !'ytes) e/ceeds t&e (&ysical )e)ory li)it (2=> !'ytes)$ => !'ytes of
a-aila'le )e)ory can actually carry any one of t&e two (rocesses to co)(letion$ wit&out
t&e ris, of e/&austing t&e )e)ory resource. %&erefore$ t&e current state of allocation for
)e)ory is considered safe.
1&ysical )e)ory: 2=> !'ytes
Allocated: 2?? !'ytes
!a/i)u) allocation
1" "=? !'ytes
12 "=? !'ytes
0urrent allocation
1" "?? !'ytes
12 "?? !'ytes
On t&e ot&er &and$ if eac& (rocess &as already allocated ""? !'ytes$ t&e syste) &as
reac&ed an unsafe allocation state@t&e re)aining 3> !'ytes is not enoug& for eit&er
(rocess to co)(lete.
1&ysical )e)ory: 2=> !'ytes
Allocated: 22? !'ytes
!a/i)u) allocation
1" "=? !'ytes
12 "=? !'ytes
0urrent allocation
1" ""? !'ytes
12 ""? !'ytes
<ince we cannot (redict future$ (rocesses under t&e deadloc, (re-ention a((roac&es often
o-eresti)ate resources and lead to inefficient use of resources.
Deadlock Detection and *eco#ery
%&e deadloc, detection#and#reco-ery strategy is t&e )ost co))only used a((roac&. %&e
'asic algorit&) in-ol-es t&ree ste(s:
". <can t&e resource allocation gra(&
2. .etect circular c&ains of re:uests
3. +eco-er fro) t&e deadloc,
%&e idea is to re)o-e t&e fourt& deadloc, condition of circular c&ain of re:uests.
%&read A
%&read B
+esource A +esource B
waiting for
owned 'y waiting for
owned 'y
Once t&e circular c&ain of re:uests are identified$ t&ere are so)e (ossi'le actions:
(a) Cill a t&read and force it to gi-e u( resources.
(') +oll'ac, actions of a deadloc,ed t&read.
+e)o-ing a deadloc,ed t&read is not always (ossi'le$ since a t&read )ay own loc,s and
resources. +e)o-ing a t&read )ay lea-e t&e re)aining syste) in an inconsistency state.
+olling 'ac, a t&read re:uires checkpointing$ or ta,ing sna(s&ots of syste) states fro)
ti)e to ti)e. <o$ a deadloc,ed t&read can 'e rolled back (destroyed and restored) to a
recent consistent state.

You might also like