DEADLOCKS

Both processes are blocked and will remain so forever. This situation is called a deadlock.

6.1 RESOURCES 

6.1.1 Preemptable and Nonpreemptable Resources 

            Resources come in two types: preemptable and nonpreemptable. A preempt-able resource is one that can be taken away from the process owning it with no ill effects. Memory is an example of a preemptable resource.

             A nonpreemptable resource, in contrast, is one that cannot be taken away from its current owner without causing the computation to fail.

             In general, deadlocks involve nonpreemptable resources.

            The sequence of events required to use a resource is given below in an abstract form.

1. Request the resource.
2. Use the resource.
3. Release the resource.

            If the resource is not available when it is requested, the requesting process is forced to wait. In some operating systems, the process is automatically blocked when a resource request fails, and awakened when it becomes available.

            Now let us consider a situation with two processes, A and B, and two re-sources. Two scenarios are depicted in Fig. 6-2. In Fig. 6-2(a), both processes ask for the resources in the same order. In Fig. 6-2(b), they ask for them in a dif-ferent order. This difference may seem minor, but it is not.

            In Fig. 6-2(a), one of the processes will acquire the first resource before the other one. That process will then successfully acquire the second resource and do its work. If the other process attempts to acquire resource 1 before it has been re-leased, the other process will simply block until it becomes available.

             In Fig. 6-2(b), the situation is different. It might happen that one of the proc-esses acquires both resources and effectively blocks out the other process until it is done. However, it might also happen that process  A acquires resource 1 and process B acquires resource 2. Each one will now block when trying to acquire the other one. Neither process will ever run again. This situation is a deadlock.
                                                                                    

6.2 INTRODUCTION TO DEADLOCKS

Deadlock can be defined formally as follows:

              A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause. 

             None of the processes can run, none of them can release any resources, and none of them can be awakened. The number of processes and the number and kind of resources possessed and requested are unimportant. This result holds for any kind of resource, including both hardware and software. This
kind of deadlock is called a resource deadlock.

6.2.1 Conditions for Resource Deadlocks 

          Coffman et al. (1971) showed that four conditions must hold for there to be a (resource) deadlock:

1. Mutual exclusion condition. Each resource is either currently assign-ed to exactly one process or is available.

2. Hold and wait condition. Processes currently holding resources that were granted earlier can request new resources.

3. No preemption condition. Resources previously granted cannot be forcibly taken away from a process. They must be explicitly releas-ed by the process holding them.

4. Circular wait condition. There must be a circular chain of two or more processes, each of which is waiting for a resource held by the next member of the chain.

              All four of these conditions must be present for a resource deadlock to occur. If one of them is absent, no resource deadlock is possible. It is worth noting that each condition relates to a policy that a system can have or not have. Can a given resource be assigned to more than one process at once? Can a process hold a resource and ask for another?

Can resources be preempted? Can circular waits exist?

6.2.2 Deadlock Modeling

              A directed arc from a resource node (square) to a process node (circle) means that the resource has previously been requested by, granted to, and is currently held by that process. In Fig. 6-3(a), resource R is cur-rently assigned to process A.

             A directed arc from a process to a resource means that the process is currently blocked waiting for that resource.

                   In general, four strategies are used for dealing with deadlocks.

1. Just ignore the problem. Maybe if you ignore it, it will ignore you.
2. Detection and recovery. Let deadlocks occur, detect them, and take action.
3. Dynamic avoidance by careful resource allocation.
4. Prevention, by structurally negating one of the four required conditions.

          

6.4 DEADLOCK DETECTION AND RECOVERY

           A second technique is detection and recovery. When this technique is used, the system does not attempt to prevent deadlocks from occurring. Instead, it lets them occur, tries to detect when this happens, and then takes some action to recover after the fact.

6.4.1 Deadlock Detection with One Resource of Each Type

              As an example of a more complex system than the ones we have looked at so far, consider a system with seven processes, A though  G, and six resources, R through W. The state of which resources are currently owned and which ones are currently being requested is as follows:

1. Process A holds R and wants S.
2. Process B holds nothing but wants T.
3. Process C holds nothing but wants S.
4. Process D holds U and wants S and T.
5. Process E holds T and wants V.
6. Process F holds W and wants S.
7. Process G holds V and wants U.

              It uses one dynamic data structure, L, a list of nodes, as well as the list of arcs. During the al-gorithm, arcs will be marked to indicate that they have already been inspected, to prevent repeated inspections. 

The algorithm operates by carrying out the following steps as specified:

1. For each node, N in the graph, perform the following five steps withN as the starting node. 

2. Initialize L to the empty list, and designate all the arcs as unmarked.

3. Add the current node to the end of L and check to see if the nodenow appears in L two times. If it does, the graph contains a cycle(listed in L) and the algorithm terminates.

4. From the given node, see if there are any unmarked outgoing arcs. Ifso, go to step 5; if not, go to step

5. Pick an unmarked outgoing arc at random and mark it. Then followit to the new current node and go to step 3.

6. If this node is the initial node, the graph does not contain any cyclesand the algorithm terminates. Otherwise, we have now reached adead end. Remove it and go back to the previous node, that is, the
one that was current just before this one, make that one the currentnode, and go to step 3.

6.4.2 Deadlock Detection with Multiple Resources of Each Type 

             E is the existing resource vector. It gives the total number of instances of each resource in existence.

Let A be the available resource vector .Now we need two arrays, C, the current allocation matrix, and  R, the

request matrix.

            if we add up all the instances of the resource j that have been allo-cated and to this add all the instances that are available, the result is the number of instances of that resource class that exist.

6.4.3 Recovery from Deadlock

Recovery through Preemption
         差点儿不现实....算了吧。。

。

Recovery through Rollback

       If the system designers and machine operators know that deadlocks are likely, they can arrange to have processes checkpointed periodically. Checkpointing a process means that its state is written to a file so that it can be restarted later.

       To be most effective, new checkpoints should not overwrite old ones but should be written to new files, so as the process executes, a whole sequence accumulates. When a deadlock is detected, it is easy to see which resources are needed. To do the recovery, a process that owns a needed resource is rolled back to a point in
time before it acquired that resource by starting one of its earlier checkpoints.

Recovery through Killing Processes

                   The crudest, but simplest way to break a deadlock is to kill one or more processes.

                   Where possible, it is best to kill a process that can be rerun from the beginning with no ill effects.

                  On the other hand, a process that updates a database cannot always be run a second time safely. If the process adds 1 to some field of a table in the database, running it once, killing it, and then running it again will add 2 to the field, which is incorrect.

6.5 DEADLOCK AVOIDANCE 

                     Thus the question arises: Is there an algorithm that can always avoid deadlock by making the right choice all the time?

The answer is a qualified yes—we can avoid deadlocks, but only if certain information is avail-able in advance.

详细内容。

。。看书吧，blog旨在“恢复记忆”，勾勒出整章的知识框架和个人认为比較重要的地方...

衡山的日出，秒速五厘米的赶脚啊。。

。美到没盆友。。。