COM222 OPERATING SYSTEMS

Lesson 6: Deadlocks
AIM

 This unit aims at introducing the concepts of

deadlocks in operating systems. It explains the
various principals of deadlocks and methods for
handling deadlocks.
Objectives

By the end of this unit the student should be able to:

 Define a deadlock
 Explain the various principals of deadlocks
 Differentiate
between Preemptable and
Nonpreemptable Resources
 Clearlyexplain the conditions that are necessary for a
deadlock to occur
 Discuss the various strategies for handling deadlocks
 What a Deadlock IS
Computer systems are full of resources that can only be used by one process
at a time. Common examples include flatbed plotters, CD-ROM readers,
CDROM recorders, 8mm DAT tape drive backup systems, image setters, and
slots in the system's process table.

Having two processes simultaneously writing to the printer leads to gibberish.

Having two processes using the same slot in the process table will probably
lead to a system crash.

Consequently, all operating systems have the ability to (temporarily) grant a

process exclusive access to certain resources.

For many applications, a process needs exclusive access to not one

resource, but several. Consider, for example, a marketing company that
specializes in marking large, detailed demographic maps of the United States
one I-meter wide flatbed plotter. The demographic information comes from
CD-ROMs containing census and other data. Suppose that process A asks for
the CD-ROM drive and gets it. A moment later, process B asks for the flatbed
plotter and gets it, too.
 Now process A asks for the plotter and blocks waiting for it. Finally, process B
asks for the CD-ROM drive and also blocks. At this point both processes are
blocked and will remain so forever. This situation is called a deadlock.
 Deadlocks are not a good thing to have in your system. Deadlocks can occur in
many situations besides requesting dedicated I/O devices.
 In a data base system, for example, a program may have to lock several records
it is using, to avoid race conditions. If process A locks record Rl and process B
locks record R2, and then each process tries to lock the other one's record, we
also have a deadlock. Thus deadlocks can occur on hardware resources or on
software resources.
 There are two basic situations that must be avoided:
 Deadlocks: two (or more) processes are waiting for a resource allocated to
the other process. Neither process can complete until the required resource
has been allocated but neither process will release the resources it
currently has until it has completed.
 Starvation: Three or more processes are waiting access to the same
resource and one (or more) process is never given a turn
 Deadlocks are more serious than starvation because it affects more than one
job. There is no single simple solution, it requires outside intervention.
Resources
 Deadlocks can occur when processes have been granted exclusive
access to devices, files, and so forth.
 To make the discussion of deadlocks as general as possible, we will
refer to the objects granted as resources. The resources may be either
physical or logical.
 A resource can be a hardware device (e.g., a tape drive) or a piece of
information (e.g., a locked record in a data base).
 A computer will normally have many different resources that can be
acquired. For some resources, several identical instances may be
available, such as three tape drives.
 When several copies of a resource are available, any one of them can
be used to satisfy any request for the resource. In short, a resource is
anything that can only be used by a single process at any instant.
Preemptable and Nonpreemptable Resources

 Resources come in two flavors: preemptable and nonpreemptable.

 A preemptable resource is one that can be taken away from the process
with no ill effects. Memory is an example of a preemptable resource.
Consider, for example, a system with 5 12K of user memory, one printer,
and two 512K processes that each want to print something.
 Process A requests and gets the printer, then starts to compute the values
to print. Before it has finished with the computation, it exceeds its time
quantum and is swapped out.
 Process B now runs and tries, unsuccessfully, to acquire the printer.
Potentially, we now have a deadlock situation, because A has the printer
and B has the memory, and neither can proceed without the resource held
by the other. Fortunately, it is possible to preempt (take away) the memory
from B by swapping it out and swapping A in. Now A can run, do its
printing, and then release the printer. No deadlock occurs.
 A nonpreemptable resource, in contrast, is one that cannot be taken away
from its current owner without causing the computation to fail. If a process has
begun to print output, taking the printer away from it and giving it to another
process will result in garbled output. Printers are not preemptable.
 In general, deadlocks involve nonpreemptable resources. Potential deadlocks
that involve preemptable ones can usually be resolved by reallocating
resources from one process to another. Thus our treatment will focus on
nonpreemptable resources. The sequence of events required to use a resource
is:
 1. Request the resource.
 2. Use the resource.
 3. Release the resource.
 If the resource is not available when it is requested, the requesting process is
forced to wait. In some operating systems, the process is automatically blocked
when a resource request fails and awakened when it becomes available. In
other systems, the request fails with an error code, and it is up to the calling
process to wait a little while and try again.
 Deadlocks usually occur when non-sharable, nonpreemtable resources such as
file, printers, tape drives etc are allocated to jobs that eventually require non-
sharable, nonpreemptive resources.
Principles of Deadlock

 Deadlock can be defined formally as follows:

 A set of processes is deadlocked if each process in the set is waiting
for an event that only another process in the set can cause.
 Because all the processes are waiting, none of them will ever cause
any of the events that could wake up any of the other members of the
set, and all the processes continue to wait forever.
 In most cases, the event that each process is waiting for is the release
of some resource currently possessed by another member of the set. In
other words, each member of the set of deadlocked processes is
waiting for a resource that is owned by a deadlocked process. None of
the processes can run, none of them can release any resources, and
none of them can be awakened. The number of processes and the
number and kind of resources possessed and requested are
unimportant.
Necessary and Sufficient Deadlock Conditions
 Coffrnan et al. (1971) showed that four conditions must hold for there
to be a deadlock:
 Mutual exclusion condition. Each resource is either currently
assigned to exactly one process or is available.
 Hold and wait condition. Processes currently holding resources
granted earlier can request new resources.
 No preemption condition. Resources previously granted cannot
be forcibly taken away from a process. They must be explicitly
released by the process holding them.
 Circular wait condition. There must be a circular chain of two or
more processes, each of which is waiting for a resource held by
the next member of the chain.
As an example, consider the traffic deadlock in the following
figure
 Consider each section of the street as a
resource.
 Mutual exclusion condition applies, since
only one vehicle can be on a section of
the street at a time.
 Hold-and-wait condition applies, since
each vehicle is occupying a section of
the street, and waiting to move on to
the next section of the street.
 No-preemptive condition applies, since a
section of the street that is a section of
the street that is occupied by a vehicle
cannot be taken away from it.
Circular wait condition applies, since

each vehicle is waiting on the next
vehicle to move. That is, each vehicle in
the traffic is waiting for a section of
street held by the next vehicle in the
traffic.
Can a deadlock occur between threads? Give reasons.
A deadlock is not possible between two threads in
a process, because it is the process that holds
resources, not the thread that is, each thread has
access to the resources held by the process.
Methods for Handling Deadlocks

 Resources requests and release are received in an unpredictable

order, which makes it difficult to design foolproof preventive policy.
In general operating systems use one of Four (4) strategies to deal
with deadlocks.
 The Ostrich Approach
Just ignore the deadlock problem altogether.
 Deadlock Detection and Recovery :
Detect deadlock and, when it occurs, take steps to recover.
 Deadlock Avoidance
Avoid deadlock by careful resource scheduling
 Deadlock Prevention
Prevent deadlock by resource scheduling so as to negate at least
one of the four conditions.
The Ostrich Algorithm

 The simplest approach is the ostrich algorithm: stick your head in the sand
and pretend there is no problem at all.
 Different people react to this strategy in different ways. Mathematicians find
it totally unacceptable and say that deadlocks must be prevented at all costs.
 Engineers ask how often the problem is expected, how often the system
crashes for other reasons, and how serious a deadlock is. If deadlocks occur
on the average once every 50 years, but system crashes due to hardware
failures, compiler errors, and operating system bugs occur once a month,
most engineers would not be willing to pay a large penalty in performance or
convenience to eliminate deadlocks.
Deadlock Detection and Recovery
 A second technique is detection and recovery. When this technique is
used, the system does not do anything except monitor the requests and
releases of resources.
 Every time a resource is requested or released, the resource graph is
updated, and a check is made to see if any cycles exist, If a cycle
exists, one of the processes in the cycle is killed.
 If this does not break the deadlock, another process is killed, and so on
until the cycle is broken.
 A somewhat cruder method is to not even maintain the resource graph
but instead periodically check to see if there are any processes that
have been continuously blocked for more than say, 1 hour.
 Such processes are then killed. Detection and recovery is the strategy
often used on large mainframe computers, especially batch systems in
which killing a process and then restarting it is usually acceptable.
 Care must be taken to restore any modified files to their original state,
however, and undo any other side effects that may have occurred.
Deadlock Prevention

 The third deadlock strategy is to impose suitable restrictions on processes

so that deadlocks are structurally impossible. The four conditions stated
by Coffman et al. (1971) provide a clue to some possible solutions.
 If we can ensure that at least one of these conditions is never satisfied,
then deadlocks will be impossible.

 For Approaches to Deadlock Prevention, consider using:

 Mutual Exclusion
 Hold and Wait
 No Preemption
 Circular Wait
Mutual Exclusion

 If no resource were ever assigned exclusively to a single process, we would

never have deadlocks. However, it is equally clear that allowing two
processes to write on the printer at the same time will lead to chaos. By
spooling printer output, several processes can generate output at the same
time. In this model, the only process that actually requests the physical
printer is the printer daemon. Since the daemon never requests any other
resources, we can eliminate deadlock for the printer.
 Unfortunately, not all devices can be spooled (the process table does not lend
itself well to being spooled). Furthermore, competition for disk space for
spooling can itself lead to deadlock. What would happen if two processes
each filled up half of the available spooling space with output and neither
was finished? If the daemon were programmed to begin printing even before
all the output were spooled, the printer might lie idle if an output process
decided to wait several hours after the first burst of output. For this reason
and demons are normally programmed to print only after the complete output
file is available. Neither process will ever finish, so we have a deadlock on
the disk.
Hold and Wait
 The second of the conditions stated by Coffman et al. looks more
promising. If we can prevent processes that hold resources from
waiting for more resources, we can eliminate deadlocks. One way to
achieve this goal is to require all processes to request all their
resources before starting execution.
 If everything were available, the process would be allocated
whatever it needed and could run to completion. If one or more
resources were busy nothing would be allocated and the process
would just wait.
 An immediate problem with this approach is that many processes do
not know how many resources they will need until they have started
running. Another problem is that resources will not be used optimally
with this approach.
 Take as an example, a process that reads data from an input tape,
analyzes it for an hour, and then writes an output tape as well as
plots the results. If all resources must be requested in advance, the
process will tie up the output tape drive and the plotter for an hour.
 A slightly different way to break the hold-and-wait
condition is to require a process requesting a resource to
first temporarily release all the resources it currently
holds. Only if the request is successful can it get the
original resources back.
 Resource holding may be side stepped by forcing each job
to request at creation time every resource it would need
to run to completion.
 This is impractical and would be significantly decreases
degree of multiprogramming.
No Preemption
 Attacking the third condition (no preemption) is even less
promising than attacking the second one.
 If a process has been assigned the printer and is in the
middle of printing its output, forcibly taking away the
printer because a needed plotter is not available will lead
to a mess.
Circular Wait
 Circular wait can be bypassed if the operating system prevents the formation of
a circle.
 This is not so always easy to detect when there are a large number of processes
and a large number of resources.
Deadlock Avoidance

 If the operating system can’t remove one of the conditions

for deadlock, then maybe it can avoid deadlock if the system
knows ahead of time the sequence of requests associated
with each active process.
 End of Lesson 6