An Operating Systems Vade Mecum

142 Resource Deadlock Chapter 4We might allow other small requests to be satisfied meanwhile, in the hope that theprocesses we favor in this way will eventually release enough resources to satisfy thefirst-blocked process. More precisely, we might sort the resource-wait list by the order inwhich processes block. When resources are freed, we scan this list and grant resourcesonly to processes whose current request can be fully satisfied. Unfortunately, this first-fitpolicy will starve the first-blocked process if there is a continuous stream of new jobswith smaller requirements.One way to modify this strategy is to allow partial allocation. As many units of theresource are granted to the first process in the list as may be done safely; the rest may beapplied (if safe) to later processes in the list. Even this policy fails, because there aresituations in which no resources may safely be granted to the first blocked process, eventhough others may continue.Another modification is to order the resource-wait list according to some safesequence. (If there are several safe sequences, any one will do.) Resources are granted,either partially or fully, starting at the head of this list. However, there is no way toguarantee that any particular process will ever reach the start of this list. A process mayremain near the end of the safe sequence and never be allocated resources.The starvation detection approach is modeled after deadlock detection. By thetime deadlock is detected, it is too late, but it is never too late to fix starvation. Starvationmight be signaled by a process remaining on the resource-wait list for too long, measuredin either time units or units of process completions.Once starvation has been detected, new processes may be denied resources untilstarving processes have completed. Of course, processes that already have resourcesmust be allowed to get more, since they may appear earlier on the safe sequence. Thisapproach is certain to work, but it must be tuned carefully. If starvation detection is toosensitive, new processes are banned too often, with the result that there is an overalldecrease in throughput. In other words, the policy is too conservative. If detection is notsensitive enough, however, processes can starve for a long time before they are finallyallowed to run.Luckily, starvation is seldom a problem in actual operating systems, because nonpreemptable,serially reusable resources such as printers and tape drives tend to beunderused, and the existence of idle periods tends to prevent starvation.10 PERSPECTIVEDeadlock arises from dynamic resource sharing. If resources are not shared, there cannever be a deadlock. Deadlocks are especially dangerous in time-critical work. If theoperating system is used to run programs that control factory processes or pilot aircraft,deadlock is unacceptable.The danger of deadlocks is mitigated by several considerations. First, deadlockscan often be avoided by proper design of the algorithms that share resources. For example,different parts of the kernel may share information, like process context blocks.Those parts will want exclusive access during the time they modify that information;such access is like holding a resource. A hierarchical design inside the kernel is often