Boost logo

Boost :

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:
(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;
 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*:


    "naked" count(s)


    pthread_refcount_t stuff (<>)


    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, gregod at, cpdaniel at, john at