DeadlockChapter 3

R1

R2

P2P1

Allocated

Requested

Resources

• Processes compete for system resources– CPU cycles– I/O devices– Printers– Tape drives – Files– Tables– Database records

Resources: Preemptible vs. Nonpreemptible

• Preemptible– Can be taken away from a process without ill

effect• Examples?

• Nonpreemptible– Taking it away from a process causes the

process to fail

• We are concerned with nonpreemptable resources

How a process relates to a (nonpreemptible) resource

• It requests the resource– What can it do if it isn’t available?

• It uses the resource

• It releases the resource, making it available to another process

Using a semaphore to protect resources

One resource Two resources

Using semaphores to protect resources

Deadlock-free Deadlock-prone

The problem of deadlock

• If a process is waiting for a resource that is held by another process that is waiting for another resource held by another process…– A set of processes is in a deadlocked state when

every process is waiting for an event that can be caused only by another process in the set

The four necessary conditions for deadlock to occur

• Mutual exclusion– the resource can be used by only one process at a time

• Hold & wait or resource holding– processes are permitted to hold onto their current

resources while they wait for others

• No preemption– no process can bump another for its resource

• Circular wait – can show that there is a cycle

Resource allocation graphs for deadlock modeling

a) Resource R is assigned to Process Ab) Process B is waiting for Resource Sc) Processes C & D are in deadlock over Resources T & U

Creating deadlock

A B C

Avoiding deadlock

Addressing the issue of deadlock

• Ignorance– Ostrich algorithm

• Detection & recovery– Scan the system looking for cycles of hold & wait– Implement recovery algorithms

• Avoidance– If it seems that deadlock is a possibility, do something to

keep it from happening

• Prevention– negate one of the four necessary conditions

Ignorance: Ostrich Algorithm

• Pretend there is no problem

• Reasonable if – deadlocks occur very rarely – cost of prevention is high

• UNIX and Windows takes this approach

• It is a trade off between – convenience– correctness

Deadlock detection in a graph

• Find a process not waiting for any resource.– Remove its allocation arrows & reallocate its resources

• Find a process that is waiting only for resources that are not completely allocated.– Remove these allocation arrows & reallocate the

resources

• Repeat until all lines have been removed or you determine that they cannot all be removed.

Resource graph: detection with one resource of each type

A cycle can be found within the graph, denoting deadlock

T

Resource graph: detection with multiple resources of each type

R1 R3

R2 R4

P1 P2 P3

Data structures needed for detection with multiple resources of each type

n

Σ Cij + Aj = Eji=1

Fig. 3-6

Detection with multiple resources of each type

Resources in existence Resources available

See pp. 172-173

Recovery from deadlock

• Recovery through preemption– take a resource from some other process– depends on nature of the resource

• Recovery through rollback– checkpoint a process periodically– use this saved state – restart the process if it is found deadlocked

Recovery from deadlock

• Recovery through killing processes– crudest but simplest way to break a deadlock– kill one of the processes in the deadlock cycle– the other processes get its resources – choose process that can be rerun from the beginning

Avoidance – Banker’s algorithm

• Use an algorithm similar to what a bank uses to ensure that it always has funds on hand to satisfy its customers’ eventual needs– Each process must state upfront what its

maximum resource needs will be

• Deal with safe and unsafe states– avoid unsafe states

• Working with multiple instances of resources

Safe state

State (a) is safe because • It is not deadlocked• There is a scheduling order for each process to run to completion

(a) (b) (c) (d) (e)

We have a total of 10 instances of a given resource, with processes A, B, C holding & eventually needing what is indicated here:

Unsafe states

State (b) is unsafe because

• There is no way to satisfy all processes after it

(a) (b) (c) (d)

Banker's Algorithm for multiple instances of a single resource

(a) (b) (c)

Are each of these states safe or unsafe?

Banker's Algorithm for multiple resources

Prevention

• Don’t allow mutual exclusion

• Eliminate resource holding

• Allow preemption

• Modify circular wait

Preventing the “mutual exclusion” condition

• Devices, such as printer, can be spooled– only the printer daemon uses printer resource– thus deadlock for printer eliminated

• But not all devices can be spooled, so abide by the principle:– Allow as few processes as possible to actually

claim the resource

Preventing the “hold and wait” condition

• Require processes to request all resources before starting– Then, a process never has to wait for what it

needs

• Problems– Process may not know required resources at start– Ties up resources other processes could be using

Preventing the “no preemption” condition

• This is not usually a viable option

• Consider a process given the printer– halfway through its job– now forcibly take away printer– !!??

Preventing the “circular wait” condition

Order resources Allocate in order

Summary of approaches to deadlock prevention

Related issues

• Two-phase locking in databases

• Deadlocking on semaphores

• Starvation in CPU scheduling