[PDF] - Concurrency: Principles of Deadlock Operating Systems Fall 2002 PDF Document

SLIDE 1

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 resources

A process can grab the last instance of a resource A and wait for the resource B Another process may hold B and wait for A No one can proceed: Deadlock

SLIDE 2

OS Fall’02

Deadlock

Permanent blocking of a set of processes

that either compete for system resources

r 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 2 3 4

OS Fall’02

Deadlock in the everyday life

SLIDE 3

OS Fall’02

Deadlock when contending for the critical section

while(1) } section remainder ; ] [ section critical ]); 1 [ ( ; ] [ { do : Process false i flag i flag while true i flag P

i

= − = ] 2 [ : Shared flag boolean

OS Fall’02

Example of Deadlock

Progress

f Q

Release A Release B Get A Get B Get A Get B Release A Release B Progress

f P

A Required B Required A Required B Required deadlock inevitable 1 2 3 4 5 6

P and Q want A P and Q want B OS Fall’02

Example of No Deadlock

Progress

f Q

Release A Release B Get A Get B Get A Release A Get B Release B Progress

f P

A Required B Required A Required B Required 1 2 3 4 5 6 P and Q want A P and Q want B

SLIDE 4

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

ther

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);

SLIDE 5

OS Fall’02

Conditions for Deadlock

Policy conditions

Mutual exclusion Hold-and- wait No preemption

Circular wait

Resource B Resource A Process P1 Process P2

Requests H e l d b y R e q u e s t s Held 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

SLIDE 6

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 avoidance

Deadlocks are possible in principle but avoided

Deadlock detection

Deadlocks can occur: detect and solve the problem

OS Fall’02

Deadlock prevention

Design system so that it violates one of

the four necessary conditions

Prevent hold and wait:

request all the resources at the outset wait until all the resources are available

Prevent circular wait by defining linear

rdering of the resource types

A process holding some resources can request

nly resource types with higher numbers

SLIDE 7

OS Fall’02

Preventing circular wait

P1 P2 P3 R1 R2 R3

OS Fall’02

Deadlock prevention: Cons

Degraded performance

Delayed execution Low parallelism

Hold and wait prevention is wasteful

Hold resources more than they are needed When 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 available currently available processes’ resource claim processes’ current resources allocation

SLIDE 8

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 2 6 1 3 3 1 4 4 2 2 1 6 1 2 2 1 1 2 P1 P2 P3 P4 R1 R2 R3 R1 R2 R3 R1 R2 R3 9 3 6 Available 0 1 1

OS Fall’02

Determination of the safe state

Claim Allocated Total 3 2 2 3 1 4 4 2 2 1 2 1 1 2 P1 P2 P3 P4 R1 R2 R3 R1 R2 R3 R1 R2 R3 9 3 6 Available 6 2 3 Claim Allocated Total 3 1 4 4 2 2 2 1 1 2 P1 P2 P3 P4 R1 R2 R3 R1 R2 R3 R1 R2 R3 9 3 6 Available 7 2 3

SLIDE 9

OS Fall’02

Determination of the safe state

Claim Allocated Total 4 2 2 2 P1 P2 P3 P4 R1 R2 R3 R1 R2 R3 R1 R2 R3 9 3 6 Available 9 3 4 Claim Allocated Total P1 P2 P3 P4 R1 R2 R3 R1 R2 R3 R1 R2 R3 9 3 6 Available 9 3 6

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

OS Fall’02

Banker’s algorithm

When a process request resources:

Assume the request is granted Update the system state accordingly Determine whether the resulting state is safe If yes: grant the resources Otherwise, block the process until it is safe to grant the resources

OS Fall’02

Banker’s algorithm

Claim Allocated Total 3 2 2 6 1 3 3 1 4 4 2 2 1 5 1 1 2 1 1 2 P1 P2 P3 P4 R1 R2 R3 R1 R2 R3 R1 R2 R3 9 3 6 Available 1 1 2

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

SLIDE 10

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 checks

When deadlock occurs - detect and recover Detection: 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

rder

OS Fall’02

Dining philosophers problem

SLIDE 11

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/even give’m another fork allow at most 4 philosophers at the table Randomized (Lehmann-Rabin)

OS Fall’02

Concurrency: summary

Critical section is an abstract problem for

studying concurrency and synchronization

software solutions hardware primitives higher level primitives: semaphores, monitors

Deadlocks are inherent to concurrency

4 conditions 3 ways to cope with

OS Fall’02