Operating Systems

Start Lecture #5

Remark: The format for lab2 output was stated on the mailing list.

Chapter 6 Deadlocks

Remark: Deadlocks are closely related to process management so belong here, right after chapter 2. It was here in 2e. A goal of 3e is to make sure that the basic material gets covered in one semester. But I know we will do the first 6 chapters so there is no need for us to postpone the study of deadlock.

A deadlock occurs when every member of a set of processes is waiting for an event that can only be caused by a member of the set.

Often the event waited for is the release of a resource.

In the automotive world deadlocks are called gridlocks.

• The processes are the cars.
• The resources are the spaces occupied by the cars

For a computer science example consider two processes A and B that each want to print a file currently on a CD-ROM Drive.

1. A has obtained ownership of the printer and will release it after getting the CD Drive and printing one file.
2. B has obtained ownership of the CD drive and will release it after getting the printer and printing one file.
3. A tries to get ownership of the drive, but is told to wait for B to release it.
4. B tries to get ownership of the printer, but is told to wait for A to release it.

Bingo: deadlock!

6.1 Resources

The resource is the object granted to a process.

6.1.1 Preemptable and Nonpreemptable Resources

Resources come in two types

1. Preemptable, meaning that the resource can be taken away from its current owner (and given back later). An example is memory.
2. Non-preemptable, meaning that the resource cannot be taken away. An example is a printer.

The interesting issues arise with non-preemptable resources so those are the ones we study.

The life history of a resource is a sequence of

1. Request
2. Allocate
3. Use
4. Release

Processes request the resource, use the resource, and release the resource. The allocate decisions are made by the system and we will study policies used to make these decisions.

6.1.2 Resource Acquisition

A simple example of the trouble you can get into.

• Two resources and two processes.
• Each process wants both resources.
• Use a semaphore for each. Call them S and T.
• If both processes execute
  P(S); P(T); --- V(T); V(S)
  all is well.
• But if one executes instead
  P(T); P(S); -- V(S); V(T)
  disaster! This was the printer/CD example just above.

Recall from the semaphore/critical-section treatment last chapter, that it is easy to cause trouble if a process dies or stays forever inside its critical section; we assume processes do not do this. Similarly, we assume that no process retains a resource forever. It may obtain the resource an unbounded number of times (i.e. it can have a loop forever with a resource request inside), but each time it gets the resource, it must release it eventually.

6.2 Introduction to Deadlocks

To repeat: A deadlock occurs when a every member of a set of processes is waiting for an event that can only be caused by a member of the set.

Often the event waited for is the release of a resource.

Note on lab 2 (scheduling).
If several processes are waiting on I/O, you are to assume noninterference. For example, assume that on cycle 100 process A flips a coin and decides its wait is 6 units (i.e., during cycles 101-106 A will be blocked. Assume B begins running at cycle 101 for a burst of 1 cycle. After this cycle process B flips a coin and decides its wait is 3 units. You do NOT alter process A. That is, Process A will become ready after cycle 106 (100+6) so enters the ready list cycle 107 and process B becomes ready after cycle 104 (101+3) and enters ready list cycle 105.
End of Note

6.2.1 (Necessary) Conditions for Deadlock

The following four conditions (Coffman; Havender) are necessary but not sufficient for deadlock. Repeat: They are not sufficient.

1. Mutual exclusion: A resource can be assigned to at most one process at a time (no sharing).
2. Hold and wait: A processing holding a resource is permitted to request another.
3. No preemption: A process must release its resources; they cannot be taken away.
4. Circular wait: There must be a chain of processes such that each member of the chain is waiting for a resource held by the next member of the chain.

The first three are static characteristics of the system and resources.w That is, for a given system with a fixed set of resources, the first three conditions are either always true or always false: They don't change with time. The truth or falsehood of the last condition does indeed change with time as the resources are requested/allocated/released.

6.2.2 Deadlock Modeling

On the right are several examples of a Resource Allocation Graph, also called a Reusable Resource Graph.

• The processes are circles.
• The resources are squares.
• An arc (directed line) from a process P to a resource R signifies that process P has requested (but not yet been allocated) resource R.
• An arc from a resource R to a process P indicates that process P has been allocated resource R.

Homework: 5.

Consider two concurrent processes P1 and P2 whose programs are.

      P1                   P2
    request R1           request R2
    request R2           request R1
    release R2           release R1
    release R1           release R2
  

On the board draw the resource allocation graph for various possible executions of the processes, indicating when deadlock occurs and when deadlock is no longer avoidable.

There are four strategies used for dealing with deadlocks.

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

6.3 Ignoring the problem--The Ostrich Algorithm

The put your head in the sand approach.

• If the likelihood of a deadlock is sufficiently small and the cost of avoiding a deadlock is sufficiently high it might be better to ignore the problem. For example if each PC deadlocks once per 10 years, the one reboot may be less painful that the restrictions needed to prevent it.
  
  
• Clearly not a good philosophy for nuclear missile launchers.
  
  
• For embedded systems (e.g., missile launchers) the programs run are fixed in advance so many of the issues that occur in systems like linux or windows (such as many processes wanting to fork at the same time) don't occur.

6.4 Detecting Deadlocks and Recovering From Them

6.4.1 Detecting Deadlocks with Single Unit Resources

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

• Thus a request can be satisfied by only one specific resource.
  
  
• In this case the 4 necessary conditions for deadlock are also sufficient.
  
  
• Remember we are making an assumption (single unit resources) that is often invalid. For example, many systems have several printers and a request is given for a printer not a specific printer. Similarly, one can have many CD-ROM drives.
  
  
• So the problem comes down to finding a directed cycle in the resource allocation graph. Why?
  Answer: Because the other three conditions are either satisfied by the system we are studying or are not in which case deadlock is not a question. That is, conditions 1,2,3 are conditions on the system in general not on what is happening right now.

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 to see if the graph is a DAG (directed acyclic graph), building a list as you go down the DAG (and pruning it as you backtrack back up).
   
   
2. If you ever find the same node twice on your list, you have found a directed cycle, 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 there are a finite number of nodes.

6.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.
  1. look for a process that might be able to terminate (i.e., all its request arcs can be satisfied).
  2. If one is found pretend that it does terminate (erase all its arcs), and repeat step 1.
  3. 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.
  
  
• The algorithm just given makes the most optimistic assumption about a running process: it will return all its resources and terminate normally. If we still find processes that remain blocked, they are deadlocked.
  
  
• In the bankers algorithm we make the most pessimisticassumption about a running process: it immediately asks for all the resources it can (details later on can). If, even with such demanding processes, the resource manager can insure that all process terminates, then we can insure that deadlock is avoided.

6.4.3 Recovery from deadlock

Recovery through Preemption

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

Recovery through 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.

Recovery through Killing 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 6.6 before 6.5 since 6.6 is easier and I believe serves as a good warm-up.

6.6 Deadlock Prevention

Attack one of the coffman/havender conditions.

6.6.1 Attacking the Mutual Exclusion Condition

Idea is to use spooling instead of mutual exclusion. Not possible for many kinds of resources.

6.6.2 Attacking the Hold and Wait Condition

Require each processes to request all resources at the beginning of the run. This is often called One Shot.

6.6.3 Attacking the No Preemption Condition

Normally not possible. That is, some resources are inherently pre-emptable (e.g., memory). For those deadlock is not an issue. Other resources are non-preemptable, such as a robot arm. It is often not possible to find a way to preempt one of these latter resources. One exception is if the resource (say a CD-ROM drive) can be virtualized (recall hypervisors).

6.6.4 Attacking the Circular Wait Condition

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.

Homework: Consider Figure 6-4. Suppose that in step (o) C requested S instead of requesting R. Would this lead to deadlock? Suppose that it requested both S and R.

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

6.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., planar. This procedure assumes that we know the entire request and release pattern of the processes in advance so it is not a practical solution. 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 are indicated.
• 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 brown 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 brown 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.
  1. H excuting a little.
  2. V excuting a little.
  3. H executes; requests the printer; gets it; executes some more.
  4. 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—Dante.
• The right thing to do is to deny the request, let H execute move horizontally under the magenta and dark green. At the end of the dark green, no danger remains, both processes will complete successfully. Victory!
• 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 what order.

Homework: All the trajectories in Figure 6-8 are horizontal or vertical. Is is possible for a trajectory to be a diagonal.

Homework: 11, 12.

6.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 each process.
  
  
• 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 announces its maximum usage. That is each process, before making any resource requests, tells the resource manager the maximum number of units of each resource the process can possible need. 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, the process is aborted (or an error code is returned and no resources are allocated).
  • 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.

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

Recall the comparison made above between detecting deadlocks (with multi-unit resources) and the banker's algorithm (which stays in safe states).

• The deadlock detection algorithm given makes the most optimistic assumption about a running process: it will return all its resources and terminate normally. If we still find processes that remain blocked, they are deadlocked.
  
  
• The banker's algorithm makes the most pessimistic assumption about a running process: it immediately asks for all the resources it can (details later on can). If, even with such demanding processes, the resource manager can assure that all process terminates, then we can assure that deadlock is avoided.

In the definition of a safe state no assumption is made about the running processes; that is, for a state to be safe termination must occur no matter what the processes do (providing the all terminate and to not exceed their claims). Making no assumption is the same as making the most pessimistic assumption.

Give an example of each of the four possibilities. A state that is

1. Safe and deadlocked--not possible.
   
   
2. Safe and not deadlocked--trivial (e.g., no arcs).
   
   
3. Not safe and deadlocked--easy (any deadlocked state).
   
   
4. Not safe and not deadlocked--interesting.

Is the figure on the right safe or not?

• You can NOT tell until I give you the initial claims of the process.
  
  
• Please do not make the unfortunately common exam mistake to give an example involving safe states without giving the claims.
  
  
• For the figure on the right, if the initial claims are:
  P: 1 unit of R and 2 units of S (written (1,2))
  Q: 2 units of R and 1 units of S (written (2,1))
  the state is NOT safe.
  
  
• But if the initial claims are instead:
  P: 2 units of R and 1 units of S (written (2,1))
  Q: 1 unit of R and 2 units of S (written (1,2))
  the state IS safe.
  
  
• Explain why this is so.