From: dmoore99atwork (dmoore_at_[hidden])
Date: 2002-03-12 10:56:16
--- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> Programming with POSIX Threads by David R. Butenhof actually has an
> implementation of a thread_pool concept. A thread pool differs
from the thread group a lot. The thread group is nothing but a
> specialized container used to help manage multiple threads. A
thread pool, on the other hand, fully controls the lifetime of
several threads and handles dispatching "jobs" to any of these
threads that are idle.
Thanks for the pointer.
> > > If there are other higher-level concepts you're interested in
> > > like to hear what they are.
> > Ideas I would add to the list of "core" concepts:
> > B. FIFO, or LIFO, or priority based mutexes (or other
> This one I'd need more convincing of. Can you provide detailed
> rationale and prior art for this?
I was just trying to synthesize some requests I'd seen on the list
and some ideas I'd received via email...
I've also seen them referred to as "strong" mutexes on the list.
What I guess I really meant was do you see a place for an
implementation of Mutexes meeting your "FIFO" and "Priority Driven"
Scheduling Policies (mutex_concepts.html) within Boost.Threads?
Is it possible to standardize the definition of a FIFO Scheduling
policy, and allow library implementors to implement it *if possible*
for a particular platform?
> > C. A safe realization of semaphores may also have a place here?
> Possibly, but I'm not about to try and tackle that one on my own
> given the time constraints and goals I currently have.
It certainly sparked a lively discussion during the initial
Boost.Threads review process!
-- Back to the subject of Other Primitives in general:
Can two lines be drawn through an ordered list of features like so:
Combinations of IO (sockets?) and threading
"Reactor" like event dispatching
Thread-safe Message Queues
Strong Locking Primitives
Everything above line A would be higher level library(ies)
implemented in terms of Boost.Threads. Users could be comforable
that these libraries themselves are cross-platform and built on a
Stuff between lines A and B seem to be "Core Concepts" which could
make it into Boost.Threads, but there seems to be a time issue with
making certain standardization deadlines.
Below line B is of course the current Boost.Threads library...
The only three things that I think are missing from the picture going
1. As the library founder, where would you place these lines?
2. As ideas come up on the list which belong above lines A or B, it
would be great to track them, along with citations/references, so
that they aren't lost. Perhaps a Boost.Threads area on the Wiki
3. What are the ramifications for things between A&B if they don't
make the deadline for submission? Would these concepts remain in
limbo, or would they effectively be bumped up above line A until the
next iteration of the standards process for a C++ threading library?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk