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