Boost logo

Boost :

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.

Cheers... mo

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:
>
> 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
>
> _______________________________________________
> 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