[sp_counted_base] Why does sp_counted_base.hpp not use atomic_count for gcc environments?
On sparc/gcc environment, boost/detail/sp_counted_base.hpp will use sp_counted_base_pt.hpp, which of course implements counter protection via pthread_mutex operations. Other gcc-environments (x86, x64, ia64, ppc) have the concept of using asm directives for atomic increment & decrement, which obviously is more efficient than the mutex operations. The boost/detail/atomic_count_gcc.hpp implementation seems like a more efficient mechanism for incrementing/decrementing the shared_ptr reference counters. In fact, the shared_ptr_nmt.hpp implementation does use boost::detail::atomic_count for the reference count (albeit directly, rather than through the shared_count template). I am using atomic_count as the basis for my internal reference counting for my intrusive_ptr-based objects and am happy with this. So I'm curious as to why sp_counted_base.hpp does not use the atomic increment/decrement model for sparc/gcc that it does for other gcc environments?
Jerry Lawson wrote:
On sparc/gcc environment, boost/detail/sp_counted_base.hpp will use sp_counted_base_pt.hpp, which of course implements counter protection via pthread_mutex operations. Other gcc-environments (x86, x64, ia64, ppc) have the concept of using asm directives for atomic increment & decrement, which obviously is more efficient than the mutex operations.
The boost/detail/atomic_count_gcc.hpp implementation seems like a more efficient mechanism for incrementing/decrementing the shared_ptr reference counters. In fact, the shared_ptr_nmt.hpp implementation does use boost::detail::atomic_count for the reference count (albeit directly, rather than through the shared_count template).
I am using atomic_count as the basis for my internal reference counting for my intrusive_ptr-based objects and am happy with this.
So I'm curious as to why sp_counted_base.hpp does not use the atomic increment/decrement model for sparc/gcc that it does for other gcc environments?
The primitives supplied by g++ were not enough to support sp_counted_base (although this is going to change in 4.2, I think). There is an assembly language version scheduled for 1.35 in the CVS. You can play with it by downloading http://boost.cvs.sourceforge.net/*checkout*/boost/boost/boost/detail/sp_coun... and applying the patch http://boost.cvs.sourceforge.net/boost/boost/boost/detail/sp_counted_base.hpp?r1=1.8&r2=1.9 There is currently a problem with 64-bit SPARCs in 32-bit mode, where the default architecture isn't v9 (g++ doesn't support the notion of v8+). We're looking into fixing that on the bjam side.
Thanks for the response. I will patch my boost with those files. Just for my education, however, I'd like to understand what was missing from the gcc primitives that you needed for the sp_counted_base required implementation? Furthermore, should it be okay for me to continue to use atomic_count_gcc.hpp's pre-increment and post-increment overloaded operators as the implementation for my specialization of intrusive_ptr_add_ref(T*) and intrusive_ptr_add_release(T*) free functions? Thanks.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: Thursday, January 11, 2007 11:50 AM To: boost@lists.boost.org Subject: Re: [boost] [sp_counted_base] Why does sp_counted_base.hpp notuseatomic_count for gcc environments?
On sparc/gcc environment, boost/detail/sp_counted_base.hpp will use sp_counted_base_pt.hpp, which of course implements counter
via pthread_mutex operations. Other gcc-environments (x86, x64, ia64, ppc) have the concept of using asm directives for atomic increment & decrement, which obviously is more efficient than the mutex operations.
The boost/detail/atomic_count_gcc.hpp implementation seems
efficient mechanism for incrementing/decrementing the shared_ptr reference counters. In fact, the shared_ptr_nmt.hpp implementation does use boost::detail::atomic_count for the reference count (albeit directly, rather than through the shared_count template).
I am using atomic_count as the basis for my internal reference counting for my intrusive_ptr-based objects and am happy with this.
So I'm curious as to why sp_counted_base.hpp does not use
Jerry Lawson wrote: protection like a more the atomic
increment/decrement model for sparc/gcc that it does for other gcc environments?
The primitives supplied by g++ were not enough to support sp_counted_base (although this is going to change in 4.2, I think). There is an assembly language version scheduled for 1.35 in the CVS. You can play with it by downloading
http://boost.cvs.sourceforge.net/*checkout*/boost/boost/boost/ detail/sp_counted_base_gcc_sparc.hpp
and applying the patch
http://boost.cvs.sourceforge.net/boost/boost/boost/detail/sp_c ounted_base.hpp?r1=1.8&r2=1.9
There is currently a problem with 64-bit SPARCs in 32-bit mode, where the default architecture isn't v9 (g++ doesn't support the notion of v8+). We're looking into fixing that on the bjam side.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I wrote:
The primitives supplied by g++ were not enough to support sp_counted_base (although this is going to change in 4.2, I think).
It seems that 4.1 supports the atomics as well, http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Atomic-Builtins.html so we'll be able to take advantage of them for 1.35 for all g++ targets. Jerry Lawson wrote:
Thanks for the response. I will patch my boost with those files.
Just for my education, however, I'd like to understand what was missing from the gcc primitives that you needed for the sp_counted_base required implementation?
shared_ptr requires a "compare and swap" operation (__sync_(bool|val)_compare_and_swap in the page above) in addition to atomic increment/decrement, and libstdc++ doesn't provide one.
Furthermore, should it be okay for me to continue to use atomic_count_gcc.hpp's pre-increment and post-increment overloaded operators as the implementation for my specialization of intrusive_ptr_add_ref(T*) and intrusive_ptr_add_release(T*) free functions?
You should be OK. I don't remember any reports of a problem with atomic_count_gcc.
participants (2)
-
Jerry Lawson -
Peter Dimov