Operating Systems - Deadlocks€¦ · Deadlock detection Recovery from deadlock Stephan Sigg Operating Systems 22/86. Deadlocks Handling of deadlocks Three possible approaches to

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


OutlineDeadlocks

1 DeadlocksSystem modelDeadlock characterisationResource allocation graphHandling of deadlocks

Deadlock preventionDeadlock avoidance

Deadlock detectionRecovery from deadlock


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



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



Several methods to detect, prevent or deal with deadlocksexist

Operating systems typically do not providedeadlock-prevention facilities

Programmer has to ensure deadlock-free programs


OutlineDeadlocks





DeadlocksSystem model

System model

Processes request resources beforeusing them

Processes release resources after usingthem

A process may request as manyresources as it requires


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


OutlineDeadlocks





DeadlocksDeadlock Characterisation

Necessary conditions for a deadlock

Mutual exclusion

Hold and wait

No preemption

Circular wait

holds re

quests

requests

holds



Mutual exclusion

Resources held exclusivelyby one process at most

Other processesrequesting the resourceare delayed until theresource is released

requests

holds



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



No preemption

Resources cannot bepreempted

A resource is released bya process only after thatprocess has completed itstask

holds re

quests

requests

holds



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


OutlineDeadlocks





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



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



P

R

1

1 R2

R2

R3R4

R4

R4

P2 P3



P

R

1

1 R2

R3R4

P2 P3

. ..

....Stephan Sigg Operating Systems 20/86


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

. ..

....


OutlineDeadlocks





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



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



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



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



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


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



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



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



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



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



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


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



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



Safe state

Example

Max. Need Allocated free

P0 10 5P1 4 2P2 9 2

free 3



Safe state

Example


P0 10 5P1 4 4P2 9 2

free 1



Safe state

Example


P0 10 5P1 0 0P2 9 2

free 5



Safe state

Example


P0 10 10P1 0 0P2 9 2

free 0



Safe state

Example


P0 0 0P1 0 0P2 9 2

free 10



Safe state

Example


P0 0 0P1 0 0P2 9 9

free 3



Safe state

Example


P0 0 0P1 0 0P2 0 0

free 12



Safe stateWhen resources are differently allocated, a deadlock may occur:

Example


P0 10 5P1 4 2P2 9 2

free 3



Safe stateWhen resources are differently allocated, a deadlock may occur:

Example


P0 10 5P1 4 2P2 9 3

free 2



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



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



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



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




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




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




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




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]




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]




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]



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



Safety algorithm

The safetey algorithm runs in timeO

(m · n2

)

Resources

Running processes




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.



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



Example

Allocation Max Need Available


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



Example



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)



Example



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



The resulting state would be:

Example



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



Assume a further request Request4 = (3, 3, 0):

Example



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



The resulting state would be:

Example



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



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



OutlineDeadlocks





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



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



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



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



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




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




Assume that process P2 makes one additional request for aninstance of type C:

Example


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



Assume that process P2 makes one additional request for aninstance of type C:

Example


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


OutlineDeadlocks





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



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



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



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



Resource preemption

Resources from processes aresuccessively preempted until deadlockis broken

Aspects to consider:

Process that is impactedRollback

Starvation

holds re

quests

requests

holds



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



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



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


OutlineDeadlocks





DeadlocksQuestions, discussion, remarks

Questions?


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.


Documents

Operating Systems - Deadlocks€¦ · Deadlock detection Recovery from deadlock Stephan Sigg Operating Systems 22/86. Deadlocks Handling of deadlocks Three possible approaches to