Chapter 7 Deadlocks Operating System Concepts 9 th

Chapter 7: Deadlocks Operating System Concepts – 9 th Edition Silberschatz, Galvin and Gagne © 2013

Chapter 7: Deadlocks n System Model n Deadlock Characterization n Methods for Handling Deadlocks n Deadlock Prevention n Deadlock Avoidance n Deadlock Detection n Recovery from Deadlock Operating System Concepts – 9 th Edition 7. 2 Silberschatz, Galvin and Gagne © 2013

Chapter Objectives n To develop a description of deadlocks, which prevent sets of concurrent processes from completing their tasks n To present a number of different methods for preventing or avoiding deadlocks in a computer system Operating System Concepts – 9 th Edition 7. 3 Silberschatz, Galvin and Gagne © 2013

Introduction - Deadlock n In a multiprogramming environment, several processes may compete for a finite number of resources. n A process requests resources; if the resources are not available at that time, the process enters a waiting state. n Sometimes, a waiting process is never again able to change state, because the resources it has requested are held by other waiting processes. This situation is called a deadlock. Operating System Concepts – 9 th Edition 7. 4 Silberschatz, Galvin and Gagne © 2013

Introduction n This chapter describes various methods that an OS can use to prevent or deal with deadlocks. n Although some applications can identify programs that may deadlock, operating systems typically do not provide deadlock-prevention facilities, and it remains the responsibility of programmers to ensure that they design deadlock-free programs. Operating System Concepts – 9 th Edition 7. 5 Silberschatz, Galvin and Gagne © 2013

System Model n A system consists of a finite number of resources to be distributed among a number of competing processes. n The resources may be partitioned into several types (or classes), each consisting of some number of identical instances. l CPU cycles, files, and I/O devices (such as printers, DVD drives, etc) are examples of resource types. l If a system has two CPUs, then the resource type CPU has two instances. Operating System Concepts – 9 th Edition 7. 6 Silberschatz, Galvin and Gagne © 2013

System Model n A process must request a resource before using it and must release the resource after using it. l A process may request as many resources as it requires to carry out its designated task. n Obviously, the number of resources requested may not exceed the total number of resources available in the system (Requests Resources). Operating System Concepts – 9 th Edition 7. 7 Silberschatz, Galvin and Gagne © 2013

System Model n A system consists of a finite number of resources n Resource types R 1, R 2, . . . , Rm 4 For example, CPU cycles, memory space, I/O devices n Each resource type Ri has Wi instances. n Each process utilizes a resource as follows: l request l use l release Operating System Concepts – 9 th Edition 7. 8 Silberschatz, Galvin and Gagne © 2013

System Model n request : The process requests the resource. If the request cannot be granted immediately, then the requesting process must wait (blocked) until it can acquire the resource. n use : The process can operate on the resource (if the resource is a printer, the process can print on the printer). n release: The process releases the resource. l A set of processes is in a deadlocked state when every process in the set is waiting for an event that can be caused only by another process in the set. Operating System Concepts – 9 th Edition 7. 9 Silberschatz, Galvin and Gagne © 2013

Deadlock Conditions A deadlock situation can arise if the following four conditions hold simultaneously in a system: . n Mutual exclusion: only one process at a time can use a resource n Hold and wait: a process holding at least one resource is waiting to acquire additional resources held by other processes n No preemption: a resource can be released only voluntarily by the process holding it, after that process has completed its task n Circular wait: 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, 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 Pn is waiting for a resource that is held by P 0. Operating System Concepts – 9 th Edition 7. 10 Silberschatz, Galvin and Gagne © 2013

Deadlock with Mutex Locks n We emphasize that all four conditions must hold for a deadlock to occur. n The circular-wait condition implies the hold-and-wait condition, so the four conditions are not completely independent. n Deadlocks can occur via system calls, locking, etc. Operating System Concepts – 9 th Edition 7. 11 Silberschatz, Galvin and Gagne © 2013

Resource-Allocation Graph n Deadlocks can be described more precisely in terms of a directed graph called a resource-allocation graph. n This graph consists of a set of vertices V and a set of edges E. n The set of vertices V is partitioned into two different types of nodes: P = {P 1, P 2, . . . , Pn}, the set consisting of all the active processes in the system, and R = {R 1, R 2, . . . , Rm}, the set consisting of all resource types in the system. Operating System Concepts – 9 th Edition 7. 12 Silberschatz, Galvin and Gagne © 2013

Resource-Allocation Graph n A directed edge from process Pi to resource type Rj is denoted by Pi → Rj and is called a request edge, l it signifies that process Pi has requested an instance of resource type Rj and is currently waiting for that resource. n A directed edge from resource type Rj to process Pi is denoted by Rj → Pi is called an assignment edge, l it signifies that an instance of resource type Rj has been allocated to process Pi. Operating System Concepts – 9 th Edition 7. 13 Silberschatz, Galvin and Gagne © 2013

Resource-Allocation Graph n The graph has a set of vertices V and a set of edges E. n V is partitioned into two types: l P = {P 1, P 2, …, Pn}, the set consisting of all the processes in the system l R = {R 1, R 2, …, Rm}, the set consisting of all resource types in the system n request edge – directed edge Pi Rj n assignment edge – directed edge Rj Pi Operating System Concepts – 9 th Edition 7. 14 Silberschatz, Galvin and Gagne © 2013

Resource-Allocation Graph n Pictorially, we represent each process Pi as a circle and each resource Rj as a rectangle. n Since resource type Rj may have more than one instance, we represent each such instance as a dot within the rectangle. n Note that a request edge points to only the rectangle Rj , whereas an assignment edge must also designate one of the dots in the rectangle. Operating System Concepts – 9 th Edition 7. 15 Silberschatz, Galvin and Gagne © 2013

Resource-Allocation Graph n Process n Resource Type with 4 instances n Pi requests instance of Rj Pi Rj n Pi is holding an instance of Rj Pi Rj Operating System Concepts – 9 th Edition 7. 16 Silberschatz, Galvin and Gagne © 2013

Resource-Allocation Graph n When a process Pi requests an instance of resource type Rj , a request edge is inserted in the resource-allocation graph. n When this request can be fulfilled, the request edge is instantaneously transformed to an assignment edge. n When the process no longer needs access to the resource, it releases the resource. As a result, the assignment edge is deleted. Operating System Concepts – 9 th Edition 7. 17 Silberschatz, Galvin and Gagne © 2013

Example of a Resource Allocation Graph Figure 7. 1 Operating System Concepts – 9 th Edition 7. 18 Silberschatz, Galvin and Gagne © 2013

A Resource Allocation Graph Figure 7. 1 n The resource-allocation graph shown in Figure 7. 1 depicts the following situation. n The sets P, R, and E: l P = {P 1, P 2, P 3} l R = {R 1, R 2, R 3, R 4} l E = {P 1 → R 1, P 2 → R 3, R 1 → P 2, R 2 → P 1, R 3 → P 3} Operating System Concepts – 9 th Edition 7. 19 Silberschatz, Galvin and Gagne © 2013

A Resource Allocation Graph Figure 7. 1 n Resource instances: ◦ One instance of resource type R 1 ◦ Two instances of resource type R 2 ◦ One instance of resource type R 3 ◦ Three instances of resource type R 4 n Process states: ◦ Process P 1 is holding an instance of resource type R 2 and is waiting for an instance of resource type R 1. ◦ Process P 2 is holding an instance of R 1 and an instance of R 2 and is waiting for an instance of R 3. ◦ Process P 3 is holding an instance of R 3. Operating System Concepts – 9 th Edition 7. 20 Silberschatz, Galvin and Gagne © 2013

Resource Allocation Graph n Given the definition of a resource-allocation graph, it can be shown that; n if the graph contains no cycles, then no process in the system is deadlocked. n If the graph does contain a cycle, then a deadlock may exist. Operating System Concepts – 9 th Edition 7. 21 Silberschatz, Galvin and Gagne © 2013

Resource Allocation Graph n If each resource type has exactly one instance, then a cycle implies that a deadlock has occurred. n If the cycle involves only a set of resource types, each of which has only a single instance, then a deadlock has occurred. n Each process involved in the cycle is deadlocked. n In this case, a cycle in the graph is both a necessary and a sufficient condition for the existence of deadlock. Operating System Concepts – 9 th Edition 7. 22 Silberschatz, Galvin and Gagne © 2013

Resource Allocation Graph n If each resource type has several instances, then a cycle does not necessarily imply that a deadlock has occurred. n In this case, a cycle in the graph is a necessary but not a sufficient condition for the existence of deadlock. n To illustrate this concept, we return to the resource- allocation graph depicted in Figure 7. 1. n Suppose that process P 3 requests an instance of resource type R 2. Since no resource instance is currently available, we add a request edge P 3 → R 2 to the graph (Figure 7. 2). At this point, two minimal cycles exist in the system: Operating System Concepts – 9 th Edition 7. 23 Silberschatz, Galvin and Gagne © 2013

Resource Allocation Graph With A Deadlock Figure -7. 2 Operating System Concepts – 9 th Edition 7. 24 Silberschatz, Galvin and Gagne © 2013

Resource Allocation Graph With A Deadlock -Figure 7. 2 n Suppose that process P 3 requests an instance of resource type R 2. Since no resource instance is currently available, we add a request edge P 3 → R 2 to the graph (Figure 7. 2). At this point, two minimal cycles exist in the system: 4 P 1 → R 1 → P 2 → R 3 → P 3 → R 2 → P 1 4 P 2 → R 3 → P 3 → R 2 → P 2 n Processes P 1, P 2, and P 3 are deadlocked. l Process P 2 is waiting for the resource R 3, which is held by process P 3. Process P 3 is waiting for either process P 1 or process P 2 to release resource R 2. n In addition, process P 1 is waiting for process P 2 to release resource R 1. Operating System Concepts – 9 th Edition 7. 25 Silberschatz, Galvin and Gagne © 2013

Graph With A Cycle But No Deadlock Figure 7. 3 Operating System Concepts – 9 th Edition 7. 26 Silberschatz, Galvin and Gagne © 2013

Resource Allocation Graph With No Deadlock - Figure 7. 3 n Now consider the resource-allocation graph in Figure 7. 3. In this example, we also have a cycle: P 1 → R 1 → P 3 → R 2 → P 1 n However, there is no deadlock. n Observe that process P 4 may release its instance of resource type R 2. n That resource can then be allocated to P 3, breaking the cycle. Operating System Concepts – 9 th Edition 7. 27 Silberschatz, Galvin and Gagne © 2013

Basic Facts n If graph contains no cycles no deadlock n If graph contains a cycle l if only one instance per resource type, then deadlock l if several instances per resource type, possibility of deadlock n In summary, if a resource-allocation graph does not have a cycle, then the system is not in a deadlocked state. n If there is a cycle, then the system may or may not be in a deadlocked state. l Show its proof n This observation is important when we deal with the deadlock problem. Operating System Concepts – 9 th Edition 7. 28 Silberschatz, Galvin and Gagne © 2013

Methods for Handling Deadlocks n Generally speaking, we can deal with the deadlock problem in one of three ways: l We can use a protocol to prevent or avoid deadlocks, ensuring that the system will never enter a deadlocked state. l We can allow the system to enter a deadlocked state, then detect it, and recover. l We can ignore the problem altogether and pretend that deadlocks never occur in the system. n The third solution is the one used by most operating systems, including Linux and Windows. Operating System Concepts – 9 th Edition 7. 29 Silberschatz, Galvin and Gagne © 2013

Methods for Handling Deadlocks n Ensure that the system will never enter a deadlock state by using one of the following schemes: l Deadlock prevention l Deadlock avoidance n Allow the system to enter a deadlock state and then recover n Ignore the problem and pretend that deadlocks never occur in the system; used by most operating systems, including UNIX Operating System Concepts – 9 th Edition 7. 30 Silberschatz, Galvin and Gagne © 2013

Deadlock Prevention n As we noted in the previous section, for a deadlock to occur, each of the four necessary conditions must hold; l Mutual Exclusion l Hold and Wait l No Preemption l Circular Wait n By ensuring that at least one of these conditions cannot hold, we can prevent the occurrence of a deadlock. n We elaborate on this approach by examining each of the four necessary conditions separately. Operating System Concepts – 9 th Edition 7. 31 Silberschatz, Galvin and Gagne © 2013

Mutual Exclusion n Mutual Exclusion – is not required for sharable resources (e. g. , read-only files); it must hold for non-sharable resources. l Sharable resources, in contrast, do not require mutually exclusive access and thus cannot be involved in a deadlock. 4 Read-only files are a good example of a sharable resource. If several processes attempt to open a readonly file at the same time, they can be granted simultaneous access to the file. 4 A process never needs to wait for a sharable resource. Operating System Concepts – 9 th Edition 7. 32 Silberschatz, Galvin and Gagne © 2013

Hold and Wait n Hold and Wait – must guarantee that whenever a process requests a resource, it does not hold any other resources l Require process to request and be allocated all its resources before it begins execution, or allow process to request resources only when the process has none allocated to it. l Low resource utilization; starvation possible Operating System Concepts – 9 th Edition 7. 33 Silberschatz, Galvin and Gagne © 2013

No Preemption n No Preemption – The third necessary condition for deadlocks is that there be no preemption of resources that have already been allocated. l If a process that is holding some resources requests another resource that cannot be immediately allocated to it, then all resources currently being held are released l Preempted resources are added to the list of resources for which the process is waiting l Process will be restarted only when it can regain its old resources, as well as the new ones that it is requesting Operating System Concepts – 9 th Edition 7. 34 Silberschatz, Galvin and Gagne © 2013

Circular Wait n Circular Wait – The fourth and final condition for deadlocks is the circular-wait condition. l One way to ensure that this condition never holds is to impose a total ordering of all resource types and to require that each process requests resources in an increasing order of enumeration. Operating System Concepts – 9 th Edition 7. 35 Silberschatz, Galvin and Gagne © 2013

Deadlock Avoidance n Deadlock-prevention algorithms, as discussed in the previous section prevent deadlocks by limiting how requests can be made. l The limits ensure that at least one of the four necessary conditions for deadlock cannot occur. l Possible side effects of preventing deadlocks by this method, however, are low device utilization and reduced system throughput. n An alternative method for avoiding deadlocks is to require additional information about how resources are to be requested. Operating System Concepts – 9 th Edition 7. 36 Silberschatz, Galvin and Gagne © 2013

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

Safe State n A state is safe if the system can allocate resources to each process (up to its maximum) in some order and still avoid a deadlock. l A safe state is one in which there is at least one sequence of resource allocations to processes that does not result in a deadlock – all of the processes can be run to completion n More formally, a system is in a safe state only if there exists a safe sequence. n A sequence of processes <P 1, P 2, . . . , Pn> is a safe sequence for the current allocation state if, for each Pi , the resource requests that Pi can still make can be satisfied by the currently available resources plus the resources held by all Pj, with j < i. Operating System Concepts – 9 th Edition 7. 38 Silberschatz, Galvin and Gagne © 2013

Safe State n When a process requests an available resource, system must decide if immediate allocation leaves the system in a safe state n System is in safe state if there exists a sequence <P 1, P 2, …, Pn> of ALL the processes in the systems such that for each Pi, the resources that Pi can still request can 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, Pi +1 can obtain its needed resources, and so on Operating System Concepts – 9 th Edition 7. 39 Silberschatz, Galvin and Gagne © 2013

Safe State: Basic Facts n If a system is in safe state no deadlocks n If a system is in unsafe state possibility of deadlock n Deadlock Avoidance ensure that a system will never enter an unsafe state. Operating System Concepts – 9 th Edition 7. 40 Silberschatz, Galvin and Gagne © 2013

Deadlock 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 – 9 th Edition 7. 41 Silberschatz, Galvin and Gagne © 2013

Resource-Allocation Graph Scheme n If we have a resource-allocation system with only one instance of each resource type, we can use a variant of the resource-allocation graph defined here for deadlock avoidance. n In addition to the request and assignment edges already described, we introduce a new type of edge, called a claim edge. n A claim edge Pi → Rj indicates that process Pi may request resource Rj at some time in the future. n Claim edge resembles a request edge in direction but is represented in the graph by a dashed line. Operating System Concepts – 9 th Edition 7. 42 Silberschatz, Galvin and Gagne © 2013

Resource-Allocation Graph Scheme 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 to a claim edge n Resources must be claimed a priori in the system. l That is, before process Pi starts executing, all its claim edges must already appear in the resourceallocation graph. Operating System Concepts – 9 th Edition 7. 43 Silberschatz, Galvin and Gagne © 2013

Resource-Allocation Graph Scheme n Now suppose that process Pi requests resource Rj. The request can be granted only if converting the request edge Pi → Rj to an assignment edge Rj → Pi does not result in the formation of a cycle in the resource-allocation graph. n To illustrate this algorithm, we consider the resource- allocation graph of Figure 7. 7. n Suppose that P 2 requests R 2. Although R 2 is currently free, we cannot allocate it to P 2, since this action will create a cycle in the graph (Figure 7. 8) is an unsafe state. l A cycle, indicates that the system is in an unsafe state n If P 1 requests R 2 and R 2 assigned P 2 and P 2 requests R 1, then a deadlock will occur (Figure 7. 8) Operating System Concepts – 9 th Edition 7. 44 Silberschatz, Galvin and Gagne © 2013

Resource-Allocation Graph - Figure 7. 7 Operating System Concepts – 9 th Edition 7. 45 Silberschatz, Galvin and Gagne © 2013

Unsafe State In Resource-Allocation Graph Figure 7. 8 Operating System Concepts – 9 th Edition 7. 46 Silberschatz, Galvin and Gagne © 2013

Resource-Allocation Graph Algorithm n Suppose that process Pi requests a resource Rj n The request can be granted only if converting the request edge to an assignment edge does not result in the formation of a cycle in the resource allocation graph. Operating System Concepts – 9 th Edition 7. 47 Silberschatz, Galvin and Gagne © 2013

Single Instance of Each Resource Type n Maintain wait-for graph 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. If there is a cycle, there exists a deadlock n 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 Operating System Concepts – 9 th Edition 7. 48 Silberschatz, Galvin and Gagne © 2013

Resource-Allocation Graph and Wait-for Graph Resource-Allocation Graph Operating System Concepts – 9 th Edition 7. 49 Corresponding wait-for graph Silberschatz, Galvin and Gagne © 2013

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 The deadlock avoidance algorithm that we describe next is applicable to such a system but is less efficient than the resource-allocation graph scheme. n This algorithm is commonly known as the banker’s algorithm. n The name was chosen because the algorithm could be 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. Operating System Concepts – 9 th Edition 7. 50 Silberschatz, Galvin and Gagne © 2013

Data Structures for the Banker’s Algorithm Let n = number of processes, and m = number of resources types. n Available: Vector of length m. If available [j] = k, there are k instances of resource type Rj available n Max: n x m matrix. If Max [i, j] = k, then process Pi may request at most k instances of resource type Rj n Allocation: n x m matrix. If Allocation[i, j] = k then Pi is currently allocated k instances of Rj n Need: n x m matrix. If Need[i, j] = k, then Pi may need k more instances of Rj to complete its task Need [i, j] = Max[i, j] – Allocation [i, j] Operating System Concepts – 9 th Edition 7. 51 Silberschatz, Galvin and Gagne © 2013

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 2. Find an i such that both: (a) Finish [i] = false (b) Needi 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] == true for all i, then the system is in a safe state Operating System Concepts – 9 th Edition 7. 52 Silberschatz, Galvin and Gagne © 2013

Resource-Request Algorithm for Process Pi Requesti = 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: Available = Available – Requesti; Allocationi = Allocationi + Requesti; Needi = Needi – Requesti; If safe the resources are allocated to Pi l If unsafe Pi must wait, and the old resource-allocation state is restored l Operating System Concepts – 9 th Edition 7. 53 Silberschatz, Galvin and Gagne © 2013

Example of Banker’s Algorithm n 5 processes P 0 through P 4; 3 resource types: A (10 instances), B (5 instances), and C (7 instances) n Snapshot at time T 0: Allocation Max Available ABC ABC P 0 010 753 332 P 1 200 322 P 2 302 902 P 3 211 222 P 4 002 433 Operating System Concepts – 9 th Edition 7. 54 Silberschatz, Galvin and Gagne © 2013

Example (Cont. ) n The content of the matrix Need is defined to be Max – Allocation Need ABC P 0 743 P 1 122 P 2 600 P 3 011 P 4 431 n The system is in a safe state since the sequence < P 1, P 3, P 4, P 2, P 0> satisfies safety criteria Operating System Concepts – 9 th Edition 7. 55 Silberschatz, Galvin and Gagne © 2013

Example: P 1 Request (1, 0, 2) n Check that Request Available (that is, (1, 0, 2) (3, 3, 2) true Allocation Need Available ABC ABC P 0 010 743 230 P 1 302 020 P 2 302 600 P 3 211 011 P 4 002 431 n 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? n Can request for (0, 2, 0) by P 0 be granted? Operating System Concepts – 9 th Edition 7. 56 Silberschatz, Galvin and Gagne © 2013

Recovery from Deadlock n When a detection algorithm determines that a deadlock exists, several alternatives are available. n There are two options for breaking a deadlock: l One is simply to abort one or more processes to break the circular wait. l The other is to preempt some resources from one or more of the deadlocked processes. Operating System Concepts – 9 th Edition 7. 57 Silberschatz, Galvin and Gagne © 2013

Eliminate deadlocks by aborting a process n To eliminate deadlocks by aborting a process, we use one of two methods. In both methods, the system reclaims all resources allocated to the terminated processes. l Abort all deadlocked processes: This method clearly will break the deadlock cycle, but at great expense. The deadlocked processes may have computed for a long time, and the results of these partial computations must be discarded and probably will have to be recomputed later. l Abort one process at a time until the deadlock cycle is eliminated: This method incurs considerable overhead, since after each process is aborted, a deadlock-detection algorithm must be invoked to determine whether any processes are still deadlocked. Operating System Concepts – 9 th Edition 7. 58 Silberschatz, Galvin and Gagne © 2013

Recovery from Deadlock: Resource Preemption n To eliminate deadlocks using resource preemption, we successively preempt some resources from processes and give these resources to other processes until the deadlock cycle is broken. n If preemption is required to deal with deadlocks, then three issues need to be addressed: l Selecting a victim l Rollback l Starvation Operating System Concepts – 9 th Edition 7. 59 Silberschatz, Galvin and Gagne © 2013

Recovery from Deadlock: Resource Preemption n Selecting a victim – Which resources and which processes are to be preempted? As in process termination, we must determine the order of preemption to minimize cost. n Rollback – If we preempt a resource from a process, what should be done with that process? Clearly, it cannot continue with its normal execution; it is missing some needed resource. l We must roll back the process to some safe state and restart it from that state. Return to some safe state, restart process for that state. n Starvation – How do we ensure that starvation will not occur? same process may always be picked as victim. The most common solution is to include the number of rollbacks in the cost factor. Operating System Concepts – 9 th Edition 7. 60 Silberschatz, Galvin and Gagne © 2013