Re: Threads: Barrier Synchronization

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-03-07 16:28:49

--- In boost_at_y..., "dmoore99atwork" <dmoore_at_a...> wrote:
> Hi,
> 
> I wanted to run something by you - after posting this library, I 
got 
> a couple of private emails from a "semaphore zealot" and 
a "spinlock 
> zealot" who seemed to view my posting as an opening salvo in some 
> kind of thread revolt.  It was really quite humorous.
> 
> Anyways, I've been reading/lurking on the threads library for quite 
a 
> while, and it seems that your focus is on getting the core right, 
and 
> in getting the core of the threads library submitted for 
> standardization.  Cancellation issues, etc. seem to dominate there.
> 
> I've started using boost::mutex and boost::condition in real code, 
> and I'm interested in fleshing out the higher-level constructs like 
> barrier, rw_mutex, etc.

There are some higher-level constructs that are planned for inclusion 
in Boost.Threads.  They include the barrier, rw_mutex and 
thread_pool.  They don't exist right now simply because of time 
constraints and other priorities.  If you want to tackle designing 
and implementing (and remember that designing is more important to 
me) any of these concepts while I'm busy with the other things 
(updating the documentation, fleshing out cancellation and thread 
attributes are the three current top priorities) I'd be happy for the 
assist.

If there are other higher-level concepts you're interested in I'd 
like to hear what they are.  They may not be within what I consider 
the proper scope, but in that case they may well be candidates for 
some external submission.  For instance, a thread safe "reactor" (aka 
the Reactor Pattern) is too high level and would only cloud the focus 
of the effort of standardizing a threading library, but it would be a 
concept that would likely be of interest to others.

> Are you comfortable with this occurring in parallel with your 
> standards-oriented work in the core?  The two activities seem 
fairly 
> othrogonal to me, and any construct like a thread-safe message 
queue 
> which isn't fundamental enough to be in the standard could at least 
> be added to a set of nice examples of using boost::threads...

A message queue is fundementally a realization of the Reactor 
Pattern... though maybe not the realization I'd prefer.  This 
particular concept, as I just said, would only cause Boost.Threads to 
lose focus.  But it would likely be an addition to Boost that many 
would like to see.  So, if you want to undertake that particular 
concept I'd suggest proposing it as a seperate Boost library.
 
> But, if you think this would be a distraction to working through 
the 
> tough cancellation point type issues, let me know and I'll keep 
this 
> stuff to myself until you launch the Boost::Threads list...

I think it would be beneficial for everyone for higher level concepts 
to be explored.  Just understand the focus of Boost.Threads and why 
many (most) such concepts are likely to be better as seperate 
libraries.

Bill Kempf