Re: thread monitors

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-10-23 17:06:38

--- In boost_at_[hidden], Gregory Seidman <gseidman_at_a...> wrote:
> A friend of mine handed me the minutes of the 10/22 meeting because 
I had
> been telling him about having implemented monitors in C++ (trying 
to have
> the convenience of Java's synchronization primitives). I have 
attached my
> implementation to this message.

--- In boost_at_[hidden], Gregory Seidman <gseidman_at_a...> wrote:
> A friend of mine handed me the minutes of the 10/22 meeting because 
I had
> been telling him about having implemented monitors in C++ (trying 
to have
> the convenience of Java's synchronization primitives). I have 
attached my
> implementation to this message.

Thanks for the post Greg.  It may prove useful to us.  However, I 
think you misunderstood the minutes.  What you posted is not a 
monitor in the classic sense.  A classic monitor is a class whose 
methods are synchronized (by a mutex, presumably) and can temporarily 
relinquish the "lock" by waiting on a condition variable.  What you 
have is quite similar, but it requires programmer discipline.  The 
methods aren't synchronized automatically, instead you must 
explicitly synchronize them (through a macro that creates a "token" 
in your case).  This is what the minutes referred to as "a monitor 
pattern".  The current Boost threads concepts already support this 
form of a monitor.  In fact, if you look at the web documentation or 
at the Win32 implementation code you'll find the classic example of a 
monitor, the bounded buffer, implemented using our interfaces.  
Useage is as straightforward (maybe a tad more straight forward) as 
your code.

If you're really intersted in this area I'd really like to encourage 
you to look at what we have in Boost so far and give us your input 
from there.  You may also want to read the list archives, as the 
monitor concept has been discussed extensively here.  I think that we 
all agree that monitors are an important concept (though there are 
other concepts that may prove more important, such as channels).  I 
just think we've concluded that with out language support it is a 
concept relegated to a useage pattern, not a class type unto itself.

Bill Kempf