Helge Bahmann wrote:
Hello Mikael,
On Tue, 1 Dec 2009, Mikael Olenfalk wrote:
Hello Helge,
I am trying to use Boost.Atomic in my project but am experiencing the following two problems:
- boost/atomic/memory_order.hpp: enum memory_order is redeclared from boost/memory_order.hpp (1.37)
Yes, I realized that today; the definition in boost/memory_order.hpp is outdated, it should be replaced with boost/atomic/memory_order.hpp or augmented to include "memory_order_consume" (it is contained in more "recent" proposals of the C++0x standard, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2643.html).
I will add _consume to boost/memory_order.hpp. FWIW, the enum values in it are chosen so that one can use if( mo & memory_order_acquire ) { // insert trailing fence } and if( mo & memory_order_release ) { // insert leading fence } instead of a switch. I think that your PPC trailing fence (isync) is wrong for loads. isync should only be used after a conditional jump (if one wants acquire semantics). For loads, you need either a trailing lwsync, or a fake never-taken branch + isync. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2745.html Your use of a single lock for seq_cst operations has given me pause, but now that I've thought about it some more, I think that this is not necessary. Per-location locks also provide sequential consistency. There is already boost/smart_ptr/detail/spinlock_pool.hpp that you may use for the fallback - if you like.