Chapter 6 Deadlock Problemscs325/OSP_06.pdf · Chapter 6 Deadlock Situations – Examples A Systems...

Betriebssysteme ws2000/2001

Prof. H. D. Clausen 1

S 2004 CS 325 1

Deadlock ProblemsDeadlock Problems

Chapter 6

Deadlock Situations Deadlock Situations –– ExamplesExamplesA Systems ModelA Systems ModelSerially Reusable ResourcesSerially Reusable ResourcesDeadlock DetectionDeadlock DetectionRecovery and PreventionRecovery and PreventionConsumable ResourcesConsumable ResourcesResource GraphsResource GraphsDynamic Addition and RemovalDynamic Addition and Removal

S 2004 CS 325 2

Policy versus MechanismPolicy versus Mechanism

• Separate what is allowed to be done with how it is done– a process knows which of its children threads are important

and need priority

• Requests for resources

• Scheduling of requests

• Allocation of resources

• Release of resources



S 2004 CS 325 3

Deadlock Deadlock –– reasons, occurrencesreasons, occurrences

• Processes compete for “resources”

• Sharing of resources among competitors

• Sequence of allocations can lead to blocking

• Dynamic resource sharing, parallel programming and communicating processes are critical

S 2004 CS 325 4

Deadlock Deadlock –– “deadly embrace”“deadly embrace”

• Resource: reusable, scarce, stable commodity (hw,sw)– serially reusable: * request * use* release

on a serial basis

– consumable: * producer * “message-send/receive”* consumer

resource with a short lifetime



S 2004 CS 325 5

“deadly embrace” “deadly embrace” -- deadlockdeadlock

p1: : p2: :: :

Request(D); Request(T);

r1: Request(T); :

: r2: Request(D);

: ::

Release(T); Release(D);

Release(D); Release(T);

: :

S 2004 CS 325 6

Reusable Resources Reusable Resources

• Reusable resources are permanent objects

* The number of units within a class is constant

* Each unit is either available, or is allocated to one and only one process

* A process must first request and acquire a resource unit before it can release that unit



S 2004 CS 325 7

Consumable Resources Consumable Resources

• Reusable resources are produced and consumed dynamically

* The number of units within a class varies at runtime

* A process may increase the number of units of a resource class by releasing one or more units without acquiring them first

* A process may decrease the number of units of a resource class by requesting and acquiring one or more units

S 2004 CS 325 8

Deadlock on Deadlock on FielFiel AccessAccess

p1: p2:

: :

: :

a: open(f1, w); c: open(f2, w);

b: open(f2, w); d: open(f1, w);

: :

: :



S 2004 CS 325 9

“deadly embrace” “deadly embrace” -- deadlockdeadlock

p1: p2: p3:: : :: : :if (C) send(p2,m);LOOP { LOOP { LPOOP {receive(p3,m); receive(p1,m); receive(p2,m);: : :: : :send(p2,m); send(p3,m); send(p1,m);

S 2004 CS 325 10

Deadlock on Memory AllocationDeadlock on Memory Allocation

p1: p2:

: :

: :

a: Get Mem(2); c: Get Mem(1);

b: Get Mem(2); d: Get Mem(2);

: :

: :



S 2004 CS 325 11

Strategies Strategies -- Approaches Approaches

• Ignore

• Handle

– Detect & recover

– Avoid

– Prevent

S 2004 CS 325 12

Conditions for DeadlocksConditions for Deadlocks

1. Mutual exclusion condition: each resource is either currently assigned to exactly one process or it is available.

2. Hold and Wait condition: processes currently holding resources allocated earlier can request new resources.

3. No preemption condition: resources previously acquired cannot be forcibly taken away from processes; they must be explicitly released by the process holding them.

4. Circular wait condition: there must be a circular chain of two or more processes, each of which is waiting for a resource held by the next member of the chain.



S 2004 CS 325 13

Resources Resources

• Two basic categories

– “reusable” resources – e.g. peripherals, printer

– “consumable” resources – e.g. messages

• Two basic operations

– request/allocate

– release

S 2004 CS 325 14

Resource GraphsResource Graphs

• Elements and Relationships– Resources– Processes – Resource Requests– Resource Allocations

• Notational Elements– Vertices– Edges



S 2004 CS 325 15

p3

p2

p1

R

R

Resource GraphsResource Graphs

R

(a) Process holding a resource

(b) Process requestinga resource

p4

R

(c) Deadlocked processes

S 2004 CS 325 16

p3

example of a resource graph

deadlock with SR resources

p2p1

R R



S 2004 CS 325 17

p3p1

Deadlock Occurrence Deadlock Occurrence

p1:requests R1requests R2releases R1releases R2

p2



3 concurrent processes accessing common resources

S 2004 CS 325 18

p3p1

R1

Deadlock Occurrence Deadlock Occurrence –– sequence 1 sequence 1

p1requests

R1

p2

R2 R3

p2requests

R2

p3requests

R3



S 2004 CS 325 19

p3p1

R1


p1requests

R2

p2

R2 R3

p2requests

R3

p3requests

R1

S 2004 CS 325 20

p3p1

R1


p1requests

R1

p2

R2 R3

p3requests

R3



S 2004 CS 325 21

p3p1

R1


p2

R2 R3

p3requests

R1

p1releases

R2

p1releases

R2

p3 allocates R1 and runs to completion

S 2004 CS 325 22

Deadlock Strategies Deadlock Strategies

1. Just ignore the problem – hopefully it ignores us too.

2. Detection and recovery: let deadlocks occur, then detect them and take action.

3. Dynamic avoidance by careful resource allocation.

4. Prevention by structurally negating on of the four conditions necessary for a deadlock.



S 2004 CS 325 23

p3

(a) simple example of adeadlock situation

deadlock with SR resources

R1

p2p1

p2p1

R2 allocationrequest

R(b) single resource sharing (n=3, m=2)

allocation request

S 2004 CS 325 24

States and TransitionsStates and Transitions

• Requests

• Acquisitions

• Releases

• Deadlock states and safe states



S 2004 CS 325 25

p1 p1 p1 p1

p2 p2 p2 p2

R R R R

S T U V1 1 1

process operations

Request Acquisition Release

S 2004 CS 325 26

R1

S0

State transitions caused by process p1

request R1

release R2

R2

p1 p1 p1 p1 p1

p1 p1 p1 p1 p1

acquire R1 acquire R2 acquire R2

release R1

S1 S2 S3 S4



S 2004 CS 325 27

S 2004 CS 325 28

Research on DeadlocksResearch on Deadlocks

Quotes from Andrew Tanenbaum:“If there ever was a subject that was investigated mercilessly during the early days of computing, it was deadlocks. … Deadlock detection is a nice little graph theory problem that one mathematically inclined graduate student can get his jaws around and chew on for 3 or 4 years. All kinds of algorithms were devised, each one more exotic and less practical than the previous one. …When an operating system wants to do deadlock detection or prevention, which few of them do, they use one of the methods discussed”



S 2004 CS 325 29

Research on DeadlocksResearch on Deadlocks

Final quote from Andrew Tanenbaum:

“There is still a little research on distributed deadlock detection. …

None of it is even remotely practical in real systems. Its main function seems to be keeping otherwise unemployed graph theorists off the streets.”

S 2004 CS 325 30

Deadlock states and safe statesDeadlock states and safe states

• Blocked processes

• Deadlocked processes

• Deadlock states

• Safe states



S 2004 CS 325 31

Compute and IO ProcessCompute and IO Process

: :

pc: Request(M, all); pio: Request(IO_request);

Release(IO_request); :

rc: Request(IO_completion); rio: Request(D);

: :

: :

Release(M, all); Perform_IO;

Release(IO_completion);

: :

S 2004 CS 325 32

Message PassingMessage Passing

Safe order of operations:

pi: Release(Si); Request (Sj);

Unsafe order of operations:

p1: . . . Request(S3); Release(S1); . . . .





S 2004 CS 325 33

p3

(a) SR an CR resource sharing

deadlock with CR resources

M

piopc

p2

p1

produce

R

(b) single resource sharing

. . .

IO completion

S2

S3 S1

“granularity”

S 2004 CS 325 34

System ModelSystem Model

• System of states σ {S, T, U, V, . . . } and a set π of processes {p1, p2, . . . }

• A process pi : σ { σ }– pi : S –i W; S –* W;– pi is blocked not∃ S ––i T A process pi is deadlocked,∀T: S ––i T pi is blocked.

S is a deadlock state if a process pi is deadlocked in S.



S 2004 CS 325 35

S

1

1

1

2

1

1 1

2112 UTSW V

T

U V

2 2

examples of systems

(a) system with deadlock states:

(b) system with deadlock and safe states

p1 is blocked here

p2 is deadlocked in U and in V since it is blocked in either one;

deadlock state safe

statesnot safe

S 2004 CS 325 36

Insert tif of Fig. 4-4

system state changes in file sharing example



S 2004 CS 325 37

Serially Reusable ResourcesSerially Reusable Resources

• A SR resource is a finite set of identical units:– The number of units is constant– Each unit is either available or allocated to one an only one

process – no sharing is allowed.

– A process may release a unit only if it has previously acquired that unit.

• Representation by a process-resource graph (reusableresource graph)– A set of two mutually exclusive subsets of process and

resource nodes [containing one or more units]

– The graph is bipartite– The edges are directed [allocated/requested] and limited

S 2004 CS 325 38

Deadlock DetectionDeadlock Detection• Process progression – investigate the most favorable

state changes• Is there a sequence of operations such that the system

will NOT deadlock• Simulate the most favorable execution of each unblocked

process in a sequential mode:– An unblocked process acquires all resources it needs, then

releases all of its resources and remains dormant thereafter

– The released resources might wake up some previously blocked processes

– Continue in this way until there are no more unblocked processes

– If at termination there remain some blocked processes the original state is a deadlock state;



S 2004 CS 325 39

p3

example of a resource graph reduction

Graph reduction - 1

p2p1

R R

p5p4

R

S 2004 CS 325 40

p3


Graph reduction - 2

p2

R R

p5p4

R



S 2004 CS 325 41

p3


Graph reduction - 3

R R

p5

R

S 2004 CS 325 42

p2

p1

p1

p2

R1R2

another sequence of reductions

R1 R2

Reduced by p1

Reduced by p2

unblocked

unblocked



S 2004 CS 325 43

p1

p2

another sequence of reductions

R1 R2

p1

p2

R1 R2

Reduced by p1

Reduced by p2

unblockedsafe

S 2004 CS 325 44

Deadlock TheoremDeadlock Theorem

• Necessary and sufficient condition:• A state S is a deadlock state IFF the reusable

resource graph is NOT completely reducible;• Based on the observation (Lemma 1) that all reduction

sequences lead to the same irreducible graph.• If Reach(n) is the set of nodes reachable from node n

then the graph contains a cycle if n ∋ Reach(n);• A cycle in a graph is a necessary condition for deadlock. • A knot is a subset of nodes which are reachable from

every node inside but no outside nodes are reachable.• Reducible resource graphs can be represented in matrix

or list form (compression techniques to save storage).



S 2004 CS 325 45

a

Knot K = {b, c, d, e}

illustration of cycles and knots

Example of a knot - and a cycle b

d

ce

S 2004 CS 325 46

Deadlock DetectionDeadlock Detection

• Reduction of resource graphs

• Special cases– Testing for a specific process– Continuous deadlock detection– Immediate allocation (knots)– Single unit resources

• Deadlock detection in distributed systems– Central coordinator– Distributed coordination



S 2004 CS 325 47

Recovery from DeadlockRecovery from Deadlock

• Recovery through preemption

• Recovery through rollback (checkpoints)

• Recovery through process termination

S 2004 CS 325 48

Recovery from DeadlockRecovery from Deadlock

• 2 general approaches– Process termination– Resource preemption

• Termination costs:– Process priority– Restarting and re-running the process– “external” costs

• Termination schemes:– least expensive process– minimum cost process– Apply resource preemption



S 2004 CS 325 49

Dynamic Deadlock AvoidanceDynamic Deadlock Avoidance

• Claim graphs

• Banker’s Algorithm

S 2004 CS 325 50

End End

Date post:	19-Feb-2021
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

Chapter 6 Deadlock Problemscs325/OSP_06.pdf · Chapter 6 Deadlock Situations – Examples A Systems...

Documents