Chapter 7 – Deadlock (Pgs 283 – 306)
CSCI 3431: OPERATING SYSTEMS
Overview
 When a set of processes is prevented from
completing because each is preventing the
other from accessing resources that the other
needs, we say that deadlock occurs
 Deadlock is a cause of process starvation, but
is not the only cause
 Deadlock is not monitored, identified, or
handled by the O/S, it is a programmer
responsibility to prevent
Resources
 Memory, CPU cycles, files, I/O devices (network,
printer, keyboard, mouse) can be partitioned into
sets
 All the members of a set are equivalent such that
a process can use any member, e.g., two
identical printers
 A resource must be (in this order):
1.
2.
3.

Requested (and waited for until available)
Used
Released
Generally, when one process has a resource,
another process cannot use it
Necessary Conditions
1. Mutual Exclusion: At least one resource must be
held in a non-sharable mode
2. Hold and Wait: A process must be holding at
least one resource and waiting to acquire some
other resource
3. No Pre-emption: A resource cannot be
involuntarily taken away from a process that is
using it
4. Circular Wait: It must be possible to structure
the waits such that,
P1 w. P2, P2 w. P3, ... , Pn w. P1
Resource Allocation Graphs
 Two types of nodes:
Processes
2. Resources
1.
 Directed edges go
from a Process to a Resource (request)
2. from a Resource to a Project (assignment)
1.
 A cycle in the graph indicates deadlock
Deadlock (Fig 7.3)
NO Deadlock (Fig 7.4)
Three Solutions
1. Prevent/Avoid Deadlock


Prevention: When deadlock is going to occur,
stop it
Avoidance: Reschedule processes so that
deadlock does not have to be prevented
2. Detect and Recover
3. Ignore the Issue
 Generally, most O/S use solution 3 and expect
programmers to deal with the issue
Prevention (via 4 conditions)
 Disallow anything that requires mutual exclusion
(unreasonable)
 Do not allow a process to request a resource
while it is holding one (or) only let a process run if
all resources are available (inefficient)
 Pre-empt a process to break a cycle (only
effective if preemption can later be effectively
reversed, e.g., not printing)
 Order resources and allow them only to be
acquired and held in order (complex, but
effective)
Avoidance
 Requires knowledge of which resources a
process will use (process can declare this)
 Goal is to always maintain a "safe state" for
which some sequence of (deadlock free)
resource allocations is possible
 Two common algorithms:
Resource allocation graph algorithm
2. Bankers algorithm
1.
Resource Graph Prevention
 Put in temporary edges that represent what a
process could use (claim edges)
 If these edges cause a cycle, then there is an
unsafe state
 Prevent unsafe states by not allowing a
process to use any resources until it can do so
without putting the system in an unsafe state
 Not effective for multiple instances of each
resource
Banker's Algorithm
 Less efficient than resource allocation graph




algorithm
Again requires a process to know all the
resources it is going to need
Safety (sub) Algorithm: Checks if a system is
in a safe state
Request (sub) Algorithm: Determines if a
request is possible
I am unaware of any O/S that actually uses
the Banker's Algorithm (or ever will ...)
Deadlock Detection
 Too inefficient to actually do this for every




resource request
Could just do it at regular intervals (but
nobody does)
Does not fix the problem
A lot of effort for a generally rare problem
(programmers like to avoid deadlock
anyways)
Use algorithm 7.6.2 if really desired
Recovery
 Process Termination (2 approaches)
1. Abort all known deadlocked processes
2. Abort one at a time until deadlock eliminated
 Termination can leave a resource (e.g., file) in
an invalid state
 Consider:
1. Process priority (importance of job)
2. How long it ran and how long it will take to
complete (preserve computation)
3. Which resources it uses (1 vs many)
Resource Pre-Emption
 Alternative to Process Termination
 Similar factors to consider
 Effective for some resources for which invalid
state is not likely or hard to handle
 Maybe be repairable using rollback
 May cause starvation if performed multiple
times
Ignoring the Problem
 More likely due to increasing concurrency
 Less likely as many resources now designed
for concurrency
 Programmers more able to deal with the
issue than in the past
 More of interest to researchers than to
practictioners
 More effort to avoid/detect than is probably
worth making
To Do:
 Begin Assignment 2 in Lab
 Read Chapter 7 (pgs 283-306; this lecture)
 Start reading Chapter 8 (next lecture)