Operating Systems Principles Process Management and Coordination Lecture 6: Deadlocks

Operating Systems PrinciplesProcess Management and Coordination

Lecture 6: Deadlocks

主講人：虞台文

Content Deadlocks with Reusable and Consumable Resources Approaches to the Deadlock Problem System Model

– Resource Graphs – State Transitions– Deadlock States and Safe States

Deadlock Detection – Reduction of Resource Graphs– Special Cases of Deadlock Detection – Deadlock Detection in Distributed Systems

Recovery from Deadlock Dynamic Deadlock Avoidance

– Claim Graphs – The Banker’s Algorithm

Deadlock Prevention



Deadlocks with Reusable and

Consumable Resources

Deadlocks

Deadlocks Informal definition: Process is blocked

on resource that will never be released. Deadlocks waste resources Deadlocks are rare:

– Many systems ignore them Resolved by explicit user intervention

– Critical in many real-time applications May cause damage, endanger life

Reusable/Consumable Resources

Reusable Resources– Number of units is “constant”– Unit is either free or allocated; no sharing– Process requests, acquires, releases unitsExamples: (h/w) memory, devices (s/w) files, tables

Consumable Resources– Number of units varies at runtime– Process may create new units– Process may consume units (no releasing)Examples: messages, signals

Reusable/Consumable Resources

Reusable Resources– Number of units is “constant”– Unit is either free or allocated; no sharing– Process requests, acquires, releases unitsExamples: (h/w) memory, devices (s/w) files, tables

Consumable Resources– Number of units varies at runtime– Process may create new units– Process may consume units (no releasing)Examples: messages, signals

Main topic of the lecture

Reusable Resources

Example (File Sharing)

p1: ... open(f1,w); open(f2,w); ...

p2: ... open(f2,w); open(f1,w); ...

Deadlock when executed concurrently

Example (Message Passing)

p1: ... if(C)send(p2,m); while(1){ recv(p3,m); ... send(p2,m); }

Deadlock when C is not true

p2: ... while(1){ recv(p1,m); ... send(p3,m); }

p3: ... while(1){ recv(p2,m); ... send(p1,m); }

Assume that send/recv are blocking operations.

Deadlock, Livelock, and Starvation

Deadlock– Two or more processes (threads) are blocked indefinitely, waiting for each other.

Livelock– Processes (threads) run but make no progress– An `active’ form of deadlock.

Starvation– Some Processes (threads) get deferred forever.– E.g., one process dominates, not allowing other processes to progress.

Deadlock and livelock will lead to starvation.But, the inverse is not necessary true.

Examples:Starvation Not Due to Deadlock or Livelock

Deadlock and livelock will lead to starvation.But, the inverse is not necessary true.

Higher-Priority Process dominates:– ML scheduling where one queue is never

empty

Starvation on Memory Blocks: – Total memory is 200MB– Unbounded stream of 100MB requests may

starve a 200MB request



Approaches to the

Deadlock Problem

Approaches to Deadlock Problem

1. Detection and Recovery– Allow deadlock to happen and eliminate it

2. Avoidance (dynamic)– Runtime checks disallow allocations

that might lead to deadlocks3. Prevention (static)

– Restrict type of request and acquisitionto make deadlock impossible



System Model

Resource GraphProcess = CircleResource = Rectangle with small circles for each unitResource Request = Edge from process to resource classResource Allocation = Edge from resource unit to process

State Transitions by p1 Process

R

p1

p2

R

p1

p2

R

p1

p2

R

p1

p2

S0 S1 S2 S3Request R

(by p1)Acquire R

(by p1)Release R

(by p1)

The state transition diagram described below is not complete.The actual number of states depends on possible operations of processes.

Process Operations on Resources

Request: Create new request edge piRj

– pi has no outstanding requests– number of edges between pi and Rj units in RjAcquisition: Reverse request edge to piRj

– All requests of pi are satisfied– pi has no outstanding requests

Release: Remove edge piRj

R

p1

p2

R

p1

p2

R

p1

p2

R

p1

p2

R

p1

p2

R

p1

p2

R

p1

p2

R

p1

p2

R

p1

p2

S0 S1 S2 S3Request R

(by p1)Request R

(by p1)Acquire R

(by p1)Acquire R

(by p1)Release R

(by p1)Release R

(by p1)

Deadlock States and Safe States

A process is blocked in state S if it cannot cause a transition to a new state, i.e.,

– it cannot request, acquire, or release any resource. A Process is Deadlocked in state S if it blocked now

and remains blocked forever.

Deadlock StateA state contains a deadlocked process.

Safe StateNo deadlock state can ever be reached using request, acquire, release.

Example

R1 R2

p1

p2

p1 and p2 both need R1 and R2.

p1: Request(R1); Request(R2);

Release(R2); Release(R1);



Example





Example





Example





Example





Example

R1 R2

p1

p2

Example

p1 is blocked.

p2 is blocked.

Example

A deadlock state.

No state is safe since the deadlock state is always reachable.

Necessary Condition for Deadlock

A cycle in the resource graph is a necessary condition for

deadlock.



Deadlock Detection

Graph Reduction Technique Graph Reduction:

Repeat the following:1. Select unblocked process p2. Remove p and all request and allocation edges

Deadlock Graph not completely reducible.

All reduction sequences lead to the same result.



p1 p2

p4 p5

p3

R1 R2 R3



p1 p2

p4 p5

p3

R1 R2 R3



p1 p2

p4 p5

p3

R1 R2 R3



p1 p2

p4 p5

p3

irreducible

Deadlock detectedR1 R2 R3



Special Cases of Deadlock Detection

Testing for specific process pContinuous deadlock detection Immediate allocationsSingle-unit resources

Testing for specific process

Testing for specific process p:– Reduce until p is removed or graph

irreducible

Testing for specific process p Continuous deadlock detection Immediate allocations Single-unit resources

Continuous Deadlock Detection

Testing for specific process p:– Reduce until p is removed or graph irreducible

Continuous deadlock detection:1. Current state not deadlocked2. Next state T deadlocked only if:

a. Operation was a request by p andb. p is deadlocked in T

3. Try to reduce T by p


Immediate Allocations


All satisfiable requests granted immediately Expedient state = no satisfiable request edges

Grantedimmediately

Non-Expedient State Expedient State

p1 p2

p4 p5

p3

R1 R2 R3

p1 p2

p4 p5

p3

R1 R2 R3

Satisfiable



All satisfiable requests granted immediately Expedient state = no satisfiable request edges Knot K:

– Every node in K reachable from any other node in K– No outgoing edges (only incoming)

Knot in expedient state Deadlock Intuition:

– All processes must have outstanding requests in K– Expedient state requests not satisfiable



Expedient State

p1 p2

p4 p5

p3

R1 R2 R3



Expedient State

p1 p2

p4 p5

p3

R1 R2 R3

Knot

Single-Unit Resources


For single-unit resource, cycle deadlock– Every p must have a request edge to R– Every R must have an allocation edge to p– R is not available and thus p is blocked

p1

p2

R1 R2

p1

p2

R1 R2

DeadlockedNot Deadlocked

Single-Unit Resources


Wait-For Graph (wfg): Show only processes

Deadlock Detection in Distributed Systems

Central Coordinator Approach

Distributed Approach

Central Coordinator Approach

Central Coordinator (CC)– Each machine maintains a local wfg– Changes reported to CC– CC constructs and analyzes global wfg

Problems– Coordinator is a performance bottleneck– Communication delays may cause phantom deadlocks

p2

p1

M1

p3

p4

M2

Phantom Deadlocks

Central Coordinator (CC)– Each machine maintains a local wfg– Changes reported to CC– CC constructs and analyzes global wfg

Problems– Coordinator is a performance bottleneck– Communication delays may cause phantom deadlocks

p2

p1

M1

p3

p4

M2

p2

p1

M1

p3

p4

M2

Due to timeout, p3 cancel the request.

But, the message passed to CC is delayed

p1 requesting the resourceholding by p4 causes phantom deadlock.

phantomedge

Deadlock

Distributed Approach Detect cycles using probes. If process pi blocked on pj , it launches probe pi pj

pj sends probe pi pj pk along all request edges, etc. When probe returns to pi, cycle is detected

p1 p2 p3

p7 p6

p4 p5

M1 M2

M3 M4

p1 p2 p1 p2 p3 p1 p2 p3 p4

p1 p2 p3 p7

p1 p2 p3 p4 p5

p1 p2 p3 p4 p5 p1

p1 p2 p3 p4 p5 p6p1 p2 p3 p4 p5 p6 p4

Distributed Approach Detect cycles using probes. If process pi blocked on pj , it launches probe pi pj

pj sends probe pi pj pk along all request edges, etc. When probe returns to pi, cycle is detected

p1 p2 p3

p7 p6

p4 p5

M1 M2

M3 M4

p1 p2 p1 p2 p3 p1 p2 p3 p4

p1 p2 p3 p7

p1 p2 p3 p4 p5

p1 p2 p3 p4 p5 p1

p1 p2 p3 p4 p5 p6p1 p2 p3 p4 p5 p6 p4

Deadlock detected by M4.

Deadlock detected by M1.



Recovery from Deadlock

Recovery from Deadlock Process termination

– Kill all processes involved in deadlock or– Kill one at a time. In what order?

By priority: consistent with scheduling or By cost of restart: length of recomputation or By impact on other processes: CS, producer/consumer

Resource preemption– Direct: Temporarily remove resource (e.g., Memory)– Indirect: Rollback to earlier “checkpoint”



Dynamic

Deadlock Avoidance

Deadlock Avoidance Deadlock Detection & Recovery

– The resources requested by processes are granted as long as they are available.

– OS resolves deadlock if detected. Deadlock Avoidance

– Prevent deadlocks from developing by delaying acquisition of resources that might cause deadlock in the future.

– Deadlock cannot occur.

The Prior Knowledge for Deadlock Avoidance

Deadlock avoidance requires some future knowledge of requests for resources from each of the participating processes.

The precise knowledge is usually not available in advance.

Processes specify maximum claim, i.e., the largest number of units of each resource needed at any one time.

Maximum Claim Graph (MCG)

p1

Process indicates maximum resources needed Potential request edge: piRj (dashed) May turn into real request edge

R

p2

State Transition Using MCG Process indicates maximum resources needed Potential request edge: piRj (dashed) May turn into real request edge

p1

R

p2

S0 S1Request R

(by p2)S2

Acquire R(by p2)

S3Request R

(by p1)

p1

R

p2

p1

R

p2

p1

R

p2

S4Acquire R

(by p1)

p1

R

p2

The Banker’s Algorithm Theorem: Prevent acquisitions from producing a irreducible claim graph All state are safe. Banker’s algorithm:

– Given a satisfiable request, pR, temporarily grant request: changing pR to Rp

– Reduce new claim graph– If it is completely reducible, proceed

else reverse acquisition.

Testing for safety algorithm (Dijkstra 1968)

The Banker’s Algorithm

p1 p2 p3

R1 R2


R1 R2

p1 p2 p3

Which of the requests can safely be granted?

Can p1R1 be safely be granted?Can p2R1 be safely be granted?Can p3R1 be safely be granted?


R1 R2


p1 p2 p3

Temporarilygrant

Can such an RAG be completely reducible?


R1 R2


p1 p2 p3

Temporarilygrant



R1 R2


p1 p2 p3

granted



R1 R2

p1 p2 p3



R1 R2



p1 p2 p3

Temporarilygrant


R1 R2

p1 p2 p3


notgranted


R1 R2

p1 p2 p3



R1 R2


p1 p2 p3


Temporarilygrant


R1 R2


p1 p2 p3


Temporarilygrant



p1 p2 p3

R1 R2

granted

Special Case: Single-Unit Resource

Check for cycles after tentative acquisition– Disallow if cycle is found

If claim graph contains

no undirected cycles,all states are safe – No directed cycle can

ever be formed.



Deadlock Prevention

Deadlock Prevention Deadlock Detection & Recovery

– Granted resources as long as they are available.– OS resolves deadlock if detected.

Deadlock Avoidance– Os performs runtime checks to ensure the system

never enters unsafe state.– Deadlock cannot occur.

Deadlock Prevention– All processes must follow certain rules for

requesting and releasing resources.– Deadlock is impossible to occur.

Conditions for a Deadlock

Mutual exclusion:Resources are not sharable.

Hold and wait:Process must be holding one resource while requesting another.

No preemption:No resource is preemptable.

Circular wait:A closed chain of processes exists, such that each process holds at least one resources needed by the next process in the chain.

Eliminating any of these conditions would make deadlock impossible.

Deadlock Prevention

Mutual exclusion Hold and wait No preemption Circular wait

Eliminating any of

Eliminating the `Mutual Exclusion’ Condition– Not possible in most cases

E.g., data files and databases for write access are not sharable.

– Spooling makes I/O devices sharable Virtual devices

Deadlock Prevention


Eliminating any of

Eliminating the `Hold and Wait’ Condition– Request all resources at once– Release all resources before a new request

Eliminating the `No preemption’ Condition– Release all resources if current request blocks

Deadlock Prevention


Eliminating any of

Eliminating the `Circular Wait’ Condition– Impose a total ordering of all resource types, and

require that each process requests resources in an increasing order of enumeration.

Fact: A cycle in the resource graph can develop only when processes request the same resources in the different order.

Comparisons

Documents

Operating Systems Principles Process Management and Coordination Lecture 6: Deadlocks