Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at