Re: Threads: Other Primitives

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