From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-05-22 12:41:07
-------- Original Message --------
Date: Thu, 22 May 2003 19:37:13 +0200
From: Alexander Terekhov <terekhov_at_[hidden]>
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:
(A Proposal to Add General Purpose Smart Pointers to...)
The count structure C has the following members:
Virtual table pointer (C is polymorphic);
Mutex (for multithreaded builds);
Original pointer passed to the constructor;
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
> 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*:
pthread_refcount_t stuff (<http://tinyurl.com/cewa>)
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk