CS420: Operating Systems

Deadlocks & 

Deadlock Prevention
YORK COLLEGE OF PENNSYLVAN

MNK
YORK COLLEGE OF PENNSYLVANIA

JHG
'@OK
James Moscola

12
Department of Engineering & Computer Science

York College of Pennsylvania

CS420: Operating Systems Based on Operating System Concepts, 9th Edition by Silberschatz, Galvin, Gagne
 The Deadlock Problem

• Deadlock - A condition that arises when two or more processes are waiting
indefinitely for an event that can only be caused by one of the waiting
processes
- The events that the processes are waiting for will never happen :-(

- Other processes in the system that need the resources that are currently locked
will never get access to them

• Operating systems do not typically provide deadlock-prevention facilities

- It is up to the programmer to design deadlock-free programs

• Deadlock will become an even greater problem with the trend toward more
processor cores and more threads

CS420: Operating Systems 2

 Bridge Crossing Example

• Traffic can only pass bridge in one direction

• Each section of a bridge can be viewed as a resource

• If a deadlock occurs, it can be resolved if one car backs up (preempt resources

and rollback)

• Several cars may have to be backed up if a deadlock occurs

• Starvation is possible

CS420: Operating Systems 3

 Deadlock Characterization

• Deadlock can arise if the four conditions hold simultaneously

- Mutual exclusion - only one process at a time can use a resource

- Hold and wait - a process holding at least one resource is waiting to acquire
additional resources held by other processes

- No preemption of resources - a resource can be released only voluntarily by the

process holding it, after that process has completed its task

- 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

CS420: Operating Systems 4

 Resource-Allocation Graph

• Deadlocks can be described precisely using system resource-allocation graphs

• A resource-allocation graph consists of a set of vertices V and a set of edges E

- V is partitioned into two sets:

• P = {P1, P2, …, Pn}, the set consisting of all the processes in the system

• R = {R1, R2, …, Rm}, the set consisting of all resource types in the system

- There are also two different types of edges:

• Request edge – directed edge Pi → Rj, a process Pi is requesting a resource of

type Rj

• Assignment edge – directed edge Rj → Pi, a resource of type Rj has been

assigned to a process Pi

CS420: Operating Systems 5

 Resource-Allocation Graph (Cont.)

• A process is represented as a circular vertex in the

graph

• A resource type is represented as a square vertex

in the graph
- Because there may be multiple instances of some
resources (i.e. two disks), each instance of a
resource is represented using a dot

• A directed edge from a process Pi to a resource Rj

is a request from Pi for a resource of type Rj

• A directed edge from a resource instance to a

process Pi indicates that the resource has been
allocated to Pi

CS420: Operating Systems 6

 Resource-Allocation Graph (Cont.)

• If the graph contains no cycles, then no

process in the system is deadlocked

• If the graph does contain cycles, then

deadlock may exist, but is not guaranteed to
exist
- If a resource type has exactly one instance
then a cycle implies that a deadlock has
occurred

- If a resource type has several instances, then

a cycle does not necessarily imply that a
deadlock has occurred

CS420: Operating Systems 7

 Resource Allocation Graph With A Deadlock

• Two cycles exist in the graph to the right

- P1 ➔ R1 ➔ P2 ➔ R3 ➔ P3 ➔ R2

- P2 ➔ R3 ➔ P3 ➔ R2 ➔ P2

• Processes P1, P2 and P3 are deadlocked

- P2 is waiting for R3 (held by P3)

- P3 is waiting for R2 (held by P1 and P2)

- P1 is waiting for R1 (held by P2)

CS420: Operating Systems 8

 Graph With a Cycle But No Deadlock

• A cycle exists in the graph to the right

- P1 ➔ R1 ➔ P3 ➔ R2 ➔ P1

• Processes P3 is waiting for resource R2

- P4 should eventually release R2

• Process P1 is waiting for resource R1

- P2 should eventually release R1

CS420: Operating Systems 9

 Resource Allocation Graph Recap

• If graph contains no cycles then no deadlock possible

• If graph contains a cycle then,

- If only one instance per resource type, then deadlock exists

- If several instances per resource type, then deadlock is possible

CS420: Operating Systems 10

 Methods for Handling Deadlocks

• Possible for OS to deal with deadlock in one of three ways:

- Ensure that the system will never enter a deadlock state


- Allow the system to enter a deadlock state and then recover


- Ignore the problem and pretend that deadlocks never occur in the system 

(used by most operating systems, including UNIX)

• Requires that application developers write programs that avoid deadlock

CS420: Operating Systems 11

 Methods for Handling Deadlocks

• To ensure that deadlocks never occur, a system can use either deadlock-
prevention or deadlock-avoidance

• Deadlock Prevention - ensure that at least one of the four necessary

conditions for deadlock cannot hold

• Deadlock Avoidance - requires that the operating system be given

comprehensive information about which resources a process will request
during its lifetime
- Operating system can then make intelligent decisions about when a process
should be allocated a resource

CS420: Operating Systems 12

 Methods for Handling Deadlocks

• If a system does not use either deadlock-prevention or deadlock-avoidance, a

deadlock situation may eventually arise
- Need some way to detect these situations -- deadlock detection

- Need some way to recover from these situations -- deadlock recovery

• If a system does not use deadlock-detection/deadlock-avoidance, and does

not use deadlock-detection/deadlock-recovery, then the system performance
may eventually deteriorate
- Reboot

CS420: Operating Systems 13

 Deadlock Prevention

• For deadlock to occur, each of the four necessary conditions must hold true

• To prevent deadlock, ensure that at least one of these four conditions does not
hold true
(1) Mutual Exclusion

• Not required for sharable resources (i.e. read-only files)

• Must hold true for non-sharable resources :-(

• In general, cannot prevent deadlock by denying the mutual-exclusion

condition because some resources are non-sharable

CS420: Operating Systems 14

 Deadlock Prevention (Cont.)

• For deadlock to occur, each of the four necessary conditions must hold true

• To prevent deadlock, ensure that at least one of these four conditions does not hold
true
(2) Hold-and-wait

• To ensure the hold-and-wait condition never occurs, must guarantee that

whenever a process requests a resource, it does not hold any other resources

- One approach requires a process to request and be allocated all its resources
before it begins execution

• Low resource utilization because resources may allocated but unused for a
long time

• Starvation is possible if at least one of the resources that a process needs is

always allocated to some other process

- Another approach allows a process to request resources only when it has none

CS420: Operating Systems 15

 Deadlock Prevention (Cont.)

• For deadlock to occur, each of the four necessary conditions must hold true

• To prevent deadlock, ensure that at least one of these four conditions does not
hold true
(3) No Preemption of Resources

• To ensure that the no preemption condition never occurs:

- If a process that is holding some resources requests another resource that

cannot be immediately allocated to it, then all resources currently being
held are released

- All preempted resources are added to the list of resources for which the
process is waiting

- A process will be restarted only when it can regain its old resources, as
well as the new ones that it is requesting


CS420: Operating Systems 16

 Deadlock Prevention (Cont.)

• For deadlock to occur, each of the four necessary conditions must hold true

• To prevent deadlock, ensure that at least one of these four conditions does not
hold true
(4) Circular Wait

• To ensure that a circular waiting condition never occurs, impose a total

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

- Each resource type is given an integer value, must request desired

resource in increasing order



LAN Port = 1
 If a process needs both the LAN and the
Disk Drive = 2
 printer, it must request the LAN first, and
Printer = 3 then request the printer

CS420: Operating Systems 17

 Deadlock Avoidance

• Requires that the system has some additional a priori information 


available
- Simplest and most useful model requires that each process declare the
maximum number of resources of each type that it may need

- A 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

CS420: Operating Systems 18

 Safe State

• When a process requests an available resource, system must decide if immediate

allocation leaves the system in a safe state

• In a safe state if the system can allocate resources to each process (up to its
maximum) in some order and still avoid deadlock

• System is in 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 can be
satisfied by currently available resources plus resources held by all the Pj, with j < i

• That is:
- If resources needed by Pi are not immediately available, then Pi can wait until all Pj have
finished

- When Pj is finished, Pi can obtain the resources it needs, execute, return allocated
resources, and terminate

- When Pi terminates, Pi +1 can obtain the resources it needs, and so on

CS420: Operating Systems 19

 Safe, Unsafe, Deadlock State

• If a system is in safe state no deadlocks


• If a system is in unsafe state possibility

of deadlock


• To avoid deadlock, ensure that a system

will never enter an unsafe state

CS420: Operating Systems 20

 Avoidance Algorithms

• Two main avoidance algorithms ... choice depends on how many instances of
available resource types exist
- Single instance of a resource type

• Use a resource-allocation graph

- Multiple instances of a resource type

• Use the Banker’s Algorithm

CS420: Operating Systems 21

 Resource-Allocation Graphs for Deadlock Avoidance

• Introduce a new type of edge to the resource-allocation graph, the claim edge
- A claim edge Pi → Rj indicates that process Pi may request a resource Rj

- A claim edge is represented as dashed lines in resource-allocation graph

- Resources must be claimed a priori in the system, so all claim edges are known

• A claim edge converts to request edge when a process actually requests a

resource

• A request edge is converted to an assignment edge when the resource is

allocated to the process

• When a resource is released by a process, an assignment edge converts back

to a claim edge

CS420: Operating Systems 22

 Resource-Allocation Graph

• In this graph, both processes P1 and P2 may

eventually want to request resource R2
- Claim edges exists, because the system
knows in advance that P1 and P2 may both
want to request R2

• Currently, there are no cycles in the graph so

the system is in a safe state

• If process P2 were to request resource R2 and

be granted that resource then ...

CS420: Operating Systems 23

 Unsafe State In Resource-Allocation Graph

• If process P2 were to request resource R2 and

be granted that resource then a cycle is
formed in the resource-allocation graph

• The system is not yet deadlocked, but is in an

unsafe state

• If process P1 were to request resource R2,

then the system would be in a deadlocked
state

• To prevent an unsafe state and the possibility

of deadlock, P2 should not be allocated
resource R2 when it makes the request, P2
must wait for P1 to release R1 so that no
cycles are created

CS420: Operating Systems 24

 Banker’s Algorithm

• Use for deadlock avoidance when multiple instances of resources exist

• Each process must a priori claim maximum use

• When a process requests a resource it may have to wait

• When a process gets all its resources it must return them in a finite amount of
time

• Banker’s algorithm needs to know three things to work:

- How much of each resource each process could possibly request

- How much of each resource each process is currently holding

- How much of each resource the system currently has available

CS420: Operating Systems 25

 Data Structures for the Banker’s Algorithm

• Let n = number of processes, and m = number of resource types

- Available -- Vector of length m that indicates the number of available resources
of each type. If Available[j] = k, there are k instances of resource type Rj available

- Max -- n x m matrix that defines the maximum demand of each process on each
resource type. If Max[i,j] = k, then process Pi may request at most k instances of
resource type Rj

- Allocation -- n x m matrix that defines the number of resources of each type

currently allocated to each process. If Allocation[i,j] = k then Pi is currently
allocated k instances of Rj

- Need -- n x m matrix that indicates the remaining resource needs of each

process. If Need[i,j] = k, then Pi may need k more instances of Rj to complete its
task

Need [i,j] = Max[i,j] – Allocation[i,j]

CS420: Operating Systems 26

 Banker’s Algorithm -- Safety Procedure

• Used to determine whether or not a system is in a safe state

• Local Data Structures

- Finish -- a vector[1 .. n] , initialize as false for each process Pi

• The procedure to check for a safe state:

(1) Find a process Pi such that Finish[i] = false and Needi ≤ Available




If Pi exists do the following:


Available = Available + Allocationi

Finish[i] = true

Go back to Step #1

(2) If no such process Pi exists





If Finish[i] = true for all processes Pi for i=1 .. n, then the system is in a safe state




Otherwise, processes with a Finish[i] value of false are in an unsafe state and can
potentially deadlock

CS420: Operating Systems 27

 Example of Banker’s Algorithm-Check Safe State

• Consider a system with

- Five processes P0 - P4
- Three resource types, A (10 instance), B (5 instances), and C (7 instances)

• At some time t0, the system looks like the following:




Allocation Max

 Available
A B C A B C A B C
P0 0 1 0 7 5 3
3 3 2
P1 2 0 0 3 2 2
P2 3 0 2 9 0 2
P3 2 1 1 2 2 2
P4 0 0 2 4 3 3
• Is this a safe state?

CS420: Operating Systems 28

 Example of Banker’s Algorithm-Check Safe State (Cont.)

• The n x m matrix Need is defined as

- Need[i,j] = Max[i,j] – Allocation[i,j]

• The sequence <P1, P3, P0, P2, P4> is a safe sequence (there are other safe
sequences as well)

Allocation Max Need Available

A B C A B C A B C A B C
P0 0 1 0 7 5 3 7 4 3 3 3 2
P1 2 0 0 3 2 2 1 2 2
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1

CS420: Operating Systems 29

 Banker’s Algorithm -- Resource-Request

• Used to determine whether requests for resources can be safely granted

• Local Data Structure

- Requesti -- a vector[1 .. m], is a request vector for process Pi , the number of additional resources, of each
type 1..m, that process Pi is requesting

• The procedure to determine if resource can be safely granted

(1) If (Requesti > Needi) then raise an error -- process Pi is trying to get more resources than it initially
declared it would need

(2) If (Requesti > Availablei) then process Pi must wait because there are not currently sufficient resources
available to satisfy the request

(3) Pretend to allocate the requested resources to process Pi


Available = Available - Requesti

Allocationi = Allocationi + Requesti

Needi = Needi - Requesti
(4) Check the safety of the state that would result from step #3

If step#3 produces a safe state, then the resources are allocated for real

If step#3 produces an unsafe state, then don’t allocate the resources to process Pi, the process must wait


CS420: Operating Systems 30

 Example of Banker’s Algorithm - P1 Request

• Since the system is in a safe state, use the Resource Request procedure to
determine if the following request can be granted
- P1 requests one instance of resource A, and two instances of resource C

The request vector looks like --> Request1 = (1, 0, 2)
- First note if the resources are available to fulfill this request: Request1 ≤ Available

Allocation Max Need Available

A B C A B C A B C A B C
P0 0 1 0 7 5 3 7 4 3 3 3 2
P1 2 0 0 3 2 2 1 2 2
P2 3 0 2 9 0 2 6 0 0 (1,0,2) ≤ (3,3,2)

P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1

CS420: Operating Systems 31

 Example of Banker’s Algorithm - P1 Request (Cont.)

• After determining that the resources are actually available, pretend to allocate
them to process P1

• Update the Allocation, Need and Available values

• Check to see if this new state is safe, if yes, then allocate resources for real
Allocation Max Need Available
A B C A B C A B C A B C
P0 0 1 0 7 5 3 7 4 3 3 3 2
P1 2 0 0 3 2 2 1 2 2 2 3 0
P1 3 0 2 3 2 2 0 2 0
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1
• Is this a safe state? The sequence <P1, P3, P4, P0, P2> is a safe sequence
CS420: Operating Systems 32
 Example of Banker’s Algorithm - P1 Request (Cont.)

• What if P4 requests (3, 3, 0) ?
 Request cannot be granted, not

enough resources available

• What if P0 requests (0,2,0) ? Request cannot be granted,

system ends up in an unsafe state

Allocation Max Need Available

A B C A B C A B C A B C
P0 0 1 0 7 5 3 7 4 3 2 3 0
P1 3 0 2 3 2 2 0 2 0
P2 3 0 2 9 0 2 6 0 0
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1

CS420: Operating Systems 33

 Deadlock Detection

• In systems that don’t use deadlock-prevention or deadlock-avoidance,

deadlock may occur

• Such a system may provide:

- A deadlock detection algorithm that determines if a deadlock has occurred in the
system

- A deadlock recovery algorithm to recover from deadlock if it has occurred

• As with deadlock avoidance, systems with multiple instances of a single

resource type must be considered differently than systems with only single
instance resources

CS420: Operating Systems 34

 Single Instance of Each Resource Type

• If all resources have only a single instance, use a wait-for graph for deadlock
detection
- All Nodes are processes

- An edge Pi → Pj exists if Pi is waiting for Pj to release a resource

• Deadlock exists in the system if and only if the wait-for graph contains a cycle

• 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 n2 operations,

where n is the number of vertices in the graph

CS420: Operating Systems 35

 Resource-Allocation Graph and Wait-for Graph

Resource-Allocation Graph Corresponding wait-for graph

CS420: Operating Systems 36

 Several Instances of a Resource Type

• The wait-for graph cannot be used in systems with multiple instances of each
resource type

• The deadlock detection algorithm for several instance contains similar data
structures to the Banker’s Algorithm

• Let n = number of processes, and m = number of resource types

- Available -- Vector of length m that indicates the number of available resource of
each type. If available [j] = k, there are k instances of resource type Rj available

- Allocation -- n x m matrix that defines the number of resources of each type

currently allocated to each process. If Allocation[i,j] = k then Pi is currently allocated
k instances of Rj

- Request -- n x m matrix that indicates the current request of each process. If

Request[i,j] = k then process Pi is requesting k more instances of resource type Rj


CS420: Operating Systems 37

 Deadlock Detection Algorithm

• Used to determine whether or not a system is in a deadlocked state (very

similar to Banker’s Algorithm safety procedure)

• Local Data Structures

- Finish -- a vector[1 .. n] , initialize as false for each process Pi where 

Allocationi ≠ 0, true otherwise

• The procedure to check for a deadlocked state:

(1) Find a process Pi such that Finish[i] = false and Requesti ≤ Available




If Pi exists do the following:


Available = Available + Allocationi

Finish[i] = true

Go back to Step #1

(2) If no such process Pi exists





If Finish[i] = false for a processes Pi for i=1 .. n, then Pi is in a deadlocked state

CS420: Operating Systems 38

 Example of Deadlock Detection Algorithm

• Consider a system with

- Five processes P0 - P4
- Three resource types, A (7 instance), B (2 instances), and C (6 instances)

• At some time T0, the system looks like the following:





 Allocation Request
A B C A B C Available
P0 0 1 0 0 0 0 A B C
0 0 0
P1 2 0 0 2 0 2
P2 3 0 3 0 0 0
P3 2 1 1 1 0 0
P4 0 0 2 0 0 2
• Is the system deadlocked? The sequence <P0, P2, P3, P1, P4> will
result in Finish[i] = true for all processes

CS420: Operating Systems 39

 Example of Deadlock Detection Algorithm (Cont.)

• Continuing the previous example, suppose that process P2 now requests one
additional resource of type C

• At some time T0, the system looks like the following:





 Allocation Request
A B C A B C Available
P0 0 1 0 0 0 0 A B C
0 0 0
P1 2 0 0 2 0 2
P2 3 0 3 0 0 1
P3 2 1 1 1 0 0 Can only reclaim resources held by
P0. Insufficient resources to handle
P4 0 0 2 0 0 2
the requests from other processes.
• Is the system deadlocked? Deadlock exists consisting of
processes P1, P2, P3, and P4

CS420: Operating Systems 40

 Deadlock Detection Algorithm Usage

• When, and how often, to invoke the detection algorithm depends on:
- How often a deadlock is likely to occur?

- How many processes will need to be rolled back?

• If the detection algorithm is invoked every time a request for allocation cannot be
granted:
- The algorithm can detect specifically which processes caused the deadlock

- There is a lot of computational overhead when running the algorithm so frequently

• If the detection algorithm is invoked less frequently (e.g. once per hour):
- It is difficult to determine which processes caused the deadlock

- The computational overhead can be reduced

CS420: Operating Systems 41

 Deadlock Recovery

• Once deadlock has been detected in a system there are several options for
dealing with deadlock
- Notify the system user and let them deal with it

- Have the system terminate one or more processes

- Have the system preempt resources from one or more of the deadlocked
processes

CS420: Operating Systems 42

 Deadlock Recovery: Process Termination

• When terminating processes to recover from deadlock, resources are

reclaimed from any terminated process
- Terminating a process means that work done by that process may be lost

• Two options:
- Abort all deadlocked processes

• Potential to lose a lot of work / computation time

- Abort one process at a time until the deadlock cycle is eliminated

• Lots of overhead since the deadlock-detection algorithm must be run after

each process is terminated


CS420: Operating Systems 43

 Deadlock Recovery: Process Termination (Cont.)

• If terminating processes, in what order should processes be terminated?

• Consider:
- Priority of the process

- How long process has computed, and how much longer to completion

- Resources the process has used

- Resources process needs to complete

- How many processes will need to be terminated

- Is process interactive or batch?

CS420: Operating Systems 44

 Deadlock Recovery: Resource Preemption

• Continually preempt the resources from processes and give those resources to
other processes until the system is no longer deadlocked

• Must consider the following:

- How should victims be selected? And how can cost be minimized?

- How should a preempted process get rolled back?

• Would like to return the process to some safe state without having to
completely restart the process. To do so requires some fancy bookkeeping
by the system to know where the most recent safe state was prior to the
deadlock.

- How to ensure that starvation does not occur?

• Don’t want resources to always get preempted from the same process

CS420: Operating Systems 45