"David Maisonave" <dmaisonave@commvault.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:<ufyn5wggo.fsf@boost-consulting.com>...
"David Maisonave" <dmaisonave@commvault.com> 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