Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-11 08:57:33

--- In boost_at_[hidden], scleary_at_j... wrote:
> 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
> > 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
> 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
> to create monitors.

The atomic gate requires no variable at all, only a CV. The gate
requires a variable and a CV, but the while loop construct is missing.

void gate::enter()
   mutex::lock lock(mx);
   if (!is_open)

void gate::open()
   mutex::lock lock(mx);
   is_open = true;

void gate::close()
   mutex::lock lock(mx);
   is_open = false;

Off the cuff, so I may have a race condition here, but you get the
idea. A full gate can be modeled using a CV and said model would not
require the usual while/wait construct normally required for "proper"
use of a CV. There are actually quite a few constructs that fit
within this "flood gate" paradigm. I've actually seen a similar
construct used to model Win32 Event primitives in pthreads.

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