An Operating Systems Vade Mecum

Deadlock and starvation 125first place, as a less liberal policy might:1 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, applying some clever policy.5 A requests another tape drive.6 The resource manager grants tape drive 2 to A.7 A returns tape drive 1.8 The resource manager grants tape drive 1 to B.9 B requests one tape drive.10 The resource manager blocks B, since no drives are available.11 A returns tape drive 2.12 The resource manager grants tape drive 2 to B.13 B returns tape drive 2.14 B returns tape drive 1.Figure 4.2 shows the resource graph at three points in this scenario. After line 6, B iswaiting for either tape drive, so we have shown two arrows from B. However, there is nocycle in the graph. At the end, both A and B can successfully terminate.Deadlock can exist among more than two processes. For example, we couldaccidentally get into the following state:Process Has WantsA tape printer B printer plotter C plotter tape This situation is shown in the resource graph of Figure 4.3. The essence of a deadlock isthe existence of a cycle of processes, each of which is waiting for something held by thenext process in the cycle. Our first example had a cycle of two processes. This secondexample has three.Deadlock is an obvious problem when it happens; all the processes in the deadlockstop making any progress, even though other processes might continue unaffected. Theway to prevent deadlock is for the resource manager sometimes to deny a resource whenAAAtape 1 tape 2tape 1 tape 2tape 1tape 2BBBafter line 6 after line 10 after line 12Figure 4.2 Avoiding deadlock