Re: [boost] I think using spinlocks to simulate an atomicshared_ptr isdeadlock-prone, or inefficient.

From: Talbot, George (Gtalbot_at_[hidden])
Date: 2006-11-17 15:43:14

As a developer of an application using these techniques, shared_ptr<>
has a lot of advantages.  Can a class which has the same public
interface as shared_ptr<> be written using your methods?  Could
boost::shared_ptr<> itself be rewritten to use your methods resulting in
an atomic shared_ptr<>?

--
George T. Talbot
<gtalbot_at_[hidden]>
> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Chris Thomasson
> Sent: Thursday, November 16, 2006 7:18 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] I think using spinlocks to simulate an
> atomicshared_ptr isdeadlock-prone, or inefficient.
> 
> > I read the stuff from Chris Thommason and I have to admit that I'm
not
> > too sure how I'd wrap shared_ptr with it to make this work.
> 
> Here is an alternative to shared_ptr:
> 
> http://appcore.home.comcast.net/vzoom/refcount/
> 
> This is my version of an atomically thread-safe reference counting
that
> covers both basic and strong thread-safety models. Parts of it can
also be
> used in a signal handler, because it has 100% lock-free weak
> increments/decrements' and pointer swap operations. It amortizes lock
> actions from the first strong reference to an object X, down to the
> drop-to-zero condition of object X. What do you think?
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost