I advocated a while back that monitors should be simplified.  But  
#enter, #leave, and #critical: is too simple: some sort of condition  
variable is frequently necessary.  The typical situation is that a  
processes, while in the monitor, finds that a condition that must be  
true for it to do its work is false, e.g., some resource that it  
needs is unavailable.  So, it needs to atomically release the monitor  
lock and wait for the condition.

I advocated the Mesa "naked notify" semantics for condition  
variables, in which the notify operation is hint that the condition  
may have changed, rather than a guarantee that the condition is  
true.  This makes such signals easier to implement on  
multiprocessors, and makes it possible to connect condition variables  
directly to (virtual) hardware events, because there is no need to  
hold the monitor lock when signaling them.  With such conditions, we  
could get rid of the Semaphore class entirely, since all events could  
signal conditions in appropriate monitors.

I can envisage two condition variable classes that provide similar  
but different interfaces: a lightweight condition class, in which the  
boolean condition is specified by the programmer, but not checked by  
the implementation, and a heavyweight implementation in which the  
condition is both specified and checked, and in the case where a  
signal is received but the condition is still false, the process  
waits again.

Timeouts are in my opinion a mistake, because once the process is  
released on a timeout, one has no idea how to proceed.

I even started to implement this at some point.  I found that  
subclassing semaphore was impossible, because there is a check in the  
VM that causes the semaphore primitives to fail if the class of the  
receiver is not exactly Semaphore.  I have a special version of the  
VM that removes this check.  But I never found time to complete the  
implementation; it can be quite tricky to ensure that these things  
work ALL of the time, and not just most of the time!

Or maybe Andreas is asking about simple mutual exclusion and not  
monitors at all --- in which case, all one needs is a "Semaphore  
forMutualExclusion"

     Andrew

On 2005 Nov 02, at 23:49, Andreas Raab wrote:

> Hi Folks,
>
> I was looking for a simple monitor implementation (e.g., a  
> mechanism for mutual exclusion which allows the same process to  
> enter it multiple times) and looked at the implementation of  
> Monitor that is present in 3.9...
>
> What do other people think? Is there any reason for Monitor being  
> such a heavy-weight object by default? Is it necessary that a  
> monitor support all of the extra functionality besides the basic  
> "allow a process to enter it multiple times"?
>