Deadlocks

Ankur Gupta
Agenda

 Introduction to Deadlocks
 Necessary Conditions for Deadlocks
 Types of Resources
 Deadlock modeling
 Deadlock prevention
 Deadlock avoidance
 Deadlock detection and recovery
Deadlocks

 A condition where two or more processes

cannot proceed with execution, as the
resources they require are being held by other
processes.
 Deadlocks can occur on both hardware and
software resources, in a multiprogramming
environment
Necessary Conditions for Deadlocks

Coffman (1971) proved that four conditions need to exist for Deadlocks to
occur

 Mutual Exclusion – shared resources can be used by at most one

process at a time, which grants it exclusive rights to that resource,
leading to deadlocks
 Hold and Wait – each process acquires some resources and continues
to wait to acquire the rest of the resources, without giving up the
acquired ones.
 No preemption of resources – once granted resources can only be
voluntarily released by the process, the OS cannot forcibly take away
the resources
 Circular waiting – processes may be involved in a circular chain, where
each process holds one or more resources being requested by the next
process in the chain.
Types of resources

 Preemptable resources
resources which are shared, but can be taken away
from the process
– Primary memory
– CPU
 Nonpreemtable resources
resources which cannot be taken away from
processes
– Process shared data
– CD writer
– Printer

Deadlocks generally involve Nonpreemptable resources.

Deadlock modeling

 Can be modeled by means of a directed

graph
P2
Resource Resource

requesting
R2 Deadlock R1
holding

Process Process P1
Resource Allocation
Graphs
Deadlock modeling

 So, by dynamically constructing resource

allocation graphs and by examining the state
of the graph before allocating a resource to a
process (whether it leads to a cycle in the
graph) we can avoid deadlocks.

 Question : How can I detect cycles in a

directed graph? Come up with an algorithm.
Deadlock prevention
Negate any of the four necessary conditions for
deadlock

 Mutual Exclusion : don’t allow a process exclusive access to a resource,

but that would cause corruption of shared resources. Negating this
condition is not feasible, so try negating the other conditions
 Hold and Wait :
– require processes to release all held resources, if the additional
resources it is requesting for are not available. So, waiting
processes cannot keep holding resources indefinitely. This is
sometimes not practical, as asking a process to release its
resources in the middle of a critical operation can be catastrophic.
– Alternatively, require each process to acquire all needed resources
before beginning execution. But, it is very difficult for processes to
estimate the exact requirement of resources. So, processes could
overestimate the resources they need, thereby depriving other
processes. So, optimum resource utilization may not be there.
Deadlock prevention

• No-preemption
• Allow the OS to take away resources from blocked processes
allowing some other process to acquire the released resource
and begin execution
• Not applicable to all type of resources. For instance,
preempting a partially updated file, will result in corruption. So,
this has limited applicability
• Circular Waiting
• Linear ordering of resources into classes. A process can only
acquire a class of resources in an atomic operation and that
too in a strictly increasing order.
• Problem here is that the whole class of resources is claimed in
advance although some of the resources may not be required
or may be needed only for a short period of time. This lowers
the degree of concurrency as these resources cannot be
allocated to other processes.
Deadlock Prevention

 Hence, there is no perfect solution for

preventing the occurrence of deadlocks.
 Moreover, some of the solutions discussed in
previous slides are not practical to
implement in real systems. Negating the four
conditions is too much work and not worth it.
So, lets look at deadlock avoidance as an
alternative
Deadlock avoidance

 Grant those resources to requesting processes

which are safe and do not result in deadlocks
 The resource allocator examines the possibility of a
granted resource causing a potential deadlock
 Otherwise the requesting process is blocked or
suspended till it is safe to grant the requested
resources.
 By avoiding such resource granting operations
deadlocks can be avoided altogether.
Deadlock avoidance (Contd….)
 Deadlock avoidance algorithms require that each process
knows the amount of resources it requires in advance. Once
execution begins a process can request resources
incrementally up to its pre-claimed limit as long as they are
grantable by the system – the stated requirements should not
exceed the total resource capacity of the system
 These algorithms are based on the concept ofsafe states – a
state represents the condition of the system after allocation of
requested resources. A safe state implies that granting the
requested resources to a process will not lead to deadlocks i.e
there exist scheduling decisions which will allow all processes
to complete their execution. Hence, any resource allocation
which is unsafe needs to be denied.
Deadlock avoidance (Contd….)

Currently Assigned Resources Resources still needed

A 3 0 1 1 A 1 1 0 0
B 0 1 0 0 B 0 1 1 2
C 1 1 1 0 C 3 1 0 0
D 1 1 0 1 D 0 0 1 0
E 0 0 0 0 E 2 1 1 0

X = (6342) P = (5322) A = (1020)

X – total resource, P – currently used, A - available
Deadlock avoidance (Contd….)

 The obvious shortcoming of this algorithm is

that the processes cannot estimate
accurately what their processing
requirements will be in future. Also, the no. of
processes in a multiprogramming
environment is not fixed, but varies
dynamically.
Deadlock detection

 Trying to prevent or avoid deadlocks involves

a lot of processing overheads and impacts
the overall performance of the system.
Instead, why not allocate resources to
requesting processes freely and check once
in a while if a deadlock has occurred. If it has
then recover from it by reclaiming the
resources on which processes are blocked
and continue execution as before.
Deadlock detection (Contd….)

 Given a set of processes and resources, we

can construct a resource allocation graph
and visually inspect it for cycles. If a cycle
exists, it indicates the presence of a
deadlock. But, this is not usable in actual
systems
Deadlock detection (Contd….)
 We use a matrix-based algorithm for deadlock detection
when there are multiple resources of each type – say 6
printers, 5 disks, 4 CPUs etc. ( almost same algo which we
used in Deadlock avoidance, except that in this case we
mark the process which completes its execution on being
granted the requested resources. When the algo
terminates, all unmarked processes are deadlocked.)
 The frequency of running the deadlock detection algo is a
system design parameter – we could run it whenever a
resource is requested or after fixed time intervals or when
one or more processes are blocked for a long enough
time.
 However, just detection is no good. We need to recover
from deadlocks
Deadlock Recovery Strategies
 Preemption – not suitable for Nonpreemptable
resources
 Rollback – processes are checkpointed/committed
periodically, which records the run time state of the
system in terms of the quantum of work
accomplished. These checkpoint files contain the
memory image of the process and the resources it
had acquired at that stage So, a series of checkpoint
files are created for a process during its lifetime.
When a deadlock is detected a rollback operation
restores the state of the process to the last
checkpointed state. So, some amount of work done
is lost. These operations are most common in
database applications.
Deadlock Recovery

 Killing deadlocked processes – simplest way to get

rid of deadlocks. Kill one of the processes in a cycle
and hope that the resources that it releases, will
allow others to complete execution. Keep killing
processes until the deadlock is broken. The issue
here is the choice of the process to kill. Killing for
instance, a compilation process is alright, since
there is no difference between the first run and the
second. However, killing a database update
application and running it a second time may corrupt
the database.
What did we learn?

 Deadlocks can and will occur.

 It is too expensive and inefficient to try and prevent or
avoid deadlocks. Also automatically detecting deadlocks
is not too practical.
 Only the users of the system can realize if a deadlock has
occurred.
 There is no specific testing done for finding deadlocks in
commercial software systems. We only do performance
and stress testing and long-term testing
 The easiest way to recover from deadlocks is to restart
the software/hardware. Such an operation if done in 1 or
2 months of operation is more or less acceptable for
commercial software systems.
THANK YOU !!