Remove all the resource nodes together with the associated edges

Figure 5.2 Two resource allocation graphs: (a) without deadlock and (b) with deadlock.

Let us consider the dining philosophers problem where five philosophers spend their lives thinking and eating on a round table. When a philosopher gets hungry, he tries to pick up two forks closest to him:

one that lies in between him and his left-hand side neighbor and another that lies in between him and his right-hand side neighbor. When a philosopher has both forks, he starts eating. When he finishes eating, he puts down both of his forks. A deadlock situation occurs when each of the five philosophers (P

i) has his right-hand side fork (F

i) and wants to access his left-hand side fork (F

i+1 or F

5 if i = 1) as shown in the resource allocation graph in Figure 5.3 (a). Following the transformation procedure we can derive the corresponding wait-for graph as shown in Figure 5.3 (b).

5.1.3 Strategies for handling deadlocks There are three strategies for handling deadlocks:

• Deadlock prevention. Prevents deadlocks by restraining requests made to ensure that at least one of the four deadlock conditions cannot occur.

• Deadlock avoidance. Dynamically grants a resource to a process if the resulting state is safe. A state is safe if there is at least one execution sequence that allows all processes to run to

completion.

• Deadlock detection and recovery. Allows deadlocks to form; then finds and breaks them.

Figure 5.3 The dining philosophers problem: (a) A deadlock situation shown in a resource allocation graph. (b) The corresponding wait-for graph.

Both deadlock prevention and avoidance use a pessimistic approach: Assume that deadlock will occur and try to prevent or avoid it. One commonly used deadlock prevention is done by having a process acquire all the needed resources simultaneously before it starts (it may not be a trivial task) or by preempting a process that holds the needed resource(s). The former method is inefficient because it decreases system concurrency. The latter approach is also inefficient, because irrelevant processes may be aborted.

Although deadlock avoidance strategies are often used in centralized systems and many algorithms have been proposed (e.g., Dijkstra’s banker’s algorithm [4]), they are rarely used in a distributed system. This is because checking for safe states is computationally expensive due to the large number of processes and resources in distributed systems without a global clock.

Deadlock detection and recovery uses an optimistic approach. However, it may not be efficient for applications where deadlocks occur frequently. Some distributed detection algorithms can be easily

implemented and will be discussed later in this chapter.

We use the bridge crossing example to illustrate these three approaches. A typical deadlock prevention will place constraints on the direction people are allowed to move from one city to another. One naive approach is to allow people to move only from city A to city B. However, this is not a feasible approach since no one can move from city B to city A. One solution is to build another bridge (see Figure 5.1 (b)) that allows people to move from city B to city A. This approach is feasible, but resources (bridges) may not be fully utilized. For example, when there is heavy traffic from city A to city B and at the same time almost no traffic from city B to city A, only one bridge can be utilized - a utilization of close to fifty percent of resources.

In deadlock avoidance, the concept of a safe state is introduced which is dependent on the application. In the bridge crossing example, there is no need to place any constraints on moving directions in deadlock avoidance. However, whenever a person is about to step onto the bridge, he or she needs to check if there are other people coming from the other direction and have already been on the bridge (a safety check). However, the safety concept cannot be easily defined or captured for some applications. In this example the avoidance approach fails when either the bridge is too long or the weather is too foggy for people to see the other end of the bridge.

In deadlock detection and recovery, neither constraints nor safety checks are necessary. A detection mechanism is needed to detect a possible deadlock situation. In the bridge crossing example, when two persons coming from different directions meet on the bridge and no one is willing to back off a deadlock occurs. However, in reality the detection process is much more complex especially in distributed

systems. There are several ways to perform a recovery: Either one process is aborted (one person is thrown into the river in the river crossing example) or one process is forced to release the occupied resources (at least one person backs off in the river crossing example). The selection of the victim is also important: Logically a person who is close to the destination should have a higher priority than the one who just stepped onto the bridge.

Previous Table of Contents Next

Copyright © CRC Press LLC

Previous Table of Contents Next

5.1.4 Models of request

There are in general two types of deadlock:

• Resource deadlock

• Communication deadlock

In communication deadlocks, messages are the resources for which processes wait. The real difference between resource deadlock and communication deadlock is that the former usually uses the AND condition while the latter uses the OR condition defined as follows:

• AND condition. A process that requires resources for execution can proceed when it has acquired all those resources.

• OR condition. A process that requires resources for execution can proceed when it has acquired at least one of those resources.

The reason the OR condition is used for communication deadlocks is that most distributed control structures are nondeterministic; a process may be waiting for a message from more than one process.

Another condition is called P-out-of-Q which means that a process simultaneously requests Q resources and remains blocked until it is granted any P of those resources. The AND-OR model is another

generalization of the AND and OR, models. AND-OR requests may specify any combination of AND and OR requests. For example, it is possible to request a AND (b OR c). Since it is hard to analyze the deadlock situation under this model, we consider here the AND and OR conditions separately.

5.1.5 Models of process and resource

Normally a process may use a resource following the steps below: (1) Request. If the request is not immediately granted, the requesting process has to wait until it acquires the resource. (2) Use. The process uses the resource. (3) Release. The process releases the resource.

A resource is any object that processes can request and wait for. In general, a resource is either reusable or consumable. A reusable resource does not disappear as a result of its use and it can be used over and over again. Examples of reusable resource are CPU, memory, and I/O. A consumable resource vanishes as a result of its use. Examples of consumable resource are message, signal, etc.

5.1.6 Deadlock conditions

The condition for deadlock in a system using the AND condition is the existence of a cycle. However, in

a system using the OR condition a cycle may or may not cause a deadlock. The condition for deadlock in a system using the OR condition is the existence of a knot. A knot (K) consists of a set of nodes such that for every node a in K, all nodes in K and only the nodes in K are reachable from node a. For

example, in Figure 5.4 (a) there is a cycle, P

4 → P

4 is waiting for a message from either P

2 or P the wait-for graph in Figure 5.4 (b) has a deadlock. In this chapter we focus on resource deadlocks only;

for a more detailed discussion on communication deadlocks see [2] and [7].

Figure 5.4 Two systems under the OR condition with (a) no deadlock and without (b) deadlock.

In the subsequent discussion the deadlock handling methods are general to both types of deadlock unless otherwise specified.

Previous Table of Contents Next

Copyright © CRC Press LLC

Previous Table of Contents Next

5.2 Deadlock Prevention

Deadlock prevention algorithms prevent deadlocks by restraining how process requests can be made.

Deadlock prevention is commonly achieved by one of the following approaches; all of which are based on breaking one of the four deadlock conditions:

1. A process acquires all the needed resources simultaneously before it begins its execution, therefore breaking the hold and wait condition. In the dining philosophers’ problem, each

philosopher is required to pick up both forks at the same time. If he fails, he has to release the fork (s) (if any) that he has acquired.

2. All resources are assigned unique numbers. A process may request a resource with a unique