If the thread scheduler is able to divine the types of non-CPU recourses required by a program, it could bias its program selection towards the programs that require under-used resources, or at least avoid selecting programs that require heavily used resources. The information about current resource load would come from the resource manager.
Most answers to this question were correct, but several answers resorted to special-purpose systems (real-time or embedded, usually), which wasn't necessary to answer the question.
try-take(), a conditional version of the
take() binary-semaphore operation. Rather than blocking when s is
false, s.try-take() returns false to indicate that s is unavailable;
when s is available, s.try-take() returns true to indicate the calling
process has seized s.
One motivation for implementing try-take() is to allow optimizations not
possible with take(). Give an example of such an optimization.
There are two main optimizations, one at application level and the other at
system level. At the application level, try-take() allows an application to
do other things while it waits for a semaphore to become available; the
penalty for such concurrency is increasing the chance that some other process
will grab the semaphore.
At the system level, checking to the semaphore for availability is a read-only
operation, and can be performed in a way that doesn't require entry into the
kernel (which is not to suggest it's an unprotected operation). Once
try-get() determines that the semaphore is available, it can then enter the
kernel and actually try for the semaphore.
Most answers described the process non-blocking optimization; none described the kernel optimization.
Each process has an possible maximum allocation of two tape drives. Under the Banker's Algorithm, the last available tape drive would be allocated to a process that already has one tape drive, ensuring process to at least that process.
Most of the answers for this question got the general idea, but botched the details. In particular, it's not necessary to make sure two tape drives are always in reserve as long as the algorithm allocates the last tape drive as described above.
It does not, because the CPU has to take responsibility for managing the devices, which represents an overhead that can be avoided by using DMA and interrupts.
Most answers to this question were correct.
This page last modified on 2 November 2003.