Re: [boost] Bug in sp_counted_base and atomic_count?
On x86 this is certainly not an issue, but on machines with more relaxed memory model (ia64, sparc or power), in my opinion, this can be an issue... If you take a look at the IA64 and PPC versions of sp_counted_base, you'll see that they do include memory barriers.
In file boost_1_33_1/boost/detail/sp_counted_base_gcc_ia64.hpp : class sp_counted_base { private: //... long use_count_; // #shared long weak_count_; // #weak + (#shared != 0) public: sp_counted_base(): use_count_( 1 ), weak_count_( 1 ) // <--------- ordinal store In file boost_1_33_1/boost/detail/sp_counted_base_gcc_ppc.hpp the same.... In file boost_1_33_1/boost/detail/atomic_count_gcc.hpp : class atomic_count { public: explicit atomic_count(long v) : value_(v) {} // <--------- ordinal store ///... private: //... mutable _Atomic_word value_; }; gcc can compile to Alpha and to IA-64 and to PPC... What I miss?
Дмитрий Вьюков wrote:
sp_counted_base(): use_count_( 1 ), weak_count_( 1 ) // <--------- ordinal store
There's also a hidden ordinary store to the vtable pointer. In general, when passing an object X from thread A to thread B, you are expected to ensure the necessary visibility (and not the author of X). Usually the queue that you're using for message passing will contain the acquire/release pair in pop/push. Otherwise you wouldn't be able to pass ordinary objects between threads. Or to take a simple example: X * px; thread_A() { store_release( &px, new X ); } thread_B() { X * p = load_acquire( &px ); // use *p } The store/load part ensures the visibility of X in thread B and not X itself.
participants (2)
-
Peter Dimov -
Дмитрий Вьюков