Re: Threads: better condition variables?

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 
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.

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)
      cv.wait(mx);
}

void gate::open()
{
   mutex::lock lock(mx);
   is_open = true;
   cv.signal();
}

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.