[boost] Re: Smart Pointers - (many) thanks and (some) questions

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.