Deadlocks OS
Deadlocks OS
))
Outline:
Deadlock problem
System Model
Deadlock Characterization
Methods for Handling Deadlocks
Deadlock Prevention
Deadlock Avoidance
Deadlock Detection
Recovery from Deadlock
Combined Approach to Deadlock Handling
8.1
The Deadlock Problem
P0 P1
wait (A); wait(B)
wait (B); wait(A)
8.2
Bridge Crossing Example
8.3
System Model
A set of processes is in a deadlock state when every
process in the set is waiting for an event that can be
caused by another process in the set.
Events:
Resource acquisition and release.
Resource types R , R , . . ., R
1 2 n
Physical resources:CPU cycles, memory space, I/O devices
Logical resources: files, semaphores, and monitors
Each resource type R has W instances.
i i
Each process utilizes a resource as follows:
Request: if the request is not granted , then it must wait.
Use: The process can operate on the resource.
Release: The process releases the resources.
Multi-threaded programs are good candidates for
deadlock because multiple threads compete for shared
resources.
8.4
Deadlock Characterization
Deadlock can arise if four conditions hold simultaneously.
Mutual exclusion: only one process at a time can use at least
one resource. Resources are non sharable.
Hold and wait: a process holding at least one resource is
waiting to acquire additional resources held by other processes.
No preemption: Resources can not be preempted; that is 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-1,Pn, P0} 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.
8.6
Resource-Allocation Graph (Cont.)
Process
Pi requests instance of Rj
Pi
Rj
Pi is holding an instance of Rj
Pi
Rj
8.7
Example of a Resource Allocation Graph
8.8
Resource Allocation Graph With A Deadlock
8.9
Resource Allocation Graph With A Cycle But No Deadlock
8.10
Basic Facts
8.11
Methods for Handling Deadlocks
Three ways
Ensure that the system will never enter a
deadlock state.
8.12
Methods for Handling Deadlocks
To ensure that deadlocks never occur, the system can
use either deadlock prevention and deadlock-avoidance
schemes.
Deadlock prevention: set of methods for ensuring that at least
one of the necessary conditions can not hold.
Deadlock avoidance: Requires that operating system be given
in advance additional information concerning which resources
a process will request and use during its life time.
Deadlock detection: examines the state of the system to
determine whether a deadlock has occurred or not.
Alternatively, assume that deadlock would not occur.
Resort to manual recovery when performance
degrades due to deadlock.
8.13
Deadlock Prevention
8.14
Deadlock Prevention
Restrain the ways request can be made.
Mutual Exclusion – It is not possible to prevent
deadlocks through ME, as some resources are
intrinsically non-sharable.
Hold and Wait – must guarantee that whenever a
process requests a resource, it does not hold any other
resources.
Protocol 1: Requires a process to request and be
allocated all its resources before it begins execution.
System calls requesting resources for a process
precede all other system calls.
Protocol 2: Allow process to request resources only
when the process has none.
A process can request some resources and use
them. Before, it can request additional resources, it
must release all the resources that it is currently
allocated.
8.15
Deadlock Prevention
Hold and Wait – Example
Consider a process that copies data from tape drive to a disk file and then prints
the results to the printer.
Protocol1: If all the resources are requested at the beginning of a process, the
process must request the tape drive, disk file, and printer.
It will the printer during entire execution, even though it needs at the end.
Protocol 2: It copies data from tape drive to disk file and releases them. It gain
requests disk file and printer.
Disadvantages:
Resource utilization is very low
Resource may be allocated but unused for a long time.
Starvation is possible
A process that needs several resources may have to wait indefinitely, at
least one of the resources that it needs is always allocated to another
process.
Inefficient
Delays process initiation
Future resource requirements must be known
8.16
Deadlock Prevention (Cont.)
No Preemption –
Protocol: 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.
Possible for CPU registers and memory space whose state can be
restored later, but not possible for printers and tape drives.
8.17
Deadlock Prevention (Cont.)
Circular Wait –
F:RN is a one-to-one function, where N is a set of natural
numbers.
Protocol 1: impose a total ordering of all resource types,
and require that each process requests resources in an
increasing order of enumeration.
A process initially can request any number of instances
of type Ri. Then the process can request instances of a
resource type Rj if and only if F(Rj) >F(Ri).
Protocol 2: Whenever a process requests an instance of
resource type Rj, it has released any other resources Ri
such that F(Ri) >=F(Rj).
Ordering
8.18
Deadlock prevention
Circular Wait:
“witness” system call is implemented in BSD UNIX for lock order
verifier
“witness” uses mutual-exclusion locks to protect critical regions and
maintains the relationship of lock orders in the system
Suppose thread_one aquires locks in the order first_mutex and
second_mutex. Then witness records that first_mutex should be
obtained before second_mutex. If thread_two later aquires locks out
of order, witness generates a warning message.
thread_one thread_two:
{ {
lock(first_mutex); lock(second_mutex);
lock(second_mutex); lock (first_mutex);
. .
. .
} }
8.19
Deadlock Avoidance
Deadlock prevention algorithms
Low device utilization, and reduced system
throughput.
Alternative method is get additional
information about the processes
Resources currently available, resources
currently allocated to a process, and future
requests and releases of each process.
Various algorithms differ about amount and
type of information required.
8.20
Deadlock Avoidance (Class #18)
8.21
Safe State
When a process requests an available resource, system must
decide if immediate allocation leaves the system in a safe state.
8.22
Basic Facts
8.23
Safe, Unsafe , Deadlock State
8.24
Example
Consider a system with 12 magnetic tape drives and three processes
P0,P1,P2.
P0 requires 10 tape drives, P1 may need 4, and P2 may need up to 9
tape drives.
Suppose at time t0, P0 is holding 5 tape drives, P1 holding 2, and P2 is
holding 2 tape drives.
There are 3 free tape drives
8.26
Resource-Allocation Graph Algorithm
If we have a resource-allocation (RA) system with one instance of
each resource type, we can use this approach.
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.
When a resource is released by a process, assignment edge
reconverts to a claim edge.
Resources must be claimed a priori in the system.
Before the process starts executing, all its claim edges must appear
in the RA graph.
Suppose a process Pi requests a resource Rj. The request can be
granted if converting the request edge Pi Rj to an assignment
edge Rj Pi does not result in the formation of a cycle in the RA
graph.
8.27
Resource-Allocation Graph Algorithm
Cycle detection algorithm is used to detect
a cycle.
If there are n processes detecting a cycle
requires an order of n*n operations.
8.28
Resource-Allocation Graph For Deadlock Avoidance
Suppose P2 requests R2
8.29
Unsafe State In Resource-Allocation Graph
Multiple instances.
8.31
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 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.
8.33
Safety Algorithm
1. Let Work and Finish be vectors of length m and n,
respectively. Initialize:
Work = Available
Finish [i] = false for i - 1,3, …, n.
2. Find and 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.
8.34
Example of Banker’s Algorithm
8.35
Example (Cont.)
8.36
Example P1 Request (1,0,2) (Cont.)
Check that Request Available (that is, (1,0,2) (3,3,2)
true.
Allocation Need Available
ABC ABC ABC
P0 0 1 0 743 230
P1 302 020
P2 301 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?
8.37
Deadlock Detection
Allow system to enter deadlock
state
Detection algorithm
Resource allocation graph algorithm
Detection algorithm (similar to
Banker’s algoritm)
Recovery scheme
8.38
Single Instance of Each Resource
Graph based approach
Maintain wait-for graph
Nodes are processes.
Pi Pj if Pi is waiting for Pj.
8.39
Resource-Allocation Graph and Wait-for Graph
8.40
Several Instances of a Resource Type
Available: A vector of length m indicates the
number of available resources of each type.
8.41
Detection Algorithm
1.Let Work and Finish be vectors of length
m and n, respectively Initialize:
(a) Work = Available
(b) 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
8.42
Detection Algorithm (Cont.)
8.43
Example of Detection Algorithm
8.44
Example (Cont.)
8.45
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
8.47
Recovery from Deadlock: Process Termination
Abort all deadlocked processes.
More expensive
Abort one process at a time until the deadlock cycle is eliminated.
Overhead: after the abort of each process detection algorithm have to be
invoked.
Aborting a process is not easy.
Printing or updating a file
In which order should we choose to abort? (should incur minimum cost)
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?
8.48
Recovery from Deadlock: Resource Preemption
We preempt some resources from one process and give
it to other processes. Until the deadlock cycle is broken.
For preemption three issues are to be addressed
Selecting a victim – minimize cost.
Number of resources the deadlocked process is
holding, time consumed by it for execution.
Rollback – return to some safe state, restart process
for that state.
Rollback as far as necessary to break the deadlock.
Starvation – same process may always be picked as
victim,
Solution: include number of rollbacks in cost factor.
8.49
Deadlock Handling: summary
8.50