Deadlocks Contents

advertisement
TDDI04
Concurrent Programming,
Operating Systems,
and Real-time Operating Systems
Contents
§ The Deadlock Problem
§ System Model
§ Deadlock Characterization
§ Methods for Handling Deadlocks
Deadlocks
§ Deadlock Prevention
§ Deadlock Avoidance
§ Deadlock Detection
[SGG7] Chapter 7
§ Recovery from Deadlock
Copyright Notice: The lecture notes are mainly based on Silberschatz’s, Galvin’s and Gagne’s book (“Operating System
Concepts”, 7th ed., Wiley, 2005). No part of the lecture notes may be reproduced in any form, due to the copyrights
reserved by Wiley. These lecture notes should only be used for internal teaching purposes at the Linköping University.
Acknowledgment: The lecture notes are originally compiled by C. Kessler, IDA.
Klas Arvidsson, IDA,
Linköpings universitet.
Bridge Crossing Example
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
© Silberschatz, Galvin and Gagne 2005
7.2
The Deadlock Problem
§ A set of blocked processes each holding a shared resource
and waiting to acquire a resource held by another process in
the set.
§ Example:
§ Narrow bridge: Traffic only in one direction at a time.
§ 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).
•
•
System has 2 tape drives.
P1 and P2 each hold one tape drive and each needs
another one.
§ Example:
•
§ Several cars may have to be backed up if a deadlock occurs.
§ Starvation is possible.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.3
© Silberschatz, Galvin and Gagne 2005
P1
wait(B)
wait(A)
…
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.4
© Silberschatz, Galvin and Gagne 2005
[Coffman et al. 1971]
Deadlock can arise only if four conditions hold simultaneously:
§ Resource types R1, R2, . . ., Rm
CPU cycles, memory space, I/O devices
§ 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.
§ Each resource type Ri has Wi instances.
§ Each process utilizes a resource as follows:
§ No preemption of resources: a resource can be released
only voluntarily by the process holding it, after that process
has completed its task.
request
use
§ Circular wait: there exists a set {P0, P1, …, Pn} of waiting
processes such that
release
•
•
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
P0
wait (A);
wait (B);
…
Deadlock Characterization
System Model
•
•
•
Semaphores A and B, initialized to 1
7.5
© Silberschatz, Galvin and Gagne 2005
Pi is waiting for a resource that is held by Pi+1, 0 ≤ i < n
Pn is waiting for a resource that is held by P0.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.6
© Silberschatz, Galvin and Gagne 2005
1
Resource-Allocation Graph
A set of vertices V and a set of edges E.
Example of a Resource Allocation Graph
Process
V partitioned into 2 types of vertices:
§ P = {P1, P2, …, Pn},
the set of all processes
in the system.
Resource type
with 4 instances
§ R = {R1, R2, …, Rm},
the set of all resource types
in the system.
Pi requests an
instance of Rj
E has two types of edges:
Pi is holding an
§ request edge – directed edge Pi → Rj instance of Rj
Pi
Rj
Pi
Rj
§ assignment edge – directed edge Rj → Pi
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.7
© Silberschatz, Galvin and Gagne 2005
Resource Allocation Graph With A Deadlock
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.9
© Silberschatz, Galvin and Gagne 2005
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.8
© Silberschatz, Galvin and Gagne 2005
Resource Allocation Graph
With A Cycle But No Deadlock
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.10
© Silberschatz, Galvin and Gagne 2005
Basic Facts
Methods for Handling Deadlocks
§ Graph contains no cycles ⇒ no deadlock.
§ Deadlock Prevention and Deadlock Avoidance:
Ensure that the system will never enter a deadlock state.
§ Graph contains a cycle ⇒
•
•
if only one instance per resource type, then deadlock.
if several instances per resource type, possibility of
deadlock.
§ Deadlock Detection and Deadlock Recovery:
Allow the system to enter a deadlock state and then recover.
§ Ignore the problem
and pretend that deadlocks never occur in the system
•
•
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.11
© Silberschatz, Galvin and Gagne 2005
used by most operating systems, including UNIX, Windows
responsibility lifted to the user / programmer.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.12
© Silberschatz, Galvin and Gagne 2005
2
Deadlock Prevention
[Havender 1968]
Ensure that at least one of the four necessary conditions for
deadlock occurrence does not hold.
Deadlock Prevention (Cont.)
§ No Preemption of Resources –
•
If a process 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.
§ Mutual Exclusion – needed only for limited shared resources
•
Example: Read-only-file access by arbitrarily many readers
§ 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 as a whole before it begins execution,
or allow process to request resources only when the
process has none.
§ Circular Wait – impose a total ordering of all resource types,
and require that each process requests resources in an
increasing order of enumeration.
Low resource utilization; starvation possible; not flexible.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
© Silberschatz, Galvin and Gagne 2005
7.13
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.14
© Silberschatz, Galvin and Gagne 2005
Deadlock Avoidance
Safe Resource Allocation State
Requires that the system has a priori information available
about the needed resources.
§ When a process requests an available resource,
system must decide if immediate allocation leaves the system
in a safe state.
§ Simplest model:
[Dijkstra 1965]
Each process must declare the maximum number of
resources of each type that it may need.
§ Resource-allocation state is defined by
•
•
the number of available and allocated resources, and
the maximum demands of the processes.
§ State transition = granting a request or releasing resource
§ Deadlock-avoidance algorithm dynamically examines the
resource-allocation state to ensure that there can never be a
circular-wait condition.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
© Silberschatz, Galvin and Gagne 2005
7.15
§ System is in safe state if there exists a safe sequence of all
processes.
§ Sequence <P1, P2, …, Pn> is safe if, for each Pi, the resources
that Pi can still request can be satisfied by currently available
resources + resources held by all the Pj, with j<i.
• If Pi‘s 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, Pi+1 can obtain its needed resources,
and so on.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.16
© Silberschatz, Galvin and Gagne 2005
Basic Facts
Deadlock Avoidance Algorithms
§ If a system is in safe state ⇒ no deadlocks.
Avoidance Algorithms for 2 Cases:
§ If a system is in unsafe state ⇒ possibility of deadlock.
§ Case 1: All resource types have 1 instance only
•
§ Avoidance:
ensure that a system will
never enter an unsafe state.
Resource Allocation Graph Algorithm
§ Case 2: Multiple instances per resource type
•
Banker’s Algorithm
??
grant request
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.17
© Silberschatz, Galvin and Gagne 2005
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.18
© Silberschatz, Galvin and Gagne 2005
3
Resource-Allocation Graph Algorithm
Unsafe State In Resource-Allocation Graph
§ Claim edge Pi → Rj
indicates that process Pi may request
resource Rj
• represented by a dashed line.
§ Claim edge converts to
request edge when the process
requests the resource.
Resource
assignment
§ When a resource is released
by a process, assignment edge
reconverts to a claim edge.
request
claim
If this claim turns
into a request,
then we have a
deadlock!
§ Resources must be claimed
a priori in the system.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
Banker’s Algorithm
© Silberschatz, Galvin and Gagne 2005
7.19
[Dijkstra 1965] [Habermann 1968]
© Silberschatz, Galvin and Gagne 2005
n = number of processes, Pi
m = number of resources types, Rj
§ Available: Vector of length m.
Available [j] = k iff k instances of resource type Rj available
§ Each process must a priori claim maximum use.
§ When a process requests a resource, it may have to wait.
§ Max: n x m matrix.
Max [i,j] = k ⇒ Pi may request at most k instances of Rj
§ When a process gets all its resources,
it must return them in a finite amount of time.
§ Allocation: n x m matrix.
Allocation[i,j] = k iff Pi is currently allocated k instances of Rj
§ Principle: System is always in a safe state.
§ Need: n x m matrix.
Need[i,j] = k ⇒ Pi may need k more instances of Rj
to complete its task.
Need [i,j] = Max[i,j] – Allocation [i,j]
§ At each new resource request:
1. Assume the request is granted
2. Check if the resulting system is in a safe state
3. If so – grant the request, otherwise delay it.
7.21
7.20
Data Structures for the Banker’s Algorithm
§ Supports multiple instances of a resource type.
• Current state: # held resources of each type per process
• State transition: grant a request or get back a resource
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
© Silberschatz, Galvin and Gagne 2005
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.22
© Silberschatz, Galvin and Gagne 2005
Safety Algorithm: Is the system in a safe state?
Resource-Request Algorithm for Process Pi
1. Vectors Work[m] and Finish[n], initialized to:
Work = Available
Requesti: request vector for process Pi.
Requesti [ j ] = k iff Pi wants k instances of resource type Rj.
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.
Remember for
what processes
we already found
a safe path.
Find unfinished process
that can claim its
remaining need
Finish and return
all its allocated
resources
Time required: O(m
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.23
1. If Requesti ≤ Needi go to step 2.
Otherwise, error(“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;
n2)
© Silberschatz, Galvin and Gagne 2005
l
If safe ⇒ the resources are allocated to Pi.
l
If unsafe ⇒ Pi must wait, and the old resource-allocation
state is restored.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.24
© Silberschatz, Galvin and Gagne 2005
4
Example of Banker’s Algorithm
Example (Cont.)
§ 5 processes P0 … P4
§ 3 resource types:
A (10 instances), B (5 instances), C (7 instances)
§ Snapshot at time T0:
Allocation
Need := Max – Allocation:
Max
Available
P0
P1
ABC
010
200
ABC
753
322
ABC
332
P2
P3
P4
302
211
002
902
222
433
P0
P1
Need
ABC
743
122
P2
P3
P4
600
011
431
§ The system is in a safe state if we can find a sequence of
execution that finish all processes (satisfies safety criteria).
We will show < P1, P3, P4, P2, P0> is such sequence.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
© Silberschatz, Galvin and Gagne 2005
7.25
Find a sequence that satisfies the safety criteria:
1. Scan for a Pi where Need[Pi] ≤ Work
2. At each ”ok”, pretend Pi allocates it’s full resource need and
finish execution, thereby releasing all allocated resources.
Need
Alloc
Work := Available
ABC 725
[3 3 2]
P0
743
010
not ok [7 4 3] > [3 3 2]
P1
122
200
ok [1 2 2] < [3 3 2]
P2
600
302
P3
011
211
P4
431
002
Not enough
resources available
for P0 to finish
immediately
Let P1 finish and
release it’s resources:
work := [3 3 2] + [2 0 0]
= [5 3 2]
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
© Silberschatz, Galvin and Gagne 2005
7.26
Example (Cont.)
Example (Cont.)
Find a sequence that satisfies the safety criteria:
1. Scan for a Pi where Need[Pi] ≤ Work
2. At each ”ok”, pretend Pi allocates it’s full resource need and
finish execution, thereby releasing all allocated resources.
Find a sequence that satisfies the safety criteria:
1. Scan for a Pi where Need[Pi] ≤ Work
2. At each ”ok”, pretend Pi allocates it’s full resource need and
finish execution, thereby releasing all allocated resources.
Need
Alloc
Work := Available
Need
ABC 725
[3 3 2]
[5 3 2]
P0
743
010
not ok
no: [7 4 3] > [5 3 2]
P1
122
200
ok
P2
600
302
no: [6 0 0] > [5 3 2]
P3
011
211
ok: [0 1 1] < [5 3 2]
P4
431
002
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
Work :=
[5 3 2] + [2 1 1]
= [7 4 3]
… (already finished)
© Silberschatz, Galvin and Gagne 2005
7.27
Example (Cont.)
Alloc
Work := Available
ABC 725
[3 3 2]
[5 3 2]
[7 4 3]
[7 5 3]
[10 5 5]
P0
743
010
not ok
no
ok
…
…
P1
122
200
ok
…
…
…
…
P2
600
302
no
P3
011
211
ok
P4
431
002
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
Work := Available
[3 3 2]
[5 3 2]
[7 4 3]
P0
743
010
not ok
no
ok: [7 4 3] == [7 4 3]
P1
122
200
ok
…
…
P2
600
302
no
P3
011
211
ok
P4
431
002
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
…
© Silberschatz, Galvin and Gagne 2005
7.28
Example (Cont.)
Find a sequence that satisfies the safety criteria:
1. Scan for a Pi where Need[Pi] ≤ Work
2. At each ”ok”, pretend Pi allocates it’s full resource need and
finish execution, thereby releasing all allocated resources.
Need
Alloc
ABC 725
…
ok
…
…
…
ok
7.29
© Silberschatz, Galvin and Gagne 2005
Need Alloc Work := Available
A B C 7 2 5 [3 3 2] [5 3 2] [7 4 3] [7 5 3] [10 5 5]
P0 7 4 3 0 1 0 no
P1 1 2 2 2 0 0 ok
P2 6 0 0 3 0 2
no
…
no
ok
…
…
…
ok
…
…
…
P3 0 1 1 2 1 1
P4 4 3 1 0 0 2
ok
…
…
…
ok
P3
P0
P2
P4
Sequence: <
P1
>
The system is in a safe state!
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.30
© Silberschatz, Galvin and Gagne 2005
5
Alternative Example:
Example Continued: P0-Request (2,2,0)
§ Often several possible sequences for a safe state:
Previous: <P1, P3, P0, P2, P4> but...
§ Check that Request ≤ Available, that is, (2,2,0) ≤ (3,3,2).
Try out the new state. It would be:
Need Alloc Work := Available
Need Alloc Work := Available
A B C 9 4 5 [1 1 2] [3 2 3] [5 2 3] [7 5 3] [10 5 5]
A B C 7 2 5 [3 3 2] [5 3 2] [7 4 3] [7 4 5] [7 5 5]
P0 7 4 3 0 1 0 no
ok
no
P1 1 2 2 2 0 0 ok
…
P2 6 0 0 3 0 2
no
P3 0 1 1 2 1 1
ok
P4 4 3 1 0 0 2
…
…
…
…
ok
…
…
…
ok
…
…
§ ... also <P1, P3, P4, P0, P2> is a possible sequence!
... as well as <P1, P3, P4, P2, P0> as stated in the book!
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
© Silberschatz, Galvin and Gagne 2005
7.31
P0 5 2 3 2 3 0 no
P1 1 2 2 2 0 0 no
P2 6 0 0 3 0 2 no
no
ok
ok
…
…
…
ok
…
…
…
P3 0 1 1 2 1 1 ok
P4 4 3 1 0 0 2
…
…
…
…
ok
Sequence: <
P3
P1
P0
P2
P4
>
Executing safety algorithm shows that <P3, P1, P0, P2, P4>
satisfies safety requirement. => commit new state.
§ Can following request for (1,2,0) by P1 be granted?
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.32
© Silberschatz, Galvin and Gagne 2005
Example Continued: P2-Request (1,0,0)
Weaknesses of the Banker’s Algorithm
§ Can request for (1,0,0) by P2 be granted?
§ Assumes a fixed number of resources
§ Check that Request ≤ Available, that is, (1,0,0) ≤ (1,1,2).
Try out the new state. It would be:
Need Alloc Work := Available
§ Assumes a fixed population of processes
•
A B C 10 4 5 [0 1 2] [2 2 3] [4 2 3]
P0 5 2 3 2 3 0 no
no
no
P1 1 2 2 2 0 0 no
ok
…
P2 5 0 0 4 0 2 no
P3 0 1 1 2 1 1 ok
…
not realistic – number of resources can vary over time
not realistic for interactive systems
§ Assumes that processes state maximum needs in advance
Unsafe
state!
no
P4 4 3 1 0 0 2
•
•
often not known
(depend e.g. on input data or user commands)
…
no
No sequence exist. Request can not be safely granted.
=> Deny and restore changes.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.33
© Silberschatz, Galvin and Gagne 2005
Deadlock Detection and Recovery
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.34
© Silberschatz, Galvin and Gagne 2005
Deadlock Detection,
Single Instance of Each Resource Type
Resource-Allocation Graph
§ Allow system to enter deadlock state
§ Detection algorithm
•
•
Corresponding
wait-for graph
§ Maintain wait-for graph
•
•
Single instance of each resource type
Multiple instances
§ Recovery scheme
Nodes are processes.
Pi → Pj
iff Pi is waiting for Pj.
§ Periodically invoke an algorithm
that searches for a cycle in the graph.
§ An algorithm to detect a cycle in a graph with O( n2 ) edges
(e.g., depth-first based) requires O( n2 ) operations,
where n = number of vertices in the graph.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.35
© Silberschatz, Galvin and Gagne 2005
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.36
© Silberschatz, Galvin and Gagne 2005
6
Deadlock Detection,
Several Instances of a Resource Type
§ Available: vector of length m
indicates the number of available resources of each type.
§ Allocation: n x m matrix
defines the number of resources of each type currently
allocated to each process.
Detection Algorithm
[Coffman et al. 1971]
1. Vectors Work[m], Finish[n] initialized by:
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
Difference to Banker’s Algorithm
(safe state): Consider the actual request
(optimistically), not the maximum needs.
Reason: We compute if there is now a
deadlock, not if one may happen later.
If no such i exists, go to step 4.
§ Request: n x m matrix
indicates the currently pending requests of each process.
Request [i, j] = k iff Pi is requesting k more instances of Rj.
3. Work = Work + Allocationi
Finish[i] = true
go to step 2.
Algorithm requires
O(m n2) operations
to detect whether
the system is in
deadlocked state.
4. If Finish[i] == false, for some i, 1 ≤ i ≤ n,
then the system is in deadlock state.
Specifically, if Finish[i] == false, then Pi is deadlocked.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
© Silberschatz, Galvin and Gagne 2005
7.37
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
© Silberschatz, Galvin and Gagne 2005
7.38
Example of Detection Algorithm
Example (Cont.)
§ 5 processes P0 … P4
§ P2 requests an additional instance of type C.
§ 3 resource types:
A (7 instances), B (2 instances), C (6 instances)
Request
§ Snapshot at time T0:
Allocation Request
ABC
000
P0
000
Available
P1
201
ABC
ABC
ABC
P2
001
P0
010
000
000
P3
100
P1
200
202
P4
002
P2
303
000
P3
211
100
P4
002
002
§ State of system?
§ Sequence <P0, P2, P3, P1, P4> yields Finish[i] = true for all i.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
Available
ABC
7.39
© Silberschatz, Galvin and Gagne 2005
•
Can reclaim resources held by process P0, but insufficient
resources to fulfill other process’ requests.
•
Deadlock exists, consisting of processes P1, P2, P3, P4.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.40
© Silberschatz, Galvin and Gagne 2005
Detection-Algorithm Usage
Recovery from Deadlock: Process Termination
§ When, and how often, to invoke depends on:
• How often a deadlock is likely to occur?
§ Abort all deadlocked processes.
•
How many processes will need to be rolled back?
> one for each disjoint cycle
§ Abort one process at a time until the deadlock cycle is
eliminated.
§ In which order should we choose to abort?
§ Invocation at every resource request?
• Too much overhead
•
•
Priority of the process.
§ Occasional invocation?
(e.g., once per hour, or whenever CPU utilization below 40%)
• 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.
•
•
•
Resources the process has used.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.41
© Silberschatz, Galvin and Gagne 2005
How long process has computed,
and how much longer to completion.
Resources the process needs to complete.
How many processes will need to be terminated.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.42
© Silberschatz, Galvin and Gagne 2005
7
Recovery from Deadlock: Resource Preemption
§ Deadlock characterization
• 4 necessary conditions
§ Selecting a victim
•
minimize cost
• Resource allocation graph
§ Deadlock prevention
• Prohibit one of the four necessary conditions
§ Rollback
•
return to some safe state,
restart process for that state.
§ Deadlock avoidance
• 1 instance-resources: Resource allocation graph algorithm
§ Starvation
•
Summary
same process may always be picked as victim,
include number of rollbacks in cost factor.
• Banker’s algorithm (state safety, request granting)
§ Deadlock detection and recovery
• 1 instance-resources: Find cycles in Wait-for graph
• Several instances: Deadlock detection algorithm
§ Do nothing – lift the problem to the user / programmer
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.43
© Silberschatz, Galvin and Gagne 2005
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
7.44
© Silberschatz, Galvin and Gagne 2005
8
Download