Re: Threads: Other Primitives

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 
I'd 
> > > 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 
> primitives).  
> 
> 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
Strong/Safe Semaphores
-----Line A--------------------
Reader/Writer Locks?
Barriers?
Thread Pools?
MultiLocks???
-----Line B--------------------
boost::mutex
boost::condition
boost::thread
boost::thread_group
boost::scoped_lock
boost::thread_specific_ptr

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 
solid foundation.

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 
forward are:

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

Thanks,
Dave