From: dmoore99atwork (dmoore_at_[hidden])
Date: 2002-03-10 17:55:26
--- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> There are some higher-level constructs that are planned for
> 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
Can you point me to a document describing exactly what you mean by
thread_pool? I know what I think of when I hear it, but in what
ways do you think it moves beyond the thread_group concept currently
in the library?
> If there are other higher-level concepts you're interested in I'd
> like to hear what they are.
Ideas I would add to the list of "core" concepts:
A. I would add to that list some sort of "multilock" which could
atomically lock several mutexes or other primitives in a safe manner
(i.e. avoiding deadlock by locking/releasing in a consistent order).
B. FIFO, or LIFO, or priority based mutexes (or other primitives).
C. A safe realization of semaphores may also have a place here?
> A message queue is fundementally a realization of the Reactor
> Pattern... though maybe not the realization I'd prefer.
That's a very thought provoking statement, at least for me. I think
of a message queue as one form of scaffolding that could be used in a
Reactor pattern. Maybe this ties into me missing what you're meaning
> particular concept, as I just said, would only cause Boost.Threads
> 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
> to be explored. Just understand the focus of Boost.Threads and why
> many (most) such concepts are likely to be better as seperate
I agree completely that higher-level concepts belong in a different
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk