Deadlock Chapter 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 resourceTwo resources

Using semaphores to protect resources Deadlock-freeDeadlock-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 A b) Process B is waiting for Resource S c) Processes C & D are in deadlock over Resources T & U

Creating deadlock ABC

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 R1R3 R2R4 P1P2P3

Data structures needed for detection with multiple resources of each type n Σ C ij + A j = E j i=1 Fig. 3-6

Detection with multiple resources of each type Resources in existenceResources available See pp

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