[interprocess] Is there a bug in spinlock atomic implementations 1.39 and 1.40?
Hi all
In both:
boost/detail/spinlock_sync.hpp boost/detail/smart_ptr/spinlock_sync.hpp
Spinlock does not has constructor, so it is possible to have spinlock::v_ uninitialized and not to equal zero. That means it may be locked by default and call below will always return false... bool try_lock() { int r = __sync_lock_test_and_set( &v_, 1 ); return r == 0; } Am I missing something?
Adding Spinlock(): v_(0) {} Looks like solves my issue. g++ 4.1.2 on suse 2.6.16.46
Regards Vlad.
=============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
AMDG Sakharuk, Vladimir wrote:
boost/detail/spinlock_sync.hpp boost/detail/smart_ptr/spinlock_sync.hpp
Spinlock does not has constructor, so it is possible to have spinlock::v_ uninitialized and not to equal zero. That means it may be locked by default and call below will always return false... bool try_lock() { int r = __sync_lock_test_and_set( &v_, 1 ); return r == 0; } Am I missing something?
Adding Spinlock(): v_(0) {} Looks like solves my issue. g++ 4.1.2 on suse 2.6.16.46
This behavior is intentional. boost::detail::spinlock is a POD type. Also, in general you shouldn't use anything in a detail directory. In Christ, Steven Watanabe
Steven, Thanks! If I can not use detail folder is there other ways I can use atomic based spinlock? Please follow the attached hyperlink to an important disclosure: http://www.credit-suisse.com/legal/marketcommentary -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Steven Watanabe Sent: Tuesday, October 13, 2009 10:22 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [interprocess] Is there a bug in spinlock atomic implementations 1.39 and 1.40? AMDG Sakharuk, Vladimir wrote:
boost/detail/spinlock_sync.hpp boost/detail/smart_ptr/spinlock_sync.hpp
Spinlock does not has constructor, so it is possible to have spinlock::v_ uninitialized and not to equal zero. That means it may be locked by default and call below will always return false... bool try_lock() { int r = __sync_lock_test_and_set( &v_, 1 ); return r == 0; } Am I missing something?
Adding Spinlock(): v_(0) {} Looks like solves my issue. g++ 4.1.2 on suse 2.6.16.46
This behavior is intentional. boost::detail::spinlock is a POD type. Also, in general you shouldn't use anything in a detail directory. In Christ, Steven Watanabe _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
Hi Vladimir, On Oct 14, 2009, at 7:13 AM, Sakharuk, Vladimir wrote:
Steven, Thanks! If I can not use detail folder is there other ways I can use atomic based spinlock?
It's not in Boost, but the Intel Threading Building Blocks has an atomic class that you could use to implement an atomic spinlock. Perhaps something like this might work? // atomic's have no constructors but you can reply on their being zero initialized tbb::atomic<int> ai; ... while(1) { if (1 == ai.compare_and_swap(1, 0)) { // ... --ai; // atomic decrement break; } } -- Noel
participants (3)
-
K. Noel Belcourt -
Sakharuk, Vladimir -
Steven Watanabe