Re: Threads: what I wrote...

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-08 09:51:57

--- In boost_at_[hidden], Dietmar Kuehl <dietmar_kuehl_at_y...> wrote:
> Hi,
> 
> I was trying to update what I uploaded yesterday. Unfortunately, I 
seem
> not to be able to create new files at egroups! I can create a 
directory
> and rename directories, I can remove files (this is what I have 
done to
> upload the new version), but I can't create new files :-( At least 
as
> a temporary work around, I have uploaded the files to
> 
>   <http://www.dietmar-kuehl.de/threads/>

I've taken a look at this.  It's a very nice write up of the topic 
and a good starting point.  I see one thing I'd correct and then have 
a comment.

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.

As for my comment...  you state a lofty goal here, namely to achieve 
thread safety internally and implicitly within an object.  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.

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

William Kempf