Buffering promotes resource sharing by decoupling data transfer between the requesting process and the resource. Shared resources don't require exclusive access and can't contribute to a deadlock condition.
The usual example of buffer-supported deadlock alleviation is the print spooler. Processes that directly access the printer must have exclusive access to the printer, otherwise the output becomes uselessly intertwined. However, if instead the processes sent their output to a buffer (a file in this case) that eventually made its way to the printer, then the competing processes wouldn't even need to request the printer, which eliminates the printer as a potential source of deadlock.
The scheduler does not use pre-emption. A polling device driver requires the CPU continually check the device to determine when it's done. Because the CPU's busy anyway, there's no reason to context switch the waiting process. An interrupt-driven device driver frees up the CPU to context switch to another process, which should increase the effective concurrency and improve throughput. Because there was no change in throughput, the scheduler must be non-pre-emptive, letting each job run to completion. (Of course, totally I-O bound jobs would exhibit almost the same behavior with a pre-emptive scheduler, but this question was about schedulers, not job mixes.)
put_msg() system call indicates that a process
should receive an error if it tries to put a message in a message pool
that's full; that is, a process doing a put_msg() never blocks.
Is it ever possible for a set of processes using only the message pool to
deadlock? Explain.
Of course. To simplify, imagine the message pool had room for one message. Let process P1 be looking for a message with tag 1 followed by a message with tag 2. Let process P2 be put a message with tag 2 in the pool, followed by a message with tag 1. P1 isn't looking for the message in the pool, so it will never be removed. P2 is waiting for the space in the message pool, which it will never see, even through P2 is not blocked in the usual sense. Deadlock ensues.
Should a process be allowed to request more of a resource Rj if it already holds some of Rj? Explain.
If a process already allocated some quantity of resource Ri, it should not be allowed to make further allocations of Ri; that is, if a process holds some of Rj, it cannot make allocations for Ri where i <= j. To allow re-allocations of the most recently allocated resource runs the risk of introducing cycles in the resource graph.
For example, suppose processes P1 and P2 each hold one unit of Rj, and there are a total of two units of Rj available. If both P1 and P2 request the other unit of Rj, they both block and deadlock ensues.
This page last modified on 5 November 2001.