Chapter 8 Deadlocks Operating System Concepts 10 th

Chapter 8: Deadlocks Operating System Concepts – 10 th Edition Silberschatz, Galvin and Gagne © 2018

Chapter 8: Deadlocks n System Model n Deadlock in Multithreaded Applications n Deadlock Characterization n Methods for Handling Deadlocks n Deadlock Prevention n Deadlock Avoidance n Deadlock Detection n Recovery from Deadlock Operating System Concepts – 10 th Edition 8. 2 Silberschatz, Galvin and Gagne © 2018

Chapter Objectives n Illustrate how deadlock can occur when mutex locks are used n Define the four necessary conditions that characterize deadlock n Identify a deadlock situation in a resource allocation graph n Evaluate the four different approaches for preventing deadlocks n Apply the banker’s algorithm for deadlock avoidance n Apply the deadlock detection algorithm n Evaluate approaches for recovering from deadlock Operating System Concepts – 10 th Edition 8. 3 Silberschatz, Galvin and Gagne © 2018

Background n In a multiprogramming/multithreading environment, l Several threads may compete for a finite number of resources l A thread requests resources: 4 If the resources are not available at that time, the thread enters a waiting state. 4 Sometimes, a waiting thread can never again change state, because the resources it has requested are held by other waiting threads 4 This situation is called a deadlock. n Deadlock is a situation in which every process in a set of processes is waiting for an event that can be caused only by another process in the set, all of which are waiting n Perhaps the best illustration of a deadlock can be drawn from a law passed by the Kansas legislature early in the 20 th century. It said, in part: l “When two trains approach each other at a crossing, both shall come to a full stop and neither shall start up again until the other has gone. ” Operating System Concepts – 10 th Edition 8. 4 Silberschatz, Galvin and Gagne © 2018

System Model Operating System Concepts – 10 th Edition Silberschatz, Galvin and Gagne © 2018

System Model n System consists of resources l Resource types R 1, R 2, . . . , Rm E. g. CPU cycles, memory space, I/O devices, etc. l Each resource type Ri has Wi instances. n Under the normal mode of operation, a process/thread utilizes a resource as follows: l Request: 4 The thread requests the resource. If the request cannot be granted immediately (i. e, if a mutex lock is currently held by another thread), then the requesting thread must wait until it can acquire the resource. l Use: 4 The thread can operate on the resource (i. e. , if the resource is a mutex lock, the thread can access its critical section) l Release: 4 The thread releases the resource Operating System Concepts – 10 th Edition 8. 6 Silberschatz, Galvin and Gagne © 2018

Deadlock in Multithreaded Application n Two mutex locks are created an initialized: n Note: If a thread attempts to acquire a locked mutex, the call to: l Pthread_mutex_lock() blocks the thread until the owner of the mutex lock invokes the pthread_mutex_unlock() Operating System Concepts – 10 th Edition 8. 7 Silberschatz, Galvin and Gagne © 2018

Deadlock in Multithreaded Application /* thread one runs in this function */ void *do_work_one(void *param) { pthread_mutex_lock( &first_mutex ); pthread_mutex_lock( &second_mutex ); /** * Do some work */ pthread_mutex_unlock( &second_mutex ); pthread_mutex_unlock( &first_mutex ); pthread_exit(0); } /* thread two runs in this function */ void *do_work_two(void *param) { pthread_mutex_lock( &second_mutex ); pthread_mutex_lock( &first_mutex ); /** * Do some work */ pthread_mutex_unlock( &first_mutex ); pthread_mutex_unlock( &second_mutex ); pthread_exit(0); } Operating System Concepts – 10 th Edition 8. 8 Silberschatz, Galvin and Gagne © 2018

Deadlock in Multithreaded Application n Deadlock is possible, if : l thread_one acquires first_mutex and thread_two acquires second_mutex l thread_one then waits for second_mutex and thread_two waits for first_mutex. n Can be illustrated with a resource allocation graph: Operating System Concepts – 10 th Edition 8. 9 Silberschatz, Galvin and Gagne © 2018

Deadlock in Multithreaded Application n Note that, even though deadlock is possible, l it will not occur if thread_one can acquire and release the mutex locks for first mutex and second mutex before thread_two attempts to acquire the locks. n And, of course, the order in which the threads run depends on how they are scheduled by the CPU scheduler. n This example illustrates a problem with handling deadlocks: l it is difficult to identify and test for deadlocks that may occur only under certain scheduling circumstances Operating System Concepts – 10 th Edition 8. 10 Silberschatz, Galvin and Gagne © 2018

Deadlock Characterization Deadlock can arise if four conditions hold simultaneously. 1. Mutual exclusion: l Only one process at a time can use a resource 2. Hold and wait: l A process holding at least one resource is waiting to acquire additional resources held by other processes 3. No preemption: l A resource can be released only voluntarily by the process holding it, after that process has completed its task 4. Circular wait: l There exists a set {P 0, P 1, …, Pn} of waiting processes such that P 0 is waiting for a resource that is held by P 1, l P 1 is waiting for a resource that is held by P 2, …, l Pn– 1 is waiting for a resource that is held by Pn, l and Pn is waiting for a resource that is held by P 0. Operating System Concepts – 10 th Edition 8. 11 Silberschatz, Galvin and Gagne © 2018

Resource-Allocation Graph n Deadlocks can be described more precisely in terms of a directed graph called a system resource-allocation graph. n A set of vertices V and a set of edges E. l V is partitioned into two types: 4 P = {P 1, – the set consisting of all the processes in the system 4 R = {R 1, – P 2, …, Pn}, R 2, …, Rm}, the set consisting of all resource types in the system l Request edge – directed edge Pi Rj l Assignment edge – directed edge Rj Pi (or Pi Rj ) Operating System Concepts – 10 th Edition 8. 12 Silberschatz, Galvin and Gagne © 2018

Resource Allocation Graph Example n One instance of R 1 n Two instances of R 2 n One instance of R 3 n Three instance of R 4 n T 1 holds one instance of R 2 and is waiting for an instance of R 1 n T 2 holds one instance of R 1, one instance of R 2, and is waiting for an instance of R 3 n T 3 holds one instance of R 3 Operating System Concepts – 10 th Edition 8. 13 Silberschatz, Galvin and Gagne © 2018

Resource Allocation Graph With A Deadlock No Deadlock If graph contains no cycles no deadlock If graph contains a cycle if only one instance per resource type, then deadlock if several instances per resource type, possibility of deadlock Operating System Concepts – 10 th Edition 8. 14 Silberschatz, Galvin and Gagne © 2018

Methods for Handling Deadlocks Operating System Concepts – 10 th Edition Silberschatz, Galvin and Gagne © 2018

Methods for Handling Deadlocks n Generally speaking, we can deal with the deadlock problem in one of three ways: 1. Ignore the problem and pretend that deadlocks never occur in the system 2. Use a protocol to prevent or avoid deadlocks, ensuring that the system will never enter a deadlocked state 4 Deadlock – Prevention Ensure that at least one of the necessary conditions cannot hold » (Mutual Exclusion, Hold and Wait, No Preemption, and Circular Wait) 4 Deadlock Avoidance – OS need to be given additional information in advance concerning which resources a thread will request and use during its lifetime, then the OS can decide for each request whether or not the thread should wait – For each thread need to know: Available vs. Allocated resources, and what are the future requests and releases 3. Allow the system to enter a deadlock state and then 4 If neither a deadlock-prevention nor a deadlock-avoidance is implemented, then a deadlock situation may arise 4 Thus, we must be able to Detect it, and Recover from it Operating System Concepts – 10 th Edition 8. 16 Silberschatz, Galvin and Gagne © 2018

1. Deadlock Prevention Simply, Invalidate one of the four necessary conditions for deadlock: 1. Mutual Exclusion – We cannot prevent deadlocks by denying the mutualexclusion condition § not required for sharable resources (e. g. , read-only files); § must hold for non-sharable resources (e. g. a mutex lock cannot be simultaneously shared by several threads) 2. Hold and Wait – We need to: “ensure that the hold-and-wait condition never occurs in the system” § must guarantee that whenever a process requests a resource, it does not hold any other resources 4 Approach #1: require process to request and be allocated all its resources before it begins execution, – 4 Cons: impractical for most applications and if applied Low resource utilization Approach #2: allows a thread to request resources only when it has none allocated to it. – Cons: may lead to starvation, wait indefinitely » If the needed R is always allocated to some other thread Operating System Concepts – 10 th Edition 8. 17 Silberschatz, Galvin and Gagne © 2018

1. Deadlock Prevention (Cont. ) 3. No Preemption – of resources that have already been allocated, to prevent deadlock, we need to ensure that this condition does not hold: l If a process is holding some resources and requests another that cannot be immediately allocated to it, then all resources currently being held are released (preempted) 4 Preempted resources are added to the list of resources for which the process is waiting for 4 Process will be restarted only when it can regain its old resources as well as the new ones that it is requesting n All three above options are almost impractical in most situations 4. Circular Wait – preventing it is a practical solution l imposing a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration Operating System Concepts – 10 th Edition 8. 18 Silberschatz, Galvin and Gagne © 2018

How to Invalidate Circular Wait n Invalidating the circular wait condition is most common. n Simply, assign each resource (i. e. mutex locks) a unique number, ( this number determines whether one precedes another) n An ordering among all synchronization objects n Then, resources must be acquired in order. n i. e. each thread can request resources only in an increasing order of enumeration and released in a decreasing order n Example: first_mutex = 1 second_mutex = 5 code for thread_two could not be written as follows: n If used, then circular-wait condition cannot hold. Operating System Concepts – 10 th Edition 8. 19 Silberschatz, Galvin and Gagne © 2018

1. Deadlock Prevention (Cont. ) n Deadlock-prevention algorithms prevent deadlocks by limiting how requests & releases can be made. n Pros: The limits ensure that at least one of the necessary conditions for deadlock cannot occur n Cons: Possible side effects of preventing deadlocks by this method, l low device utilization and l reduced system throughput Operating System Concepts – 10 th Edition 8. 20 Silberschatz, Galvin and Gagne © 2018

2. Deadlock Avoidance • • Deadlock-prevention algorithms Prevent deadlocks by limiting how requests can be made. The limits ensure that at least one of the necessary conditions for deadlock cannot occur. Possible side effects of preventing deadlocks by this method, however, are low device utilization and reduced system throughput. An alternative method for avoiding deadlocks is to require additional information about how resources are to be requested 1. Safe State 2. Resource-Allocation-Graph Algorithm 3. Banker’s Algorithm Operating System Concepts – 10 th Edition Silberschatz, Galvin and Gagne © 2018

2. Deadlock Avoidance Requires that the system has some additional a priori information available, (require additional information about how resources are to be requested) n Simplest and most useful model requires that l each process declare the maximum number of resources of each type that it may need n The deadlock-avoidance algorithm l dynamically examines the resource-allocation state to ensure that there can never be a circular-wait condition n Resource-allocation state is defined by l the number of available and allocated resources, and l the maximum demands of the processes Operating System Concepts – 10 th Edition 8. 22 Silberschatz, Galvin and Gagne © 2018

2. 1. Safe State n When a process requests an available resource, system must decide if immediate allocation leaves/keeps the system in a safe state n A state is safe if the system can allocate resources to each thread/process (up to its maximum) in some order and still avoid a deadlock. l System is in a safe state if there exists a sequence <P 1, P 2, …, Pn> of ALL the processes in the systems such that: 4 for each Pi, the resources that Pi can still request to be satisfied by currently available resources + resources held by all the Pj, with j < i n That is: l If Pi resource needs are not immediately available, then Pi can wait until all Pj have finished l When Pj is finished, Pi can obtain needed resources, execute, return allocated resources, and terminate l When Pi terminates, then Pi+1 can obtain its needed resources, and so on Operating System Concepts – 10 th Edition 8. 23 Silberschatz, Galvin and Gagne © 2018

Safe State Example n Consider a system with: l 12 resources and l 3 threads/processes: T 0, T 1, and T 2. l Assume: T 0 requires 10 resources, thread T 1 may need as many as 4, and thread T 2 may need up to 9 resources. l Suppose that, at time t 0, thread T 0 is holding 5 resources, thread T 1 is holding 2 resources, and thread T 2 is holding 2 resources. (Thus, there are 3 free resources. ) n At time t 0, the system is in a safe state. The sequence <T 1, T 0, T 2> satisfies the safety condition l n T 1 can immediately be allocated all its resources and then return them (the system will then have 5 available resources); then T 0 can get all its resources and return them (the system will then have 10 available resources); and finally T 2 can get all its resources and return them (the system will then have all 12 resources available). A system can go from a safe state to an unsafe state. Suppose that, at time t 1, the T 2 requests and is allocated 1 more resource. l Then only T 1 can be allocated all its resources. When it returns them, the system will have only 4 available resources. Since T 0 is allocated 5 resources but has a maximum of 10, it may request 5 more resources. If it does so, it will have to wait, because they are unavailable. Operating System Concepts – 10 th Edition 8. 24 Silberschatz, Galvin and Gagne © 2018

Basic Facts n If a system is in safe state no deadlocks n If a system is in unsafe state possibility of deadlock n Avoidance ensure that a system will never enter an unsafe state. (how ? ) n Safe, Unsafe, Deadlock State l A safe state is not a deadlocked state. l Equally, a deadlocked state is an unsafe state. l Not all unsafe states are deadlocks Safe, Unsafe, Deadlock State n As long as the state is safe, the operating system can avoid unsafe (and deadlocked) states Operating System Concepts – 10 th Edition 8. 25 Silberschatz, Galvin and Gagne © 2018

Avoidance Algorithms n Single instance of a resource type l Use a resource-allocation graph n Multiple instances of a resource type l Use the Banker’s Algorithm Operating System Concepts – 10 th Edition 8. 26 Silberschatz, Galvin and Gagne © 2018

1. Resource-Allocation Graph Scheme n introduce a new type of edge, called Claim edge Pi --- Rj indicated that process Pi may request resource Rj; represented by a dashed line (-----) n Claim Edge converts to Request Edge when a process requests a resource n Request Edge converted to an Assignment Edge when the resource is allocated to the process n When a resource is released by a process, assignment edge reconverts back to a Claim Edge Request Edge n Resources must be claimed a priori in the system Assignment Edge <T 1, T 2>: safe <T 2, T 1>: unsafe Operating System Concepts – 10 th Edition Claim Edge 8. 27 Silberschatz, Galvin and Gagne © 2018

1. Resource-Allocation Graph Algorithm n Suppose that process Pi requests a resource Rj n The request can be granted only l • • • if converting the request edge to an assignment edge does not result in the formation of a cycle in the resource allocation graph Suppose that T 2 requests R 2. Although R 2 is currently free, we cannot allocate it to T 2, since this action will create a cycle in the graph. Figure shows a cycle indicates that the system is in an unsafe state. If T 1 requests R 2, and T 2 requests R 1, then a deadlock will occur. 1 2 <T 1, T 2>: safe <T 2, T 1>: unsafe Operating System Concepts – 10 th Edition Unsafe State In Resource-Allocation Graph 8. 28 Silberschatz, Galvin and Gagne © 2018

2. Banker’s Algorithm n The resource-allocation-graph algorithm is not applicable to a resource allocation system with multiple instances of each resource type. n However, this Banker’s Algorithm is applicable to such a system but is less efficient than the resource-allocation graph scheme. l used in a banking system to ensure that the bank never allocated its available cash in such a way that it could no longer satisfy the needs of all its customers n Banker’s Algorithm n Determines whether the allocation of resources keeps it in a safe state l Handles Multiple instances of resources l Each process must a priori claim maximum use (# of resources) l 4 it must declare the maximum number of instances of each resource type that it may need 4 number may not exceed the total number of resources in the system When a process requests a resource it may have to wait 4 l until some other thread releases enough resources When a process gets all its resources it must return resources in a finite amount of time Operating System Concepts – 10 th Edition 8. 29 Silberschatz, Galvin and Gagne © 2018

Data Structures for the Banker’s Algorithm Let n = number of processes/threads in the system, and m = number of resources types. n Available: Vector of length m, number of available resources of each type l If available[j]==k, there are k instances available of resource type Rj n Max: An n x m matrix, maximum demand of each thread l If Max[i, j]==k, then process Pi may request at most k instances of resource type Rj n Allocation: An n x m matrix. # resources of each type currently allocated to each thread l If Allocation[i, j]==k, then Pi is currently allocated k instances of Rj n Need: An n x m matrix. # of remaining resource need of each thread l If Need[i, j]==k, then Pi may need k more instances of Rj to complete its task l Note that: Need[i, j] = Max[i, j] – Allocation [i, j] Operating System Concepts – 10 th Edition 8. 30 Silberschatz, Galvin and Gagne © 2018

Safety Algorithm 1. Let Work and Finish be vectors of length m and n, respectively. Initialize: Work = Available Finish[i] = false; #for i = 0, 1, …, n-1 l Initially, no process has finished and the number of available resources is represented by the Available array. 2. Find an index i such that both: (a) Finish[i] == false and (b) Needi Work If no such i exists, go to step 4 l : need for the Pi Find an unfinished process whose need can be satisfied by the available resources. If no such process exists, just go to step 4. 3. Work = Work + Allocationi Finish[i] = true go to step 2 l When an unfinished process is found, then the resources are allocated and the process is marked finished. Then, the loop is repeated to check all other processes. 4. If Finish[i] == true for all i, then the system is in a safe state n Note: this algorithm may require an order of m × n 2 operations to determine whether a state is safe. Operating System Concepts – 10 th Edition 8. 31 Silberschatz, Galvin and Gagne © 2018

Resource-Request Algorithm for Process Pi n Describe the algorithm for determining whether requests can be safely granted. Requesti is request vector for process Pi. If Requesti [j] == k then process Pi wants k instances of resource type Rj 1. If Requesti Needi go to step 2. Otherwise, raise error condition, since process has exceeded its maximum claim 2. If Requesti Available, go to step 3. Otherwise Pi must wait, since resources are not available 3. Pretend to allocate requested resources to Pi by modifying the state as follows (what will be the system state if): Available = Available – Requesti; Allocationi = Allocationi + Requesti; Needi = Needi – Requesti; n If the resulting resource-allocation state is safe complete the allocation to Pi n If new state is unsafe Pi must wait, and the old resource-allocation state is restored Operating System Concepts – 10 th Edition 8. 32 Silberschatz, Galvin and Gagne © 2018

Example of Banker’s Algorithm n Consider a system with 5 processes/threads P 0 through P 4; and n 3 resource types A, B, and C: l Type A (10 instances), l Type B (5 instances), and l Type C (7 instances) n Snapshot at time t 0: Allocation Max Available ABC ABC P 0 0 1 0 7 5 3 3 3 2 P 1 2 0 0 3 2 2 P 2 3 0 2 9 0 2 P 3 2 1 1 2 2 2 P 4 0 0 2 4 3 3 Operating System Concepts – 10 th Edition 8. 33 Silberschatz, Galvin and Gagne © 2018

Example (Cont. ) n The content of the matrix Need is defined to be Max – Allocation Need P 0 P 1 P 2 P 3 P 4 Allocation Max Available Allocation Max A Available ABC BC ABC Need ABC A B 0 C 1 0 ABC 753 ABC 332 A B C P 0 0 1 20 0 0 7 5 3 3 2 32 3 2 7 4 3 P 0 P 1 P 07 4 3 2 0300 2 322 902 1 2 2 P P 2 P 11 2 2 1 3 0 22 1 1 902 222 6 0 0 P 3 P 2 2 1 01 0 2 222 433 0 1 1 P 2 P 4 P 36 0 0 433 4 3 1 P P 40 1 10 0 2 3 P 4 4 3 1 n We claim that the system is currently in a safe state. Indeed, the sequence < P 1, P 3, P 4, P 2, P 0> satisfies safety criteria, is this correct? is this correct Operating System Concepts – 10 th Edition 8. 34 Silberschatz, Galvin and Gagne © 2018

Example: P 1 Request (1, 0, 2) n Suppose now that thread P 1 requests one additional instance of resource type A and two instances of resource type C, so Request 1 = (1, 0, 2). n To decide whether this request can be immediately granted, we first Check that Request 1 Available (that is, (1, 0, 2) (3, 3, 2) true) n Then, pretend that this request has been fulfilled, we arrive at the following new state, we should get following state: P 0 P 1 P 2 P 3 P 4 Allocation Need Allocation Available. Max Need A BACB C A B C P 0 010 753 743 P 0 0 20 1 0 7 4 3 2 3 0 P 1 302 322 0 P 1 3 0 2 0 P 2 302 902 600 P 6 0 0 211 222 1 3 P 2 0 13 0 2 P 4 002 433 431 P 3 2 1 1 0 1 1 P 4 0 0 2 Available ABC 230 4 3 1 n We must determine whether this new system state is safe, Executing safety algorithm shows that sequence < P 1, P 3, P 4, P 0, P 2> satisfies safety requirement n Can request for (3, 3, 0) by P 4 be granted? No, resources are not available n Can request for (0, 2, 0) by P 0 be granted? No, the resulting state is unsafe Operating System Concepts – 10 th Edition 8. 35 Silberschatz, Galvin and Gagne © 2018

Deadlock Detection • Single Instance of Each Resource Type • Several Instances of a Resource Type • Detection-Algorithm Usage Operating System Concepts – 10 th Edition Silberschatz, Galvin and Gagne © 2018

Deadlock Detection n If a system does not employ either a: l deadlock-prevention or a l deadlock-avoidance algorithm, 4 Then a deadlock situation may occur n Allow system to enter deadlock state. Thus, the environment provide: l Detection Algorithm 4 An algorithm that examines the state of the system to determine whether a deadlock has occurred l Recovery Scheme 4 An algorithm to recover from the deadlock Operating System Concepts – 10 th Edition 8. 37 Silberschatz, Galvin and Gagne © 2018

Single Instance of Each Resource Type n Maintain wait-for graph l Obtain this graph from the resource-allocation graph by removing the resource nodes and collapsing the appropriate edges l Nodes are processes l Pi Pj if Pi is waiting for Pj n Periodically invoke an algorithm that searches for a cycle in the graph. l If there is a cycle, there exists a deadlock n An algorithm to detect a cycle in a graph requires an order of O(n 2) operations, where n is the number of vertices in the graph (# of processes and/or threads) Operating System Concepts – 10 th Edition 8. 38 Silberschatz, Galvin and Gagne © 2018

Resource-Allocation Graph and Wait-for Graph Resource-Allocation Graph Corresponding wait-for graph As before, a deadlock exists in the system iff the wait-for graph contains a cycle. Operating System Concepts – 10 th Edition 8. 39 Silberschatz, Galvin and Gagne © 2018

Several Instances of a Resource Type n Note: the wait-for graph scheme is not applicable to a resource-allocation system with multiple instances of each resource type. n Then, We turn now to a deadlock detection algorithm that is applicable to such a system similar to those used in the banker’s algorithm l Available: A vector of length m indicates the number of available resources of each type l Allocation: An n x m matrix defines the number of resources of each type currently allocated to each process l Request: An n x m matrix indicates the current request of each process. If Request[i][j]==k, then process Pi is requesting k more instances of resource type Rj. Operating System Concepts – 10 th Edition 8. 40 Silberschatz, Galvin and Gagne © 2018

Detection Algorithm 1. Let Work and Finish be vectors of length m and n, respectively Initialize: (a) Work = Available (b) For i = 1, 2, …, n, if Allocationi 0, then Finish[i] = false; otherwise, Finish[i] = true 2. Find an index i such that both: (a) Finish[i] == false (b) Requesti Work If no such i exists, go to step 4 3. Work = Work + Allocationi Finish[i] = true go to step 2 4. If Finish[i] == false, for some i, 1 i n, then the system is in deadlock state. Moreover, if Finish[i] == false, then Pi is deadlocked Operating System Concepts – 10 th Edition 8. 41 Silberschatz, Galvin and Gagne © 2018

Example: Detection Algorithm n To illustrate this algorithm, consider a system with five processes P 0 through P 4; three resource types A (7 instances), B (2 instances), and C (6 instances) n Snapshot at time t 0: Allocation Request ABC P 0 Available ABC 0 1 0 0 0 0 P 1 2 0 0 2 P 2 3 0 3 0 0 0 P 3 2 1 1 1 0 0 P 4 0 0 2 n We claim that the system is not in a deadlocked state. , Sequence <P 0, P 2, P 3, P 1, P 4> will result in Finish[i] = true for all i Operating System Concepts – 10 th Edition 8. 42 Silberschatz, Galvin and Gagne © 2018

Example (Cont. ) n Suppose now that P 2 requests an additional instance of type C (one additional request) P 0 P 1 P 2 P 3 P 4 New Request ABC 000 202 001 100 002 P 0 P 1 P 2 P 3 P 4 Request A B Allocation C ABC P 0 010 0 P 2 0 2 200 1 P 2 3 0 0 1 P 3 2 1 1 P 1 0 0 002 4 0 0 2 Request ABC 000 202 000 100 002 Available ABC 000 n Can we still work with this sequence: <P 0, P 2, P 3, P 1, P 4> n State of system? l Can reclaim resources held by process P 0, but insufficient resources to fulfill other processes; requests l Deadlock exists, consisting of processes P 1, P 2, P 3, and P 4 Operating System Concepts – 10 th Edition 8. 43 Silberschatz, Galvin and Gagne © 2018

Detection-Algorithm Usage n When, and how often, to invoke depends on: l How often a deadlock is likely to occur? l How many processes will need to be rolled back? 4 one for each disjoint cycle n If detection algorithm is invoked arbitrarily, l there may be many cycles in the resource graph and l so we would not be able to tell which of the many deadlocked processes “caused” the deadlock. n Note: Deadlocks occur only when some thread/processes makes a request that cannot be granted immediately. l This request may be the final request that completes a chain of waiting threads. In the extreme, then, we can invoke the deadlock detection algorithm every time a request for allocation cannot be granted immediately. 4 In this case, we can identify not only the deadlocked set of threads but also the specific thread that “caused” the deadlock. (incur considerable overhead) Operating System Concepts – 10 th Edition 8. 44 Silberschatz, Galvin and Gagne © 2018

Recovery from Deadlock • Process and Thread Termination • Resource Preemption Operating System Concepts – 10 th Edition Silberschatz, Galvin and Gagne © 2018

Recovery from Deadlock: Process Termination n There are two options for breaking a deadlock: l Abort all deadlocked processes l Abort one process at a time until the deadlock cycle is eliminated n In which order should we choose to abort? 1. Priority of the process 2. How long process has computed, and how much longer to completion 3. Resources the process has used 4. Resources process needs to complete 5. How many processes will need to be terminated 6. Is process interactive or batch? Operating System Concepts – 10 th Edition 8. 46 Silberschatz, Galvin and Gagne © 2018

Recovery from Deadlock: Resource Preemption n Selecting a victim – minimize cost n Rollback – If we preempt a resource from a process, what should be done with that process? return to some safe state, restart process for that state. l Since, in general, it is difficult to determine what a safe state is, the simplest solution is a total rollback: abort the process and then restart it. n Starvation – How do we ensure that starvation will not occur? same process may always be picked as victim, include number of rollback in cost factor Operating System Concepts – 10 th Edition 8. 47 Silberschatz, Galvin and Gagne © 2018

End of Chapter 8 Operating System Concepts – 10 th Edition Silberschatz, Galvin and Gagne © 2018