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

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

"David Maisonave" <dmaisonave_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:<ufyn5wggo.fsf_at_[hidden]>...
>> "David Maisonave" <dmaisonave_at_[hidden]> writes:

<snip loads of quoted text>

Please don't overquote.

>> IIUC, the thread-safety problem with reference-linked implementation 
>> isn't that so much that it's hard to achieve -- anyone can use a 
>> shared mutex -- it's that it's hard to make a thread-safe 
>> implementation efficient.  That is to say, you pay for the cost of 
>> locking and unlocking a mutex, and there's no way around it (**).  
>> Locking and unlocking mutexes is way more expensive than performing 
>> the lock-free operations used by boost::shared_ptr.
>
> That's true.  But it's been my experience that the majority of
> development don't have objects access via multiplethreads or don't run
> in a multithread environment.
> In this environment, you're paying additional price for using
> boost::shared_ptr reference-count logic, but not getting any benefits
> from it.

Not if you're compiling without mt support on; the thread safety
features of shared_ptr just compile away (and I think there's a macro
you can use to force them off).  Let's compare apples to apples: your
reflinked implementation will be slower in a MT environment.  I'm not
yet convinced it will be faster in a ST environment unless you leave
the MT features of shared_ptr turned on.

> With a policy base smart pointer, you can pick and choose what's
> best for paticular requirement, instead of being stuck with a one
> less than optimal method.

Yeah, yeah, old story.  I think almost everyone believes that there
will be times when its necessary to have a special-purpose optimized
smart pointer.  But now you're mixing up the issues.  We were talking
about the efficiency of your implementation w.r.t. threading.  You
can't sidestep that issue by saying "it's more flexible."

>> >> 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.
>> 
>> Oh, I had no idea you were using the allocator for your 
>> reference-linked smart pointers.  I see no mention of that macro in 
>> your header.  Where do you use it?
>
> Please check out the test code.

I don't have time to grok your code right now.  Can't you just answer
my question?

> If you're testing code within the same translation unit, and you declare
> BOOST_SP_USE_QUICK_ALLOCATOR at the top of the translation unit, then
> it's going to effect all the code in that translation unit.

Since when?

> I don't use BOOST_SP_USE_QUICK_ALLOCATOR in my smart_ptr, any more than
> boost::shared_ptr uses it in it's header.

shared_ptr does use BOOST_SP_USE_QUICK_ALLOCATOR in its header, by including
boost/detail/sp_counted_impl.hpp, which contains these lines:

  #if defined(BOOST_SP_USE_QUICK_ALLOCATOR)
  #include <boost/detail/quick_allocator.hpp>
  #endif
  .
  .
  .
  #if defined(BOOST_SP_USE_QUICK_ALLOCATOR)

      void * operator new( std::size_t )
      {
          return quick_allocator<this_type>::alloc();
      }

      void operator delete( void * p )
      {
          quick_allocator<this_type>::dealloc( p );
      }

  #endif

the quick allocator doesn't just get used by virtue of being
#included.  You have to overload operator new if you want new and
delete to use it for a particular type.

> Not only would it be more difficult for me to compile the code so as to
> only use BOOST_SP_USE_QUICK_ALLOCATOR for boost::shared_ptr, but it also
> wouldn't make much sence just to give boost::shared_ptr that advantage,
> and not do so for the other smart pointers when trying to make a level
> comparison test.

I'm not suggesting you do that.  I'm telling you that when you define
BOOST_SP_USE_QUICK_ALLOCATOR, the pointee of a shared_ptr is still
allocated (in the normal case) using the builtin operator new.  It
sounds like you're claiming that in your tests, when
BOOST_SP_USE_QUICK_ALLOCATOR is #defined, the pointees of your smart
pointers are allocated using the quick allocator.  If that's the case,
and if you haven't also done something to cause the pointees of
shared_ptr to use the quick allocator, you don't have a level test.

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