Re: [boost] Proposal to add smart_ptr to the boost library

From: David Maisonave (dmaisonave_at_[hidden])
Date: 2006-01-30 13:58:01

"David Abrahams" <dave_at_[hidden]> wrote in message
news:<874q3ld907.fsf_at_[hidden]>...
> "David Maisonave" <boost_at_[hidden]> writes:
> 
> > "Daniel Wallin" <dalwan01_at_[hidden]> wrote in message 
> > news:<drkmls$kb5$1_at_[hidden]>...
> 
> >> It's in the FAQ:
> >> 
> >> http://www.boost.org/libs/smart_ptr/shared_ptr.htm#FAQ
> >> 
> >>   Q. Why doesn't shared_ptr use a linked list implementation?
> >> 
> >>   A. A linked list implementation does not offer enough advantages
to
> >>      offset the added cost of an extra pointer. See timings page.
In
> >>      addition, it is expensive to make a linked list implementation
> >>      thread safe.
> >
> >
> > You can avoid having to make the implementation thread safe by 
> > making the pointee thread safe.
> 
> One of us here understands nothing about the problem.  I don't know 
> that much about threading, but I think I have a grip on this issue at 
> least.  As I understand the problem, if two neighboring shared_ptr's 
> in a reference-linked chain are destroyed at the same time, they will 
> be modifying the same pointer values simultaneously -- without a lock 
> in your case.  I don't see how making the pointee threadsafe is going 
> to help one bit.

IMHO, you don't fully understand my propose solution.
Please look at the current smart pointer locking method:
http://code.axter.com/smart_ptr.h
By using intrusive lock logic, you can lock the pointee, and thereby
locking all the shared_ptr objects.
Here's the smart pointer destructor:
        inline ~smart_ptr() throw()
        {
                m_ownership_policy.destructor_lock_policy(m_type);
                CHECKING_POLICY::before_release(m_type);
                m_ownership_policy.release(m_type, m_clone_fct,
m_ownership_policy);
                CHECKING_POLICY::after_release(m_type);
        }

There's similar logic in constructor and assignment operator.
This should work on all three main types of reference policies, to
include reference-link.
Do you understand intrusive logic?  You need to fully understand how
intrusive logic works, in order to understand the method.

> > This can be done by using an intrusive lock.
> >
> > On my test, reference-link is over 25% faster than reference-count 
> > logic for initialization. With BOOST_SP_USE_QUICK_ALLOCATOR defined,

> > than reference-link is over 30% faster than reference-count logic 
> > for initialization. I get the above results using VC++ 7.1, and if I

> > use the GNU 3.x compiler, than the difference is even greater in 
> > favor of reference-link logic.
> > With the Borland compiler, the difference is about 22%
> 
> Are you claiming that using BOOST_SP_USE_QUICK_ALLOCATOR actually 
> slows boost::shared_ptr down on all these compilers?  

Of course not....
When you define BOOST_SP_USE_QUICK_ALLOCATOR, that does not just
increase the performance of boost objects.
It increases the performance for all object within the translation unit
that has the define, and that is using allocators.
So even though shared_ptr gets an increase performance boost, the
smart_ptr gets an even greater performance boost, which increases the
performance ratio.

If you have any thoughts, please feel free to inspect and perform the
same test using the following code:
http://code.axter.com/smart_ptr.h
http://code.axter.com/shape_test.h
http://code.axter.com/boost_ptr_containers/main.cpp
http://code.axter.com/cow_ptr.h
http://code.axter.com/copy_ptr.h

I welcome inspection and critiques of my work.