CPSC 457

CPSC 457
Deadlocks

Fall 2017

Contains slides from Mea Wang, Andrew Tanenbaum and Herbert Bos, Silberschatz, Galvin and Gagne

1
 CPSC 457
Midterm marks

2
 CPSC 457
Overview

● system model
● deadlock characterization
● methods for handling deadlocks
○ deadlock prevention
○ deadlock avoidance
○ deadlock detection
○ recovery from deadlock

3
 CPSC 457
Deadlock definition

● A set of processes is deadlocked if:

○ each process in the set is waiting for an event; and
○ all such events can be caused only by another process in the set.

● Event could be anything, eg.

○ resource becoming available
○ mutex/semaphore/spinlock being unlocked
○ message arriving

4
 CPSC 457
System model

● system consists of processes and resources

● n processes: P1, P2, …, Pn
● m resource types: R1, R2, . . ., Rm
○ eg. CPU, memory space, I/O devices
● each resource type Ri has Wi instances
○ eg. 1 CPU, 5 disks, 3 printers
● each process utilizes a resource in the same manner:
1. request a resource ― OS may block process
2. use a resource ― for a finite amount of time
3. release a resource ― may result in unblocking related process(es)

5
 CPSC 457
Deadlock - necessary conditions
● mutual exclusion condition
○ the involved resources must be unshareable (max. one process per resource)
● hold and wait condition
○ a process holding at least one resource is waiting to acquire additional resources
● no preemption condition
○ a resource can be released only by the process holding it (voluntary)
● circular wait condition
○ there is an ordering of processes {P1, P2, … , Pn}, such that
□ P1 waits for P2
□ P2 waits for P3, … Deadlock can arise only
□ Pn waits for P1 if all four conditions
○ ie. there is a cycle hold simultaneously!
6
 CPSC 457
Deadlock with mutex locks
● deadlocks can occur via system calls, locking, etc.
● deadlock example with 2 mutexes:

thread
Thread 1: Thread 2: 1

lock( mutex1 ); lock( mutex2 ); mutex mutex

lock( mutex2 );
// critical section
unlock( mutex2 );
unlock( mutex1 );
lock( mutex1 ); 1 2
// critical section
unlock( mutex1 );
thread
unlock( mutex2 ); 2

● all 4 necessary conditions present:

○ mutual exclusion, hold and wait, no preemption, circular wait

7
 CPSC 457
Resource-Allocation Graph with 1 instance per resource type

● A set of vertices V and a set of edges E.

● set of vertices V is partitioned into two subsets:

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

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

● request edge ― directed edge Pi → Rj

thread
1

● assignment edge ― directed edge Rj → Pi

mutex mutex
1 2

thread
2 8
 CPSC 457
Resource-Allocation Graph with multiple instances per resource
● Process Pi : ● Pi requests an instance of Rj :

Pi
Pi

Rj
request edge points to resource type, not
● multiple instances per resource type are
resource instance
represented as dots inside resources
● Pi is holding an instance of Rj :
● Resource Rj with 3 instances:

Pi

Rj
Rj
assignment edge originates from instance,
not type
9
 CPSC 457
Resource Allocation Graph Example

P1 is
requesting R1

P1 holds R2

No cycle in the graph ⇒ No deadlock

10
 CPSC 457
Resource Allocation Graph With A Deadlock

Deadlock ⇒ Cycle
11
 CPSC 457
Graph With A Cycle But No Deadlock

Cycle ⇏ Deadlock
12
 CPSC 457
Example
● consider 3 processes A, B and C which want to perform operations on resources R, S and T:

Process A: Process B: Process C:

1. request R 1. request S 1. request T
2. request S 2. request T 2. request R
3. release R 3. release S 3. release T
4. release S 4. release T 4. release R

● depending on the order in which we process the operations, we may end up:
○ with a deadlock
○ or no deadlock

13
 CPSC 457
Example: sequence of operations leading to deadlock
Process A: Process B: Process C:
1. request R 1. request S 1. request T
2. request S 2. request T 2. request R
3. release R 3. release S 3. release T
4. release S 4. release T 4. release R

Sequence:

1. A requests R - granted
2. B requests S - granted
3. C requests T - granted
4. A requests S - block
1 2 3
5. B requests T - block
6. C requests R - block

⇒ deadlock

4 5
6
14
 CPSC 457
Example: sequence of operations not leading to deadlock
Process A: Process B: Process C:
1. request R 1. request S 1. request T
2. request S 2. request T 2. request R
3. release R 3. release S 3. release T
4. release S 4. release T 4. release R

Sequence:

1. A requests R - granted
2. C requests T - granted
3. A requests S - granted
4. C requests R - blocked
1 2 3
5. A releases R - unblocks C
6. A releases S

⇒ no deadlock

4 5 6 15
 CPSC 457
Deadlock Facts

● if graph contains no cycles ⇒ no deadlock

● if graph contains a cycle ⇒
○ if only one instance per resource type, then guaranteed deadlock
○ if multiple instances per resource type, then possible deadlock

16
 CPSC 457
Methods for dealing with deadlocks
● Ignore the problem:
○ pretend that deadlocks never occur in the system
○ approach of many operating systems, including UNIX
○ it's up to applications to address their deadlock issues

● Ensure that the system will never enter a deadlock state:

○ deadlock prevention
○ deadlock avoidance

● Allow the system to enter a deadlock state and then recover:

○ deadlock detection
○ recovery from deadlock
17
 CPSC 457
Deadlock prevention

● deadlock prevention = any technique that attacks one of the 4 necessary conditions

● avoiding mutual exclusion condition

○ mutual exclusion not required for shareable resources (eg. read-only files)
○ spooling can help for some resource types (eg. printers)
○ not practical in most cases (most resources are not shareable, and non-spoolable)

● avoiding hold and wait condition

○ eg. whenever a process requests a resource, it does not hold any other resources
□ option 1: process must request all needed resources at the beginning
□ option 2: process can request resources only when it has no resources
○ low resource utilization; starvation possible

18
 CPSC 457
Deadlock prevention - example
● how do we fix the deadlock possibility below by avoiding hold and wait condition?

Thread 1: Thread 2:

lock( mutex1 ); lock( mutex2 );

lock( mutex2 ); lock( mutex1 );
// critical section // critical section
unlock( mutex2 ); unlock( mutex1 );
unlock( mutex1 ); unlock( mutex2 );

19
 CPSC 457
Deadlock prevention - example
● option 1: acquire all resources at the beginning
● lockn() - atomically locks multiple mutexes at once

Thread 1: Thread 2:

lockn( mutex1, mutex2); lockn( mutex2, mutex1);

// critical section // critical section
unlock( mutex2 ); unlock( mutex1 );
unlock( mutex1 ); unlock( mutex2 );

20
 CPSC 457
Deadlock prevention - example
● option 2: release resources before acquiring more
● unlockAndLock() - repeat until success: unlock all locked mutexes, then lock them all atomically

Thread 1: Thread 2:

unlockAndLock( mutex2, mutex1); unlockAndLock( mutex1, mutex2);

// critical section // critical section
unlock( mutex2 ); unlock( mutex1 );
unlock( mutex1 ); unlock( mutex2 );

● both options exhibit issues with non-optimal resource utilization and starvation

21
 CPSC 457
Deadlock Prevention (Cont.)

● avoiding no preemption condition

○ 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, and
process is suspended
○ preempted resources are added to the list of resources for which the process is waiting
○ process will be resumed when it can regain its old & new resources
○ only works with resources for which we can save/restore the state (eg. CPU registers)
○ complicated mechanism, possible starvation, non-optimal use of resources

22
 CPSC 457
Deadlock Prevention (Cont.)

● avoiding circular wait condition

○ most practical condition to avoid
○ eg. impose a total ordering on all resources, and require that each process requests
resources in an increasing order of enumeration
○ trivial with global mutex variables in C/C++
eg. we can simply use address of the mutex variable

if ( &m1 < &m2) {

lock(m1); lock(m2);
} else {
lock(m2); lock(m1);
}
23
 CPSC 457
Deadlock Example
● avoiding circular wait condition example:
● lock mutexes in the same order by all threads

Thread 1: Thread 2:

lock( mutex1); lock( mutex1);

lock( mutex2); lock( mutex2);
// critical section // critical section
unlock( mutex2 ); unlock( mutex1 );
unlock( mutex1 ); unlock( mutex2 );

● quite practical for very small number of mutexes / resources

24
 CPSC 457
Deadlock Example with Lock Ordering
void transaction(Account a1, Account a2, double amount) {
mutex lock1, lock2;
m1 = get_mutex(a1); // get exclusive access to account a1
m2 = get_mutex(a2); // get exclusive access to account a2
lock(m1);
lock(m2);
withdraw(a1, amount);
deposit(a2, amount);
unlock(m2);
unlock(m1);
}

Imagine 2 transactions execute concurrently:

Transaction 1 transfers $25 from account A to account B
Transaction 2 transfers $50 from account B to account A
⇒ Possible Deadlock. 25
 CPSC 457
Deadlock Example with Lock Ordering
void transaction(Account a1, Account a2, double amount) {
mutex lock1, lock2;
m1 = get_mutex(a1); // get exclusive access to account a1
m2 = get_mutex(a2); // get exclusive access to account a2
if( id(a1) > id(a2))
swap( m1, m2);
lock(m1); Alternatively:
lock(m2);
withdraw(a1, amount); if( id(a1) > id(a2)) {
deposit(a2, amount); lock(m1); lock(m2);
lock(m2); } else {
lock(m1); lock(m2); lock(m1);
} }

Avoiding circular wait condition by ordering resources.

26
 CPSC 457
Deadlock Avoidance

● deadlock prevention schemes can lead to low resource utilization

● deadlock avoidance can increase resource utilization if some a priori information is 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

27
 CPSC 457
Safe State

● a system is in a safe state if there exists a sequence <P1, P2, …, Pn> of all running processes in the
system where they can all finish, while allowing them to claim their maximum resources
○ i.e. the processes can finish even under the worst case scenario ― where they each request
their max. resources as their next step
● a system is in an unsafe state if there does not exist such an execution sequence
● when a process requests an available resource, the system determines if granting such request
would lead to a safe state
○ if new state is safe, request is granted
○ if new state is not safe, request is denied and process waits

28
 CPSC 457
Safe, Unsafe, Deadlock State

● If a system is in a safe state → deadlocks are

not possible (because they will be avoided
unsafe
by the system).
deadlock state

● If a system is in an unsafe state → deadlocks

are possible (but not guaranteed).

● Avoidance algorithm ensures that a system

never enters an unsafe state, by safe
state
rejecting/blocking some requests.

29
 CPSC 457
Deadlock Avoidance Algorithms

● for single instance per resource type

● we use a resource-allocation graph algorithm

● for multiple instances per resource type

● we use the banker’s algorithm

30
 CPSC 457
Resource-Allocation Graph Algorithm

● 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 actually 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

31
 CPSC 457
Resource-Allocation Graph

assignment edge request edge

P1 holds R1 R1 P2 is
requesting R1

P1 P2

claim edge claim edge

P1 may P2 may
request R2 R2 request R2

32
 CPSC 457
Resource-Allocation Graph

R1 R1 R1

P1 P2 P1 P2 P1 P2

R2 R2 R2

claim edge request edge assignment edge

P2 may request R2 P2 did request R2 P2 now holds R2
33
 CPSC 457
Resource-Allocation Graph Algorithm
● suppose that process requests a resource
● the request can be granted only if allowing the request will not violate safe state
● we make sure that converting the request edge to an assignment edge does not result in
formation of a cycle
● complexity: same as cycle-detection algorithm in a directed graph, i.e. O(|V| + |E|)

R1

P1 P2

R2 cannot be granted
can be granted
and P2 would block 34
 CPSC 457
Banker’s Algorithm

● another avoidance algorithm

● more general than resource-allocation graph algorithm
● works with multiple instances per resource type
● requirements:
○ each process must declare maximum resources at the beginning
○ when a process requests a resource it may have to wait (even if resource is available)
○ when a process gets all its resources it must return them in a finite amount of time

35
 CPSC 457
Data Structures for the Banker’s Algorithm
Let n = number of processes, and m = number of resources types.

● Available - vector of length m

○ Available[j]=k means there are k instances of resource type Rj available
● Max - matrix n x m
○ Max[i,j]=k means that process Pi may request at most k instances of resource type Rj
○ Max[i] represents the i-th row of Max
● Allocation - matrix n x m
○ Allocation[i,j]=k means that process Pi is currently allocated k instances of Rj
● Need - matrix n x m
○ Need[i,j]=k means that Pi may need k more instances of Rj to complete its task

● Note: Need[i,j] = Max[i,j] – Allocation[i,j]

○ only 2 of Need/Max/Allocation are needed, the 3rd can be computed on the fly 36
 CPSC 457
Banker's algorithm - determining safety
Banker's algorithm tries to find whether there is an execution sequence that would finish all running
processes, assuming worst case scenario - that each process requests its maximum declared allocation
as the next step.

1. Initialize temporary vectors:

Work = Available ; vector copy
Finish[i] = false for i = 0, 1, …, n-1
2. Find an i such that
Finish[i] = false AND Need[i] ≤ Work ; vector comparison
If no such i exists, go to step 4
Complexity:
3. Update Work and Finish:
Work = Work + Allocation[i] ; vector sum O(n*n*m)
Finish[i] = true
go to step 2
4. If Finish[i] == true for all i, return true ; system is in a safe state
else return false ; system is not in a safe state 37
 CPSC 457
Algorithm to determine if request can be granted for process Pi
Inputs: (Request, i)
● Request is a vector - where Request[j] = k means process Pi wants k instances of Rj
● process number i

Algorithm:
● If Request[] > Need[i] ⇒ raise error, process has exceeded its maximum claim
● If Request[] > Available ⇒ then Pi must wait, since resources are not available
● Pretend to allocate Request[], and see if the state is still safe:
○ Save current state of Available, Allocation and Need
○ Available = Available – Request
○ Allocation[i] = Allocation[i] + Request
○ Need[i] = Need[i] – Request
● check if state still safe using Banker's algorithm
● If state safe ⇒ the request can be granted (resources are allocated to Pi), discard the saved state
● If unsafe ⇒ request must block, Pi must wait, restore the saved state 38
 CPSC 457
Example of Banker’s Algorithm
● 5 processes:
○ P0, P1, P2, P3 and P4
● 3 resource types:
○ A (10 instances), B (5 instances), and C (7 instances)
● Current state snapshot:

Allocation Max Available Need

A B C 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 ? ? ?

39
 CPSC 457
Example of Banker’s Algorithm
● 5 processes:
○ P0, P1, P2, P3 and P4
● 3 resource types:
○ A (10 instances), B (5 instances), and C (7 instances)
● Current state snapshot:

Allocation Max Available Need

A B C A B C A B C A B C
Need = Max - Allocation
P0 0 1 0 7 5 3 3 3 2 7 4 3
P1 2 0 0 3 2 2 1 2 2 Is the system in a safe state?
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

40
 CPSC 457
Example of Banker’s Algorithm
● 5 processes:
○ P0, P1, P2, P3 and P4
● 3 resource types:
○ A (10 instances), B (5 instances), and C (7 instances)
● Current state snapshot:

Allocation Max Available Need

A B C A B C A B C A B C
Need = Max - Allocation
P0 0 1 0 7 5 3 3 3 2 7 4 3
P1 2 0 0 3 2 2 1 2 2 Is the system in safe state?
P2 3 0 2 9 0 2 6 0 0
Yes - safety algorithm
P3 2 1 1 2 2 2 0 1 1 P1, P3, P4, P2, P0
P4 0 0 2 4 3 3 4 3 1

41
 CPSC 457
Example of Banker’s Algorithm
● 5 processes:
○ P0, P1, P2, P3 and P4
● 3 resource types:
○ A (10 instances), B (5 instances), and C (7 instances)
● Current state snapshot:
Final exam question candidates:
Allocation Max Available Need
● Can request (1,0,2) for P1 be
A B C A B C A B C A B C
granted?
P0 0 1 0 7 5 3 3 3 2 7 4 3 ● Can request (3,3,0) for P4 be
P1 2 0 0 3 2 2 1 2 2 granted?
● Can request (0,2,0) for P0 be
P2 3 0 2 9 0 2 6 0 0 granted?
P3 2 1 1 2 2 2 0 1 1
Show your work / show possible
P4 0 0 2 4 3 3 4 3 1
sequence.

42
 CPSC 457
Banker's algorithm example
Allocation Max Available
A B C A B C A B C Given the state of the system on
P0 0 1 0 7 5 3 3 3 2 the left, can we grant an additional
request (1,0,2) to P1?
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

43
 CPSC 457
Banker's algorithm example
Allocation Max Available
A B C A B C A B C Given the state of the system on
P0 0 1 0 7 5 3 2 3 0 the left, can we grant an additional
request (1,0,2) to P1?
P1 3 0 2 3 2 2
P2 3 0 2 9 0 2
1. Update Allocation and
P3 2 1 1 2 2 2 Available
P4 0 0 2 4 3 3

44
 CPSC 457
Banker's algorithm example
Allocation Max Available Need
A B C A B C A B C A B C Given the state of the system on
P0 0 1 0 7 5 3 2 3 0 7 4 3 the left, can we grant an additional
request (1,0,2) to P1?
P1 3 0 2 3 2 2 0 2 0
P2 3 0 2 9 0 2 6 0 0
1. Update Allocation and
P3 2 1 1 2 2 2 0 1 1 Available
P4 0 0 2 4 3 3 4 3 1 2. Calculate Need

45
 CPSC 457
Banker's algorithm example
Allocation Max Available Need
A B C A B C A B C A B C Given the state of the system on
P0 0 1 0 7 5 3 2 3 0 7 4 3 the left, can we grant an additional
request (1,0,2) to P1?
P1 3 0 2 3 2 2 0 2 0
P2 3 0 2 9 0 2 6 0 0
1. Update Allocation and
P3 2 1 1 2 2 2 0 1 1 Available
P4 0 0 2 4 3 3 4 3 1 2. Calculate Need
3. Is the new state safe?
Use Banker's algorithm, which produces sequence:

1. P1: available = (2,3,0) + (3,0,2) → (5,3,2)

2. P3: available = (5,3,2) + (2,1,1) → (7,4,3)
3. P0: available = (7,4,3) + (0,1,0) → (7,5,3)
4. P2: available = (7,5,3) + (3,0,2) → (10,5,5)
5. P4: available = (10,5,5) + (0,0,2) → (10,5,7) 46
 CPSC 457
Banker's algorithm example
Allocation Max Available Need
A B C A B C A B C A B C Given the state of the system on
P0 0 1 0 7 5 3 2 3 0 7 4 3 the left, can we grant an additional
request (1,0,2) to P1?
P1 3 0 2 3 2 2 0 2 0
P2 3 0 2 9 0 2 6 0 0
1. Update Allocation and
P3 2 1 1 2 2 2 0 1 1 Available
P4 0 0 2 4 3 3 4 3 1 2. Calculate Need
3. Is the new state safe?
Use Banker's algorithm, which produces sequence:

1. P1: available = (2,3,0) + (3,0,2) → (5,3,2) Answer: yes, we can grant the
2. P3: available = (5,3,2) + (2,1,1) → (7,4,3) request. Possible execution
3. P0: available = (7,4,3) + (0,1,0) → (7,5,3) sequence after granting the
request:
4. P2: available = (7,5,3) + (3,0,2) → (10,5,5) P1, P3, P0, P2, P4
5. P4: available = (10,5,5) + (0,0,2) → (10,5,7) 47
 CPSC 457
Deadlock Detection

● We allow system to enter a deadlock state, but later we detect the deadlock and recover.

● Detection algorithm
○ with single instance per resource type
○ multiple instances per resource type

● Recovery scheme

48
 CPSC 457
Deadlock detection with single instance per resource type

● Maintain an up-to-date wait-for graph

○ Nodes are processes
○ Pi → Pj if Pi is waiting for Pj
○ can be obtained by collapsing resource-allocation graph
● Periodically invoke an algorithm that searches for a cycle in the graph.
● If there is a cycle, there exists a deadlock.

49
 CPSC 457
Resource-Allocation Graph and Wait-for Graph

Resource-Allocation Graph Corresponding wait-for graph

50
 CPSC 457
Deadlock detection with multiple instances per resource type

● n = number of processes
● m = number of resource types
● Available[] = vector of length m indicates the number of available resources of each type
● Allocation[][] = n x m matrix - current allocation of resources per process
● Request[][] = n x m matrix - current requests for resources per process

● very similar to banker's algorithm

○ we try to determine if there is a sequence in which running processes can finish executing
○ but assumes best case scenario - a process that is given its requested resources will finish
without asking for more resources, and then release all its resources
○ does not need Max[] or Need[] matrices

51
 CPSC 457
Detection Algorithm
1. Initialize:
Work = Available
Finish[i] = (Allocation[i] == 0) for all i = 1,2,3, … n
2. Find an index i such that:
Finish[i] == false and Request[i] ≤ Work
If no such i exists, go to step 4
3. Work = Work + Allocation[i]
Finish[i] = true
go to step 2
4. If Finish[i] == true for 1 ≤ i ≤ n, then system is not in deadlock
Otherwise, all processes Pi for which Finish[i] == false are deadlocked

Algorithm requires an order of O(m x n2) operations

to detect whether the system is in deadlocked state.
52
 CPSC 457
Example of Detection Algorithm
● Five processes P0 through P4, and three resource types A, B, C:
A with 7 instances, B with 2 instances and C with 6 instances
● Snapshot at time T:
Allocation Request Available
A B C A B C A B C
P0 0 1 0 0 0 0 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

● Q: Is there a deadlock?
● A: No, possible sequence <P0, P2, P3, P1, P4> will result in Finish[i] = true for all i

53
 CPSC 457
Example (Cont.)
● P2 requests an additional instance of type C, i.e. (0,0,1)
Allocation Request Available
A B C A B C A B C
P0 0 1 0 0 0 0 0 0 0
P1 2 0 0 2 0 2
P2 3 0 3 0 0 1
P3 2 1 1 1 0 0
P4 0 0 2 0 0 2

● State of system?
○ P0 can run and finish
○ system reclaims resources held by process P0
○ but insufficient resources to fulfill any other request
○ deadlock exists, consisting of processes P1, P2, P3, and P4
54
 CPSC 457
Detection-Algorithms - when and how often?
● detection algorithms are expensive
○ we cannot invoke them on every resource request
● other ideas for invoking detection:
○ check every few minutes
○ check when CPU goes idle
● when, and how often depends on:
○ how often a deadlock is likely to occur?
○ how many processes will be affected?
□ one for each disjoint cycle
● if we check too often - we spend too many CPU cycles on useless work
● if we don't check often enough - there may be many cycles in the resource graph and we would
not be able to tell which of the many deadlocked processes “caused” the deadlock
55
 CPSC 457
Deadlock recovery

● process termination
● process rollback
● resource preemption

56
 CPSC 457
Recovery from Deadlock: Process Termination
● we could abort all deadlocked processes
○ simple, but often a bad choice
● we could abort one process at a time until the deadlock cycle is eliminated
○ better choice, but...
● In which order should we choose to abort? Some ideas:
○ Priority of the process
○ Age of the process
○ 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?
57
 CPSC 457
Recovery from Deadlock: Process Rollback

● similar idea to process termination, but …

○ programs can cooperate
○ programs can be implemented to periodically save their current state (checkpoint)
○ when restarted, the program detects a checkpoint and resumes computation from last
checkpoint (rollback)
○ programs can checkpoint themselves just before requesting resources
● when deadlock is detected, a program can be terminated and re-scheduled to run later
○ eg. after the other affected deadlocked processes are done
● does not work well with all resource types (eg. printer)
● useful for long computations / simulation

58
 CPSC 457
Recovery from Deadlock: Resource Preemption

● similar idea to rollback, but instead of checkpointing the program, we checkpoint the resources
of the program
● only works with some resource types
● when deadlock occurs:
○ pick a victim process
○ suspend victim process
○ save state of victim's resources
○ give victim's resources to other deadlocked processes
○ when the other processes release the resources, restore resource states
○ return resources to the victim
○ unsuspend the victim

59
 CPSC 457
Recovery from Deadlock

● starvation can be a problem with rollback & checkpointing

○ we might continually pick the same process to preempt/checkpoint
○ possible solution: keep count of preemptions/checkpoints
○ when picking the next process, take this count into consideration

60
 CPSC 457
Summary

● resource allocation graphs

● necessary conditions
● methods for handling deadlocks
○ deadlock prevention - spooling, enumerating
○ deadlock avoidance - graph cycles, banker's algorithm
○ deadlock detection
○ recovery from deadlock

Reference: 6.1 - 6.2, 6.4 - 6.6 (Modern Operating Systems)

7.1 - 7.7 (Operating System Concepts)

61
 CPSC 457
Review
● Define deadlock.
● If there is a deadlock, that means there is a circular wait between processes. True or False
● If there is a circular wait between processes, than means there is a deadlock. True or False
● Which of the following methods is used to prevent circular waiting among processes and resources?
○ Spooling
○ Request all resources at the beginning
○ Take resources away
○ Order resources & lock in order
● How do we detect a deadlock?
● Name three approaches for deadlock recovery.
● What is a checkpoint?

62
 CPSC 457
Questions?

63
63