Operating Systems - Deadlocks€¦ · Deadlock detection Recovery from deadlock Stephan Sigg Operating Systems 22/86. Deadlocks Handling of deadlocks Three possible approaches to
Post on 15-Nov-2020
2 Views
Preview:
Transcript
Operating SystemsDeadlocks
Stephan Sigg
Distributed and Ubiquitous SystemsTechnische Universitat Braunschweig
November 30, 2010
Stephan Sigg Operating Systems 1/86
Overview and Structure
Introduction to operating systemsHistoryArchitectures
ProcessesProcesses, Threads, IPC, SchedulingSynchronisationDeadlocks
Memory managementPagingSegmentation
Filesystems
Security and Protection
Distributed systems
Cryptography
Stephan Sigg Operating Systems 2/86
OutlineDeadlocks
1 DeadlocksSystem modelDeadlock characterisationResource allocation graphHandling of deadlocks
Deadlock preventionDeadlock avoidance
Deadlock detectionRecovery from deadlock
Stephan Sigg Operating Systems 3/86
DeadlocksIntroduction
Several processes compete for finite number of resources
Processes request resources
When resources not available, process enters waiting state
When resources are held by other waiting processes, theprocess might wait indefinitely
This situation is called a deadlock
Stephan Sigg Operating Systems 4/86
DeadlocksIntroduction
Example
’When two trains approach each other at a crossing, both shallcome to a full stop and neither shall start up again until the otherhas gone’a
aExcerpt from a low passed by the Kansas legislature early in the 20thcentury
Stephan Sigg Operating Systems 5/86
DeadlocksIntroduction
Several methods to detect, prevent or deal with deadlocksexist
Operating systems typically do not providedeadlock-prevention facilities
Programmer has to ensure deadlock-free programs
Stephan Sigg Operating Systems 6/86
OutlineDeadlocks
1 DeadlocksSystem modelDeadlock characterisationResource allocation graphHandling of deadlocks
Deadlock preventionDeadlock avoidance
Deadlock detectionRecovery from deadlock
Stephan Sigg Operating Systems 7/86
DeadlocksSystem model
System model
Processes request resources beforeusing them
Processes release resources after usingthem
A process may request as manyresources as it requires
Stephan Sigg Operating Systems 8/86
DeadlocksSystem model
System model
A process utilises a resource in the following sequence
Request Process requests the resource. If resource is notavailable, requesting process must wait
Use Process operates on the resourceRelease The process releases the resource
Stephan Sigg Operating Systems 9/86
OutlineDeadlocks
1 DeadlocksSystem modelDeadlock characterisationResource allocation graphHandling of deadlocks
Deadlock preventionDeadlock avoidance
Deadlock detectionRecovery from deadlock
Stephan Sigg Operating Systems 10/86
DeadlocksDeadlock Characterisation
Necessary conditions for a deadlock
Mutual exclusion
Hold and wait
No preemption
Circular wait
holds re
quests
requests
holds
Stephan Sigg Operating Systems 11/86
DeadlocksDeadlock Characterisation
Mutual exclusion
Resources held exclusivelyby one process at most
Other processesrequesting the resourceare delayed until theresource is released
requests
holds
Stephan Sigg Operating Systems 12/86
DeadlocksDeadlock Characterisation
Hold and wait
A process must hold atleast one resource andwait to acquire additionalresources
These additional resourcesare currently held byother processes
holds re
quests
requests
holds
Stephan Sigg Operating Systems 13/86
DeadlocksDeadlock Characterisation
No preemption
Resources cannot bepreempted
A resource is released bya process only after thatprocess has completed itstask
holds re
quests
requests
holds
Stephan Sigg Operating Systems 14/86
DeadlocksDeadlock Characterisation
Circular wait
A set P0, . . . ,Pn of waiting processes must exist
Such that Pi is waiting for a resource held by P(i+1) mod n
holds
waits
waits
holds waits
holds
Stephan Sigg Operating Systems 15/86
OutlineDeadlocks
1 DeadlocksSystem modelDeadlock characterisationResource allocation graphHandling of deadlocks
Deadlock preventionDeadlock avoidance
Deadlock detectionRecovery from deadlock
Stephan Sigg Operating Systems 16/86
DeadlocksResource allocation graph
Resource allocation graph
Deadlocks can be described in termsof a directed graph
Vertexes are partitioned into two typesof nodes:
P = {P1, . . . ,Pn} (processes)R = {R1, . . . ,Rm} (resources)
Directed edge Pi → Rj indicates thatPi requests and waits for Rj
Directed edge Rj → Pi indicates, thatPi holds Rj
P Ri j
Pi Rj
Stephan Sigg Operating Systems 17/86
DeadlocksResource allocation graph
Example
P = {P1, P2, P3}R = {R1, R2, R3, R4}E = {P1 → R1, P2 → R3, R1 → P2, R2 → P2, R2 → P1, R3 →P3, }Resource instances
One instance of resource R1
Two instances of resource R2
One instance of resource R3
Three instances of resource R4
Process state:
P1 holds an instance of R2 and waits for R1
P2 holds an instance of R1 and waits for R3
P3 holds an instance of R3
Stephan Sigg Operating Systems 18/86
DeadlocksResource allocation graph
P
R
1
1 R2
R2
R3R4
R4
R4
P2 P3
Stephan Sigg Operating Systems 19/86
DeadlocksResource allocation graph
P
R
1
1 R2
R3R4
P2 P3
. ..
....Stephan Sigg Operating Systems 20/86
DeadlocksResource allocation graph
Deadlock detection
If the graph contains no cycles, no process is deadlockedOtherwise a deadlock may existWhen each resource type has one instance, a cycle impliesthat a deadlock occurredOtherwise, a deadlock exists, if all resource types in the cycleare exclusively allocated to processes in the cycle
P
R
1
1 R2
R3R4
P2 P3
. ..
....P
R
1
1 R2
R3R4
P2 P3
. ..
....
Stephan Sigg Operating Systems 21/86
OutlineDeadlocks
1 DeadlocksSystem modelDeadlock characterisationResource allocation graphHandling of deadlocks
Deadlock preventionDeadlock avoidance
Deadlock detectionRecovery from deadlock
Stephan Sigg Operating Systems 22/86
DeadlocksHandling of deadlocks
Three possible approaches to handle deadlocks:
Use a protocol that prevents or avoids deadlocks so that adeadlocked state is never reached
Detect deadlocks at their occurrence and recover
Ignore the problem
holds re
quests
requests
holds
holds re
quests
requests
requests
holds
holds re
questsrequests
Stephan Sigg Operating Systems 23/86
DeadlocksHandling of deadlocks
The last solution is actuallyimplemented most often in operatingsystems
Including UNIX and Windows systems
Deadlock occurrence is very rare
Therefore, the cost of addressing thisproblem is often seen as not critical
holds re
quests
requests
holds
Stephan Sigg Operating Systems 24/86
DeadlocksHandling of deadlocks
To ensure that a deadlock neveroccurs, the system can use
Deadlock prevention schemes
Ensure that at least one of thenecessary conditions is not met
Deadlock avoidance schemes
Schedule resource utilisation byprocessesBased on additional knowledge onprocessese.g. Resources requestede.g. lifetime
holds re
quests
requests
requests
Stephan Sigg Operating Systems 25/86
DeadlocksHandling of deadlocks
When no deadlock prevention ordeadlock avoidance scheme isemployed, a deadlock may occur
In this case, the system requiresalgorithms to
detect whether a deadlock hasoccurredrecover from the deadlock
holds
holds re
questsrequests
Stephan Sigg Operating Systems 26/86
DeadlocksHandling of deadlocks
When the system can not detect orrecover from deadlocks, the systemmight be unable to recognise theproblem
The performance of the system willdeteriorate
More and more processes enter adeadlocked state as they require aresource that is never released
Eventually the system will stopfunctioning
Manual restart is required
holds re
quests
requests
holds
Stephan Sigg Operating Systems 27/86
DeadlocksDeadlock prevention
Deadlock prevention
For a deadlock to occur, each of the following conditionsmust hold
Mutual exclusionHold and waitNo preemptionCircular wait
By ensuring that at least one of these conditions cannot hold,occurrence of deadlocks is prevented
requests
holds
holds re
quests
requests
holds
holds re
quests
requests
holds
holds
waits
waits
holds
waits
holds
Stephan Sigg Operating Systems 28/86
DeadlocksDeadlock prevention
Deadlock prevention – Mutual exclusion
Mutual exclusion must hold fornonsharable resources
Some resources, e.g. a read-only-filedo not require to meet this condition
In general, however, we cannot preventdeadlocks by denying mutual exclusionas some resources are nonsharable
requests
holds
Stephan Sigg Operating Systems 29/86
DeadlocksDeadlock prevention
Deadlock prevention – Hold and wait
In order to prevent hold and waitcondition, we must guarantee that
A process requesting a resource doesnot hold any other resources
Possible implementations:
System calls requesting resourcesmust precede all other system callsA process may request one ormany resources only when it holdsnone
holds re
quests
requests
holds
Stephan Sigg Operating Systems 30/86
DeadlocksDeadlock prevention
Deadlock prevention – Hold and wait
Disadvantages of these solutions
Resource utilisation may be low sinceresources may be allocated for a longperiodStarvation is possible when popularresources are repeatedly allocated toother processes
holds re
quests
requests
holds
Stephan Sigg Operating Systems 31/86
DeadlocksDeadlock prevention
Deadlock prevention – No preemption
The following protocol can prevent theno-preemption-condition:
Processes that wait on a request foradditional resources, allowpreemption of their currently holdresourcesResources are preempted only ifrequested by other processesFeasible for resources whose statecan be easily saved and restored(e.g. CPU registers, memory space)
Not applicable for some resources
e.g. printers, tape drives
holds re
quests
requests
holds
Stephan Sigg Operating Systems 32/86
DeadlocksDeadlock prevention
Deadlock prevention - Circular wait
Avoidance of circular wait: Total ordering of resource types
Resources requested in an increasing order by a processAll resources of one resource type must be requested at once
With this protocol, a cycle in the resource graph is impossible
holds
waits
waitsholds
waits
holds
Stephan Sigg Operating Systems 33/86
DeadlocksDeadlock avoidance
Deadlock avoidance
Deadlock prevention has negative side-effects:
Low device utilisationReduced system throughput
Alternative: Avoid deadlocks with the help of additionalinformation
Order in which processes request resourcesResource types and count required by processes
Typically: Ensure that deadlock can not occur by analysingthe resource allocation state
Available resourcesAllocated resourcesMaximum resource demand
Stephan Sigg Operating Systems 34/86
DeadlocksDeadlock avoidance
Safe state
A state is safe, if the system can allocate resources to eachprocess in some order and still avoid a deadlock
System is in a safe state if it exists a safe sequence (that doesnot end in a deadlock)
A sequence of processes P1, . . . ,Pn is safe, if for each Pi allresource requests can be fulfilled in order
If no such sequence exists, the state is unsafe
As long as the state is safe, the system can avoid deadlocks
Stephan Sigg Operating Systems 35/86
DeadlocksDeadlock avoidance
Safe state
Example
Max. Need Allocated free
P0 10 5P1 4 2P2 9 2
free 3
Stephan Sigg Operating Systems 36/86
DeadlocksDeadlock avoidance
Safe state
Example
Max. Need Allocated free
P0 10 5P1 4 4P2 9 2
free 1
Stephan Sigg Operating Systems 37/86
DeadlocksDeadlock avoidance
Safe state
Example
Max. Need Allocated free
P0 10 5P1 0 0P2 9 2
free 5
Stephan Sigg Operating Systems 38/86
DeadlocksDeadlock avoidance
Safe state
Example
Max. Need Allocated free
P0 10 10P1 0 0P2 9 2
free 0
Stephan Sigg Operating Systems 39/86
DeadlocksDeadlock avoidance
Safe state
Example
Max. Need Allocated free
P0 0 0P1 0 0P2 9 2
free 10
Stephan Sigg Operating Systems 40/86
DeadlocksDeadlock avoidance
Safe state
Example
Max. Need Allocated free
P0 0 0P1 0 0P2 9 9
free 3
Stephan Sigg Operating Systems 41/86
DeadlocksDeadlock avoidance
Safe state
Example
Max. Need Allocated free
P0 0 0P1 0 0P2 0 0
free 12
Stephan Sigg Operating Systems 42/86
DeadlocksDeadlock avoidance
Safe stateWhen resources are differently allocated, a deadlock may occur:
Example
Max. Need Allocated free
P0 10 5P1 4 2P2 9 2
free 3
Stephan Sigg Operating Systems 43/86
DeadlocksDeadlock avoidance
Safe stateWhen resources are differently allocated, a deadlock may occur:
Example
Max. Need Allocated free
P0 10 5P1 4 2P2 9 3
free 2
Stephan Sigg Operating Systems 44/86
DeadlocksDeadlock avoidance
Deadlock avoidance algorithms try to prevent circular wait
This is achieved, when the safe system state is never left
Whenever a process requests a resource, the algorithm checks,if the system would then traverse to an unsafe stateThe resource is granted only when the safe state is not leftOtherwise, the process has to wait
No deadlock is possible under this precondition
Stephan Sigg Operating Systems 45/86
DeadlocksDeadlock avoidance
Resource allocation algorithm
One instance of each resource:
Avoid deadlocks withresource-allocation graph
We introduce claim edges
Pi → Rj indicates that process Pi
might request Rj in the futureRepresented by dashed line
Resource request: Verify if allocationresults in circle
If not, the resource is allocated
Else, deadlock would result fromallocation: process waits
P1 P2
R1 .
R2 .
Resource allocation graphs
P1 P2
R1 .
R2 .An
unsa
fe s
tate
A s
afe
stat
e
Stephan Sigg Operating Systems 46/86
DeadlocksDeadlock avoidance
Resource allocation algorithm
Resource-allocation algorithm notapplicable when multiple instances perresource type exist
Calculation of circles: O(|V |2
)
P1 P2
R1 .
R2 .
Resource allocation graphs
P1 P2
R1 .
R2 .An
unsa
fe s
tate
A s
afe
stat
e
Stephan Sigg Operating Systems 47/86
DeadlocksDeadlock avoidance
Banker’s algorithm
When more than one instance of each resource type exists,the banker’s algorithm can be applied
The banker’s algorithm
The name was chosen because the algorithm could be used ina banking system to ensure that the bank never allocated itsavailable cash in such a way that it could no longer satisfy theneeds of all its customers.a
aA. Silberschatz, P.PB Galvin, G. Gagne, Operating System Concepts, 2010
This algorithm is less efficient than the resource-allocationalgorithm
Stephan Sigg Operating Systems 48/86
DeadlocksDeadlock avoidance
Banker’s algorithm
When a new process enters the system, it must declare themaximum number of instances of each resource it mightrequest
This number may not exceed the maximum number ofinstances of these resource types
At resource requests, the system determines wether allocationwould result in a safe state.
If not, the process waits until sufficient number of resourceshave been released
Stephan Sigg Operating Systems 49/86
DeadlocksDeadlock avoidance
Banker’s algorithm
Variables:
Number of processes: nNumber of resource types: m
Data structures required:
Available[j]Max[i][j]Allocation[i][j]Need[i][j]
Resources
Running processes
Requesting processes
Stephan Sigg Operating Systems 50/86
DeadlocksDeadlock avoidance
Banker’s algorithm
Available[j] :
Vector of length mIndicates the number of available resources ofeach resource type
Additional notation for vectors :
X ≤ Y ⇔ X [i ] ≤ Y [i ]; ∀i ∈ {0, . . . , n − 1}X < Y ⇔ X ≤ Y ∩ Y 6= X
Stephan Sigg Operating Systems 51/86
DeadlocksDeadlock avoidance
Banker’s algorithm
Max[i][j] :
n ×m matrixDefines the maximum demand of each processIf Max [i ][j ] = k, process Pi max request up to kinstances of resource type Rj
Maxi :
Specifies the i-th row in Max[i][j]
Stephan Sigg Operating Systems 52/86
DeadlocksDeadlock avoidance
Banker’s algorithm
Allocation[i][j] :
n ×m matrixDefines the number of resources of each typecurrently allocated to processesIf Allocation[i ][j ] = k , process Pi is currentlyallocated k instances of resource type Rj
Allocationi :
Specifies the i-th row in Allocation[i][j]
Stephan Sigg Operating Systems 53/86
DeadlocksDeadlock avoidance
Banker’s algorithm
Need[i][j] :
n ×m matrixIndicates the remaining resource needs of eachprocessIf Need [i ][j ] = k, process Pi may need further kinstances of resource type Rj
Needi :
Specifies the i-th row in Need[i][j]
Stephan Sigg Operating Systems 54/86
DeadlocksDeadlock avoidance
Safety algorithm
The safety algorithm determines if a system is in a safe state:1 Initialise vectors:
Work=Available
Finish[i]=false for i=0,1,. . . ,n-1
2 Find an index i such that
1 Finish[i ] == false2 Needi ≤Work
If no such i exists, go to step 43 Complete the following allocations
1 Work = Work + Allocationi
2 Finish[i]=true
Go to step 24 If Finish[i ] == true for all i, state is safe
Stephan Sigg Operating Systems 55/86
DeadlocksDeadlock avoidance
Safety algorithm
The safetey algorithm runs in timeO
(m · n2
)
Resources
Running processes
Requesting processes
Stephan Sigg Operating Systems 56/86
DeadlocksDeadlock avoidance
Resource request algorithm determines insecure transitions:
Let Requesti be the request vector
If Requesti [j ] == k , process Pi requests k instances of Rj
When resource requested the following actions are taken:1 If Requesti ≤ Needi
Go to step 2Otherwise: error, since process has exceeded maximum claim
2 If Requesti ≤ Available
Go to step 3Otherwise Pi must wait since no resources are available
3 Modify the state as follows
Available = Available − RequestiAllocationi = Allocationi + RequestiNeedi = Needi − Requesti
Only if resulting state is safe, transaction is executed.
Stephan Sigg Operating Systems 57/86
DeadlocksDeadlock avoidance
Example
Processes: P0, P1, P2, P3, P4
Resource types: A (10 instances); B (5 instances); C (7instances)
The system at T0: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 2P1 2 0 0 3 2 2 1 2 2P2 3 0 2 9 0 2 6 0 0P3 2 1 1 2 2 2 0 1 1P4 0 0 2 4 3 3 4 3 1
Stephan Sigg Operating Systems 58/86
DeadlocksDeadlock avoidance
Example
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 2P1 2 0 0 3 2 2 1 2 2P2 3 0 2 9 0 2 6 0 0P3 2 1 1 2 2 2 0 1 1P4 0 0 2 4 3 3 4 3 1
The system is in a safe state, since the sequence P1, P3, P4, P2, P0
is possible
Stephan Sigg Operating Systems 59/86
DeadlocksDeadlock avoidance
Example
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 2P1 2 0 0 3 2 2 1 2 2P2 3 0 2 9 0 2 6 0 0P3 2 1 1 2 2 2 0 1 1P4 0 0 2 4 3 3 4 3 1
Assume the request Request1 = (1, 0, 2)
Stephan Sigg Operating Systems 60/86
DeadlocksDeadlock avoidance
Example
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 2P1 2 0 0 3 2 2 1 2 2P2 3 0 2 9 0 2 6 0 0P3 2 1 1 2 2 2 0 1 1P4 0 0 2 4 3 3 4 3 1
First: Test Request1 ≤ Available
(1, 0, 2) ≤ (3, 3, 2)→ true
Stephan Sigg Operating Systems 61/86
DeadlocksDeadlock avoidance
The resulting state would be:
Example
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 0P1 3 0 2 3 2 2 0 2 0P2 3 0 2 9 0 2 6 0 0P3 2 1 1 2 2 2 0 1 1P4 0 0 2 4 3 3 4 3 1
The safety algorithm determines that the sequenceP1, P3, P4, P0, P2 leads to a safe state
Stephan Sigg Operating Systems 62/86
DeadlocksDeadlock avoidance
Assume a further request Request4 = (3, 3, 0):
Example
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 2P1 3 0 2 3 2 2 0 2 0P2 3 0 2 9 0 2 6 0 0P3 2 1 1 2 2 2 0 1 1P4 0 0 2 4 3 3 4 3 1
Stephan Sigg Operating Systems 63/86
DeadlocksDeadlock avoidance
The resulting state would be:
Example
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 0 0 2P1 3 0 2 3 2 2 0 2 0P2 3 0 2 9 0 2 6 0 0P3 2 1 1 2 2 2 0 1 1P4 3 3 2 4 3 3 1 0 1
The safety algorithm determines that this state would not besafe.
The allocation is not granted
Stephan Sigg Operating Systems 64/86
DeadlocksDeadlock avoidance
Often, algorithms for deadlockavoidance can not be applied inoperating systems
Processes are often not aware whichresources are required during theirexecution
Therefore, Deadlock detection andrecovery strategies might be morefeasible solutions
Resources
Running processes
Requesting processes
Stephan Sigg Operating Systems 65/86
OutlineDeadlocks
1 DeadlocksSystem modelDeadlock characterisationResource allocation graphHandling of deadlocks
Deadlock preventionDeadlock avoidance
Deadlock detectionRecovery from deadlock
Stephan Sigg Operating Systems 66/86
DeadlocksDeadlock detection
Deadlock detection
A system that does not inheritdeadlock-prevention or -avoidancemethod may provide
An algorithm that determines if adeadlock has occurredAn algorithm to recover from thedeadlock
A detection and recovery scheme hasadditional overhead
Run-time cost to maintain necessaryinformationExecution of the detection algorithmPotential losses as a result ofdeadlock recovery
holds re
quests
requests
requests
Stephan Sigg Operating Systems 67/86
DeadlocksDeadlock detection
Single instance of resource types
If all resources have only one instancewe can detect a deadlock again on theresource-allocation graph
The algorithm searches for cycles inthe graph
A cycle indicates a deadlock
holds re
quests
requests
requests
Stephan Sigg Operating Systems 68/86
DeadlocksDeadlock detection
Multiple instance of resource types
When resource types with multiple instances exist, a differentalgorithm has to be applied:
Variables:
Number of processes: nNumber of resource types: m
Data structures required:
Available[j]: Vector of length m that indicates the numberof available resources of each typeAllocation[i][j]: An n ×m matrix that defines thenumber of resources currently allocatedRequest[i][j]: An n ×m matrix that defines the number ofresources currently requested
Stephan Sigg Operating Systems 69/86
DeadlocksDeadlock detection
Safetey algorithm determines if system is in unsafe state:1 Initialise vectors:
Work=Available
For i=0,...,n-1: If Allocationi 6= 0 then
Finish[i]=false, else Finish[i]=true
2 Find an index i such that
1 Finish[i ] == false2 Requesti ≤Work
If no such i exists, go to step 43 Complete the following allocations
1 Work = Work + Allocation2 Finish[i]=true
Go to step 24 If Finish[i ] == false for some i, the system is in a deadlocked
state and Pi is deadlocked.
The runtime of the algorithm is O(m · n2
)Stephan Sigg Operating Systems 70/86
DeadlocksDeadlock detection
Multiple instance of resource types
Example
Processes: P0, P1, P2, P3, P4
Resource types: A (7 instances); B (2 instances); C (6instances)
The system at T0:Allocation RequestMax Available
A B C A B C A B C
P0 0 1 0 0 0 0 0 0 0P1 2 0 0 2 0 2P2 3 0 3 0 0 0P3 2 1 1 1 0 0P4 0 0 2 0 0 2
Stephan Sigg Operating Systems 71/86
DeadlocksDeadlock detection
Multiple instance of resource types
Example
Allocation RequestMax Available
A B C A B C A B C
P0 0 1 0 0 0 0 0 0 0P1 2 0 0 2 0 2P2 3 0 3 0 0 0P3 2 1 1 1 0 0P4 0 0 2 0 0 2
The state is not deadlocked:
The sequence P0, P2, P3, P1, P4 can be executed successfully
Stephan Sigg Operating Systems 72/86
DeadlocksDeadlock detection
Multiple instance of resource types
Assume that process P2 makes one additional request for aninstance of type C:
Example
Allocation RequestMax Available
A B C A B C A B C
P0 0 1 0 0 0 0 0 0 0P1 2 0 0 2 0 2P2 3 0 3 0 0 1P3 2 1 1 1 0 0P4 0 0 2 0 0 2
Stephan Sigg Operating Systems 73/86
DeadlocksDeadlock detection
Assume that process P2 makes one additional request for aninstance of type C:
Example
Allocation RequestMax Available
A B C A B C A B C
P0 0 1 0 0 0 0 0 0 0P1 2 0 0 2 0 2P2 3 0 3 0 0 1P3 2 1 1 1 0 0P4 0 0 2 0 0 2
The state is now deadlockedNumber of resources reclaimed from P0 is not sufficientA deadlock exists that contains the processes P1, P2, P3, P4
Stephan Sigg Operating Systems 74/86
OutlineDeadlocks
1 DeadlocksSystem modelDeadlock characterisationResource allocation graphHandling of deadlocks
Deadlock preventionDeadlock avoidance
Deadlock detectionRecovery from deadlock
Stephan Sigg Operating Systems 75/86
DeadlocksRecovery from deadlock
Detection algorithm usage
The frequency by which the detection algorithm should beinvoked depends on
1 The frequency by which deadlocks occur2 The number of processes that will be affected by a deadlock
The more often the algorithm is invoked, the less do weexpect the impact of system performance deterioration
However, this has to be balanced with the runtime-cost of thealgorithm
Stephan Sigg Operating Systems 76/86
DeadlocksRecovery from deadlock
Recovery from deadlock
When a deadlock is detected, severalalternatives for recovery are available
Inform an operator of the deadlockoccurrenceTry to recover
1 Process termination2 Preemption of resources
holds re
quests
requests
holds
Stephan Sigg Operating Systems 77/86
DeadlocksRecovery from deadlock
Process termination
One or more processes in the circularwait are aborted
Abort all deadlocked processes Breaksdeadlock cycle but it ismore likely, that lengthycomputations need to berecomputed
Abort one process at a time Aftereach aborted process,deadlock detectioninvoked. This mightinduce considerableoverhead.
holds re
quests
requests
holds
Stephan Sigg Operating Systems 78/86
DeadlocksRecovery from deadlock
Process termination
Problems upon process termination
If the process was in the middle ofupdating a file, the file may then bein an incorrect stateSimilarly: Printer access
holds re
quests
requests
holds
Stephan Sigg Operating Systems 79/86
DeadlocksRecovery from deadlock
Resource preemption
Resources from processes aresuccessively preempted until deadlockis broken
Aspects to consider:
Process that is impactedRollback
Starvation
holds re
quests
requests
holds
Stephan Sigg Operating Systems 80/86
DeadlocksRecovery from deadlock
Resource preemption – Process impacted
Which resources and which processesare preempted?
Minimum cost (process priority,current computation time,...)Consider number of resources aprocess is holding
holds re
quests
requests
holds
Stephan Sigg Operating Systems 81/86
DeadlocksRecovery from deadlock
Resource preemption – Rollback
The process from which the resourcewas taken can not continue normalexecution
We must roll back to some safe state
Simplest solution: Total rollback
Otherwise all running processes mustprovide more information on theirstate
holds re
quests
requests
holds
Stephan Sigg Operating Systems 82/86
DeadlocksRecovery from deadlock
Resource preemption – Starvation
Can we ensure that no starvationoccurs?
Can we guarantee that not always theresources from the same processes arepreempted?
Most common solution: Number ofrollbacks as one cost factor
holds re
quests
requests
holds
Stephan Sigg Operating Systems 83/86
OutlineDeadlocks
1 DeadlocksSystem modelDeadlock characterisationResource allocation graphHandling of deadlocks
Deadlock preventionDeadlock avoidance
Deadlock detectionRecovery from deadlock
Stephan Sigg Operating Systems 84/86
DeadlocksQuestions, discussion, remarks
Questions?
Stephan Sigg Operating Systems 85/86
LiteratureRecommended literature
A. Tanenbaum, Moderne Betriebssysteme, 2nd edition,Prentice Hall, 2009.
A. Tanenbaum, Modern operating systems, 3rd edition,Prentice Hall, 2008.
A. Silberschatz et al. Operating system concepts, Wiley, 2004.
W. Stallings, Operating systems, 6th edition, Prentice Hall,2008.
Stephan Sigg Operating Systems 86/86
top related