Deadlock avoidance is never used (either in distributed or centralized systems). The
problem with deadlock avoidance is that the algorithm will need to know resource usage
requirements in advance so as to schedule them properly. Whereas, the first of these is
trivially simple. The other two are described in details:
General methods for preventing or avoiding deadlocks can be difficult to find. Detecting a
deadlock condition is generally easier. When a deadlock is detected, it has to be broken.
This is traditionally done by killing one or more processes that contribute to the deadlock.
Unfortunately, this can lead to annoyed users. When a deadlock is detected in a system that
is based on atomic transactions, it is resolved by aborting one or more transactions. But
transactions have been designed to withstand being aborted. Consequences of killing a
process in a transactional system are less severe.
Centralized deadlock detection attempts to imitate the nondistributed algorithm through a
central coordinator. Each machine is responsible for maintaining a resource graph for its
processes and resources. A central coordinator maintains the resource utilization graph
for the entire system. This graph is the union of the individual graphs. If this coordinator
detects a cycle, it kills off one process to break the deadlock. In the non-distributed case, all
the information on resource usage lives on one system and the graph may be constructed
on that system. In the distributed case, the individual sub graphs have to be propagated to a
central coordinator. A message can be sent each time an arc is added or deleted. If
optimization is needed, a list of added or deleted arcs can be sent periodically to reduce the
overall number of messages sent.
Here is an example. Suppose machine A has a process P0, which holds the resource S and
wants resource R, which is held by P1. The local graph on A is shown in Figure 2. Another
machine, machine B has a process P2, which is holding resource T and wants resource S. Its
local graph is shown in Figure 3. Both of these machines send their graphs to the central
coordinator, which maintains the union (Figure 3).
All is well. There are no cycles and hence no deadlocks. Now two events occur. Process P1
releases resource R and asks machine B for resource T. Two messages are sent to the
Message 1 (from machine A): “releasing R”
Message 2 (from machine B): “waiting for T”
This should cause no problems (no deadlock). However, if message 2 arrives first, the
coordinator would then construct the graph in Figure 4 and detect a deadlock. Such a
condition is known as false deadlock. A way to fix this is to use Lamport’s algorithm to
impose global time ordering on all machines. Alternatively, if the coordinator suspects
deadlock, it can send a reliable message to every machine asking whether it has any release