[boost] Re: shared_ptr/weak_ptr and thread-safety

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-05-22 15:00:01

<Forward Inline>

Joseph Seigh wrote:
> 
> Alexander Terekhov wrote:
> >
> > Joseph Seigh wrote:
> > > Well, Detlefs calls it lock-free reference counting.  But Boost
> > > would probably call what they're doing with thread-safe reference
> > > counting lock-free also, and they are not the same.
> >
> > They don't call it "lock-free". Here's what they say:
> >
> > http://std.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1450.html
> > (A Proposal to Add General Purpose Smart Pointers to...)
> >
> > "....
> >  The count structure C has the following members:
> >
> >  Virtual table pointer (C is polymorphic);
> >  Use count;
> >  Weak count;
> >  Mutex (for multithreaded builds);
> >  Original pointer passed to the constructor;
> >  Deleter.
> >  ....
> >  The mutex presents another target for platform-specific
> >  optimizations. On Windows, we have been able to use a simple
> >  one-word spinlock instead of a 6 word CRITICAL_SECTION. The
> >  portable architecture of the implementation that abstracts
> >  the mutex concept in a separate class prevents further
> >  optimizations, like reusing the use count word as the
> >  spinlock, or using the Windows API InterlockedIncrement,
> >  InterlockedDecrement, and InterlockedCompareExchange
> >  primitives to attempt to eliminate the mutex altogether.
> >  Nevertheless, we believe that such optimizations are
> >  possible.
> >  ...."
> 
> The fact that they consider and have done simplistic spin locks
> speaks for itself.  

Yeah. http://lists.boost.org/MailArchives/boost/msg44460.php

>                     Also, they make a whole lot of distinctions
> that don't translate very well into a threaded environment.
> Their style of semantic definition with that pre and post internal
> data state stuff doesn't work in multi-threading. 

I think it's fine. Please see the definitions of shared_ptr and
weak_ptr thread "safeties" (below).
 
>                                                    The one thing
> you usually cannot reliably observe in multi-threading is internal data
> state.  You have to use other mechanisms to define semantics for
> multi-threading. 

I don't think so.
 
>                   To say nothing of their multiple attempts to
> deal with data "ownership".  It's why they have so many pointer
> types, all compromised in some degree or other for some small
> incremental benefit.

;-)

> 
> >
> > >                                                      The meaning
> > > of atomic w.r.t java pointers is or should be well understood, so
> > > atomic something would be indicated.  Also, it wouldn't preclude
> > > a non lock-free implementation, though you would lose the bemefits
> > > of lock-free.
> > >
> > > Maybe atomic_shared_ptr.
> >
> > Well, I'd love to have a policy-based framework that would
> > allow me to specify the *thread-safety policy*:
> >
> >   thread_safety::unsafe
> >
> >     "naked" count(s)
> >
> >   thread_safety::basic
> >
> >     pthread_refcount_t stuff (<http://tinyurl.com/cewa>)
> >
> >   thread_safety::strong
> >
> >     your "atomic" stuff
> >
> > or something like that. Note that for the blocking stuff, one
> > would REALLY want to have some support for priority protocols
> > (priority protection or priority inheritance) to fight the
> > "unbounded priority inversion" problem in the "realtime" apps.
> >
> 
> I'm never quite sure what "thread-safe" really means.  It seems
> to get used in different ways sometimes. 

thread_safety::unsafe means that *copying* AND all mutation 
operations on shared_ptr/weak_ptr copies (all pointing to the 
same object; "typed-null" including) shall be *synchronized*; 
otherwise, the behavior is undefined. Read-only stuff (copying
aside) can be done concurrently.

thread_safety::basic means that all "const" operations 
(including copying) can be done concurrently, but mutations 
shall be synchronized; otherwise, the behavior is undefined.

thread_safety::strong means "do-whatever-you-want-and-don't-
care-about-synchronization" (i.e. you can also mutate shared_ptr 
and weak_ptr objects *concurrently* without any synchronization
because it's fully synchronized "internally").
 
>                                          Atomic is easy to define.
> It just means that you will only ever read some previously stored
> value.

The C and C++ standards already mandate that! Here's what C99 
says, for example:

"The lifetime of an object is the portion of program execution 
 during which storage is guaranteed to be reserved for it. An 
 object exists, has a constant address, and retains its last-
 stored value throughout its lifetime."

regards,
alexander.