Re: [boost] Notice: Boost.Atomic (atomic operations library)

Subject: Re: [boost] Notice: Boost.Atomic (atomic operations library)
From: Peter Dimov (pdimov_at_[hidden])
Date: 2009-12-01 09:30:12

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.