Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at