OS Fall’02 Concurrency: Principles of Deadlock Operating Systems Fall 2002.

OS Fall’02

Concurrency: Principles of Deadlock

Operating Systems Fall 2002

OS Fall’02

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 Fall’02

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 Fall’02

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 Fall’02

Deadlock in the everyday life

1

23

4

OS Fall’02

Deadlock in the everyday life

OS Fall’02

Deadlock when contending for the critical section

while(1)}

sectionremainder

;][

section critical

]);1[(

;][

{ do

: Process

falseiflag

iflagwhile

trueiflag

Pi

]2[ :Shared flagboolean

OS Fall’02

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 Fall’02

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 Fall’02

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 Fall’02

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 Fall’02

Consumable resources and Deadlock

Example: Deadlock occurs if receive is blocking

P1. . .

. . .Receive(P2);

Send(P2);

P2. . .

. . .Receive(P1);

Send(P1);

OS Fall’02

Conditions for Deadlock Policy conditions

Mutual exclusionHold-and-waitNo preemption

Circular wait

ResourceB

ResourceA

ProcessP1

ProcessP2

Requests Held by

RequestsHeld By

OS Fall’02

Conditions for Deadlock

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

Circular wait

DEADLOCK

OS Fall’02

Circular Wait

P1 P2 P3

R1 R2

R3

OS Fall’02

No circular wait

P1 P2 P3

R1 R2

R3

OS Fall’02

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 Fall’02

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 Fall’02

Preventing circular wait

P1 P2 P3

R1 R2

R3

OS Fall’02

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 Fall’02

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 Fall’02

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 Fall’02

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 Fall’02

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 Fall’02

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 Fall’02

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 Fall’02

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 Fall’02

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 Fall’02

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 Fall’02

Dining philosophers problem

OS Fall’02

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 Fall’02

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

OS Fall’02

Next: Memory management