Monitors are useful as self-contained objects, such as resource allocators, to which only one thread at a time must be allowed access.
Before leaving a monitor, a thread must make sure the monitor data is in a "good" state--the state in which the next thread expects to find it.
If multiple threads are waiting on the condition when it arises, the thread that has been waiting the longest unblocks and is granted reentry into the monitor after the notifying thread has left the monitor. Alternatively, the thread that detects the condition can unblock all waiting threads using the monitor condition object's broadcast capability--this is occasionally useful for handling error conditions.
As a further protection against deadlock, a thread may specify a maximum time to wait for a condition to arise--if this period expires before the thread receives notification, the thread unblocks.
Monitor conditions
To help prevent deadlocks, a monitor can also contain a monitor condition, an object that represents an important monitor state. A resource allocator object, for example, could use a monitor condition to indicate whether the resource is currently available for allocation. A monitor condition object allows a thread that has entered the monitor to temporarily leave the monitor and wait for some necessary condition to arise before entering the monitor again. When another thread detects that the condition has been met, it can use the monitor condition object to notify the thread waiting on the condition, allowing it to reenter the monitor.
[Contents]
[Previous]
[Next]
Click the icon to mail questions or corrections about this material to Taligent personnel.