CHAPTER 8 - DEADLOCKS

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

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

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. • P1 and P2 each hold one tape drive • Each process needs another tape drive to continue. • Sometimes referred to as “Deadly Embrace”

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

SYSTEM MODEL • A system consists of a finite number of different resource types (e.g., R1, R2, . . ., 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

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 {P0, P1, …, P0} of waiting processes such that P0 is waiting for a resource that is held by P1, P1 is waiting for a resource that is held by P2, …, Pn–1 is waiting for a resource that is held by Pn, and P0 is waiting for a resource that is held by P0.

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 = {P1, P2, …, Pn}, the set consisting of all the processes in the system. • R = {R1, R2, …, Rm}, the set consisting of all resource types in the system. • request edge – directed edge P1  Rj • assignment edge – directed edge Rj  Pi

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

EXAMPLE OF A RESOURCE ALLOCATION GRAPH

Resource Allocation Graph w/ Cycles and Deadlock

Resource Allocation Graph w/ Cycle But No Deadlock

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.

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

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

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.

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?

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.

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.

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

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

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

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

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 n2 operations, where n is the number of vertices in the graph. • Gets very costly if run frequently

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

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%)

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

CHAPTER 8 - DEADLOCKS