An Operating Systems Vade Mecum

124 Resource Deadlock Chapter 42 DEADLOCK AND STARVATIONAt first glance, resource allocation seems trivial. It seems that we don’t need any policyat all. If the resource is available, grant it; if not, block the process until the resource isreleased by whoever has it. This approach is the most liberal method imaginable.The problem with this approach is that it can get stuck. The simplest scenario thatfails has two processes, A and B. Both A and B will eventually want two tape drives,and the operating system has exactly two drives. However, since neither A nor B needsboth tape drives to start out with, they ask for the drives one at a time, even though theycould have asked for both at once. Here is the scenario that runs into trouble:A requests one tape drive.The resource manager grants tape drive 1 to A.B requests one tape drive.The resource manager grants tape drive 2 to B.A requests another tape drive.The resource manager blocks A, since no drives are available.B requests another tape drive.The resource manager blocks B, since no drives are available.Both A and B are stuck: Each is waiting for a resource that is held by the other. This sortof circular waiting is called deadlock. In Europe, it is known by the more striking name‘‘deadly embrace.’’Figure 4.1 is a resource graph that shows processes and resources. We draw anarrow from a process (like A) to a resource it is waiting for (like tape 2). Similarly, wedraw an arrow from a resource (like tape 2) to a process that currently is using it, if any(like B). We see that this resource graph has a cycle. In general, deadlock is a situationin which the resource graph has a cycle. (We will return to resource graphs later andgeneralize this principle.)The only way to break a deadlock is by preempting a resource, which, as we haveseen, can injure both the process and the resource. It is far better to avoid deadlock in theAtape 1 tape 2BFigure 4.1 A deadlocked resource graph