Deadlock Chapter 3 R 1 P 1 Allocated

Deadlock Chapter 3 R 1 P 1 Allocated Requested P 2 R 2

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 A b) Process B is waiting for Resource S c) 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 T A cycle can be found within the graph, denoting deadlock

Resource graph: detection with multiple resources of each type R 1 P 1 R 3 P 2 R 2 P 3 R 4

Data structures needed for detection with multiple resources of each type n Σ Cij + Aj = Ej i=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 We have a total of 10 instances of a given resource, with processes A, B, C holding & eventually needing what is indicated here: (a) (b) (c) (d) (e) State (a) is safe because • It is not deadlocked • There is a scheduling order for each process to run to completion

Unsafe states (a) (b) (c) State (b) is unsafe because • There is no way to satisfy all processes after it (d)

Banker's Algorithm for multiple instances of a single resource (a) (b) Are each of these states safe or unsafe? (c)

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