From: Michael Ost (most_at_[hidden])
Date: 2003-05-22 13:25:58
Forgive me if I am jumping in inappropriately but if this is of
interest... I recently started using shared_ptr to solve a problem in my
app, and found that I needed to set BOOST_DISABLE_THREADS
since I don't need the thread safety built in to shared_ptr. The app
handles that itself.
But this sledgehammer approach means I can't use the boost thread
classes in the same app, which I was considering doing.
I wouldn't mind another BOOST_xxx precompiler setting to determine
thread usage in shared_ptr, since the designers appear uninterested in
the parameterization solution.
On Thu, 2003-05-22 at 10:41, Alexander Terekhov wrote:
> <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 (<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.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk