Re: [boost] Re: Threads: what I wrote...

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2000-08-08 11:50:33

Hi,
--- William Kempf <sirwillard_at_[hidden]> schrieb: > --- In
boost_at_[hidden], Dietmar Kuehl <dietmar_kuehl_at_y...> wrote:
> Your definition of a race condition leaves me wanting.  You mention 
> data repeatedly in the definition while a race condition is not 
> reliant upon data.  Any shared resource can lead to a race 
> condition.  For instance: a socket, a file, an IO stream, some 
> hardware device. All of these can be shared resources that will lead 
> to race conditions and none of them are data.  I think a better 
> definition is the one I posted previously:  "A software bug that is 
> dependent upon the order of completion of two or more independent 
> activities."  That's my correction.

I have changed this: I made basically your words into the definition
and turned my version into an [abstract] example. I got a list of
thread related definitions from the POSIX standard but I haven't
integrated them into the list of definitions for two reasons:

- I haven't come around to work on this.
- I don't know whether it is legal and/or OK to include them there.

If someone has better definitions, says that the POSIX definitions are
OK and should be included, etc. these can be included! I just put the
definitions there as a first cut. I'm not an expert in this area and
these definitions are not taken from somewhere but I have written them.
Experts in the area are likely to have better definitions but I wanted
to start out with something. This is by no means complete or something!
Actually everything can be changed: the definitions, the structure, the
goals, etc.

> As for my comment...  you state a lofty goal here, namely to achieve 
> thread safety internally and implicitly within an object.

Upon rereading I agree that it looks like I would favor this goal. In
fact, I don't! The somewhat lengthy discussion of this option gives a
wrong impression - I should move it into a separate document.

Actually, my primary goal is to support only the first option which is
labeled as "unlocked": A resource is only accessed by one thread at a
time. However, any resource used from within a resource is accessed in
a thread safe manner. This does not take any silver bullet and only
requires a minor restriction, namely that resources may not be mutually
dependant on each other.

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

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.

Thank you for your feedback. I will change the documents incorportating
your suggestions.

Dietmar

=====
<mailto:dietmar_kuehl_at_[hidden]>
<http://www.dietmar-kuehl.de/>

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/