Boost logo

Boost :

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
> not to be able to create new files at egroups! I can create a
> 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
> a temporary work around, I have uploaded the files to
> <>

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at