Re: Threads: what I wrote...

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-08 14:36:12

--- In boost_at_[hidden], Dietmar Kuehl <dietmar_kuehl_at_y...> wrote:
> Hi,
> --- William Kempf <sirwillard_at_m...> schrieb: > --- In
> boost_at_[hidden], Dietmar Kuehl <dietmar_kuehl_at_y...> wrote:
> >  We've been
> > striving for some way to do this for years, and no one's yet 
found 
> > the answer here.  Several attempts have been made using smart 
> > pointers and proxy objects similar to your suggestion in your 
vector 
> > example.  None of them work consistently or completely.  They are 
> > useful techniques that can be applied to certain corner cases, 
but 
> > they simply are not suitable as a general purpose solution as is 
> > needed for library code.  I'd be very interested in any attempts 
to 
> > finally find a full solution to this problem, but quite frankly, 
> > Boost is very unlikely to be the source of any such solution.
> 
> I still think that it should be left there as a potential goal:
> Collecting ideas how to reach a high goal might eventually lead to
> really reaching it or at least help with other ideas. However, it
> should not be our primary objective...

*THIS* I fully agree with, and is what I've been saying all along ;).
 
> > This is why I wanted to start lower.  With a common solution for 
the 
> > low level idioms that takes into account C++ features we'd have a 
> > place to start from in our pursuit of a higher level 
abstraction.  
> 
> Yes, fully agreed. I will try to rewrite this stuff, probably 
splitting
> the stuff out into a separate document. However, I would really 
like to
> here about the "low level idioms" you mention: Those I described are
> just the ideas I had (well, I heard about the partial ordering stuff
> before). There are probably more idioms and I would want to collect 
a
> more less complete set of idioms before going into the details of 
the
> interfaces supporting these idioms. Without knowledge how interfaces
> are going to be used they become either too fat or are incomplete,
> probably even both!

The currently known and used low level idioms that I'm aware of are 
those I've already listed.  Mutexes (muti?  could someone really tell 
me what the plural form is?), conditions and semaphores.  There's a 
LOT to be discussed about each of these, even though the concepts 
themselves are simple.  Just starting with the mutex I see the 
following needing discussion: recursion issues, thread ownership 
issues (can any thread unlock a locked mutex, or only the thread that 
locked it?), inclusion/exclusion of try_lock and timed_lock methods, 
process shared creation, results from copying and even if copying 
should be allowed.  I'm sure that others will have other areas of 
discussion here.  What may be needed is several forms of mutexes, or 
a mutex that has varying semantics depending on creation parameters. 

> > The current "common" interfaces such as pthreads (I also dislike 
the 
> > fact that you put such emphasis on this library in the paper, but 
> > that's my own bias) all suffer from the fact that they are C 
based 
> > interfaces.  They don't fit well with classes, objects and 
generic 
> > coding practices.  They aren't typesafe.  In general, we spend 
more 
> > time with these interfaces working around little problems such as 
> > these then we do in actually working for a better abstraction.  I 
> > *really* think that it makes sense to define such primitives as 
> > common interfaces before moving on to an attempt to "cure cancer".
> 
> I don't want to use pthread like interfaces! What I want is that 
these
> interfaces can be implemented using pthreads internally. The 
emphasis
> on pthreads here is simply because pthreads is the only standard
> threads library I'm aware of. There are various other threads 
libraries
> on different systems but these are not agreed upon by any standards
> body, AFAIK. If there are others I would consider it as important 
that
> they can be used to implement the Boost facilities as I do for
> pthreads.

I understand this.  However, pthreads have a very rocky interface 
that can result in possible problems here.  For instance, not all 
pthread implementations are required to allow for mutexes to be 
creatable as process shareable.  A pthread implementation on Win32 
can't have this attribute (well, maybe it can, but the only 
implementation I'm aware of does not allow them and I'm not sure how 
you would be able to given the interface requirements), while process 
shared mutexes on Win32 are trivial using the native API.  Though we 
probably need to be able to implement these things over the pthread 
API there are very good reasons why we should de-emphasise this up 
front.
 
> The only implication made is that whatever interface we choose for
> Boost, it should implementable using what is found in pthreads. The
> interface do not at all resemble pthreads in any way, though. For
> example, my guess on a mutex interface would look like this:
> 
>   mutex lock;
>   // ...
>   mutex::do_lock obj(lock);
> 
> where 'mutex' is some form of mutex and 'mutex::do_lock' an object
> suitable to obtain/release a lock of a 'mutex'. I would expect 
several
> flavours of different mutex classes which share, however, the basic
> approach how they are used: see above. The type choosen would 
determine
> certain properties like recursive/not recursive, support for
> non-blocking lock attempts (which would, however, use a different
> approach to the attempt eg. an extra argument).
> 
> Of course, other thread packages should be usable to implement the
> Boost interface, too. However, pthreads clearly sets a showstopper 
if
> the interface is to be integrated with the C++ standard: If it 
cannot
> be integrated with pthreads, I don't think that it would pass
> standardization, potentially they are even procedural burdance
> preventing something conflicting with another standard from
> standardization.

It's possible to implement some parts of a portable library with no 
reference at all to any pthread code.  It's important that we de-
emphasise pthreads here to insure that we don't restrict ourselves to 
only functionality/implementations available within pthreads.  We 
need to be portable, which means that we'll likely need to be 
compatible with pthreads, but we don't need to be forced to carry 
around the "baggage" that is the pthread library.  (I hope that 
statement makes sense and doesn't lead to confusion.)
 
William Kempf