Re: Threads: Other Primitives

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 
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?

> 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 
by thread_pool?

> 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 
> the 
> > tough cancellation point type issues, let me know and I'll keep 
> this 
> > 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 
> libraries.

I agree completely that higher-level concepts belong in a different 
library.

Thanks!
Dave