From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-12-28 13:51:41
From: David Abrahams (root) <abrahams_at_[hidden]>
> scleary_at_[hidden] wrote:
> >
> > Giora Unger wrote:
> >
> > > 1. As far as I understand, the library is NOT thread safe.
> > > Am I wrong ?
> > > For example, let's examine line 169 in smart_ptr.h:
> > > if (--*pn == 0) { delete px; }
> > > I believe, that in case of two threads concurrently accessing
> > > this line (the reset() method), and an initial reference count==2,
> > > then a crash is possible: if both decrements occur before both
> > > comparisons, resulting in two deletion attempts.
> >
> > The smart pointers are just as thread-safe as integers.
>
> I don't think that's entirely correct. On many platforms, all integer
> operations are atomic; the same can't be said of our smart pointers.
And on many platforms they are not, so neither are safe.
> > To use them in a
> > thread-safe way, protect them just as you would any other non-thread-safe
> > fundamental type/class/library.
>
> Good advice.
But potentially too slow, as critical sections are more than
you need.
> > Should we look at doing a portable multi-threading library? I have the
> > beginnings of one, but it doesn't allow timed waits or waiting for multiple
> > objects -- would these be considered essential or optional?
>
> Oh, optional, optional (though highly desired)!
> Portable multi-threading is badly needed!
For shared_ptr all you need is atomic increment and atomic
decrement-and-test. For Win32 you can do these in assembly
or use the InterlockedIncrement and InterlockedDecrement
functions.
However, it may not be necessary to protect every operation
on shared_ptr. It may be that your multithreaded program
already establishes critical sections within which you can
do all your shared_ptr operations.