Deadlock and Starvation

Transcription

1 Chapter 6 Deadlock and Starvation We now look into two more issues that make concurrent processing so much more difficult: deadlock and starvation. We will look at the problems first, and discuss a few ways to deal with them. Deadlock can be defined as the permanent blocking of a set of processes that either compete for system resources or communicate with each other. There is no efficient solution in the general case. We ran into it a few times when solving the consumer/producer problem. All deadlocks involve conflicting needs for resources by two or more processes. 1

2 An example A common example is the traffic deadlock, as shown in the following situation, where four cars have arrived at a four-way stop intersection at approximately the same time. More specifically, Car traveling north needs quadrants 1 and 2; car traveling west needs quadrants 2 and 3; car traveling south needs quadrants 3 and 4; and car traveling east needs quadrants 4 and 1. 2

3 What will happen? The normal rule of the road is that a car at a four way stop should yield to a car immediately to its right. This will work if there are only two or three cars competing for the quadrants. For example, if only the northbound and westbound cars arrive at the intersection, the northbound car will wait for the westbound car. On the other hand, if all the four cars come at the same time. Either all of them stick to the rule, and no one can proceed(circular wait); or all the four ignore the rule, and proceed. Then, each of them will seize a quadrant, but could not get the other (deadlock). Either way, the four cars will get stuck. 3

4 Another example Assume that there are two processes, P and Q. Process P requests resources in the following pattern: try to get A and then B; Release A, and then release B. Process Q just does the opposite. This situation can be summarized in the following picture. Notice that the shaded areas are no passing zones. (?) 4

5 What could happen? There could be a few situations, as shown in the above picture: 1. Q gets B, and then A; later on, it will release B, then A. When P resumes control, it is able to complete without any problem. 2. Q gets B, and then A. P executes for a while, then blocks on a request for A. Q resumes, and then releases B, and A. When P resumes its execution, it is also able to finish. 3. Q gets B and then P gets A. This will lead to a deadlock.(?) 4. P gets A and then Q gets B. This will also lead to deadlock.(?). 5 and 6 are symmetric to 1 and 2, respectively. 5

6 How to get out of this mess? Apparently, weather or not a deadlock occurs depends on both the dynamics of the execution and on the details of the application. For example, if P does not need both resources at the same time, then it may have the following form:..., Get A,..., Release A,..., Get B,..., Release B. Then, deadlock will not occur. Homework: Problem

7 Resource category Resources can be categorized into reusable and consumable. A reusable resource can be safely used by only one process at a time and is later released so that another resource can use it. Examples of such resources include processor, I/O channels, various memories, and data files. Consider two processes that compete for exclusive access to a disk D and a tape drive T, as shown in the following table. Step Process P Step Process Q p 0 Request(D) q 0 Request(T) P 1 Lock(D) q 1 Lock(T) p 2 Request(T) q 2 Request(D) p 3 Lock(T) q 3 Lock(D) p 4 Execute q 4 Execute p 5 Unlock(D) q 5 Unlock(T) p 6 Unlock(T) q 6 Unlock(D) 7

8 What could happen? It is easy to see that deadlock will occur if each process holds one resource and asks for the other. For example, if a multiprogramming system interleaves the two processes as follows: p 0 p 1 q 0 q 1 p 2 q 2. Although it may seem to be a programming error(why they are interleaved this way, out of a total of 14!/7!7! = 3,432 interleaving patterns?), the cause is buried in the complicated and unpredictable dispatching behavior, which makes detection of such problem difficult, if even possible. One way to deal with it is to impose constraints on the order in which resources are requested so that the above sequence will not occur. 8

9 Another example Assume that we have 200 MB available in the main memory, and two processes have the following requesting sequence. If both processes go through the first request and come to the second, a deadlock will occur.(?) Process P Process Q Request 80 MB Request 70 MB Request 60 MB Request 80 MB The best way to deal with this sort of problems is to use virtual memory. 9

10 Consumable resource A consumable resource can be created and destroyed, and there is no limit on the number of such resources of a particular type. When such a resource is acquired by a process, the resource ceases to exist. Examples include interrupts, signals, messages and information in I/O buffers. An example of deadlock with this sort of resources is shown below. Process P Process Q Receive(Q) Receive(P) Send(Q, M1) Send(P, M2) A design error is the cause of such problems, but such an error is difficult to detect. Question: What do you do when picking up the phone? 10

11 When will a deadlock occur? For a deadlock to occur, the following three conditions must be present simultaneously: 1. Mutual exclusion, namely, only one process may use a resource at a time. 2. Hold and wait, namely, a process may hold some allocated resources while waiting for the others to be assigned. 3. No preemption, namely, no resources can be forcibly removed from a process holding it. 11

12 Why these conditions? In many cases, such conditions are desirable. For example, we have seen in many cases mutual exclusion is necessary to guarantee the integrity and consistency of databases. In a multi-process system, many processes will compete for a limited number of resources, thus, the hold-and-wait also has to occur. Preemption should not be done arbitrarily, particularly, it has to be associated with a rollback mechanism to prevent loss of data. 12

13 The catalyst Although the above three conditions are necessary, their combination is not sufficient. For a deadlock to happen, there has to be another piece: 4. Circular wait, namely, a closed chain of processes exist, such that each process holds at least one resource needed by the next process. Remember that we need two semaphores to lock up the processes. Homework: Problem

14 Deadlock prevention This strategy is to design a system in such a way that no deadlock could possibly happen. More specifically, an indirect method is to prevent any one of the above three necessary conditions from happening; while a direct method is to prevent the fourth, sufficient, condition from happening. Mutual exclusion has to be supported in general. However, some resources, such as data files, can allow multiple accesses for reads, but only exclusive writes. (Two locks in database) Hold and wait can be prevented by requiring that all the resources a process needs have to be acquired at one time, and then gets blocked when all the resources are obtained. This method is inefficient since a process now has to wait for all its resources, although it can get started with only a few. 14

15 The condition of no preemption can be alleviated in a few ways. 1) if a process is denied further requests, it must release the resources it has already acquired. 2) if a process requests a resource that is held by another process, OS can take the resource away from that process and give it to the first one. The circular wait condition can be prevented by enforcing a linear order for resource types: If a process has obtained resource R, it can only request resources of type following R in the order. Assume that R i proceeds R j if i < j. Then two processes, A and B can not be deadlocked because A has acquired R i and requested R j ; while B has got R j and requested R i, which cannot happen because of the rule. Obviously, this may also unnecessarily slow down the whole process. But, compromise is the key. 15

16 Deadlock avoidance Deadlock avoidance allows the three necessary conditions but makes sure that the deadlock point will never be reached. Therefore, this strategy will allow more concurrency than the previous one. With an avoidance policy, a decision is dynamically made if the current resource allocation request will potentially lead to a deadlock, and takes actions accordingly. Thus, this strategy needs knowledge of future process request. We will discuss two approaches under this policy: 1) Don t start a process if its demands might lead to a deadlock. 2) Don t grant a request for a resource to a process if it might lead to deadlock. Homework: Problems 6.2 and

17 Process initiation denial Consider a system of n processes and m different types of resources. Let s define total amount of resources by Resource = (R 1, R 2,..., R m ), total amount of available resource by Available = (V 1, V 2,..., V m ), and maximum need by each process for each resource by maxn eed = and current allocation by Allocation = C 1,1 C 1,2 C 1,m C 2,1 C 2, C 2,m. C n,1 C n,2 C n,m A 1,1 A 1,2 A 1,m A 2,1 A 2, A 2,m. A n,1 A n,2 A n,m. 17

18 For all resource i, Now what? R i = V i + n k=1 A k,i. The total resource equals what s available plus whatever allocated. For all process k, and resource i, C k,i R i. No body asks for more than what we have. For all process k, and resource i, A k,i C k,i. We cannot give out more than what we have. The maxneed matrix shows the maximum need of each process for each resource. The information must be declared beforehand so that an avoidance strategy can work. This is not real... 18

19 To play it safe Now, we can define a deadlock avoidance policy that will deny a new process if its resource request might lead to a deadlock as follows: Start a new process, P n+1, only if, for all resource i R i C n+1,i + n k=1 C k,i. We will start a new process if whatever it needs plus whatever all the others need is no more than what we have. This policy is hardly optimal since it assumes the worst scenario, namely the maximum need. Could we be more generous? Yes, we can. 19

20 Resource allocation denial Assume that for a bunch of processes, each of them has one or more resources allocated to it. The state of a system is just the allocation of resources to processes, and can be described by the afore-defined matrixes. A safe state is one in which there is at least one sequence of resource allocation that does not lead to a deadlock. The problem is that, when we can t make everybody happy at the same time, who should we make happy first so that everybody will be eventually happy. Technically, we are looking for a deadlock avoidance sequence. I am sure it cannot be done all the time, but we might be able to do it sometimes... 20

21 A story with a happy ending Below shows a snapshot of resource allocation to four processes. We have the following resource vector (R 1, R 2, R 3 ): R 1 R 2 R , we have nine pieces of R 1, three pieces of R 2 and six pieces of R 3. and theavailable vector (V 1, V 2, V 3 ): R 1 R 2 R We have no R 1 left, one piece each for the other two... 21

22 What do you want? We have the following maximum need C i,j : R 1 R 2 R 3 P P P P , and the following allocation data A i,j, i.e., what you have got: R 1 R 2 R 3 P P P P

23 What else? The current need, namely the difference of the above two matrices: what I still want, besides what I have got: R 1 R 2 R 3 P P P P Mathematically speak, for all k, i, the current need of resource R i by process P k is simply C k,i A k,i. 23

24 Is this a safe state? Since we are looking for at least one sequence, we might try to look for any process that can be completed first, starting with what are needed and what are available. We can t start with P 1, since it has only one unit of R 1 allocated, and it needs 2 more units of R 1, but there is none left. Neither P 3 nor P 4 works, either. On the other hand, if we further allocate the last unit of R 3 to P 2, then P 2 can run to its completion, and release everything back to the system. The available vector will turn to the following, and we are rich. R 1 R 2 R All the rest can then run to their completion. Thus, the initial allocation is a safe state. 24

25 A general strategy When a bunch of processes makes requests for a set of resources, we check if there is a process, for which, all its current need can be satisfied based on what we have, and, if so, change the system state accordingly since this would lead to a safe state. Mathematically speaking, if, for some Process P k, and for all resource i [1, m], V i C k,i A k,i. We will meet all its needs, C k,i A k,i, i [1, m], then get them back after it completes. Compared with the original deadlock denial policy, it is not necessary to preempt and rollback processes, and is less restrictive, although we still need to know the maximum need for all kinds of resource by each process. Homework: Problem

26 Deadlock detection With deadlock detection, requested resources are granted whenever possible. However, periodically, OS tries to detect the circular wait condition; and will try to recover the system, if such a circular wait is spotted. Essentially, it proceeds by marking processes that are not deadlocked. 26

27 A detection algorithm Initially, all processes are not marked. 1. Mark each process that has a row in the Allocation matrix containing all zeros. This process has got nothing, thus holding nothing for other processes. 2. Initialize a vector W, equal to the available vector. 3. Find an index i such that process i is currently unmarked and the i th row of the Current need matrix is no more than W. If no such i is found, terminate the algorithm. (Everyone wants more than what s available...) 4. Otherwise, mark process i and add the corresponding row of the allocation matrix to W. (Assume P i gets it, runs through and returns everything.) Return to step 3. A deadlock exists if and only if there are unmarked processes at the end of the algorithm. 27

28 What is going on? The algorithm essentially looks for a process whose requests can all be satisfied, and then assume that the resources are granted to such a process, which runs to its completion, and then releases all the resources. It then looks for another such process. For example, given a situation represented by the following resource vector: R 1 R 2 R 3 R 4 R and the available vector: R 1 R 2 R 3 R 4 R , 28

29 together with the following current need matrix: R 1 R 2 R 3 R 4 R 5 P P P P , and the following allocation matrix: R 1 R 2 R 3 R 4 R 5 P P P P We mark P 4 first, and set W to (0,0,0,0,1). Since the need by P 3 can be met with the currently available resources, P 3 is marked and W is reset to W + (0,0,0,1,0) = (0,0,0,1,1,). At this point, no other processes can be marked, indicating that P 1 and P 2 are deadlocked: P1, with R 3, wants R 2, and P 2 does the opposite. 29

30 Deadlock recovery Once deadlock is detected, we need to recover the system by following one of several approaches. 1. Abort all the deadlocked processes, both P 1 and P 2 in this case. This is one of the most frequently followed approach. 2. Back up each deadlocked process to its previously recorded state, and restart all processes. This requires some restart and rollback mechanism(remember our DB stuff?), and deadlock may occur again. 3. Successively abort deadlocked processes until deadlock no longer exists. The order for the abortion is certainly an issue. (P 1, P 2 ), or (P 2, P 1 )? Also, after each abortion, the above detection algorithm has to be applied again. 4. Successively preempt resources until deadlock no longer exists. Again, order is an issue. 30

31 An integrated strategy Obviously, any of the afore-discussed strategies has its strength and weakness. Rather than using just one, it might make more sense to use a combination of them to deal with different situation. One approach could be grouping resources into a number of different classes; use the linear order to prevent circular wait; and within each class, use the most appropriate algorithm for that class. Homework: Self-study 6.6 on the philosopher problem, another classic one, and discuss in detail how the first solution leads to a deadlock, while the second prevents it from happening. 31