An Operating Systems Vade Mecum

Deadlock and starvation 12767854tapeprinter321process Btapeprocess AprinterFigure 4.4 Progress diagram1 A requests one tape drive.2 The resource manager grants tape drive 1 to A.3 B requests one tape drive.4 The resource manager blocks B, since A has a resource.5 A requests another tape drive.6 The resource manager grants tape drive 2 to A.7 A returns tape drive 1.8 A returns tape drive 2.9 The resource manager grants tape drive 1 to B.10 B requests one tape drive.11 The resource manager grants tape drive 2 to B.12 B returns tape drive 2.13 B returns tape drive 1.Serialization works because all waiting processes are waiting for the same running processto release resources. The running process never waits for resources, so there can beno cycle. We would like to avoid serialization when we can because reduced concurrencymeans reduced throughput. The process that has resources and is running mightbe blocked for a while in a transput-wait list. During that time no other processes wouldrun, because they are all in a resource-wait list.Even if deadlock is avoided, a more subtle problem remains. If a process isblocked even when resources are available, it might never be allowed to run again. Wecall this danger starvation. Starvation arises from consistently awarding resources to thecompetitors of a blocked process. As long as one competitor has the resources, theblocked process cannot continue. Increased conservatism is needed to prevent this problem.The spectrum from liberal to conservative is shown in Figure 4.5. Policies that aretoo liberal are subject to deadlock. Those that are too conservative reduce concurrency.