Resource Allocation and Deadlock Resource Allocation and Deadlock Handling

Conditions for Deadlock

[Coffman-etal 1971] 4 conditions must hold simultaneously for a deadlock to occur:

• Mutual exclusion: only one process at a time can use a resource.

deadlock to occur:

• Hold and wait: a process holding some resource can request additional resources and wait for them if they are held by other processesprocesses.

• No preemption: a resource can only be released voluntarily by h h ld f h h l d kthe process holding it, after that process has completed its task.– Q: examples preemptable/non-preemtable resources?

• Circular wait: there exists a circular chain of 2 or more blocked processes, each waiting for a resource held by the next process in the chain

2

the cha n

Resource Allocation & Handling of Deadlocks

• Structurally restrict the way in which processes request resources resources – deadlock prevention: deadlock is not possible

• Require processes to give advance info about the (max) resources they will require; then schedule processes in a way that avoids deadlock. – deadlock avoidance: deadlock is possible, but OS uses advance info to

avoid it

• Allow a deadlock state and then recover

• Ignore the problem and pretend that deadlocks never occur in the system (can be a “solution” sometimes?!…)

3

Resource Allocation with Deadlock Prevention

Restrain the ways requests can be made; attack at least one of the 4 conditions so that deadlocks are impossible to happen:• Mutual Exclusion – (cannot do much here …)

H ld d h h

conditions, so that deadlocks are impossible to happen:

• Hold and Wait – must guarantee that when a process requests a resource, it does not hold any other resources.– Require process to request and be allocated all its resources at once or

ll t t l h th h allow process to request resources only when the process has none. – Low resource utilization; starvation possible.

• No Preemption – If a process holding some resources requests another th t t b i di t l ll t d it l th h ld resource that cannot be immediately allocated, it releases the held

resources and has to request them again (risk for starvation).• Circular Wait – impose total ordering of all resource types, and require

that each process requests resources in an increasing order of enumeration that each process requests resources in an increasing order of enumeration (e.g first the tape, then the disk).

• Examples?4

• Examples?

Fight the circular wait: Dining philosophers exampleDining philosophers example

request forks in increasing fork-idvar f[0..n]: bin-semaphore /init all 1 /p

P_i: (i!=n)R

PnRepeat Idea:

i hi lRepeatWait(f[i])Wait(f[(i+1)modn])

RepeatWait(f[(i+1)modn]) Wait(f[i])

•Hierarchical ordering of resources( [( ) ])

Eat Eatresources

•Proc’s request Signal(f[(i+1)modn])Signal(f[i])

Signal(f[i])Signal(f[(i+1)modn])

qtheir needed resources in i i d

Thinkforever

Thinkforever

increasing order

5

Fight the hold and wait: Dining philosophers exampleDining philosophers example

semaphore S[N]i t t t [N]

take_forks(i)it( t )

leave_forks(i)wait(mutex)int state[N]

P

wait(mutex)state(i) := HUNGRYtest(i)

wa t(mutex)state(i) :=

THINKING(l f (i))Pi: do

<think>take forks(i)

test(i)signal(mutex)wait(S[i])

test(left(i))test(right(i)signal(mutex)take_forks(i)

<eat>leave forks(i)

signal(mutex)

Id l l i h_f ( )

forever

test(i)

Idea: apply mutex algorithm for each neighbourhood,instead of for each forktest(i)

if state(i) ==HUNGRY && state(left(i) ) != EATING && state(left(i) ) != EATING then

instead of for each fork

6state(i) := EATINGsignal(S[i])

Fight the no-preemption: Dining philosophers exampleDining philosophers example

var f[0..n]: records: bin-semaphore trylock(fork):pavailable: boolean /init all 1 /

P_i: Repeat

wait(fork.s)If fork.available then

fork.available := falseret:= trueRepeat

While <not holding both forks> doLock(f[i]) If !t l k(f[(i 1) d ]) th l s f[i]

ret:= trueelse ret:= false

Signal(fork.s)Return(ret)If !trylock(f[(i+1)modn]) then release f[i];

odEat

R l (f[i])

Return(ret)

Lock(fork):Release(f[i])Release(f[(i+1)modn])Think

Lock(fork):RepeatUntil (trylock(fork))

forever Release(fork):wait(fork.s)

fork.available := true

Idea: release held resources and retry when

7Signal(fork.s)the next one is not

available

Deadlock avoidance: System Model

• Resource types R1, R2, . . ., Rm

– e g CPU memory space I/O devices filese.g. CPU, memory space, I/O devices, files– each resource type Ri has Wi instances.

• Each process utilizes a resource as follows:request – request

– use – release

Resource-Allocation GraphA set of vertices V and a set of edges EA set of vertices V and a set of edges E.– V is partitioned into two sets:

• P = {P1, P2, …, Pn} the set of processesR {R R R } th t f t• R = {R1, R2, …, Rm} the set of resource types

– request edge: Pi → Rj– assignment edge: Rj → Pi

8

Example of a Resource Allocation Graphp p

9

Resource Allocation Graph With A Deadlockp

10

Resource Allocation Graph With A cycle but no Deadlock

11

Basic Facts

• graph contains no cycles ⇒ no deadlock.(i.e. cycle is always a necessary condition for deadlock)

• If graph contains a cycle ⇒• If graph contains a cycle ⇒

– if one instance per resource type, then deadlock.

– if several instances per resource type, then possibility of deadlock • Thm: if immediate-allocation-method, then knot ⇒ deadlock.Thm if immediate allocation method, then knot ⇒ deadlock.

– Knot= knot – strongly connected subgraph (no sinks) with no outgoing edges

12

Resource Allocation with Deadlock Avoidance

Requires a priori information available. • e g : each process declares maximum number of resources of each type

Deadlock-avoidance algo:• examines the resource allocation state

e.g.: each process declares maximum number of resources of each type that it may need (e.g memory/disk pages).

• examines the resource-allocation state…– available and allocated resources– maximum possible demands of the processes.t th i t ti l f i l it • …to ensure there is no potential for a circular-wait: – safe state ⇒ no deadlocks in the horizon.– unsafe state ⇒ deadlock might occur (later…)– Q: how to do the safety check?

• Avoidance = ensure that system will not enter an unsafeystate.Idea: If satisfying a request will result in an unsafe

state, the requesting process is suspended until h f d b h ill

13

enough resources are free-ed by processes that will terminate in the meanwhile.

Enhanced Resource Allocation Graph for Deadlock AvoidanceAvoidance

• Claim edge Pi → Rj : Pj may request resource Rjg i j j y q j– represented by a dashed line.

• Claim edge converts to request edge when a process requests a resourceresource.

• When a resource is released by a process, assignment edge reconverts to a claim edge.

• Resources must be claimed a priori in the system.

14

Example Resource-Allocation Graph For Deadlock Avoidance: Safe StateAvoidance: Safe State

15

Example Resource-Allocation Graph For Deadlock Av idance: Unsafe StateAvoidance: Unsafe State

16

Safety checking: More on Safe State

safe state = there exists a safe sequence <P1, P2, …, Pn> of t i ti ll terminating all processes: for each Pi, the requests that it can still make can be granted by

currently available resources + those held by P1 P2 Pi 1currently available resources + those held by P1, P2, …, Pi-1

• The system can schedule the processes as follows:y p– if Pi ‘s resource needs are not immediately available, then it can

• wait until all P1, P2, …, Pi-1 have finishedbt i d d t l t i t • obtain needed resources, execute, release resources, terminate.

– then the next process can obtain its needed resources, and so on.

17

Banker’s Algorithm for Resource Allocation with Deadlock Avoidance Deadlock Avoidance

Data Structures: • Max: n x m matrix.

– Max [i,j] = k: Pi may request max k instances of resource type Rj.• Allocation: n x m matrix.

– Allocation[i,j] = k: Pi is currently allocated k instances of RjAllocation[i,j] k Pi is currently allocated k instances of Rj.• Available: length m vector

– available [j] = k : k instances of resource type Rj available.• Need: n x m matrix: Need: n x m matrix:

– Need [i,j] = Max[i,j] – Allocation[i,j]: potential max request by Pi for resource type Rj

RECALL: Avoidance = ensure that system will not enter an unsafe state.Idea: If satisfying a request will result in an unsafe state If satisfying a request will result in an unsafe state, then requesting process is suspendeduntil enough resources are free-ed by processes that will terminate in the

meanwhile18

meanwhile.

Banker’s algorithm: Resource Allocation

For each new Requesti do /*Requesti [j] = k: Pi wants k instances of Rj. *//* Check consequence if request is granted *// qu f qu g /

remember the current resource-allocation state;Available := Available - Requesti;Allocationi := Allocationi + Requesti;Needi := Needi – Requesti;;If safety check OK ⇒ the resources are allocated to P If safety-check OK ⇒ the resources are allocated to Pi. Else ( unsafe ) ⇒

Pi must wait and i

the old resource-allocation state is restored;

19

Banker’s Algorithm: safety checkg y

• Work and Finish: auxiliary vectors of length m and n, respectively. y g p y• Initialize:

Work := AvailableFi i h [i] f l f i 1 2 Finish [i] = false for i = 1,2, …, n.

While there exists i such that both (a) Finish [i] = false• While there exists i such that both do

Work := Work + Allocationi

(a) F n sh [ ] false(b) Needi ≤ Work.

Work Work Allocationi

Finish[i] := true

• If Finish [i] = true for all i, then the system is in a safe stateelse state is unsafe

20

else state is unsafe

Very simple example execution of Bankers Algo (snapshot 1)( p )

Allocation Max Need Available B B B B A B A B A B A B

P1 1 0 1 1 0 1 0 1 P2 0 0 1 1 1 1 2

• The system is in a safe state since the sequence < P1, P2> satisfies safety criteria criteria.

A

B

21

Very simple example execution of Bankers Algo (snapshot 2)( p )

Allocation Max Need Available B B B B A B A B A B A B

P1 1 0 1 1 0 1 0 0 P2 0 1 1 1 1 0 2

• Allocating B to P2 leaves the system in an unsafe state since there is no sequence that satisfies safety criteria (Available vector is 0 !) sequence that satisfies safety criteria (Available vector is 0 !).

A

B

22

Deadlock Detection & Recovery

• Allow system to enter deadlock state D t ti l ith h t did f h ki f t i h d • Detection algorithm: what we did for checking safety in enhanced graph, now we do it in the resource allocation graph– Using resource-allocation graphsg g p– Using Banker’s algo idea

• Recovery scheme

23

Deadlock Detection

Note:Note:• similar as detecting unsafe states using Banker’s algo• Q: how is similarity explained?

Q: if they cost the same why not use avoidance instead of • Q: if they cost the same why not use avoidance instead of detection&recovery?

Data structures:Data structures:• Available: vector of length m: number of available resources of each

type.• Allocation: n x m matrix: number of resources of each type currently • Allocation: n x m matrix: number of resources of each type currently

allocated to each process.• Request: n x m matrix: current request of each process. Request

[ij] = k: Pi is requesting k more instances of resource type Rj[ij] = k: Pi is requesting k more instances of resource type Rj.

24

Detection-Algorithm Usage

• When, and how often, to invoke depends on:– How often a deadlock is likely to occur?– How many processes will need to be rolled back?

• If algorithm is invoked arbitrarily, there may be many cycles in the resource graph ⇒ we would not be able to tell which of the many d dl k d “ d” th d dl kdeadlocked processes “caused” the deadlock.

25

Recovery from Deadlock: (1) Process Termination(1) Process Termination

• Abort all deadlocked processesAbort all deadlocked processes.• Abort one process at a time until deadlock is eliminated.• In which order should we choose to abort? Criteria?

– effect of the process’ computation (breakpoints & rollback) – Priority of the process– Priority of the process.– How long process has computed, and how much longer to completion.– Resources the process has used/needs to complete.– How many processes will need to be terminated.

26

Recovery from Deadlock: (2) Resource Preemption(2) Resource Preemption

• Select a victimi i i st– minimize cost.

• Rollback – return to some safe state, restart process from that state – Must do checkpointing for this to be possible.

• Watch for starvation – same process may always be picked as victim include number of rollbacks in cost factorvictim, include number of rollbacks in cost factor.

27

Combined Approach to Deadlock Handling

• Combine the three basic approaches (prevention, avoidance, pp pdetection), allowing the use of the optimal approach for each type of resources in the system:– Partition resources into hierarchically ordered classes (deadlocks Partition resources into hierarchically ordered classes (deadlocks

may arise only within each class, then)– use most appropriate technique for handling deadlocks within each

l class, e.g:• internal (e.g. interactive I/O channels): prevention by ordering• process resources (e.g. files): avoidance by knowing max needsp ( g f ) y g m• main memory: prevention by preemption• swap space (blocks in disk, drum, …): prevention by preallocation

28

RA & Deadlock Handling in Distributed Systems

N li d l h !• Note: no centralized control here!– Each site only knows about its own resources– Deadlock may involve distributed resourcesDeadlock may involve distributed resources

29

Resource Allocation in Message-Passing Systems

Prevention (recall strategies: no cycles; request all resources at once; apply preemptive strategies) (apply in gen din phil)apply preemptive strategies) (apply in gen. din.phil)

• using priorities/hierarchical ordering of resources– Use resource-managers (1 proc/resource) and request resource from g p q

each manager (in the hierarchy order)– Use mutex (each fork is a mutex, execute Rikart&Agrawala for each)

• No hold&wait:No hold&wait:– Each process is mutually exclusive with both its neighbours => each

group of 3 neighbours is 1 Rikart&Agrawala ”instance”N P ti If h ldi t • No Preemption – If a process holding some resources requests another resource that cannot be immediately allocated, it releases the held resources and has to request them again (risk for starvation:cf extra, optional reference, PetersonStyer (not included in study material) algo for avoiding starvation).

30

Distributed R.A. with Deadlock Avoidanceor Deadlock Detection&Recoveryor Deadlock Detection&Recovery

• Centralized control – one site is responsible for safety check or deadlock detectiondeadlock detection– Can be a bottleneck (in performance and fault-tolerance)

• Distributed control – all processes cooperate in the safety check or d dl k d t ti f ti deadlock detection function – need of consistent global state– straightforward (expensive) approach: all processes try to learn global

state– less expensive solutions tend to be complicated and/or unrealistic

• Distributed deadlock avoidance or detection&recovery is not very practical

Checking global states involves considerable processing – Checking global states involves considerable processing overhead for a distributed system with a large number of processes and resourcesAlso: who will check if procs are all blocked?!

31

– Also: who will check if procs are all blocked?!