[boost] shared_ptr/weak_ptr and thread-safety

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-05-22 12:41:07

<Forward Inline>

-------- Original Message --------
Message-ID: <3ECD0AC9.69B39C93_at_[hidden]>
Date: Thu, 22 May 2003 19:37:13 +0200
From: Alexander Terekhov <terekhov_at_[hidden]>
Newsgroups: comp.programming.threads
Subject: shared_ptr/weak_ptr and thread-safety
References: ... <3ECD0007.14DC5665_at_[hidden]>

Joseph Seigh wrote:
> 
> Alexander Terekhov wrote:
> >
> > Okay. How about 'super_thread_safe_shared_ptr<>'? ;-)
> >
> > Seriously, "atomic_ptr" doesn't really convey what it is. You might
> > also want to consider making it either blocking [maximum portability;
> > but pretty much useless ;-)] or non-blocking (with "emphemeral" stuff
> > and/or whatever tricks). Oder?
> >
> 
> 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 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.

regards,
alexander.

--
http://terekhov.de/pthread_refcount_t/draft-edits.txt