DISTRIBUTED DEADLOCKS

Outline:

 Definition
 Fundamental causes of deadlocks
 Resource allocation graphs and wait for Graph
 Approaches to handling deadlocks
 Deadlock prevention
 Deadlock avoidance
 Deadlock detection and recovery
 Conclusion
 References
 What is Deadlock?

 A set of processes is in a deadlock state if every process in the set

is waiting for an event (release) that can only be caused by some
other process in the same set.
 Two common places where deadlocks may occur are with
processes in an operating system (distributed or centralized) and
with transactions in a database.
 The resources may be either physical or logical.
 Physical resources: Printers, Tape Drivers, Memory space, CPU
cycles.
 Logical resources: Files, Semaphores, Monitors.
 The simplest example is process A is waiting for a resource held by
process B and process B is waiting for a resource held by process
A. Several processes can be involved in a deadlock when there
exists a cycle of processes waiting for each other. process A waits
for B which waits for C which waits for A.
 Conditions for a deadlock to occur

1. Mutual Exclusion: At least one of the resources is non-sharable (i.e only a limited
number of processes can use it at a time and it is requested by a process while
it is being used by another one, the requesting process has to wait until the
resource is released).
2. Hold and Wait: There must be at least one process that is holding at least one
resource and waiting for other resources that are being hold by other
processes.
3. No preemption: No resource can be preempted before the holding process
completes its task with that resource.
If a process that is holding some resources requests another resource and
that resource cannot be allocated it, then it must release all resources that are
currently allocated to it.
4. Circular Wait: There exists a set of processes (p1,p2….pn) such that
P1 is waiting for a resource held by p2
P2 is waiting for a resource held by p3 ……….
Pn-1 is waiting for a resource held by pn.
Pn is waiting for a resource held by p1.
 Deadlock in distributed systems

The same conditions for deadlock in uniprocessors apply to distributed

systems. Unfortunately, as in many other aspects of distributed systems,
they are harder to detect, avoid, and prevent. Four strategies can be
used to handle deadlock:
 Ignorance: ignore the problem; assume that a deadlock will never
occur. This is a surprisingly common approach.
 Detection: let a deadlock occur, detect it, and then deal with it by
aborting and later restarting a process that causes deadlock.
 Prevention: make a deadlock impossible by granting requests so that
one of the necessary conditions for deadlock does not hold.
 Avoidance: choose resource allocation carefully so that deadlock will
not occur. Resource requests can be honored as long as the system
remains in a safe (non-deadlock) state after resources are allocated.
As an example, consider the traffic
deadlock in the following figure
Example (Contd..)

Consider each section of the street as a resource.

 Mutual exclusion condition applies, since only one vehicle can be on

a section of the street at a time.
 Hold-and-wait condition applies, since each vehicle is occupying a
section of the street, and waiting to move on to the next section of
the street.
 No-preemptive condition applies, since a section of the street that is a
section of the street that is occupied by a vehicle cannot be taken
away from it.
 Circular wait condition applies, since each vehicle is waiting on the
next vehicle to move. That is, each vehicle in the traffic is waiting for a
section of street held by the next vehicle in the traffic.
The simple rule to avoid traffic deadlock is that a vehicle should only
enter an intersection if it is assured that it will not have to stop inside the
intersection.
 Resource Allocation Graphs

 Resource allocation graphs are drawn in order to see the allocation

relations of processes and resources easily. In these graphs, processes
are represented by circles and resources are represented by boxes.
Resource boxes have some number of dots inside indicating available
number of that resource, that is number of instances.

 If the resource allocation graph contains no cycles then there is no

deadlock in the system at that instance.

 If the resource allocation graph contains a cycle then a deadlock may

exist.

• If there is a cycle, and the cycle involves only resources which have a
single instance, then a deadlock has occurred.
 Resource allocation Graphs
(contd..)
[reusable] resources with multiplicity 2

Request edge from process Pi to Rj

Pi Rj
Assignment edge from resource Rj to process Pi

Pi Rj

R1
P1 P1 holds 2 copies of resource R1, and P2
holds one copy of resource R1 and
request one copy of resource R2
R2
P2
There are three cycles, so a deadlock may exists.
Actually p1, p2 and p3 are deadlocked

There is a cycle, however there

is no deadlock. If p4 releases r2,
r2 may be allocated to p3,
which breaks the cycle.
 Resource Allocation Graph &
wait for Graph

P5 P5
R1 R3 R4

P2 P3 P1 P2 P3
P1

P4 P4

R2 R5

Resource allocation graph Corresponding wait for Graph

Methods for handling Deadlocks

 Deadlock detection and

recovery.
 Deadlock prevention
Deadlock detection – Centralized
Algorithm

 A central site is responsible of collecting all the

information to build the global WFG
 every node report to the central site
• When a process waits to enter a CS
• When a process enters a CS
• When a process releases a CS
Chandy-misra-Haas algorithm(1983)

1.Determine the dependency among processes

• If Pi is waiting for a resource which is occupied by Pj, then Pi is said
to depend on Pj
• If Pi depends on Pj and they are in the same home node,then Pi
locally depends on Pj, otherwise Pi remotely depends on Pj
• If Pi locally depends on Pj and Pj locally depends on Pk, then Pi locally
depends on Pk
2.If Pi locally depends on itself, then declare deadlock
3.If Pi locally depends on Pj and Pj remotely depends on Pk, then send
probe(i,j,k) to the home node of Pk
4. Upon receiving probe(i,j,k)
• If Pk does not depend on any process then do
nothing
• else if k = i then declare deadlock
• else if Dk(i)= true (has processed this before)
 Possibly Pi depends on Pk on two different
paths
• In this case do nothing
• else if Pk locally depends on Pm and Pm
remotely depends on Pn then send
probe(i,m,n) to home node on Pn
 Deadlock Prevention

 Deadlock Prevention is to use resources in such a way that we

cannot get into deadlocks. In real life we may decide that left
turns are too dangerous, so we only do right turns. It takes
longer to get there but it works. In terms of deadlocks, we may
constrain our use of resources so that we do not have to worry
about deadlocks. Here we explore this idea with two
examples.
 Wait die Vs Wound-wait
WAIT-DIE POLICY WOUND-WAIT POLICY

Wants Holds Wants

resource resource resource
Old Young
Older Young process
process process process

It will wait Preempt

Wants Holds
resource Holds
resource Wants resource
resource
Young Old
process process Young Old
process process
It Dies
It will wait
 Wait-die

 As we have pointed out before, killing a transaction is relatively

harmless, since by definition it can be restarted safely later.

 Wait-die:
 If an old process wants a resource held by a young process,
the old one will wait.
 If a young process wants a resource held by an old process, the
young process will be killed.

 Observation: The young process, after being killed, will then start up
again, and be killed again. This cycle may go on many times before
the old one release the resource.
 Wound-wait

 When a conflict arises, instead of killing the process making the

request, we can kill the resource owner. Without transactions, killing
a process might have severe consequences. With transactions,
these effects will vanish magically when the transaction dies.

 Wound-wait: (we allow preemption & ancestor worship)

 Once we are assuming the existence of transactions, we can do

something that had previously been forbidden: take resources
away from running processes.
 If an old process wants a resource held by a young process, the old
one will preempt the young process -- wounded and killed, restarts
and wait.
 If a young process wants a resource held by an old process, the
young process will wait.
 Conclusion

 Deadlock is the state of permanent blocking of a set of processes

each of which is waiting for an event that only another process in
the set can cause . However, handling of deadlocks in distributed
systems is more complex than in centrallised systems because the
resources,the processes and other relevant information are
scattered on different nodes of the system
 References

 Prentice Hall, 1995 A. Tanenbaum,

“Distributed Operating Systems”
 http://ieeexplore.ieee.org.
 McGraw-Hill Mukesh Singhal, “Advanced
Concepts In Operating Systems “,