From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-03-07 16:28:49
--- In boost_at_y..., "dmoore99atwork" <dmoore_at_a...> wrote:
> I wanted to run something by you - after posting this library, I
> a couple of private emails from a "semaphore zealot" and
> 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
> while, and it seems that your focus is on getting the core right,
> 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
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
> othrogonal to me, and any construct like a thread-safe message
> 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
> tough cancellation point type issues, let me know and I'll keep
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk