lecture5
DESCRIPTION
osTRANSCRIPT
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