From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-03-12 10:20:36
--- In boost_at_y..., "dmoore99atwork" <dmoore_at_a...> wrote:
> --- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> > 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.
> >
>
> 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?
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.
> > 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).
A very good idea in general. I'm a little hesitant to add new
concepts to the "core" because I really need the core to be finalized
soon in order to invite criticism/comments from experts in the
field. However, this one may be possible within my narrow
constraints currently. Let me think about this one for a short while.
> B. FIFO, or LIFO, or priority based mutexes (or other
primitives).
This one I'd need more convincing of. Can you provide detailed
rationale and prior art for this?
> 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.
Bill Kempf