Chapter 8

Deadlocks
Edited by
Ghada Mohammed S AlOsaimi
CS Lecturer, CCIS, IMSIU
Outline
 System Model
 Deadlock in Multithreaded Applications
 Deadlock Characterization
 Methods for Handling Deadlocks
 Deadlock Prevention
 Deadlock Avoidance Process
Management

 Deadlock Detection
 Recovery from Deadlock
Protection and Memory
Security Introduction Management
and Overview

Storage
Management

2
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

3
Deadlock

 In multicore system or multiprogramming environment, several threads or processes request several resources

 If resources are not available at that time, thread or process enter waiting state

 If waiting process or thread is not changing its state because the resources are held or occupied by other waiting
threads or processes

 This situation is called deadlock

 Deadlock is an example of liveness failure

 Deadlock definition is every process in a set of processes is waiting for

an event that can be caused only by another process in the set

4
System Model

 System consists of a limited number of resources that are distributed among different thread and processes
 These resourses are classified in several types
 Resource types R1, R2, . . ., Rm
 CPU cycles, memory space, IO devices, ..etc.
 Each resource type (Ri) is consisting of some number of identical instances (Wi)
 For example, if a system has four CPUs, then the resource type CPU has four instances
 Each resource type Ri has Wi instances
 Each process or thread utilizes a resource in 3 steps as follows:
 Request – process or thread requests the resource
 If the request cannot be granted immediately (for example, if a mutex lock is currently held by another thread),
then the requesting thread must wait until it can acquire the resource
 Use – process or thread can operate on the resource (for example, if the resource is a mutex lock, the thread can
access its critical section)
5
 Release – process or thread releases the resource
Deadlock Characterization

 Deadlock can arise if four conditions hold simultaneously:

1 | Mutual exclusion
 Only one process at a time can use a resource
 At least one resource must be held in a non-sharable mode
 If another process requests that resource, the requesting process must be delayed until the resource has been
released
2 | Hold and wait
 A process holding at least one resource is waiting to acquire additional resources held by other processes
3 | No preemption
 Resources cannot be preempted
 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
6
waiting for a resource that is held by P0
Resource-Allocation Graph

 Deadlocks can be described more precisely in terms of a directed graph called a system resource-allocation graph
 A set of vertices V and a set of edges E
 V is partitioned into two types:
 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
 Request edge – directed edge Pi → Rj
 Assignment edge – directed edge Rj → Pi
 Example:
 Graph has four resource types R1, R2, R3 and R4
 Number of instances: One instance of R1, Two instances of R2, One instance of R3 and Three instance of R4
 Process T1: holds one instance of R2 and is waiting for an instance of R1
 Process T2: holds one instance of R1, one instance of R2, and is waiting for an instance of R3
7
 Process T3: holds one instance of R3
Resource-Allocation Graph (cont.)

 If graph contains no cycles ⇒ no deadlock state

 If graph contains a cycle ⇒ the system may or may not be in a deadlocked state
 If only one instance per resource type, then deadlock
 If several instances per resource type, possibility of deadlock

Resource allocation graph with a deadlock Graph with a cycle but no deadlock

8
Methods for Handling Deadlocks

 We can deal with the deadlock problem in one of three ways:

1. Ensure that the system will never enter a deadlock state:
 Deadlock prevention
 Deadlock avoidance
2. Allow the system to enter a deadlock state, detect it and then recover it
 Some systems such as databases adopt this solution, allowing deadlocks to occur and then managing the
recovery
3. Ignore the problem and pretend that deadlocks never occur in the system
 Solution 3 is the one used by most OSes, including Linux and Windows
 It is then up to kernel and application developers to write programs that handle deadlocks, typically using approaches
outlined in the first solution

9
Prevention vs. Avoidance

Deadlock prevention
 Provides a set of methods to ensure that at least one of the necessary four conditions cannot hold. These methods
prevent deadlocks by constraining how requests for resources can be made.

Deadlock avoidance
 Requires that OS be given additional information in advance concerning which resources a thread will request and
use during its lifetime. With this additional knowledge, OS can decide for each request whether or not the thread
should wait.

10
Deadlock Prevention

 Invalidate at least one of the four necessary conditions for deadlock:

 Mutual Exclusion
 Not required for sharable resources (e.g., read-only files); must hold for non-sharable resources
 Hold and Wait
 Must guarantee that whenever a process requests a resource, it does not hold any other resources
 Require process to request and be allocated all its resources before it begins execution, or allow process
to request resources only when the process has none allocated to it
 Low resource utilization; starvation possible
 No Preemption
 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
 Preempted resources are added to the list of resources for which the process is waiting
 Process will be restarted only when it can regain its old resources, as well as the new ones that it is requesting
 Circular Wait
 Impose a total ordering of all resource types, and require that each process requests resources in an increasing
11
order of enumeration
Circular Wait

 Invalidating the circular wait condition is most common

 Simply assign each resource (i.e. mutex locks) a unique number
 Resources must be acquired in order
 If:

first_mutex = 1
second_mutex = 5

Code for thread_two could not be written as follows:

12
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
 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
 Safe State
 A process requests an available resource, system must decide if immediate allocation leaves the system in a safe state
 System is in safe state if there exists a sequence <P1, P2, …, Pn> of ALL processes in the systems such that for each Pi,
resources that Pi can still request can be satisfied by currently available resources + resources held by all Pj, with j < i
 That is:
 If Pi resource needs are not immediately available, then Pi can wait until all Pj have finished

13  When Pj is finished, Pi can obtain needed resources, execute, return allocated resources, and terminate
 When Pi terminates, Pi +1 can obtain its needed resources, and so on
Safe, Unsafe, Deadlock States

 If a system is in safe state ⇒ no deadlocks

 If a system is in unsafe state ⇒ possibility of deadlock

 Not all unsafe states are deadlocks, however, an unsafe state may lead to a deadlock

 Avoidance algorithms ⇒ ensure that a system will never enter an unsafe state
 May lower resource utilization because of if thread or process requests
a resource that is currently available but not sufficient, it may have to wait

14
Avoidance Algorithms

 Single instance of a resource type

 Use a resource-allocation graph

 Multiple instances of a resource type

 Use the Banker’s Algorithm

15
Resource-Allocation Graph Scheme

 Claim edge Pi → Rj – indicated that process Pj 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 to a claim edge
 Resources must be claimed a priori in the system
 Process Pi starts execution when all its claim edges must appear in the resource allocation graph

16
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
 Unsafe state in resource-allocation graph:

17
Banker’s Algorithm

 It works if we have resources with multiple instances

 Each process must a priori claim maximum use
 When a process requests a resource, it may have to wait depending on the resource availability
 When a process gets all its resources it must return them in a finite amount of time
 Data structures for the banker’s algorithm
 Let n = number of processes, and m = number of resources types
 Available – Vector of length m. If available [j] = k, there are k instances of resource type Rj are available
 Max – n x m matrix. If Max [i,j] = k, then process Pi may request at most k instances of resource type Rj
 Allocation – n x m matrix. If Allocation[i,j] = k then Pi is currently allocated k instances of Rj
 Need – n x m matrix. 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]

18
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
2. Find an i such that both:
(a) Finish [i] = false
(b) Needi ≤ Work If no such i exists, go to step 4
3. Work = Work + Allocationi
Finish[i] = true
go to step 2
4. If Finish [i] == true for all i, then the system is in a safe state

19
Safety Algorithm - Example

 5 processes P0 through P4; 3 resource types:  Solution:

A (10 instances), B (5instances), and C (7 instances)  Content of the matrix Need is defined to be
 Snapshot at time T0: Max – Allocation
Allocation Max Available Need
ABC ABC ABC ABC
P0 010 753 332 P0 743
P1 200 322 P1 122
P2 302 902 P2 600
P3 211 222 P3 011
P4 002 433 P4 431

20
The system is in a safe state since the sequence < P1, P3, P4, P2, P0> satisfies safety criteria
Safety Algorithm - Example

 5 processes P0 through P4; 3 resource types:  Solution:

A (10 instances), B (5instances), and C (7 instances)  Content of the matrix Need is defined to be
 Snapshot at time T0: Max – Allocation
Allocation Max Available Need
ABC ABC ABC ABC
P0 010 753 332 Total instance can be calculated as
P0 743
overall all allocations of that
resource for every process + the
P1 200 322 current availability of that resource P1 122
in the system
P2 302 902 P2 600
P3 211 222 + 10 = A (10 instances) P3 011
P4 002 433 P4 431

21
The system is in a safe state since the sequence < P1, P3, P4, P2, P0> satisfies safety criteria
Safety Algorithm – Example (cont.)

We got back all the resources

A (10)
B (5)
C (7)
Resource-Request Algorithm for Process Pi

Requesti – 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:
Available = Available – Requesti;
Allocationi = Allocationi + Requesti;
Needi = Needi – Requesti;
 If safe ⇒ the resources are allocated to Pi
 If unsafe ⇒ Pi must wait, and the old resource-allocation state is restored

23
Resource-Request Algorithm - Example

 P1 Request (1,0,2)
 Check that Request ≤ Available (that is, (1,0,2) ≤ (3,3,2) ⇒ true
Allocation Need Available
ABC ABC ABC
P0 010 743 230
P1 302 020
P2 302 600
P3 211 011
P4 002 431
 Executing safety algorithm shows that sequence < P1, P3, P4, P0, P2> satisfies safety requirement
 Can request for (3,3,0) by P4 be granted? Can request for (0,2,0) by P0 be granted?
24
Deadlock Detection

 Allow system to enter deadlock state

 Detection algorithm
 Single-instance resources → wait-for graph
 Multiple-instances resources → Detection algorithm

 Recovery scheme

 Detection and recovery algorithm increases overhead over system

 Run time costs + execution of detection and recovery algorithm

25
Single Instance of Each Resource Type

 Maintain wait-for graph from resource-allocation graph

 Nodes are only processes or threads; remove all resource nodes with associated edges
 Pi → Pj , if Pi is waiting for Pj
 Periodically, system 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

26
Resource-Allocation Graph Corresponding wait-for graph
Several Instances of a Resource Type

 Wait-for graph cannot detect deadlock in several instances for resource types
 Used data structures :
 Available
 A vector of length m indicates the number of available resources of each type
 Allocation
 An n x m matrix defines the number of resources of each type currently allocated to each process
 Request
 An n x m matrix indicates the current request of each process. If Request [i][j] = k, then process Pi is requesting
k more instances of resource type Rj

27
Detection Algorithm

1. Let Work and Finish be vectors of length m and n, respectively

Initialize:
Work = Available
For i = 1,2,..n, if Allocationi 0, then Finish [i] = false otherwise Finish [i] = true
2. Find an index i such that both:
(a) Finish [i] = false
(b) Requesti ≤ Work If no such i exists, go to step 4
3. Work = Work + Allocationi
Finish[i] = true
go to step 2
4. If Finish [i] == false for some I , 1 ≤ i ≤ n , then the system is in a deadlock state
Moreover, if Finish[i] == false, then Pi is deadlocked
28
Algorithm requires an order of O(m x n2) operations to detect whether the system is in deadlocked state
Detection Algorithm - Examples
Example - 1 Example - 2
 5 processes P0 through P4; 3 resource types:  P2 requests an additional instance of type C
A (7 instances), B (2 instances), and C (6 instances) Request
 Snapshot at time T0: ABC
Allocation Request Available P0 000
ABC ABC ABC P1 202
P0 010 000 000 P2 001
P1 200 202 P3 100
P2 303 000 P4 002
State of system?
P3 211 100
 Can reclaim resources held by process P0, but
P4 002 002
insufficient resources to fulfill other processes;
 Sequence <P0, P2, P3, P1, P4> will result in Finish[i] = true for all i requests
29  Deadlock exists, consisting of processes P1, P2, P3,
and P4
Detection Algorithm – Examples (cont.)

30
Detection-Algorithm Usage

 When should we invoke the detection algorithm? The answer depends on two factors:
 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

31
Recovery from Deadlock: Process Termination

 Abort all deadlocked processes

 Abort one process at a time until the deadlock cycle is eliminated
 In which order should we choose a process 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. Resource's process needs to complete
5. How many processes will need to be terminated
6. Is process interactive or batch?

32
Recovery from Deadlock: Resource Preemption

 Selecting a victim
 Which resources and which processes are to be preempted?
 As in process termination, we must determine the order of preemption to minimize cost
 Rollback
 If we preempt a resource from a process, what should be done with that process?
 Clearly, it cannot continue with its normal execution; it is missing some needed resource
 We must roll back the process to some safe state and restart it from that state
 Starvation
 Same process may always be picked as victim
 we must ensure that a process can be picked as a victim only a (small) finite number of times
 The most common solution is to include the number of rollbacks in the cost factor

33