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

From: David Abrahams (dave_at_[hidden])
Date: 2006-01-30 10:35:04

"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.

> 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?  Are you sure
there isn't something wrong with the way you're measuring?  If I had
just found the results you're claiming I would be scrutinizing my
methods very carefully.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com