Understanding Operating

Systems
Sixth Edition
CHAPTER 5
PROCESS MANAGEMENT
Learning Objectives 2

After completing this chapter, you should be

able to describe:
Several causes of system deadlock and
livelock
The difference between preventing and
avoiding deadlocks
How to detect and recover from deadlocks
Learning Objectives (contd.) 3

The concept of process starvation and how to

detect and recover from it
The concept of a race and how to prevent it
The difference between deadlock, starvation,
and race
Deadlock 4

Deadlock (deadly embrace) -- a system-wide

tangle of resource requests that begins when 2 or
more jobs are put on hold.

Each job is waiting for a vital resource to become

available.
Needed resources are held by other jobs also waiting
to run but cant because theyre waiting for other
unavailable resources.
The jobs come to a standstill.
The deadlock is complete if remainder of system
comes to a standstill as well.
Deadlock (cont'd.) 5

In some computer systems, deadlocks are

regarded as a mere inconvenience that causes
delays.
But for real-time systems, deadlocks cause
critical situations.
Regardless of the environment, the OS must
either prevent deadlocks or resolve them when
they happen.
Deadlock (cont'd.) 6
Seven Cases of Deadlock 7

1. Deadlocks on file requests

2. Deadlocks in databases
3. Deadlocks in dedicated device allocation
4. Deadlocks in multiple device allocation
5. Deadlocks in spooling
6. Deadlocks in disk sharing
7. Deadlocks in a network
Case 1: Deadlocks on File 8
Requests
If jobs are allowed to request and hold files for the
duration of their execution, a deadlock can occur.
Example (Figure 5.2)
Two programs (P1, P2) and two files (F1, F2)
Deadlock sequence
P1 has access to F1 and also requires F2
P2 has access to F2 and also requires F1
Deadlock remains
Until one program withdrawn or
Until one program forcibly removed and file released
Other programs requiring F1 or F2
Put on hold for duration of situation
Case 1: Deadlocks on File 9
Requests (cont'd.)
Case 2 : Deadlocks in 10
Databases

1. P1 accesses R1 and locks it.

2. P2 accesses R2 and locks it.

3. P1 requests R2, which is locked by P2.

4. P2 requests R1, which is locked by P1.

Case 2: Deadlocks in 11
Databases
A deadlock can occur if two processes access and lock
records in a database.
Database queries and transactions are often relatively brief
processes that either search or modify parts of a database.
Requests usually arrive at random and may be interleaved
arbitrarily.
Locking is a technique used to guarantee the integrity of
the data through which the user locks out all other users
while working with the database.
Case 2: Deadlocks in Databases 12
(contd)

Locking can be done at three different levels:

The entire database can be locked for the duration of
the request;
The most extreme and most successful solution.
Prevents a deadlock from occurring but it restricts
access to the database to one user at a time.
In a multiuser environment, response times are
significantly slowed.
Normally an unacceptable solution.
Case 2: Deadlocks in Databases13
(contd)
A subsection of the database can be locked:
When the locking is performed on only one part of
the database, access time is improved but the
possibility of a deadlock is increased because
different processes sometimes need to work with
several parts of the data base at the same time.
The individual record can be locked until the
request is completed.
Same as above.
Case 2: Deadlocks in 14
Databases (cont'd.)
Example: two processes (P1 and P2)
Each needs to update two records (R1 and R2)
Deadlock sequence
P1 accesses R1 and locks it
P2 accesses R2 and locks it
P1 requests R2 but locked by P2
P2 requests R1 but locked by P1
Race between processes:
An alternative is to avoid the use of locks
If locks are not used to preserve the integrity of the
database, the updated records might only include some of
the data, and their contents would depend on the order in
which each process finishes its execution.
Case 2: Deadlocks in Databases 15
(cont'd.)
Case 3: Dedicated
Device Allocation 16

The use of a group of dedicated devices can also deadlock

the system.
Example
Two programs (P1, P2)
Need two tape drives each
Only two tape drives in system
Deadlock sequence
P1 requests tape drive 1 and gets it
P2 requests tape drive 2 and gets it
P1 requests tape drive 2 but blocked
P2 requests tape drive 1 but blocked
Case 4: Deadlocks in Multiple 17
Device Allocation

Deadlocks can happen when several processes

request, and hold on to, several dedicated devices.
Example (Figure 5.4)
Three programs (P1, P2, P3)
Three dedicated devices (tape drive, printer, plotter)
Deadlock sequence
P1 requests and gets tape drive
P2 requests and gets printer
P3 requests and gets the plotter
P1 requests printer but blocked
P2 requests plotter but blocked
P3 requests tape drive but blocked
Case 4: Deadlocks in Multiple 18
Device Allocation (cont'd.)
Case 5: Deadlocks in Spooling 19

Printers are usually sharable devices (Virtual

devices) that use high-speed storage to transfer
data between it and the CPU.
The spooler accepts output from several users and
acts as a temporary storage area for all output until
the printer is ready to accept it (spooling).
If the printer needs all of a jobs output before it will
begin printing, but the spooling system fills the
available space with only partially completed
output, a deadlock can occur.
Case 5: Deadlocks in Spooling 20
(cont'd.)
Deadlock Sequence:
Printer needs all job output before printing begins
Spooling system fills disk space area
No one job has entire print output in spool area
Results in partially completed output for all jobs
Results in deadlock
Any part of the system that relies on spooling,
such as one that handles incoming jobs or
transfers files over a network, is vulnerable to
such a deadlock.
Case 6: Deadlocks in a Network 21

A network thats congested or has filled a large

percentage of its I/O buffer space can become
deadlocked if it doesnt have protocols to control the
flow of messages through the network.
Example (Figure 5.5)
Seven computers on network
Each on different nodes
Direction of arrows
Indicates message flow
Deadlock sequence
All available buffer space fills
Case 6: Deadlocks in a 22
Network (cont'd.)
Case 7: Deadlocks in Disk 23
Sharing
Disks are designed to be shared.
Its not uncommon for two processes to be
accessing different areas of the same disk.
This ability to share creates an active type of
deadlock, known as livelock.
Processes use a form of busy-waiting thats different
from a natural wait.
Its waiting to share a resource but never actually
gains control of it.
Case 7: Deadlocks in Disk Sharing 24
(contd)
Example (Figure 5.6)
Two competing processes are sending conflicting commands,
causing livelock.
Neither process is blocked, which would create a deadlock.
Each is active but never reaches fulfillment.
Each process waiting for I/O request
One at cylinder 20 and one at cylinder 310
Deadlock sequence
Neither I/O request satisfied
Device puts request on hold while attempting to fulfill other
request.
Case 7: Deadlocks in Disk 25
Sharing
(contd)
Example (Figure 5.6)
P1 issues a command to access track 20 of a disk.
While the control unit is moving the arm to track 20
P1 is put on hold
The I/O channel is free to process the next I/O request.
While the arm is moving into position, P2 gains control of the
I/O channel and issues a command to access track 310.
If the command is not locked out, P2 will be put on hold while
the control unit moves the arm to track 310.
Case 7: Deadlocks in Disk 26
Sharing
(contd)
Example (Figure 5.6)
Because P2 is on hold while the arm is moving, the channel
can be captures again by P1, which reconfirms its command to
read from track 10.
Because the last command from P2 had forced the arm
mechanism to track 310, the disk control unit begins to
reposition the arm to track 20 to satisfy P1.
The I/O channel would be released because P1 is once again
put on hold, so it could be captured by P2, which rediscovers
that the arm mechanism needs to be repositioned.
Case 7: Deadlocks in Disk 27
Sharing
(contd)
Example (Figure 5.6)
As a result, the arm is in a constant state of motion, moving
back and forth between tracks 20 and 310 as it responds to the
two competing commands, but satisfies neither.
Case 7: Deadlocks in Disk 28
Sharing (cont'd.)
Conditions for Deadlock 29

In each of these seven cases, the deadlock (or livelock)

involved several processes and resources.
Each deadlock was preceded by the simultaneous
occurrence of four conditions that the OS (or other systems)
could have recognized:
Mutual exclusion
Resource holding
No preemption
Circular wait
Each of these four conditions is necessary for the OS to
work smoothly.
Conditions for Deadlock 30

(contd)
None of them can be removed easily without causing the
systems overall functioning to suffer.
The system needs to recognize the combination of
conditions before they occur and threaten to cause the
system to lock up.
Conditions for Deadlock 31
(cont'd.)
Mutual exclusion
Allowing only one process access to a dedicated resource.
The first condition for deadlock.
Resource holding
Holding resource and not releasing it
Waiting for other job to retreat
The second condition for deadlock.
No preemption
Lack of temporary reallocation of resources.
The third condition for deadlock.
Conditions for Deadlock 32
(cont'd.)
Circular wait
Each process involved in the impasse is waiting for
another to voluntarily release the resource so that at
least one will be able to continue on and eventually
arrive at the destination.
Fourth condition for deadlock.
All four conditions are required for the deadlock to
occur.
Deadlock remains until one condition removed
Modeling Deadlocks 33

Directed graphs
Circles represent processes
Squares represent resources
Solid arrow from resource to process
Process holding resource
Solid arrow from a process to resource
Process waiting for resource
Arrow direction indicates flow
Cycle in graph
Deadlock involving processes and resources
Modeling Deadlocks 34
(cont'd.)
Modeling Deadlocks 35
(cont'd.)
Three graph scenarios to help detect deadlocks
System has three processes (P1, P2, P3)
System has three resources (R1, R2, R3)
Scenario one: no deadlock
Resources released before next process request
Scenario two: deadlock
Processes waiting for resource held by another
Scenario three: no deadlock
Resources released before deadlock
Modeling Deadlocks 36
(cont'd.)
No deadlock
Resources released before next process request
Modeling Deadlocks 37
(cont'd.)
Modeling Deadlocks 38
(cont'd.)
Deadlock
Processes waiting for resource held by another
Modeling Deadlocks 39
(cont'd.)
Modeling Deadlocks 40
(cont'd.)
No deadlock
Resources released before deadlock
Modeling Deadlocks 41
(cont'd.)
Modeling Deadlocks 42
(cont'd.)
Another example
Resources of same type
Allocated individually or grouped in same process
Graph clusters devices into one entity
Allocated individually or grouped in different
process
Graph clusters devices into one entity
Modeling Deadlocks 43

(cont'd.)
Strategies for Handling 44

Deadlocks
The requests and releases are received in an
unpredictable order, which makes it very
difficult to design a foolproof preventive policy.
OSs use one of three strategies to deal with
deadlocks:
Prevent one of the four conditions from occurring.
Avoid the deadlock if it becomes probable.
Detect the deadlock when it occurs and recover
from it gracefully.
Strategies for Handling 45

Deadlocks (cont'd.)
Prevention:
To prevent deadlocks, the OS must eliminate one
of the four necessary conditions:
Complicated by the fact that the same condition
cant be eliminated from every resource.
Mutual exclusion:
Necessary in any computer system because some
resources, such as memory, CPU, and dedicated
devices must be exclusively allocated to one user at a
time.
In the case of I/O devices (printers, the mutual
exclusion may be bypassed by spooling.
Strategies for Handling 46

Deadlocks
Prevention: (cont'd.)
Resource Holding:
A job holds on to one resource while waiting for another one thats not
yet available.
Could be sidestepped by forcing each job to request, at creation time,
every resource it will need to run to completion.
If every job in a batch system is given as much memory as it needs,
then the number of active jobs will be dictated by how many can fit in
memory.
Would significantly decrease the degree of multiprogramming.
Peripheral devices would be idle because they would be allocated to a
job even though they wouldnt be use all the time.
Strategies for Handling 47

Deadlocks
Prevention: (cont'd.)
Resource Holding:
Used successfully in batch environments although it:
Reduced the effective use of resources;
Restricted the amount of multiprogramming.
Doesnt work well in interactive systems.
Strategies for Handling 48

Deadlocks (cont'd.)
Prevention (cont'd.)
No preemption:
Could be bypassed by allowing the OS to deallocate
resources from jobs.
Can be done if the state of the job can be easily
saved and restored.
As when a job is preempted in a round robin
environment or a page is swapped to secondary
storage in a virtual memory system.
Preemption of a dedicated I/O device, during the
modification process, however, can require some
extremely unpleasant recovery tasks. Not accepted
to preempt dedicated I/O device or files during
modification.
Strategies for Handling 49

Deadlocks (cont'd.)
Prevention (cont'd.)
Circular Wait:
Hierarchical Ordering:
Based on a numbering system for the resources:
Printer = 1;
Disk = 2;
Tape = 3;
Plotter = 4;
And so on.
Strategies for Handling 50
Deadlocks
Prevention (cont'd.)
(cont'd.)
The system forces each job to request its resources in
ascending order.
If a job needed a printer and then a plotter, it would request them
in that order.
Printer (#1)
Plotter (#4)
If the job required the plotter first and then a plotter, it would still
request the printer first even though it wouldnt be used right away.
A job could request a printer (#1) and then a disk (#2) and then a
tape (#3); but if it needed another printer (#1) late in its
processing, it would still have to anticipate that need when it
requested the first one, and before it requested the disk.
Strategies for Handling 51

Deadlocks (cont'd.)
Prevention (cont'd.)
This scheme of hierarchical ordering removes the
possibility of a circular wait and, therefore,
guarantees the removal of deadlocks. It doesnt
require that jobs state their maximum needs in
advance, but it does require that the jobs anticipate
the order in which they will request resources.
From the perspective of a system designer, one of
the difficulties of this scheme is discovering the best
order for the resources so that the needs of the
majority of the users are satisfied.
Another difficulty is that of assigning a ranking to
nonphysical resources such as files or locked
database records where there is no basis for
assigning a higher number to one over the other.
Strategies for Handling 52

Deadlocks (cont'd.)
Avoidance:
Even if the OS cant remove one of the conditions
for deadlock, it can avoid one if the system knows
ahead of time the sequence of requests
associated with each of the active processes.
Dijkstras Bankers Algorithm was proposed in
1965 to regulate resource allocation to avoid
deadlocks.
Strategies for Handling 53

Deadlocks (cont'd.)
Avoidance:
Based on a bank with a fixed amount of capital
that operates on the following principles:
No customer will be granted a loan exceeding the
banks total capital.
All customers will be given a maximum credit limit
when opening an account.
No customer will be allowed to borrow over the limit.
The sum of all loans will not exceed the banks total
capital.
Strategies for Handling 54

Deadlocks (cont'd.)
Avoidance:
The bank has total capital of $10,000 and has
three customers, C1, C2, and C3, who have
maximum credit limits of $4,000, $5,000, and
$8,000, respectively.
Strategies for Handling 55
Deadlocks (cont'd.)
Strategies for Handling 56

Deadlocks (cont'd.)
Avoidance:
A few weeks later after more loans have been
made, and some have been repaid -
Strategies for Handling 57

Deadlocks (cont'd.)
Strategies for Handling 58

Deadlocks (cont'd.)
Avoidance:
An unsafe state doesnt necessarily lead to
deadlock, but it does indicate that the system is
an excellent candidate for one.
If we substitute jobs for customers and dedicated
devices for dollars.
In this example the system has 10 devices.
Strategies for Handling 59

Deadlocks (cont'd.)
Strategies for Handling 60

Deadlocks (cont'd.)
Strategies for Handling 61

Deadlocks (cont'd.)
The OS must be sure never to satisfy a request
that moves it from a safe state to an unsafe one.
As users are satisfied, the OS must identify the
job with the smallest number of remaining
resources and make sure that the number of
available resources is always equal to, or greater
than, the number needed for this job to run to
completion.
Requests that would place the safe state in
jeopardy must be blocked by the OS until they
can be safely accommodated.
Strategies for Handling 62

Deadlocks (cont'd.)
If this solution is expanded to work with several
classes of resources, the system sets up a
resource assignment table for each type of
resource and tracks each table to keep the
system in a safe state.
Strategies for Handling 63

Deadlocks (cont'd.)
Although the Bankers Algorithm has been used
to avoid deadlocks in systems with a few
resources, it isnt always practical for most
systems:
As they enter the system, jobs must predict the
maximum number resources needed.
Not practical in interactive systems.
The number of total resources for each class must
remain constant.
If a device breaks and becomes unavailable, the
algorithm wont work.
Strategies for Handling 64

Deadlocks (cont'd.)
The number of jobs must remain fixed.
Isnt possible in interactive systems where the
number of active jobs is constantly changing.
The overhead cost incurred by running the
avoidance algorithm can be quite high when there
are many active jobs and many devices because it
has to be invoked for every request.
Resources arent well utilized because the
algorithm assumes the worst case and keeps vital
resources unavailable to guard against unsafe
states.
Scheduling suffers as a result of the poor utilization
and jobs are kept waiting for resource allocation.
Strategies for Handling 65

Deadlocks (cont'd.)
Detection
Deadlocks can be detected by building directed
resource graphs and looking for cycles.
The algorithm used to detect circularity can be
executed whenever it is appropriate every hour,
one a day, only when the operator notices that
throughput has deteriorated, or when an angry
user complains.
Strategies for Handling 66

Deadlocks (cont'd.)
Detection algorithm
1. Find a process that is currently using a resource
and not waiting for one.
This process can be removed from the graph
Disconnecting the link tying the resource to the
process.
The resource can be returned to the available list.
This is possible because the process would
eventually finish and return the resource.
Strategies for Handling 67

Deadlocks (cont'd.)
Detection algorithm
2. Find a process thats waiting only for resource
classes that arent fully allocated
(P2, 5.12(c)).
This process isnt contributing to deadlock since it
would eventually get the resource its waiting for,
finish its work, and return the resource to the
available list.
3. Go back to step 1 and continue with steps 1 and 2
until all lines connecting resources have been
removed (5.12(d)).
Strategies for Handling 68

Deadlocks (cont'd.)
Strategies for Handling 69

Deadlocks (cont'd.)
Detection algorithm
If there are any lines left, this indicates that the
request of the process in question cant be
satisfied and that a deadlock exists.
Strategies for Handling 70

Deadlocks (cont'd.)
Strategies for Handling 71

Deadlocks (cont'd.)
Detection algorithm
A circular wait.
Strategies for Handling 72

Deadlocks (cont'd.)
Recovery
Once a deadlock has been detected, it must be
untangled and the system returned to normal as
quickly as possible.
There are several recovery algorithms, but they
have one feature in common:
They all require at least one victim, an
expendable job which, when removed from the
deadlock, will free the system.
Strategies for Handling 73

Deadlocks
Recovery
(cont'd.)
Recovery Methods:
The first and simplest recovery method, and the most drastic, is to
terminate every job thats active in the system and restart them
from the beginning.
The second method is to terminate only the jobs involved in the
deadlock and ask their users to resubmit them.
The third method is to identify which jobs are involved in the
deadlock and terminate them one at a time, checking to see if the
deadlock is eliminated after each removal, until the deadlock has
been resolved.
Once the system is free, the remaining jobs are allowed to complete
their processing and later the halted jobs are started again from the
beginning.
Strategies for Handling 74

Deadlocks
Recovery
(cont'd.)
Recovery Methods:
The fourth method can be put into effect only if the job keeps a
record, a snapshot, of its progress so it can be interrupted and then
continued without starting again from the beginning of its
execution.
This method is favored for long-running jobs to help them make a
speedy recovery.
The fifth method selects a nondeadlocked job, preempts the
resources its holding and allocates them to a deadlocked process
so it can resume execution, thus breaking the deadlock.
Strategies for Handling 75

Deadlocks
Recovery (cont'd.)
Recovery Methods:
The sixth method stops new jobs from entering the system, which
allows the nondeadlocked jobs to run to completion so theyll
release their resources.
Eventually, with fewer jobs in the system, competition for resources is
curtailed so the deadlocked processes get the resources they need to
run to completion.
The only method that doesnt rely on a victim.
Not guaranteed to work unless the number of available resources
surpasses that needed by at least one of the deadlocked jobs to run.
Several factors must be considered to select the victim
that will have the least-negative effect on the system.
Strategies for Handling 76

Deadlocks (cont'd.)
The most common are:
The priority of the job under consideration:
High-priority jobs are usually untouched.
CPU time used by the job:
Jobs close to completion are usually left alone.
The number of other jobs that would be affected
if this job were selected as the victim.
Jobs that are modifying data shouldnt be selected
for termination because the consistency and
validity of the database would be jeopardized.
Starvation 77

Deadlocks are the result of liberal allocation of

resources.
Starvation is the result of conservative
allocation of resources where a single job is
prevented from execution because its kept
waiting for resources that never become
available.
Starvation 78

The dining philosophers by Dijkstra (1968)

Five philosophers are sitting at a round table.
In the center lies a bowl of spaghetti that is
accessible to everyone.
There are forks on the table one between each
philosopher (Figure 5.14).
Starvation (cont'd.) 79
Starvation 80

The dining philosophers by Dijkstra (1968)

Local custom dictates that each philosopher must
use two forks - the forks on either side of the
plate to eat the spaghetti.
There are only five forks - not the 10 it would
require for all five philosophers.
Thats a problem for Philosopher 2.
When they sit down to dinner, P1 is the first to
take the two forks , F1 and F5, on either side of
the plate and begins to eat.
P3 does likewise, using F2 and F3.
Starvation 81

The dining philosophers by Dijkstra (1968)

P2 is unable to start because no forks are available.
The only remaining fork can be used only by P4 or P5.
P2 must wait.
P3 finishes.
Should F2 be allocated to P2?
Such a move would be a bad precedent because if
the philosophers are allowed to tie up resources
with only the hope that the other required resource
will become available, the dinner could easily slip
into an unsafe state.
Starvation 82

The dining philosophers by Dijkstra (1968)

It would be only a matter of time, before each
philosopher held a single fork and nobody could
eat.
The resources are allocated to the philosophers
only when both forks are available at the same
time (Figure 5.15)
Starvation (cont'd.) 83
Starvation 84

In a computer environment, the resources are

like forks and the competing processes are like
dining philosophers.
If the resource manager doesnt watch for
starving processes and jobs, and plan for their
eventual completion, they could remain in the
system forever waiting for the right
combination of resources.
To address this problem, an algorithm designed
to detect starving jobs can be implemented,
which tracks how long each job has been
waiting for resources (aging).
Starvation 85

Once starvation has been detected, the system

can block new jobs until the starving jobs have
been satisfied.
However:
If monitoring is done too often, then new jobs will
be blocked too frequently and throughput will be
diminished.
If its not done often enough, then starving jobs
will remain in the system for an unacceptably
long period of time.
Summary 86

Every OS must dynamically allocate a limited

number of resources while avoiding the two
extremes of deadlock and starvation.
Four methods for dealing with livelocks and
deadlocks:
Prevention, avoidance, detection, and recovery
Deadlocks can be prevented by not allowing
the four conditions of a deadlock to occur in the
system at the same time.
Summary (contd) 87

By eliminating at least one of the four

conditions (mutual exclusion, resource holding,
no preemption, and circular wait), the system
can be kept deadlock- free.
The disadvantage of a preventive policy is that
each of these conditions is vital to different parts
of the system at least some of the time, so
prevention algorithms are complex and to
routinely execute them involves high overhead.
Deadlocks can be avoided by clearly identifying
safe states and unsafe states and requiring the
system to keep enough resources in reserve to
guarantee that all jobs active in the system can
run to completion.
Summary (contd) 88

The disadvantage of an avoidance policy is that

the systems resources arent allocated to their
fullest potential.
If a system doesnt support prevention or
avoidance, then it must be prepared to detect
and recover from the deadlocks that occur.
This option usually relies on the selection of at
least one victim a job that must be terminated
before it finishes execution and restarted from the
beginning.