================ Start Lecture #11 ================
3.4.2: Detecting Deadlocks with Multiple Unit Resources
This is more difficult.
The figure on the right shows a resource allocation graph with
multiple unit resources.
Each unit is represented by a dot in the box.
Request edges are drawn to the box since they represent a request
for any dot in the box.
Allocation edges are drawn from the dot to represent that this
unit of the resource has been assigned (but all units of a resource
are equivalent and the choice of which one to assign is arbitrary).
Note that there is a directed cycle in red, but there is no
deadlock. Indeed the middle process might finish, erasing the green
arc and permitting the blue dot to satisfy the rightmost process.
The book gives an algorithm for detecting deadlocks in this more
general setting. The idea is as follows.
- look for a process that might be able to terminate (i.e., all
its request arcs can be satisfied).
- If one is found pretend that it does terminate (erase all its
arcs), and repeat step 1.
- If any processes remain, they are deadlocked.
We will soon do in detail an algorithm (the Banker's algorithm) that
has some of this flavor.
3.4.3: Recovery from deadlock
Perhaps you can temporarily preempt a resource from a process. Not
Database (and other) systems take periodic checkpoints. If the
system does take checkpoints, one can roll back to a checkpoint
whenever a deadlock is detected. Somehow must guarantee forward
Can always be done but might be painful. For example some
processes have had effects that can't be simply undone. Print, launch
a missile, etc.
We are doing 3.6 before 3.5 since 3.6 is easier.
3.6: Deadlock Prevention
Attack one of the coffman/havender conditions
3.6.1: Attacking Mutual Exclusion
Idea is to use spooling instead of mutual exclusion. Not
possible for many kinds of resources
3.6.2: Attacking Hold and Wait
Require each processes to request all resources at the beginning
of the run. This is often called One Shot.
3.6.3: Attacking No Preempt
Normally not possible.
That is, some resources are inherently preemptable (e.g., memory).
For those deadlock is not an issue.
Other resources are non-preemptable, such as a robot arm.
It is normally not possible to find a way to preempt one of these
3.6.4: Attacking Circular Wait
Establish a fixed ordering of the resources and require that they
be requested in this order. So if a process holds resources #34 and
#54, it can request only resources #55 and higher.
It is easy to see that a cycle is no longer possible.
3.5: Deadlock Avoidance
Let's see if we can tiptoe through the tulips and avoid deadlock
states even though our system does permit all four of the necessary
conditions for deadlock.
An optimistic resource manager is one that grants every
request as soon as it can. To avoid deadlocks with all four
conditions present, the manager must be smart not optimistic.
3.5.1 Resource Trajectories
We plot progress of each process along an axis.
In the example we show, there are two processes, hence two axes, i.e.,
This procedure assumes that we know the entire request and release
pattern of the processes in advance so it is not a practical
I present it as it is some motivation for the practical solution that
follows, the Banker's Algorithm.
We have two processes H (horizontal) and V.
The origin represents them both starting.
Their combined state is a point on the graph.
The parts where the printer and plotter are needed by each process
The dark green is where both processes have the plotter and hence
execution cannot reach this point.
Light green represents both having the printer; also impossible.
Pink is both having both printer and plotter; impossible.
Gold is possible (H has plotter, V has printer), but the system
can't get there.
The upper right corner is the goal; both processes have finished.
The red dot is ... (cymbals) deadlock. We don't want to go there.
The cyan is safe. From anywhere in the cyan we have horizontal
and vertical moves to the finish point (the upper right corner)
without hitting any impossible area.
The magenta interior is very interesting. It is
- Possible: each processor has a different resource
- Not deadlocked: each processor can move within the magenta
- Deadly: deadlock is unavoidable. You will hit a magenta-green
boundary and then will no choice but to turn and go to the red dot.
The cyan-magenta border is the danger zone.
The dashed line represents a possible execution pattern.
With a uniprocessor no diagonals are possible. We either move to
the right meaning H is executing or move up indicating V is executing.
The trajectory shown represents.
- H excuting a little.
- V excuting a little.
- H executes; requests the printer; gets it; executes some more.
- V executes; requests the plotter.
The crisis is at hand!
If the resource manager gives V the plotter, the magenta has been
entered and all is lost. “Abandon all hope ye who enter here”
The right thing to do is to deny the request, let H execute moving
horizontally under the magenta and dark green. At the end of the dark
green, no danger remains, both processes will complete successfully.
This procedure is not practical for a general purpose OS since it
requires knowing the programs in advance. That is, the resource
manager, knows in advance what requests each process will make and in
Homework: 10, 11, 12.
3.5.2: Safe States
Avoiding deadlocks given some extra knowledge.
Not surprisingly, the resource manager knows how many units of each
resource it had to begin with.
Also it knows how many units of each resource it has given to
It would be great to see all the programs in advance and thus know
all future requests, but that is asking for too much.
Instead, when each process starts, it gives its maximum usage.
That is each process at startup states, for each resource, the maximum
number of units it can possibly ask for.
This is called the claim of the process.
If the claim is greater than the total number of units in the
system the resource manager kills the process when receiving
the claim (or returns an error code so that the process can
make a new claim).
If during the run the process asks for more than its claim,
If a process claims more than it needs, the result is that the
resource manager will be more conservative than need be and there
will be more waiting.