CHAPTER 8 DEADLOCKS CGS 3763 Operating System Concepts

CHAPTER 8 - DEADLOCKS CGS 3763 - Operating System Concepts UCF, Spring 2003 1

OVERVIEW • System Model • Deadlock Characterization • Methods for Handling Deadlocks – – Ignore Problem Completely Deadlock Prevention Deadlock Avoidance Deadlock Detection • Recovery from Deadlock • Combined Approach to Deadlock Handling 2

THE DEADLOCK PROBLEM • Occurs when a set of blocked processes are each holding a resource and waiting to acquire a resource held by another process in the set. • Example 1: – – System has 2 tape drives. P 1 and P 2 each hold one tape drive Each process needs another tape drive to continue. Sometimes referred to as “Deadly Embrace” 3

THE DEADLOCK PROBLEM (cont. ) • Example 2: – Programs with two critical sections referencing different variables A and B – Assume semaphores initialized to 1 Interrupt P 0 : P(A) P(B) A=A+1 B=B+1 V(B) V(A) : P 1 : P(B) P(A) A=A*B B=B+A V(A) V(B) : • Semaphores can solve critical section problem but can still allow starvation and deadlocks to occur. 4

SYSTEM MODEL • A system consists of a finite number of different resource types (e. g. , R 1, R 2, . . . , Rm). Examples of resources include: – Hardware - CPU time, memory, disks, I/O devices – Software - system programs (e. g. , Compilers, Editors), shared application programs – Data - variables, records, files • Each resource type Ri has Wi instances, Wi > 1. • Each process utilizes a resource as follows: – request resource – use resource – release resource 5

WHEN DOES DEADLOCK OCCUR? • Deadlock can arise if four conditions hold simultaneously: – Mutual exclusion: only one process at a time can use a resource. – Hold and wait: a process holding at least one resource is waiting to acquire additional resources held by other processes. – No preemption: a resource can be released only voluntarily by the process holding it, after that process has completed its task. – Circular wait: there exists a set {P 0, P 1, …, P 0} of waiting processes such that P 0 is waiting for a resource that is held by P 1, P 1 is waiting for a resource that is held by P 2, …, Pn– 1 is waiting for a resource that is held by Pn, and P 0 is waiting for a resource that is held by P 0. 6

RESOURCE ALLOCATION GRAPHS • Deadlocks can be represented using Resource Allocation Graphs: – A set of vertices V and a set of edges E – V is partitioned into vertices of two types: • P = {P 1, P 2, …, Pn}, the set consisting of all the processes in the system. • R = {R 1, R 2, …, Rm}, the set consisting of all resource types in the system. – request edge – directed edge P 1 Rj – assignment edge – directed edge Rj Pi 7

RESOURCE ALLOCATION GRAPHS (cont. ) • Process • Resource Type with 4 instances • Pi requests instance of Rj Pi Rj • Pi is holding an instance of Rj Pi Rj 8

EXAMPLE OF A RESOURCE ALLOCATION GRAPH 9

Resource Allocation Graph w/ Cycles and Deadlock 10

Resource Allocation Graph w/ Cycle But No Deadlock 11

WHAT DO CYCLES TELL US? • If resource allocation graph contains no cycles, then no deadlock can occur • If graph contains a cycle then, – if only one instance per resource type, then deadlock. – if several instances per resource type, possibility of deadlock. 12

METHODS FOR HANDLING DEADLOCKS • Prevention – Ensure that one or more of the four necessary conditions for deadlock never occur • Avoidance – Only allocate resources that keep system in safe state. Requires more info and decision with each allocation request • Detection & Recovery – Allow the system to enter a deadlock state and then recover. • Ignore the problem – Don’t do anything. Doesn’t happen that often and cost of avoidance or prevention very high 13

DEADLOCK PREVENTION • Prevent Mutual Exclusion: – Use sharable resources or virtual devices where possible • e. g. , print spooling, read-only files – Problem: Not always possible. Still must hold Hold non -sharable resources • e. g. , tape drives are intrinsically non-sharable 14

DEADLOCK PREVENTION (cont. ) • Prevent Hold and Wait: – Option A: Allocate all required resources at start of job (static) or – Option B: Guarantee that whenever a process requests a resource, it does not hold any other resources. • Release all resources before requesting new ones • Example: Assume process requires tape, disk and printer. – – Request(Tape, Disk) Release(Tape, Disk) Request(Disk, Printer) Release(Disk, Printer – Problem: Low resource utilization; starvation possible. 15

DEADLOCK PREVENTION (cont. ) • Allow Preemption: – Option A: If a process holding some resources requests another resource that cannot be immediately allocated to it, then all resources currently being held by requesting process are released. • Preempted resources are added to the list of resources for which the process is waiting. • Process will be restarted only when it can regain its old resources, as well as the new ones that it is requesting. – Option B: Take resource away from other process currently holding that resource. • Works better with memory, less well with tapes, printers • Problems: Who’s the victim? Kill or rollback? Starvation? 16

DEADLOCK PREVENTION (cont. ) • Preventing Circular Wait: – Use a hierarchy of resources based on importance – Impose a total ordering using this hierarchy on all resource types – Require that each process request resources in an increasing order of enumeration. – Process cannot request a resource with a lower number until it releases all resources of higher value. • All four approaches to deadlock prevention can result in: – Lower device/resource utilization – Decreased throughput for the system. 17

DEADLOCK AVOIDANCE • Need additional a priori information about resource requirements for each process – Simplest and most useful model requires that each process declare the maximum number of resources of each type that it may need. • Must define the current state of resource allocations (which are free, which are assigned) • Must seek a “safe state” in which the system can allocate resources to each process in some order and still avoid deadlock. – System is in safe state if there exists a safe sequence for execution of all processes. • Objective of deadlock avoidance algorithm is to move from one safe state to another. 18

EXAMPLE OF SAFE STATE • Assume we have 12 instances of a resource P 1 P 2 P 3 Totals Current Allocation 1 4 5 10 Max Required 4 6 8 18 Still Needed 3 2 instances of resource to be allocated. • Safe sequences are <P 2, P 1, P 3> and <P 2, P 3, P 1> 19

EXAMPLE OF UNSAFE STATE • Assume we have 12 instances of a resource P 1 P 2 P 3 Totals Current Allocation 5 2 3 10 Max Required 10 4 9 23 Still Needed 5 2 6 2 instances of resource to be allocated. • There is no safe sequences. Deadlock will occur even after P 2 completes 20

DEADLOCK AVOIDANCE (cont. ) • When a process requests an available resource, system must decide if immediate allocation leaves the system in a safe state. – If a system is in a safe state after allocation no deadlocks go ahead and allocate – If a system is in an unsafe state after allocation possibility of deadlock don’t allocate • Avoidance ensures that a system will never enter an unsafe state. – – Resource Allocation Graph Algorithm Banker’s Algorithm Both costly to implement in terms of computation time. Not used often 21

DEADLOCK DETECTION & RECOVERY • Allow system to enter deadlock state • Detection algorithm identifies that deadlock has occurred • Recovery scheme determines how to undo the deadlock 22

WAIT-FOR GRAPH (Single Instance of Each Resource Type) • Maintain wait-for graph – Nodes are processes. – Pi Pj if Pi is waiting for Pj. – Built by collapsing resource allocation graph to have process nodes (vertices) only • Periodically invoke an algorithm to search for a cycle in the wait-for graph. – Single Instance Solution, cycle indicates deadlock • An algorithm to detect a cycle in a graph requires an order of n 2 operations, where n is the number of vertices in the graph. – Gets very costly if run frequently 23

Resource-Allocation Graph and Wait-for Graph Resource-Allocation Graph Corresponding Wait-For Graph 24

Detection-Algorithm Usage • When, and how often, to invoke depends on: – How often a deadlock is likely to occur? – How many processes will be affected by deadlock? • The longer the wait between invocations, the more processes may be involved. – If detection algorithm invoked arbitrarily, there may be many cycles in the resource graph • May not be able to tell which of the many deadlocked processes “caused” the deadlock. – May want to invoke algorithm at certain time intervals (e. g. , once per hour, half-hour) or when certain events occur (CPU utilization < 40%) 25

Recovery Schemes: Process Termination • Option A: Abort all deadlocked processes. • Option B: Abort one process at a time until the deadlock cycle is eliminated. – In which order should we choose to abort? • Priority of the process. • How long process has computed, and how much longer to completion. • Resources the process has used. • Resources process needs to complete. • How many processes will need to be terminated. • Is process interactive or batch? • Option C: Rollback or return to some safe state, restart processes from that state. • Problem: Starvation of victim if chosen often 26