Re: Threads: Other Primitives

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-03-12 12:22:01

--- In boost_at_y..., "dmoore99atwork" <dmoore_at_a...> wrote:
> --- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> > > > 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?

Currently, the scheduling policy is undefined, giving the most leeway 
to implementers/implementations.  This is an area that needs more 
focus, discussion, design rationale, etc.  However, it's mostly 
beyond my abilities to address alone, so the plan was to have 
discussion about such low-level concerns after we have the interface 
hammered out.  I thought that what you were suggesting was to have 
the scheduling policy be an "attribute" of the mutex classes, 
allowing the programmer to pick what policy he wants.  I'm not 
against this, either, but need more details/rationale on this, since 
it's something that goes beyond my experience with MT programming.

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

I don't know.  It's something to discuss, but not just yet ;).

In case some of the concerns and questions are being raised because 
people don't understand my goals/timeline, let me state it once 
again.  There are certain concepts that I believe to be "core" 
concepts necessary for a MT library.  These are, mostly, the same 
concepts that exist in most MT libraries today (thread pools are one 
that's borderline here, but are used so much that everyone's rolled 
their own at least once, and so I believe belong in the core).  I 
want to carefully design the interface for each of these core 
components and provide a portable implementation for them (even if 
they contain flaws) in order to have a base for discussion.  At that 
point I plan to invite experts or just interested parties to join in 
a mailing list dedicated to Boost.Threads.  The first order of 
business on this list will be to critic the interfaces.  The second 
will be to disect the implementations.  The third will be to insure 
we have standards quality specifications for the interfaces.  And 
finally we'll need to step back and look for concepts that were 
initially left out and determine if they should be included, keeping 
in mind that too much bloat can make standardization difficult.

I'm glad to hear suggestions now, but if something isn't "obviously" 
core to me, I'll likely just note it for evaluating at the end of the 
process I described above.  If I do this, please don't assume I have 
different visions or think the concepts "not worthy", I'm only trying 
to keep the focus very sharply defined in order to be able to 
accomplish such a large task.

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

Yes, it did, and the difficulties involved here are precisely why I 
can't tackle this one on my own given the timeline/goals.
 
> -- 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

I'm not sure there's enough of a distinction between these two to 
seperate them.

> Strong Locking Primitives
> Strong/Safe Semaphores
> -----Line A--------------------
> Reader/Writer Locks?
> Barriers?
> Thread Pools?
> MultiLocks???

Two things missing from this list that still need to be in the core 
and are planned:  cancellation and thread "attributes".

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

This would be very beneficial.
 
> 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.

There aren't really any standardization "deadlines", per se, only the 
schedule I have set in order to manage such a large task.
 
> 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?

Pretty much just where you placed them.

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

I've been tracking them in my own notes, but something public would 
be worth maintaining.  The Wiki may be the right answer, but I'm not 
familiar enough with it.  Do you care to volunteer to start something 
along these lines?

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

There's plenty of time to get everything done for standardization, 
AFAIK.  Regardless, I won't let these concepts get caught in "limbo".
 
Bill Kempf