OS Spring 2004

Concurrency: Principles of Deadlock

Operating Systems Spring 2004

OS Spring 2004

Processes and resources Processes need resources to run

CPU, memory, disk, etc…A process waiting for a resource cannot complete its execution until the resource becomes available

There is only a finite amount of resources

E.g., 1 CPU, 1 GB memory, 2 disks

OS Spring 2004

Concurrency and deadlocks In a multiprogramming system the

total resource demand by all concurrently active processes exceeds by far the total amount of available resources

Processes compete for resourcesA process can grab the last instance of a resource A and wait for the resource BAnother process may hold B and wait for ANo one can proceed: Deadlock

OS Spring 2004

Deadlock Permanent blocking of a set of

processes that either compete for system resources or communicate with each other

Involves conflicting needs for resources by two or more processes

There is no satisfactory solution in the general case

OS Spring 2004

Deadlock in the everyday life

1

23

4

OS Spring 2004

Deadlock in the everyday life

OS Spring 2004

Deadlock when contending for the critical section

while(1)}

sectionremainder

;][

section critical

]);1[(

;][

{ do

: Process

falseiflag

iflagwhile

trueiflag

Pi

]2[ :Shared flagboolean

OS Spring 2004

Example of DeadlockProgress

of Q

ReleaseA

ReleaseB

Get A

Get B

Get A Get B Release A Release B

Progressof P

ARequired

B Required

ARequired

BRequired

deadlockinevitable

1 2

3

4

5

6

P and Qwant A

P and Qwant B

OS Spring 2004

Example of No DeadlockProgress

of Q

ReleaseA

ReleaseB

Get A

Get B

Get A Release A Get B Release B

Progressof P

ARequired B Required

ARequired

BRequired

1 2 3

4

5

6

P and Qwant A

P and Qwant B

OS Spring 2004

Resource categories Reusable: Used by one process at a

time and not depleted by that use can be reused by other processes,may exist

several instances

Processors, memory, disks, tapes, etc.

Consumable: Created (produced) and destroyed (consumed) by a process

Interrupts, signals, messages, and information in I/O buffers

OS Spring 2004

Reusable resources and Deadlock

Deadlock might occur if each process holds one resource and requests the other

E.g., Space is available for allocation of 200K

P1

. . .

. . .Request 80K bytes;

Request 60K bytes;

P2

. . .

. . .Request 70K bytes;

Request 80K bytes;

OS Spring 2004

Consumable resources and Deadlock

Example: Deadlock occurs if receive is blocking

P1. . .

. . .Receive(P2);

Send(P2);

P2. . .

. . .Receive(P1);

Send(P1);

OS Spring 2004

Conditions for Deadlock Policy conditions

Mutual exclusionHold-and-waitNo preemption

Circular wait

ResourceB

ResourceA

ProcessP1

ProcessP2

Requests Held by

RequestsHeld By

OS Spring 2004

Conditions for Deadlock

•Mutual exclusion•Hold-and-wait•No preemption

Circular wait

DEADLOCK

OS Spring 2004

Circular Wait

P1 P2 P3

R1 R2

R3

OS Spring 2004

No circular wait

P1 P2 P3

R1 R2

R3

OS Spring 2004

Coping with Deadlocks Deadlock prevention

Deadlock possibility is excluded a priori by the system design

Deadlock avoidanceDeadlocks are possible in principle but avoided

Deadlock detectionDeadlocks can occur: detect and solve the problem

OS Spring 2004

Deadlock prevention Design system so that it violates

one of the four necessary conditionsPrevent hold and wait: request all the resources at the outset wait until all the resources are available

Prevent circular wait by defining linear ordering of the resource types A process holding some resources can

request only resource types with higher numbers

OS Spring 2004

Preventing circular wait

P1 P2 P3

R1 R2

R3

OS Spring 2004

Deadlock prevention: Cons Degraded performance

Delayed executionLow parallelism

Hold and wait prevention is wastefulHold resources more than they are neededWhen might this be reasonable?

OS Spring 2004

Deadlock avoidance Allocate resources in a way that

assures that the deadlock point is never reached

The allocation decision is made dynamically based on

total amount of resources availablecurrently availableprocesses’ resource claimprocesses’ current resources allocation

OS Spring 2004

Banker’s algorithm (Dijkstra

65’) Do not grant an incremental resource

request to a process is this allocation might lead to deadlock

The system state: is the current allocation of resources to processes

Safe state: is a state in which there is at least one sequence in which all processes can be run to completion

Unsafe state = NOT safe state

OS Spring 2004

Determination of the safe state

We have 3 resources types with amount:

R(1) = 9, R(2) = 3, R(3) = 6

Is the state S0 below safe?

Claim Allocated Total

3 2 26 1 33 1 44 2 2

1 0 06 1 22 1 10 0 2

P1P2P3P4

R1 R2 R3 R1 R2 R3 R1 R2 R39 3 6

Available0 1 1

OS Spring 2004

Determination of the safe state Claim Allocated Total

3 2 20 0 03 1 44 2 2

1 0 00 0 02 1 10 0 2

P1P2P3P4

R1 R2 R3 R1 R2 R3 R1 R2 R39 3 6

Available6 2 3

Claim Allocated Total

0 0 00 0 03 1 44 2 2

0 0 00 0 02 1 10 0 2

P1P2P3P4

R1 R2 R3 R1 R2 R3 R1 R2 R39 3 6

Available7 2 3

OS Spring 2004

Determination of the safe state Claim Allocated Total

0 0 00 0 00 0 04 2 2

0 0 00 0 00 0 00 0 2

P1P2P3P4

R1 R2 R3 R1 R2 R3 R1 R2 R39 3 6

Available9 3 4

Claim Allocated Total

0 0 00 0 00 0 00 0 0

0 0 00 0 00 0 00 0 0

P1P2P3P4

R1 R2 R3 R1 R2 R3 R1 R2 R39 3 6

Available9 3 6

S0 is safe: P2->P1->P3->P4

OS Spring 2004

Banker’s algorithm When a process request resources:

Assume the request is grantedUpdate the system state accordingly Determine whether the resulting state is safeIf yes: grant the resourcesOtherwise, block the process until it is safe to grant the resources

OS Spring 2004

Banker’s algorithm Claim Allocated Total

3 2 26 1 33 1 44 2 2

1 0 05 1 12 1 10 0 2

P1P2P3P4

R1 R2 R3 R1 R2 R3 R1 R2 R39 3 6

Available1 1 2

P2 requests (1, 0, 1): Grant or not?

P1 requests (1, 0, 1): Grant or not?

OS Spring 2004

Deadlock detection Banker’s algorithm is

Pessimistic: always assume that a process will not release the resources until it got’m all decreased parallelism

Involves complicated checks for each resource allocation request (O(n^2))

Optimistic approach: don’t do any checksWhen deadlock occurs - detect and recoverDetection: look for circular waits

OS Spring 2004

Practice Most operating systems employ an

“ostrich” algorithm Break hold-and-wait

Cannot acquire a resource - fail back to the user: e.g., too many processes, too many open files

Quotas Programming discipline:

acquire locks (semaphores) in a specific order

OS Spring 2004

Dining philosophers problem

OS Spring 2004

Dining philosophers problem An abstract problem demonstrating

some fundamental limitations of the deadlock-free synchronization

There is no symmetric solution Solutions

execute different code for odd/evengive’m another forkallow at most 4 philosophers at the tableRandomized (Lehmann-Rabin)

OS Spring 2004

Concurrency: summary Critical section is an abstract problem for

studying concurrency and synchronization

software solutionshardware primitiveshigher level primitives: semaphores, monitors

Deadlocks are inherent to concurrency4 conditions3 ways to cope with