INTRODUCTION

What is a deadlock?

Deadlock is defined as the permanent blocking of a set of processes that compete for
system resources, including database records or communication lines. Deadlock prevention, by
design, is the “best” solution. Deadlock occurs when a set of processes are in a wait state,
because each process is waiting for a resource that is held by some other waiting process.

Deadlocks occur when sharing reusable and non-pre-emptible resources.

In other word for 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.

CONDITIONS FOR DEADLOCK

Processes do not run constantly from the time they are created until their termination; they can be
identified in three different states: ready, running and blocked. At the ready state, a process is
stopped, allowing some other process to run; at the running state, a process is utilizing some
resource, and at the blocked state, the process is stopped and will not start running again until
something triggers it to restart.

A common undesirable condition is described as deadlock, which is when two processes are at a
running state, and have acquired some resources, but need to exchange resources to continue.
Both processes are waiting for the other to release a “requested” resource that neither one will
ever do; as a result neither one is making any progress, therefore, reaching a deadlock state.
Many scenarios have been constructed to illustrate deadlock conditions with the most popular
being the Dinning Philosopher’s Problem. In this scenario, five philosophers have five dishes of
spaghetti in front of them and five forks, one on each side of the dish. The philosophers need
both forks (left and right) in order to eat. During their dinner, they perform only two mutually
exclusive operations, think or eat.

Four conditions that must hold for a deadlock to be possible:

• Mutual exclusion: processes require exclusive control of its resources (not sharing).

• Hold and wait: process may wait for a resource while holding others.

• No preemption: process will not give up a resource until it is finished with it. Also,
processes are irreversible: unable to reset to an earlier state where resources not held.

• Circular wait: each process in the chain holds a resource requested by another
 STRATEGIES FOR DEADLOCKS

In general, four strategies are used for dealing with deadlocks:

• Ignore: stick your head in the sand and pretend there is no problem at all.

• Prevent: design a system in such a way that the possibility of deadlock is excluded a
priori (e.g., compile-time/statically, by design)

• Avoid: make a decision dynamically checking whether the request will, if granted,
potentially lead to a deadlock or not (e.g., run-time/dynamically, before it happens)

• Detect: let the deadlock occur and detect when it happens, and take some action to
recover after the fact (e.g., run-time/dynamically, after it happens)

Methods for handling deadlocks are:

 Deadlock prevention
 Deadlock avoidance
 Deadlock detection and recovery

DEADLOCK PREVENTION

Deadlocks are an undesirable system state and their prevention or detection and recovery, if
unavoidable, is necessary. Various methods and approaches exist surprisingly, there are
operating systems that ignore the issue altogether; in those situations, deadlock detection and
recovery becomes the primary focus.

Predicting potential deadlock conditions can be complex, but there are some general conditions
that if true, make deadlocks inevitable. Namely, if all of the following conditions are present:

a. a mutual exclusion condition,

b. no preemption condition,

c. a hold-and-wait condition

d. a circular-wait condition.
The strategy of deadlock prevention is to design a system in such a way that the possibility of
deadlock is excluded a priori. Methods for preventing deadlock are of two classes:

• Indirect methods prevent the occurrence of one of the necessary conditions listed earlier.

• Direct methods prevent the occurrence of a circular wait condition.

Deadlock prevention strategies are very conservative; they solve the problem of deadlock by
limiting access to resources and by imposing restrictions on processes.

For the more “pro -active” operating systems, some solutions have been proposed to provide
some type of deadlock prevention mechanism.

One solution is by exploiting the Coffman conditions that require all be present at the same time
in order to ensure deadlock. Preventing deadlock is then feasible just by isolating and prohibiting
the presence of at least one of these conditions. Neither one in particular can be distinguished as
the optimal selection, so all of them are equally good candidates for isolation and restriction.

Another solution is by forcing processes to “carry” information about the type, amount and order
in which they will utilize resources and only then, with a scheduling algorithm, allow processes
to run ensuring that deadlock possibilities are eliminated. Further, prevention can also be
accomplished by enforcing a strict scheduling algorithm for directing processes on acquiring
resources in a specific order. The advantage of these last two deadlock prevention methods is
almost guaranteed progress, but both bare the disadvantage of tremendous system overhead to
enforce the scheduling algorithms and substantial execution performance inefficiencies.

This can be avoided by prioritizing processes. Processes are assigned priorities upon creation and
when they need a resource occupied by a lower priority process, they just acquire it. Progress is
achieved in this case as well, but continuity and integrity for the lower priority process are
questionable.

MORE ON DEADLOCK PREVENTION

• Mutual exclusion

– In general, this condition cannot be disallowed.

• Hold-and-wait

– The hold and-wait condition can be prevented by requiring that a process request all its
required resources at one time, and blocking the process until all requests can be granted
simultaneously.
• No preemption

– One solution is that if a process holding certain resources is denied a further request, that
process must release its unused resources and request them again, together with the additional
resource.

• Circular Wait

– The circular wait condition can be prevented by defining a linear ordering of resource types
(e.g. Directed Acyclic Graph). If a process has been allocated resources of type R, then it may
subsequently request only those resources of types following R in the ordering.

DEADLOCK AVOIDANCE

Deadlock avoidance, allows the necessary conditions but makes judicious choices to ensure that
a deadlock-free system remains free from deadlock. With deadlock avoidance, a decision is
made dynamically whether the current resource allocation request will, if granted, potentially
lead to a deadlock. Deadlock avoidance thus requires knowledge of future requests for process
resources.

It is very difficult to determine when a system is about to reach a state of deadlock, simply
because it is nearly impossible to predict what process will request which resource before it is
released by another process. Some attempts have been made to model and forecast possible
future system states by using resource trajectories.

Another attempt has been to identify and classify system states into: safe, unsafe and deadlocked.
When the system is at a safe state it means that no deadlock has occurred and the system can still
service all pending process requests. When a system is at an unsafe state, it means that some of
the pending processes will not be serviced, and the danger of reaching a deadlock state is
imminent. Interestingly enough, an unsafe state does not guarantee a deadlock condition in the
immediate future, since the system may never have an offending process request, that could
transform the unsafe state to deadlock

.
 Ways to avoid deadlock by careful resource allocation:

• Resource trajectories.

• Safe/unsafe states.

• Dijkstra’s Banker's algorithm.

DEADLOCK DETECTION

This technique does not attempt to prevent deadlocks; instead, it lets them occur. The system
detects when this happens, and then takes some action to recover after the fact (i.e., is reactive).
With deadlock detection, requested resources are granted to processes whenever possible.
Periodically, the operating system performs an algorithm that allows it to detect the circular wait
condition.

A check for deadlock can be made as frequently as resource request, or less frequently,
depending on how likely it is for a deadlock to occur. Checking at each resource request has two
advantages: It leads to early detection, and the algorithm is relatively simple because it is based
on incremental changes to the state of the system. On the other hand, such frequent checks
consume considerable processor time.

If a system has no deadlock prevention and no deadlock avoidance scheme, then it needs a
deadlock detection scheme with recovery from deadlock capability. For this, information should
be kept on the allocation of resources to processes, and on outstanding allocation requests. Then,
an algorithm is needed which will determine whether the system has entered a deadlock state.
This algorithm must be invoked periodically.

RECOVERING FROM DEADLOCKS

If the system is in a deadlock state, some methods for recovering it from the deadlock state must
be applied. There are various ways for recovery:

 Allocate one resource to several processes, by violating mutual exclusion.

 Preempt some resources from some of the deadlocked processes.
 Abort one or more processes in order to break the deadlock.

Once the deadlock algorithm has successfully detected a deadlock, some strategy is needed for
recovery. There are various ways:

• Recovery through Preemption

In some cases, it may be possible to temporarily take a resource away from its current owner and
give it to another.

• Recovery through Rollback

If it is known that deadlocks are likely, one can arrange to have processes checkpointed
periodically. For example, can undo transactions, thus free locks on database records. This often
requires extra software functionality.

• Recovery through Termination

The most trivial way to break a deadlock is to kill one or more processes. One possibility is to
kill a process in the cycle. Warning! Irrecoverable losses or erroneous results may occur, even if
this is the least advanced process.

If preemption is used:

1. Select a victim. (Which resource(s) is/are to be preempted from which process?)

2. Rollback: If we preempt a resource from a process, roll the process back to some safe
state and mak it continue.

Here the OS may be probably encounter the problem of starvation. How can we guarantee that
resources will not always be preempted from the same process?

In selecting a victim, important parameters are:

 Process priorities
 How long the process has occupied?
 How long will it occupy to finish its job
 How many resources of what type did the process use
 How many more resources does the process need to finish its job?
 How many processes will be rolled back? (More than one victim may be selected.)

For rollback, the simplest solution is a total rollback. A better solution is to roll the victim
process back only as far as it’s necessary to break the deadlock. However, the OS needs to keep
more information about process states to use the second solution.
To avoid starvation, ensure that a process can be picked as a victim for only a small number of
times. So, it is a wise idea to include the number of rollbacks as a parameter.

Deadlock recovering can be performed in a number of ways. A common way is by establishing

priorities, namely, by forcing a process to give up a resource so requesting processes can make
progress. This solution depends on the system complexity and if the selection and re-allocation
of resources is possible. Unfortunately, the problem of continuation re-appears when the process
that forcefully yielded a holding resource, re-acquires it and continues its task as if nothing had
happened. However, by establishing a checkpoint system scheduling, ‘snapshots’ of the system
state at different instances become available, allowing deadlock recovery based on the release of
resources as indicated by a pre-deadlock state ‘snapshot’. It is also feasible to go back to the
different instances and restart the lower priority processes. Usually, recovery begins from an
earlier checkpoint and as a result some progress would be lost. Interestingly enough, if a lower
priority process requests the resource it gave up, it would again enter a wait state. The most
effective way of deadlock recovery is by terminating one of the deadlocked processes. It is a
very severe and ungraceful way for resolving deadlocks requiring some sensible judgment
on what process should be terminated. The termination decision should be dependent on the
nature of the process and the possible losses from its termination. Unfortunately there is no rule
of what constitutes a sensible termination since the number of deadlock processes can be more
than two. Usually, processes that can be re-executed and produce the same result are the best
candidates for termination.

ADVANTAGES OF DEADLOCK

 No preemption is needed for deadlocks.

 It is a good method if the state of the resource can be saved and restored easily.
 It is good for activities that perform a single burst of activity.
 It does not need run-time computations because the problem is solved in system design

DISADVANTAGES OF DEADLOCK

 The processes must know the maximum resource of each type required to execute it.
 Preemptions are frequently encountered.
 It delays the process initiation.
 There are inherent pre-emption losses.
 It does not support incremental request of resources
 TYPES OF DEADLOCK
1. Resource deadlock
2. Communication deadlock

1. RESOURCE DEADLOCK: it occurs when process are trying to get exclusive access to
devices, files, locks, servers, or other resources.
In resource deadlock model, a process waits until it has received all the resources
that it has requested. The resource model is also called the AND MODEL. In this model,
a deadlock occurs if and only if there is a cycle to make progress.

Possible situation: Transaction-processing scenario

2. COMMUNICATION DEADLOCK: Also referred to as communication deadlock

model, occurs when process A is trying to send a message to process B, which is trying to
send a Message to process C which is trying to send a Message to A.

The communication deadlock model is also called OR MODEL. Evidently, it easily

satisfies the circular-wait condition for deadlock to occur.

Possible situation: Message-passing scenario.

CONCLUSION

Deadlocks are an undesirable but intriguing system condition. There are multiple variable
conditions that can lead to deadlocks and as a result make them very complex and difficult to
prevent. Recovering from deadlocks also has its own challenges, particularly because it is
difficult to re-instate the system, to a similar one prior to deadlock, in order to complete
interrupted processing. There are some formalized methods via resource trajectories and state
diagrams, which can to some extent, predict deadlocks. However, completely restricting their
occurrence requires a firmly designed operating system along with very efficient synchronization
algorithms.