NOTE: These notes are by Allan Gottlieb, and are reproduced here, with superficial modifications, with his permission. "I" in this text generally refers to Prof. Gottlieb, except in regards to administrative matters.


================ Start Lecture #8 (Feb. 20) ================

There are four strategies used for dealing with deadlocks.

  1. Ignore the problem
  2. Detect deadlocks and recover from them
  3. Avoid deadlocks by carefully deciding when to allocate resources.
  4. Prevent deadlocks by violating one of the 4 necessary conditions.

3.3: Ignoring the problem--The Ostrich Algorithm

The ``put your head in the sand approach''.

3.4: Detecting Deadlocks and Recovering From Them

3.4.1: Detecting Deadlocks with Single Unit Resources

Consider the case in which there is only one instance of each resource.

To find a directed cycle in a directed graph is not hard. The algorithm is in the book. The idea is simple.

  1. For each node in the graph do a depth first traversal (hoping the graph is a DAG (directed acyclic graph), building a list as you go down the DAG.
  2. If you ever find the same node twice on your list, you have found a directed cycle and the graph is not a DAG and deadlock exists among the processes in your current list.
  3. If you never find the same node twice, the graph is a DAG and no deadlock occurs.
  4. The searches are finite since the list size is bounded by the number of nodes.

3.4.2: Detecting Deadlocks with Multiple Unit Resources

This is more difficult.

3.4.3: Recovery from deadlock

Preemption

Perhaps you can temporarily preempt a resource from a process. Not likely.

Rollback

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 progress.

Kill processes

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.

Remark: 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.

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

3.5.2: Safe States

Avoiding deadlocks given some extra knowledge.

Definition: A state is safe if there one can find an ordering of the processes such that: if the processes are run in this order, they will all terminate (assuming none exceeds its claim).

Give an example of all four possibilities. A state that is

  1. Safe and deadlocked--not possible
  2. Safe and not deadlocked
  3. Not safe and deadlocked
  4. Not safe and not deadlocked--interesting

A manager can determine if a state is safe.

The manager then follows the following procedure, which is part of Banker's Algorithms discovered by Dijkstra, to determine if the state is safe.

  1. If there are no processes remaining, the state is safe.

  2. Seek a process P whose max additional requests is less than what remains (for each resource).
  3. The banker now pretends that P has terminated (since the banker knows that it can guarantee this will happen). Hence the banker pretends that all of P's currently held resources are returned. This makes the banker richer and hence perhaps a process that was not eligible to be chosen as P previously, can now be chosen.

  4. Repeat these steps.

Example 1

processclaimcurrent
X31
Y115
Z1910
total16

Example 2

processclaimcurrent
X31
Y115
Z1912
total18

Start with example 1 and assume that Z now requests 2 units and we grant them.

Remark: An unsafe state is not necessarily a deadlocked state. Indeed, if one gets lucky all processes may terminate successfully. A safe state means that the manager can guarantee that no deadlock will occur.