Operating Systems Lecture Notes

Lecture 4
Deadlock
Martin C. Rinard
You may need to write code that acquires more than one lock. This opens up the
possibility of deadlock. Consider the following piece of code:
Lock *l1, *l2;
void p() {
l1->Acquire();
l2->Acquire();
code that manipulates data that l1 and l2 protect
l2->elease();
l1->elease();
!
void q() {
l2->Acquire();
l1->Acquire();
code that manipulates data that l1 and l2 protect
l1->elease();
l2->elease();
!
If p and q execute concurrently, consider what may happen. irst, p acquires l1 and q
acquires l2. Then, p waits to acquire l2 and q waits to acquire l1. !ow long will they
wait" ore#er.
This case is called deadlock. $hat are conditions for deadlock"
o %utual &xclusion: 'nly one thread can hold lock at a time.
o !old and $ait: (t least one thread holds a lock and is waiting for another process
to release a lock.
o )o preemption: 'nly the process holding the lock can release it.
o Circular $ait: There is a set t1, ..., tn such that t1 is waiting for a lock held by t2, ...,
tn is waiting for a lock held by t1.
!ow can p and q a#oid deadlock" 'rder the locks, and always acquire the locks in that
order. &liminates the circular wait condition.
'ccasionally you may need to write code that needs to acquire locks in different orders.
!ere is what to do in this situation.
o irst, most locking abstractions offer an operation that tries to acquire the lock but
returns if it cannot. $e will call this operation "r#Acquire. *se this operation to
try to acquire the lock that you need to acquire out of order.
o If the operation succeeds, fine. 'nce you+#e got the lock, there is no problem.
o If the operation fails, your code will need to release all locks that come after the
lock you are trying to acquire. %ake sure the associated data structures are in a
state where you can release the locks without crashing the system.
o ,elease all of the locks that come after the lock you are trying to acquire, then
reacquire all of the locks in the right order. $hen the code resumes, bear in mind
that the data structures might ha#e changed between the time when you released
and reacquired the lock.
!ere is an example.
int d1, d2;
$$ "he standard acquisition order %or these t&o locks
$$ is l1, l2'
Lock *l1, $$ protects d1
*l2; $$ protects d2
$$ (ecrements d2, and i% the result is ), increments d1
void increment() {
l2->Acquire();
int t * d2;
t--;
i% (t ** )) {
i% (l1->"r#Acquire()) {
d1++;
! else {
$$ An# modi%ications to d2 ,o here - in this case none
l2->elease();
l1->Acquire();
l2->Acquire();
t * d2;
t--;
$$ some other thread ma# have chan,ed d2 - must recheck it
i% (t ** )) {
d1++;
!
!
l1->elease();
!
d2 * t;
l2->elease();
!
This example is somewhat contri#ed, but you will recogni-e the situation when it occurs.
There is a generali-ation of the deadlock problem to situations in which processes need
multiple resources, and the hardware may ha#e multiple kinds of each resource . two
printers, etc. /eems kind of like a batch model . processes request resources, then system
schedules process to run when resources are a#ailable.
In this model, processes issue requests to '/ for resources, and '/ decides who gets
which resource when. ( lot of theory built up to handle this situation.
0rocess first requests a resource, the '/ issues it and the process uses the resource, then
the process releases the resource back to the '/.
,eason about resource allocation using resource allocation graph. &ach resource is
represented with a box, each process with a circle, and the indi#idual instances of the
resources with dots in the boxes. (rrows go from processes to resource boxes if the
process is waiting for the resource. (rrows go from dots in resource box to processes if
the process holds that instance of the resource. /ee ig. 1.2.
If graph contains no cycles, is no deadlock. If has a cycle, may or may not ha#e deadlock.
/ee ig. 1.3, 1.4.
/ystem can either
o ,estrict the way in which processes will request resources to pre#ent deadlock.
o ,equire processes to gi#e ad#ance information about which resources they will
require, then use algorithms that schedule the processes in a way that a#oids
deadlock.
o 5etect and eliminate deadlock when it occurs.
irst consider pre#ention. 6ook at the deadlock conditions listed abo#e.
o %utual &xclusion . To eliminate mutual exclusion, allow e#erybody to use the
resource immediately if they want to. *nrealistic in general . do you want your
printer output interlea#ed with someone elses"
o !old and $ait. To pre#ent hold and wait, ensure that when a process requests
resources, does not hold any other resources. &ither asks for all resources before
executes, or dynamically asks for resources in chunks as needed, then releases all
resources before asking for more. Two problems . processes may hold but not use
resources for a long time because they will e#entually hold them. (lso, may ha#e
star#ation. If a process asks for lots of resources, may ne#er run because other
processes always hold some subset of the resources.
o Circular $ait. To pre#ent circular wait, order resources and require processes to
request resources in that order.
5eadlock a#oidance. /implest algorithm . each process tells max number of resources it
will e#er need. (s process runs, it requests resources but ne#er exceeds max number of
resources. /ystem schedules processes and allocates resoures in a way that ensures that
no deadlock results.
&xample: system has 23 tape dri#es. /ystem currently running 07 needs max 27 has 8, 02
needs max 9 has 3, 03 needs max : has 3.
Can system pre#ent deadlock e#en if all processes request the max" $ell, right now
system has 4 free tape dri#es. If 02 runs first and completes, it will ha#e 8 free tape
dri#es. 07 can run to completion with those 8 free tape dri#es e#en if it requests max.
Then 03 can complete. /o, this schedule will execute without deadlock.
If 03 requests two more tape dri#es, can system gi#e it the dri#es" )o, because cannot be
sure it can run all ;obs to completion with only 2 free dri#e. /o, system must not gi#e 03
3 more tape dri#es until 02 finishes. If 03 asks for 3 tape dri#es, system suspends 03 until
02 finishes.
Concept: /afe /equence. Is an ordering of processes such that all processes can execute
to completion in that order e#en if all request maximum resources. Concept: /afe /tate .
a state in which there exists a safe sequence. 5eadlock a#oidance algorithms always
ensure that system stays in a safe state.
!ow can you figure out if a system is in a safe state" <i#en the current and maximum
allocation, find a safe sequence. /ystem must maintain some information about the
resources and how they are used. /ee '/C 1.8.4.
Avail-./ * num0er o% resource . availa0le
1a2-i,./ * ma2 num0er o% resource . that process i &ill use
Alloc-i,./ * num0er o% resource . that process i currentl# has
3eed-i,./ * 1a2-i,./ - Alloc-i,./
)otation: A4*5 if for all processes i, A-i/4*5-i/.
/afety (lgorithm: will try to find a safe sequence. /imulate e#olution of system o#er time
under worst case assumptions of resource demands.
16 7ork * Avail;
8inish-i/ * 8alse %or all i;
26 8ind i such that 8inish-i/ * 8alse and 3eed-i/ 4* 7ork
9% no such i e2ists, ,oto :
;6 7ork * 7ork + Alloc-i/; 8inish-i/ * "rue; ,oto 2
:6 9% 8inish-i/ * "rue %or all i, s#stem is in a sa%e state
)ow, can use safety algorithm to determine if we can satisfy a gi#en resource demand.
$hen a process demands additional resources, see if can gi#e them to process and remain
in a safe state. If not, suspend process until system can allocate resources and remain in a
safe state. )eed an additional data structure:
equest-i,./ * num0er o% . resources that process i requests
!ere is algorithm. (ssume process i has ;ust requested additional resources.
16 9% equest-i/ 4* 3eed-i/ ,oto 2' <ther&ise, process has
violated its ma2imum resource claim'
26 9% equest-i/ 4* Avail ,oto ;' <ther&ise, i must &ait
0ecause resources are not availa0le'
;6 =retend to allocate resources as %ollo&s6
Avail * Avail - equest-i/
Alloc-i/ * Alloc-i/ + equest-i/
3eed-i/ * 3eed-i/ - equest-i/
9% this is a sa%e state, ,ive the process the resources' <ther&ise,
suspend the process and restore the old state'
$hen to check if a suspended process should be gi#en the resources and resumed"
'b#ious choice . when some other process relinquishes its resources. 'b#ious problem .
process star#es because other processes with lower resource requirements are always
taking freed resources.
/ee &xample in /ection 1.8.4.4.
Third alternati#e: deadlock detection and elimination. =ust let deadlock happen. 5etect
when it does, and eliminate the deadlock by preempting resources.
!ere is deadlock detection algorithm. Is #ery similar to safe state detection algorithm.
16 7ork * Avail;
8inish-i/ * 8alse %or all i;
26 8ind i such that 8inish-i/ * 8alse and equest-i/ 4* 7ork
9% no such i e2ists, ,oto :
;6 7ork * 7ork + Alloc-i/; 8inish-i/ * "rue; ,oto 2
:6 9% 8inish-i/ * 8alse %or some i, s#stem is deadlocked'
1oreover, 8inish-i/ * 8alse implies that process i is deadlocked'
$hen to run deadlock detection algorithm" 'b#ious time: whene#er a process requests
more resources and suspends. If deadlock detection takes too much time, maybe run it
less frequently.
'>, now you+#e found a deadlock. $hat do you do" %ust free up some resources so that
some processes can run. /o, preempt resources . take them away from processes. /e#eral
different preemption cases:
o Can preempt some resources without killing ;ob . for example, main memory. Can
;ust swap out to disk and resume ;ob later.
o If ;ob pro#ides rollback points, can roll ;ob back to point before acquired
resources. (t a later time, restart ;ob from rollback point. 5efault rollback point .
start of ;ob.
o or some resources must ;ust kill ;ob. (ll resources are then free. Can either kill
processes one by one until your system is no longer deadlocked. 'r, ;ust go ahead
and kill all deadlocked processes.
In a real system, typically use different deadlock strategies for different situations based
on resource characteristics.
This whole topic has a sort of ?7+s and 17+s batch mainframe feel to it. !ow come these
topics ne#er seem to arise in modern *nix systems"