Chapter 8: Deadlocks

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018
 Chapter 8: Deadlocks
 System Model
 Deadlock in Multithreaded Applications
 Deadlock Characterization
 Methods for Handling Deadlocks
 Deadlock Prevention
 Deadlock Avoidance
 Deadlock Detection
 Recovery from Deadlock

Operating System Concepts – 10th Edition 8.2 Silberschatz, Galvin and Gagne ©2018
 Chapter Objectives

 Illustrate how deadlock can occur when mutex locks are used
 Define the four necessary conditions that characterize deadlock
 Identify a deadlock situation in a resource allocation graph
 Evaluate the four different approaches for preventing deadlocks
 Apply the banker’s algorithm for deadlock avoidance
 Apply the deadlock detection algorithm
 Evaluate approaches for recovering from deadlock

Operating System Concepts – 10th Edition 8.3 Silberschatz, Galvin and Gagne ©2018
 Background
 In a multiprogramming/multithreading environment,
 Several threads may compete for a finite number of resources
 A thread requests resources:
 If the resources are not available at that time, the thread enters a
waiting state.
 Sometimes, a waiting thread can never again change state, because the
resources it has requested are held by other waiting threads
 This situation is called a deadlock.
 Deadlock is a situation in which every process in a set of processes is waiting
for an event that can be caused only by another process in the set, all of which
are waiting
 Perhaps the best illustration of a deadlock can be drawn from a law passed by
the Kansas legislature early in the 20th century. It said, in part:
 “When two trains approach each other at a crossing, both shall come to a full
stop and neither shall start up again until the other has gone.” 

Operating System Concepts – 10th Edition 8.4 Silberschatz, Galvin and Gagne ©2018
 Deadlock in Multithreaded Application
 Two mutex locks are created an initialized:

 Note: If a thread attempts to acquire a locked mutex, the call to:

 Pthread_mutex_lock()

blocks the thread until the owner of the mutex lock invokes the

pthread_mutex_unlock()

Operating System Concepts – 10th Edition 8.5 Silberschatz, Galvin and Gagne ©2018
 Deadlock in Multithreaded Application
 Note that, even though deadlock is possible,
 it will not occur if thread_one can acquire and release the mutex locks for
first mutex and second mutex before thread_two attempts to acquire the
locks.
 And, of course, the order in which the threads run depends on how they are
scheduled by the CPU scheduler.
 This example illustrates a problem with handling deadlocks:
 it is difficult to identify and test for deadlocks that may occur only under
certain scheduling circumstances

Operating System Concepts – 10th Edition 8.6 Silberschatz, Galvin and Gagne ©2018
 Deadlock Characterization
Deadlock can arise if four conditions hold simultaneously.
1. Mutual exclusion:
 Only one process at a time can use a resource
2. Hold and wait:
 A process holding at least one resource is waiting to acquire additional resources held
by other processes

3. No preemption:
 A resource can be released only voluntarily by the process holding it, after that
process has completed its task

4. Circular wait:
 There exists a set {P0, P1, …, Pn} of waiting processes such that P0 is waiting for a
resource that is held by P1,
 P1 is waiting for a resource that is held by P2, …,
 Pn–1 is waiting for a resource that is held by Pn,
 and Pn is waiting for a resource that is held by P0.
Operating System Concepts – 10th Edition 8.7 Silberschatz, Galvin and Gagne ©2018
 Methods for Handling
Deadlocks

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018
 Methods for Handling Deadlocks
 Generally speaking, we can deal with the deadlock problem in one of three ways:
1. Ignore the problem and pretend that deadlocks never occur in the system

2. Use a protocol to prevent or avoid deadlocks, ensuring that the system will
never enter a deadlocked state
 Deadlock Prevention
– Ensure that at least one of the necessary conditions cannot hold
» (Mutual Exclusion, Hold and Wait, No Preemption, and Circular Wait)
 Deadlock Avoidance
– OS need to be given additional information in advance concerning which
resources a thread will request and use during its lifetime, then the OS can
decide for each request whether or not the thread should wait
– For each thread need to know: Available vs. Allocated resources, and what
are the future requests and releases

3. Allow the system to enter a deadlock state and then

 If neither a deadlock-prevention nor a deadlock-avoidance is
implemented, then a deadlock situation may arise
 Thus, we must be able to Detect it, and Recover from it
Operating System Concepts – 10th Edition 8.9 Silberschatz, Galvin and Gagne ©2018
 1. Deadlock Prevention
Simply, Invalidate one of the four necessary conditions for deadlock:
1. Mutual Exclusion – We cannot prevent deadlocks by denying the mutual-
exclusion condition
 not required for sharable resources (e.g., read-only files);
 must hold for non-sharable resources (e.g. a mutex lock cannot be simultaneously
shared by several threads)

2. Hold and Wait – We need to: “ensure that the hold-and-wait condition never
occurs in the system”
 must guarantee that whenever a process requests a resource, it does not hold any
other resources
 Approach #1: require process to request and be allocated all its resources before
it begins execution,
– Cons: impractical for most applications and if applied Low resource utilization

 Approach #2: allows a thread to request resources only when it has none
allocated to it.
– Cons: may lead to starvation, wait indefinitely
» If the needed R is always allocated to some other thread

Operating System Concepts – 10th Edition 8.10 Silberschatz, Galvin and Gagne ©2018
 1. Deadlock Prevention (Cont.)
3. No Preemption – of resources that have already been allocated, to prevent
deadlock, we need to ensure that this condition does not hold:
 If a process is holding some resources and requests another that cannot be
immediately allocated to it, then all resources currently being held are released
(preempted)
 Preempted resources are added to the list of resources for which the process is
waiting for
 Process will be restarted only when it can regain its old resources as well as the new
ones that it is requesting

 All three above options are almost impractical in most situations

4. Circular Wait – preventing it is a practical solution 

 imposing a total ordering of all resource types, and require that each process
requests resources in an increasing order of enumeration

Operating System Concepts – 10th Edition 8.11 Silberschatz, Galvin and Gagne ©2018
 1. Deadlock Prevention (Cont.)
 Deadlock-prevention algorithms prevent deadlocks by limiting how
requests & releases can be made.

 Pros: The limits ensure that at least one of the necessary conditions for
deadlock cannot occur

 Cons: Possible side effects of preventing deadlocks by this method,

 low device utilization and
 reduced system throughput

Operating System Concepts – 10th Edition 8.12 Silberschatz, Galvin and Gagne ©2018
 2. Deadlock Avoidance
• Deadlock-prevention algorithms Prevent deadlocks by limiting how requests can be
made. The limits ensure that at least one of the necessary conditions for deadlock cannot
occur. Possible side effects of preventing deadlocks by this method, however, are low
device utilization and reduced system throughput.
• An alternative method for avoiding deadlocks is to require additional information about
how resources are to be requested

1. Safe State
2. Resource-Allocation-Graph Algorithm
3. Banker’s Algorithm

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018
 2. Deadlock Avoidance
Requires that the system has some additional a priori information available,
(require additional information about how resources are to be requested)

 Simplest and most useful model requires that

 each process declare the maximum number of resources of each
type that it may need

 The deadlock-avoidance algorithm

 dynamically examines the resource-allocation state to ensure that
there can never be a circular-wait condition

 Resource-allocation state is defined by

 the number of available and allocated resources, and
 the maximum demands of the processes

Operating System Concepts – 10th Edition 8.14 Silberschatz, Galvin and Gagne ©2018
 2.1. Safe State
 When a process requests an available resource, system must decide if immediate
allocation leaves/keeps the system in a safe state

 A state is safe if the system can allocate resources to each thread/process (up to
its maximum) in some order and still avoid a deadlock.

 System is in a safe state if there exists a sequence <P1, P2, …, Pn> of ALL
the processes in the systems such that:
 for each Pi, the resources that Pi can still request to be satisfied by
currently available resources + resources held by all the Pj, with j < i

 That is:
 If Pi resource needs are not immediately available, then Pi can wait until all
Pj have finished
 When Pj is finished, Pi can obtain needed resources, execute, return
allocated resources, and terminate
 When Pi terminates, then Pi+1 can obtain its needed resources, and so on

Operating System Concepts – 10th Edition 8.15 Silberschatz, Galvin and Gagne ©2018
 Safe State Example
 Consider a system with:
 12 resources and
 3 threads/processes: T0, T1, and T2.
 Assume: T0 requires 10 resources, thread T1 may need as many as 4, and thread T2
may need up to 9 resources.
 Suppose that, at time t0, thread T0 is holding 5 resources, thread T1 is holding 2
resources, and thread T2 is holding 2 resources. (Thus, there are 3 free resources.)
 At time t0, the system is in a safe state. The sequence <T1, T0, T2> satisfies the
safety condition
 T1 can immediately be allocated all its resources and then return them (the system will
then have 5 available resources); then T0 can get all its resources and return them (the
system will then have 10 available resources); and finally T2 can get all its resources
and return them (the system will then have all 12 resources available).
 A system can go from a safe state to an unsafe state. Suppose that, at time t1, the T2
requests and is allocated 1 more resource.
 Then only T1 can be allocated all its resources. When it returns them, the system will
have only 4 available resources. Since T0 is allocated 5 resources but has a maximum
of 10, it may request 5 more resources. If it does so, it will have to wait, because they
are unavailable.
Operating System Concepts – 10th Edition 8.16 Silberschatz, Galvin and Gagne ©2018
 Basic Facts
 If a system is in safe state  no deadlocks

 If a system is in unsafe state  possibility of deadlock

 Avoidance  ensure that a system will

never enter an unsafe state. (how ?)

 Safe, Unsafe, Deadlock State

 A safe state is not a deadlocked state.
 Equally, a deadlocked state is an unsafe state. Safe, Unsafe, Deadlock State
 Not all unsafe states are deadlocks

 As long as the state is safe, the operating system can avoid unsafe (and
deadlocked) states

Operating System Concepts – 10th Edition 8.17 Silberschatz, Galvin and Gagne ©2018
 Avoidance Algorithms
 Single instance of a resource type
 Use a resource-allocation graph

 Multiple instances of a resource type

 Use the Banker’s Algorithm

Operating System Concepts – 10th Edition 8.18 Silberschatz, Galvin and Gagne ©2018
 1. Resource-Allocation Graph Scheme
 introduce a new type of edge, called Claim edge Pi --- Rj indicated that

process Pi may request resource Rj; represented by a dashed line (-----)

 Claim Edge converts to Request Edge when a process requests a resource

 Request Edge converted to an Assignment Edge when the resource is
allocated to the process
 When a resource is released by a process, assignment edge reconverts back
to a Claim Edge Request Edge

 Resources must be claimed a priori in the system

Assignment Edge
<T1,T2>: safe
<T2,T1>: unsafe
Claim Edge

Operating System Concepts – 10th Edition 8.19 Silberschatz, Galvin and Gagne ©2018
 1. Resource-Allocation Graph Algorithm
 Suppose that process Pi requests a resource Rj

 The request can be granted only

 if converting the request edge to an assignment edge does not
result in the formation of a cycle in the resource allocation graph
• Suppose that T2 requests R2. Although R2
is currently free, we cannot allocate it to
T2, since this action will create a cycle in
the graph.
• Figure shows a cycle indicates that the 1
system is in an unsafe state.
• If T1 requests R2, and T2 requests R1, then
a deadlock will occur.
2

<T1,T2>: safe
<T2,T1>: unsafe Unsafe State In
Resource-Allocation Graph
Operating System Concepts – 10th Edition 8.20 Silberschatz, Galvin and Gagne ©2018
 2. Banker’s Algorithm
 The resource-allocation-graph algorithm is not applicable to a resource allocation
system with multiple instances of each resource type.
 However, this Banker’s Algorithm is applicable to such a system but is less efficient
than the resource-allocation graph scheme.
 used in a banking system to ensure that the bank never allocated its available cash in
such a way that it could no longer satisfy the needs of all its customers

 Banker’s Algorithm
 Determines whether the allocation of resources keeps it in a safe state
 Handles Multiple instances of resources
 Each process must a priori claim maximum use (# of resources)
 it must declare the maximum number of instances of each resource type that it may need
 number may not exceed the total number of resources in the system
 When a process requests a resource it may have to wait
 until some other thread releases enough resources
 When a process gets all its resources it must return resources in a
finite amount of time
Operating System Concepts – 10th Edition 8.21 Silberschatz, Galvin and Gagne ©2018
 Data Structures for the Banker’s Algorithm
Let n = number of processes/threads in the system, and
m = number of resources types.

 Available: Vector of length m, number of available resources of each type

 If available[j]==k, there are k instances available of resource type Rj
 Max: An n x m matrix, maximum demand of each thread
 If Max[i,j]==k, then process Pi may request at most k instances of
resource type Rj

 Allocation: An n x m matrix. # resources of each type currently allocated to

each thread
 If Allocation[i,j]==k, then Pi is currently allocated k instances of Rj

 Need: An n x m matrix. # of remaining resource need of each thread

 If Need[i,j]==k, then Pi may need k more instances of Rj to complete its
task
 Note that: Need[i,j] = Max[i,j] – Allocation [i,j]
Operating System Concepts – 10th Edition 8.22 Silberschatz, Galvin and Gagne ©2018
 Safety Algorithm
1. Let Work and Finish be vectors of length m and n, respectively. Initialize:
Work = Available
Finish[i] = false; #for i = 0, 1, …, n-1
 Initially, no process has finished and the number of available resources is
represented by the Available array.
2. Find an index i such that both:
(a) Finish[i] == false and (b) Needi  Work : need for the Pi
If no such i exists, go to step 4
 Find an unfinished process whose need can be satisfied by the available resources. If
no such process exists, just go to step 4.

3. Work = Work + Allocationi

Finish[i] = true
go to step 2
 When an unfinished process is found, then the resources are allocated and the
process is marked finished. Then, the loop is repeated to check all other processes.
4. If Finish[i] == true for all i, then the system is in a safe state
 Note: this algorithm may require an order of m × n2 operations to determine whether a
state is safe.

Operating System Concepts – 10th Edition 8.23 Silberschatz, Galvin and Gagne ©2018
 Resource-Request Algorithm for Process Pi
 Describe the algorithm for determining whether requests can be safely
granted.
Requesti is request vector for process Pi. If Requesti [j] == k then
process Pi wants k instances of resource type Rj
1. If Requesti  Needi go to step 2. Otherwise, raise error condition, since
process has exceeded its maximum claim
2. If Requesti  Available, go to step 3. Otherwise Pi must wait, since
resources are not available
3. Pretend to allocate requested resources to Pi by modifying the state as
follows (what will be the system state if):
Available = Available – Requesti;
Allocationi = Allocationi + Requesti;
Needi = Needi – Requesti;

 If the resulting resource-allocation state is safe complete the allocation to Pi

 If new state is unsafe  Pi must wait, and the old resource-allocation state is
Operating System Concepts – 10th Edition 8.24 Silberschatz, Galvin and Gagne ©2018
 Example of Banker’s Algorithm
 Consider a system with 5 processes/threads P0 through P4; and
 3 resource types A, B, and C:
 Type A (10 instances),
 Type B (5 instances), and
 Type C (7 instances)
 Snapshot at time t0:
Allocation Max Available
ABC ABC ABC
P0 0 1 0 753 332
P1 2 0 0 322
P2 3 0 2 902
P3 2 1 1 222
P4 0 0 2 433

Operating System Concepts – 10th Edition 8.25 Silberschatz, Galvin and Gagne ©2018
 Deadlock Detection
• Single Instance of Each Resource Type
• Several Instances of a Resource Type
• Detection-Algorithm Usage

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018
 Deadlock Detection
 If a system does not employ either a:
 deadlock-prevention or a
 deadlock-avoidance algorithm,
 Then a deadlock situation may occur

 Allow system to enter deadlock state. Thus, the environment provide:

 Detection Algorithm
 An algorithm that examines the state of the system to determine
whether a deadlock has occurred

 Recovery Scheme
 An algorithm to recover from the deadlock

Operating System Concepts – 10th Edition 8.27 Silberschatz, Galvin and Gagne ©2018
 Single Instance of Each Resource Type

 Maintain wait-for graph

 Obtain this graph from the resource-allocation graph by removing the
resource nodes and collapsing the appropriate edges
 Nodes are processes
 Pi  Pj if Pi is waiting for Pj

 Periodically invoke an algorithm that searches for a cycle in the graph.

 If there is a cycle, there exists a deadlock

 An algorithm to detect a cycle in a graph requires an order of O(n2)

operations, where n is the number of vertices in the graph (# of processes
and/or threads)

Operating System Concepts – 10th Edition 8.28 Silberschatz, Galvin and Gagne ©2018
 Resource-Allocation Graph and Wait-for Graph

Resource-Allocation Graph Corresponding wait-for graph

As before, a deadlock exists in the system iff the wait-for graph

contains a cycle.

Operating System Concepts – 10th Edition 8.29 Silberschatz, Galvin and Gagne ©2018
 Detection-Algorithm Usage
 When, and how often, to invoke depends on:
 How often a deadlock is likely to occur?
 How many processes will need to be rolled back?
 one for each disjoint cycle

 If detection algorithm is invoked arbitrarily,

 there may be many cycles in the resource graph and
 so we would not be able to tell which of the many deadlocked processes
“caused” the deadlock.
 Note: Deadlocks occur only when some thread/processes makes a request that
cannot be granted immediately.
 This request may be the final request that completes a chain of waiting
threads. In the extreme, then, we can invoke the deadlock detection algorithm
every time a request for allocation cannot be granted immediately.
 In this case, we can identify not only the deadlocked set of threads but also the
specific thread that “caused” the deadlock. (incur considerable overhead)

Operating System Concepts – 10th Edition 8.30 Silberschatz, Galvin and Gagne ©2018
 Recovery from Deadlock
• Process and Thread Termination
• Resource Preemption

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018
 Recovery from Deadlock: Process Termination

 There are two options for breaking a deadlock:

 Abort all deadlocked processes
 Abort one process at a time until the deadlock cycle is eliminated

 In which order should we choose to abort?

1. Priority of the process
2. How long process has computed, and how much longer to completion
3. Resources the process has used
4. Resources process needs to complete
5. How many processes will need to be terminated
6. Is process interactive or batch?

Operating System Concepts – 10th Edition 8.32 Silberschatz, Galvin and Gagne ©2018
 Recovery from Deadlock: Resource Preemption

 Selecting a victim – minimize cost

 Rollback – If we preempt a resource from a process, what should be

done with that process? return to some safe state, restart process for
that state.
 Since, in general, it is difficult to determine what a safe state is, the simplest
solution is a total rollback: abort the process and then restart it.

 Starvation – How do we ensure that starvation will not occur? same

process may always be picked as victim, include number of rollback in
cost factor

Operating System Concepts – 10th Edition 8.33 Silberschatz, Galvin and Gagne ©2018