Re: Threads: better condition variables?

From: scleary_at_[hidden]
Date: 2000-08-11 08:42:36

William Kempf, sirwillard_at_m... wrote:
> --- In boost_at_[hidden], jsiek_at_l... wrote:
> > scleary_at_j... writes:
> > > Right!  Condition variables can also be used on their own.
> > 
> > I'm not familiar with the usage scenario you're alluding to
> > here. Could you give an example?
> 
> To implement a gate.  If the gate is closed you wait on the 
> condition, but once the condition is signaled there isn't really a 
> reason to retest to see if the gate is opened.  This is just one 
> simple example.

Yes, this is what I was thinking of.  It's used as a "go" signal to multiple
threads, but only those threads that were already waiting.  (In this sense,
it's not what I call a "gate", since a "gate" can remain open -- CV's only
support a type of "atomic open and shut").  To be fair, I should also say
that I've been multithreaded programming for years, and have only used CV's
in this way once; the vast majority of cases, they are paired with mutexes
to create monitors.

> > I'm not sure I like the use of the word "monitor" in this sense. I've
> > always thought that a monitor is a class that automatically serializes
> > accesses to its member functions. I know that signal() and wait() were
> > discussed in Hoare's paper, but I thought he was using "condition
> > variable" for that part of the functionality.

I've always used "monitor" (overloaded word) as a synchronization primitive,
though I suppose that the proper definition would be a set of code blocks
that are critical sections (a set of functions in a class, if you will),
also allowing blocking within those critical sections.  Win32 does the same
thing -- "critical section" is the OS sync prim used to implement an actual
critical section.  I think it's always clear from the context which
definition is intended.

        -Steve