-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Chris Thomasson Sent: Thursday, November 16, 2006 7:18 PM To: boost@lists.boost.org 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

OK...so I've been looking at this, and I'm having a bit of trouble reading it. Am I right in saying that ptr_base<> is your refcounted pointer, yes? What I'm trying to go for is to see how close to the shared_ptr<> public interface I can get for an atomic refcounted pointer. I'll shortly post a working prototype wrapper for shared_ptr<> that uses a spinlock, as a demonstration of the interface that I'm looking for. Looking more closely at your ptr_base<> template (sorry I didn't get to it before...I've had a bit of time the last couple of days), I would like to discuss further with you how close in interface to shared_ptr<> one could come with the techniques you describe. Is the stuff (vzoom, refcount, appcore) you are working on public, or is this part of a proprietary thing? Thanks for pointing me to your code, it's been helpful in trying to understand this stuff. -- George T. Talbot <gtalbot@locuspharma.com> 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