teacher's notes - lec chapter 6 - deadlocks

7/25/2019 Teacher's Notes - Lec Chapter 6 - Deadlocks

1/11

J.E.D.I.

1 Deadlocks

1.1 ObjectivesThis chapter discusses deadlocks. We will discuss what deadlocks are and under whatconditions deadlocks occur. Then we will discuss how deadlocks can be prevented, avoided,and what can be done to recover from them.

1.2 Chapter Outline Introduction

Resource Allocation raphs

!onditions for Deadlocks

Deadlock "revention

Deadlock Avoidance

Deadlock Recover#

1.3 Introduction"rocesses re$uire resources in order to finish the work assi%ned to them. In a multitaskin%environment, multiple processes would have to compete for a limited number of resources.This means that there is a chance that a process would not be able to %et a resource when itneeds it. A process that can not %et the resource it needs would need to enter a wait stateuntil the resource becomes available.

&owever, there is a chance that a process never leaves the wait state because the resource itis re$uestin% is bein% held b# other processes also in a wait state. This situation is called adeadlock.

!onsider the followin% e'ample.

Alice and (ob are two friends who carpool. )ne da#, Alice was in the office wantin% to %ohome. *he has the car ke#s but doesn+t have the car. )n the other hand, (ob was at homewantin% to %o to the office. &e has the car but does not have the car ke#s.

Alice and (ob need both resources car and car ke#s- to complete their task. (oth of them arein possession of one resource and is waitin% for each other to %et the other resource. In the

end, none of them %et to %o where the# want to.

1.3.1 Resource Allocation GraphsTo %ive a better idea of what deadlocks are, we will now discuss resource allocation %raphs. Aresource allocation %raph shows what processes are in possession and or are re$uestin% whichresources.

The followin% is a resource allocation %raph. "rocesses are represented b# circles whileresources are represented b# s$uares.

)peratin% *#stems /


2/11

J.E.D.I.

A process that is re$uestin% a resource has an arrow pointin% from the process circle to theresource s$uare, this is called a re$uest ed%e. A process that owns a resource has an arrowpointin% from the resource s$uare to the process circle, this is called an assi%nment ed%e.

*ome resources ma# have more than one instance. 0or e'ample, a process is re$uestin% for aprinter. It turns out that there are three printers in the office and the process ma# be contentwith an# of these printers. If that is the case, then the resource s$uare has dots whichrepresent the number of instances of that resource. A process that owns an instance of thatresource has an arrow pointin% from the instance dot to the process.

The followin% dia%ram shows the resource allocation %raph of Alice and (ob.

)peratin% *#stems 1


3/11

J.E.D.I.

We can see that the resource allocation %raph for Alice and (ob has a clearl# defined c#cle. Infact, an# such c#cle of resource re$uests and resource allocation describes a deadlock if eachresource has onl# one instance. If a resource has multiple instances, then the chance of adeadlock still e'ists.

1.3.2 Conditions for DeadlocksThere are four conditions re$uired for deadlocks to occur.

2utual e'clusion 3 a resource can onl# be allocated to a sin%le process. If a processre$uires a resource that is allocated to another process, then that process must waituntil the other process is finished with that resource.

&old and wait 3 a process that is re$uestin% a resource and is denied does not let %o ofresources allocated to it.

4o preemption 3 a process cannot be forced to let %o of a resource allocated to it

!ircular wait 3 there e'ists a circular order of waitin% processes. 0or e'ample, "/ iswaitin% for a resource held b# "1 which is waitin% for a resource held b# "5 which iswaitin% for a resource held b# "/.

1.3.3 Deadlock handling)peratin% s#stems address the deadlock issue in the followin% wa#s

Deadlock prevention 3 totall# prevent deadlocks b# eliminatin% one of the necessar#deadlock conditions from ever occurrin%.

Deadlock avoidance 3 the s#stem does not totall# prevent deadlocks but is able todetect if %rantin% a process a resource pushes the s#stem into an unsafe state wheredeadlocks are possible.

Deadlock recover# 3 the s#stem does not prevent or avoid deadlocks but, when adeadlock is detected, provides a wa# to recover from it.

Deadlock i%norance 3 simpl# i%nore the fact that deadlocks occur. Althou%h this ma#seem counter6intuitive, operatin% s#stems that place emphasis on speed rather thanreliabilit# ma# find the al%orithms needed for prevention, avoidance or recover# ma#cause performance de%radation. Worse comes to worst, a deadlock can simpl# beresolved with a $uick reboot.

1.4 Deadlock Prevention

All four conditions must be present in the s#stem for a deadlock to occur. Deadlock preventionmeans havin% a scheme which prevents an# one of these conditions from bein% present in thes#stem.

1.4.1 Mutual Exclusion re!entionA mutuall# e'clusive resource is a necessar# condition for a deadlock. A printer cannot beshared while a process is usin% it. &owever, additional printer instances such as a differentprinter down the hall- could be allocated to re$uestin% resources while the main printer is inuse. The mutual e'clusion condition can be prevented b# simpl# providin% additional resourceinstances.

&owever, some resources are inherentl# unsharable. 0or instance, onl# a sin%le process can bemade to write or read from the ke#board at a time.

)peratin% *#stems 5


4/11

J.E.D.I.

1.4.2 "old and #ait re!entionThe hold and wait condition e'ists in the s#stem if a process, while waitin% for a resource tobecome available, does not let %o of the resources it alread# owns. There is a wa# to preventthis condition from happenin%. 0or instance, if a process re$uests for additional resources , it

must let %o of the resources it alread# has. Another protocol is for a process to initiall# declareall the resources it will ever need, and the operatin% s#stem will let this process run after allthe resources are made available to it.

1.4.3 $o%pree&ption re!ention)ne wa# to prevent deadlocks is to allow resources to be forcibl# deallocated from a process inorder to be assi%ned to another. This would allow an# process to %et all the resources it needsat an# %iven time even if the# are in use b# other processes. 4o deadlocks will occur becauseprocesses would not have to wait for resources.

&owever, not all resources can be easil# be switched to other processes. !onsider mechanicaldevices such as printers or disks. A printer that is switched to another process in the middle ofa 7ob would end up printin% the first part of a pa%e from the first process and end up with thebottom of the pa%e from the second process.

1.4.4 Circular #ait pre!ention"reventin% circular wait means establishin% an order b# which processes re$uest for resources.0or e'ample, we can setup a value s#stem for each resource. 0or e'ample, the printer couldhave value /8, tape drive value 18, flopp# disk value 98 and hard disk /88.

)nce we have established this, a process can onl# re$uest a resource in increasin% order. If ithas to re$uest a lower valued resource, then it would have to release all lower valuedresources it contains.

If a process re$uires the flopp# and the hard disk then it must re$uest the flopp# first and thenre$uest for the hard disk. 4ow that it owns the flopp# disk 98- and hard disk /88-. Then itre$uires the tape drive. *ince its a lower numbered resource, it would have to release 98 and/88 before %ettin% /8.

We can establish that no circular wait occurs via a proof b# contradiction. / 0or e'ample, wehave "i as part of a circular wait of processes :"8, "/, ... "n;. "i would be waitin% for "i


5/11

J.E.D.I.

*afe state 3 the resource allocation of the s#stem is not in a deadlock state. A safestate means that the ma'imum resource need of a process can be met b# the reserveresources of the s#stem, or b# resources currentl# held b# other processes whosema'imum needs can also be met.

nsafe state 3 the resource allocation of the s#stem is not in a deadlock state but hasthe potential to enter a deadlock state. This is because the ma'imum resource need ofa process cannot be met b# the reserve resources of the s#stem, or throu%h theresources held b# other processes.

Deadlock state

In a safe state, the ma'imum resource need of a process can be met either b# the reserveresources of the s#stem or from resources bein% held b# processes whose ma'imum needs canbe met.

In an unsafe state, the ma'imum resource needed b# a process cannot be met because thereare not enou%h reserve resources. )n top of that, the resources held b# other processes cannot be used because their ma'imum needs can not be met. The deadlock does not occur untilthe process re$uests for additional resources.

1.'.2 Resource Allocation GraphThe operatin% s#stem tries to keep resource allocation in a safe state b# filterin% additionalresource re$uests. )ne wa# to do this is b# checkin% if a %ranted resource allocation results ina c#cle in the resource allocation %raph.

To do this, we add an additional concept to our resource allocation %raph, the claim ed%e. Aclaim ed%e appears in our resource allocation %raph to indicate that a process would bere$uestin% that ed%e some time in the future. This is in contrast to the re$uest ed%e, where

the process is alread# askin% for the resource and will not continue processin% until theresource is allocated to it.

When a process starts runnin%, it immediatel# tells the operatin% s#stem all the possibleresources it would be usin%, which would appear in the resource allocation %raph as claimed%es. Durin% the process+ lifetime, claim ed%e would transform to re$uest ed%es when the

)peratin% *#stems 9


6/11

J.E.D.I.

process actuall# needs that resource. If a process+ re$uest is %ranted, then that re$uest ed%ewould be transformed into an assi%nment ed%e.

Bnowin% all the claim ed%es at the start, the operatin% s#stem would be able to 7ud%e whetheror not assi%nin% a resource to a process would potentiall# cause a c#cle in the future. This

knowled%e keeps the s#stem in a safe state.

1.'.3 )anker*s Algorith&The resource allocation %raph strate%# can onl# be made to work if all resources are sin%leinstance resources. The banker+s al%orithm can be made to run even if the resources havemultiple instances.

In the banker+s al%orithm , a process must initiall# indicate the ma'imum number of instancesof each resource t#pe it would need durin% the course of its e'ecution.

0or e'ample, consider a s#stem havin% three resource t#pes, A, ( and ! with ma'imuminstances of /9, C, and /8 respectivel#.

Available

A B C

15 6 10

"rocesses "/ throu%h "9 indicate the ma'imum amount of resources the# would need throu%han arra# called 2a'

Max

A B C

P1 6 3 9P2 1 1 1

P3 4 3 7

P4 1 2 3

P5 10 2 6

Durin% process e'ecution, a process would be allocated a certain number of resources. Thiswould be placed in an arra# called allocated. The remainin% resources needed b# the process

i.e. 2a' 3 Allocated- is placed in the 4eed arra#. )f course our available table chan%es toreflect the allocated processes.

Max Allocated Need Available

A B C A B C A B C A B C

P1 6 3 9 4 2 3 2 1 6 3 2 3

P2 1 1 1 1 1 0 0 0 1

P3 4 3 7 2 0 0 2 3 7

P4 1 2 3 0 0 3 1 2 0

P5 10 2 6 5 1 1 5 1 5

4ow we are all set for our banker+s al%orithm.

)peratin% *#stems C


7/11

J.E.D.I.

A process is able to terminate if the number of available resources is enou%h to meet its needs.When this happens, then the resources it currentl# has can be added to the available pool.The s#stem is in a safe state if all processes are able to meet their needs and deallocate theirassi%ned resources.

In summar#, %ive the process ever#thin% that it needs so that it will be able to pa# ever#thin%back. If all processes can pa# back , then the s#stem is in a safe state.

We will tr# to run our banker+s al%orithm on our test data.

0irst, we tr# to look for an# process whose need can be met b# the available resources. We cansee that we can meet "1+s need. We then %ive "1 all its needs so it can finish e'ecution andthe allocated resources returned to the pool.



P1 6 3 9 4 2 3 2 1 6 4 3 3

P2 1 1 1 0 0 0 0 0 0 ok!

P3 4 3 7 2 0 0 2 3 7

P4 1 2 3 0 0 3 1 2 0

P5 10 2 6 5 1 1 5 1 5

We can also meet "@+s needs>



P1 6 3 9 4 2 3 2 1 6 4 3 6

P2 1 1 1 0 0 0 0 0 0 ok!

P3 4 3 7 2 0 0 2 3 7

P4 1 2 3 0 0 0 1 2 0 ok!

P5 10 2 6 5 1 1 5 1 5

We can also meet "/+s needs>



P1 6 3 9 0 0 0 0 0 0 ok! 8 5 9

P2 1 1 1 0 0 0 0 0 0 ok!

P3 4 3 7 2 0 0 2 3 7

P4 1 2 3 0 0 3 1 2 0 ok!

P5 10 2 6 5 1 1 5 1 5

Then "5+s needs>



P1 6 3 9 0 0 0 0 0 0 ok! 10 5 9

)peratin% *#stems


8/11

J.E.D.I.

P2 1 1 1 0 0 0 0 0 0 ok!

P3 4 3 7 0 0 0 0 0 0 ok!

P4 1 2 3 0 0 0 0 0 0 ok!

P5 10 2 6 5 1 1 5 1 5

0inall# "9+s needs



P1 6 3 9 0 0 0 0 0 0 ok! 15 6 10

P2 1 1 1 0 0 0 0 0 0 ok!

P3 4 3 7 0 0 0 0 0 0 ok!

P4 1 2 3 0 0 0 0 0 0 ok!

P5 10 2 6 0 0 0 0 0 0 ok!

*ince all processes have been able to pa# back their resources, we can sa# that the s#stem isin a safe state. 0or each step , no particular order of processes is necessar# as lon% as theavailable resources can meet the process+ needs.

The operatin% s#stem assi%ns resources to a process onl# if, after the assi%nment, the s#stemis still in a safe state. )f course, an# resource re$uest must first meet the specified ma'imumresource allocation #ou cannot owe more than #our ma'imum-.

0or e'ample, "/ re$uests for 1 additional A resource, or 1,8,8-. We will first allocate theresource and tr# to see if the s#stem is still in a safe state.

Allocated Need Available

A B C A B C A B C

P1 6 2 3 0 1 6 1 2 3 initial

P2 1 1 0 0 0 1 2 3 3 P2 needs et

P3 2 0 0 2 3 7 2 3 6 P4 needs et

P4 0 0 3 1 2 0 5 9 P1 needs et

P5 5 1 1 5 1 5 10 5 9 P3 needs et

15 6 10 P5 needs et

Safe state

*ince the s#stem is in a safe state then we can successfull# allocate the re$uested resource.

&owever, there is a chance that a resource won+t be allocated because the s#stem enters anunsafe state. !onsider an additional re$uest b# "/ for 1 additional ! resources, or 8,8,1-

Allocated Need Available

A B C A B C A B C

P1 6 2 5 0 1 1 1 2 1 initial

)peratin% *#stems


9/11

J.E.D.I.

P2 1 1 0 0 0 1 2 3 1 P2 needs et

P3 2 0 0 2 3 7 2 3 4 P4 needs et

P4 0 0 3 1 2 0 No other processes ee!s "et#

P5 5 1 1 5 1 5

4ot bein% able to complete the al%orithm means that not all resource needs can be allocated.The s#stem will be in an unsafe state if the resource re$uest is %ranted. Therefore, theoperatin% s#stem denies the re$uest b# "/ until other processes return their resources.

1. Deadlock Detection and !ecover"If the s#stem does not prevent or avoid deadlocks, then the s#stem can enter a deadlock

state. If this happens, then the s#stem must first find out that it is in a deadlock state, andonce it does, recover from it.

1.+.1 Deadlock detectionTo find out if a process is deadlocked, the s#stem can maintain a version of the resourceallocation %raph with resources removed. This is called a wait for %raph. There would e'ist adirected ed%e between "i and "7 in the wait6for %raph if in the resource allocation %raph, "i iswaitin% for a resource R which belon%s to "7

)peratin% *#stems F


10/11

J.E.D.I.

A deadlock e'ists if there is a c#cle in the wait6for %raph.

0or multiple resource instances, we have a modified banker+s al%orithm. Instead of considerin%a 2a' or a 4eed column, we consider a re$uest column, meanin%, that the process would need

these resources at this point in time to continue processin%.A process can finish runnin% if the available resources are able to meet its current re$uest,then addin% its allocated resources into the available pool. This is the main difference with theori%inal banker+s al%orithm. We are optimistic that the process would be able to release itsallocated resources if we meet onl#- its current need.

The s#stem is not in a deadlock state if all processes are able to meet their re$uest from theavailable pool and release their resources. If this doesn+t happen, then those processes withunaddressed re$uests are in the deadlock c#cle

0or e'ample, we are %iven the followin% s#stem status>

Allocated "e#$est Available

A B C A B C A B C

P1 0 1 0 0 0 0 0 0 0

P2 1 1 2 2 0 2

P3 2 0 0 0 0 0

P4 0 0 1 0 2 1

P5 2 1 1 0 0 0

!urrentl#, we don+t have enou%h available resources to satisf# re$uests. (ut we assume that

processes currentl# havin% resources will be kind enou%h to release them once we meet theirre$uest. We now run this modified banker+s al%orithm>


A B C A B C A B C

P1 0 1 0 0 0 0 0 0 0 intial

P2 1 1 2 2 0 2 0 1 0 P1%s &e#$est et!

P3 2 0 0 0 0 0 2 1 0 P3%s &e#$est et!

P4 0 0 1 0 2 1 4 2 1 P5%s &e#$est et!

P5 2 1 1 0 0 0 4 2 2 P4%s &e#$est et!5 3 4 P2%s &e#$est et

No !ea!loc$

A deadlock occurs if not all of the process+ re$uests are %ranted. "rocesses involved in thedeadlock are those whose re$uests are not met.

!onsider the followin% scenario and the banker+s al%orithm e'ecution


A B C A B C A B C

)peratin% *#stems /8


11/11

J.E.D.I.

P1 0 1 0 0 0 0 0 0 0 intial

P2 1 1 2 2 0 2 0 1 0 P1%s &e#$est et!

P3 2 0 0 0 1 0 2 1 0 P3%s &e#$est et!

P4 0 0 1 0 2 1 'e cannot (&ant t)e &e#$est o* P2+P4+ P5!

P5 2 1 1 0 3 0 %2& %4& %5 are !ea!loc$e!

These al%orithms should be run periodicall# to check if the s#stem is in a deadlock state. )ncea deadlock has been determined, the s#stem can now choose a recover# strate%#.

1.+.2 rocess ,er&inationWe can break a deadlock b# terminatin% processes involved in the deadlock. We can terminate

one process at a time until the deadlock breaks, or simpl# terminate all processes. Terminatin%a process ma# have dire conse$uences. 0or e'ample, if a process is in the middle of writin% toa file when it is terminated, then the file ma# be left in an inconsistent state,thus destro#in%it. We would also need to determine a criteria for choosin% a victim. 0or instance, we couldterminate recentl# started processes first, as it would be eas# to 7ust restart them. We couldalso choose to terminate lower priorit# processes first.

1.+.3 Resource ree&ptionAn alternative to terminatin% processes is to remove allocated resources from processes inorder to break the deadlock. &owever, when a resource is removed from a process b# ane'ternal source, the process can no lon%er proceed as usual.

!onsider a process that opens a file and has code that saves data to the file. If file access isrevoked, then what would happen to the file save instructions when the# are runG )ne wa# isto rollback e'ecution to the code 7ust before the revoked resource was re$uested and have thepro%ram run once a%ain from that point, re$uestin% for the resource once more. &owever, thisre$uires information on what state the process was at that point, and in some cases it would

7ust be simpler to do a total rollback, or 7ust restart the process.

)peratin% *#stems //

teacher's notes - lec chapter 6 - deadlocks

Documents