Re: [Boost-users] Subject:[atomic] why atomic<>::store method can not support memory_order_consum memory_order_acquire and memory_order_acq_rel these memory_orders?

Subject: Re: [Boost-users] Subject:[atomic] why atomic<>::store method can not support memory_order_consum memory_order_acquire and memory_order_acq_rel these memory_orders?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-07-22 20:20:28

On 22/07/2015 14:43, class7class_at_[hidden] wrote:
> I am a SE and I program based on boost library, I have one question to
> ask as below:
>
> When I use the atomic library included boost , I coded as following:
>    atomic<bool> flag; //declare the var
>                    flag.store(true,boost::memory_order_acq_rel); // use
> store method to change the value of flag
>
> but BOOST_ASSERT failed,and I read the code of base_atomic<> template
> class,I found the the store() method can not support several
> memory_orders metioned in the subject , and the other methods can not
> support all memory_orders,such as:
>    1.the load method can not support memory_order_release and
> memory_order_acq_rel
>    2. the compare_exchange_strong method can not support
> memory_order_release and memory_order_acq_rel
>    3. the compare_exchange_weak method can not support
> memory_order_release and memory_order_acq_rel
>
> I really want to know the reason that why the methods of atomic can not
> support all memory_orders.

Because this is mandated by the standard, and because doing otherwise 
doesn't really make sense.

Loads can't release, and stores can't acquire.  Therefore those memory 
orders are nonsensical.

memory_order_acq_rel exists for RMW operations such as compare_exchange. 
  The "acq" applies to the load and the "rel" to the store.  It's not 
sensible for a store alone.

> If I need the methods of the atomic<> support all memory_orders,how
> can i do?

You can re-read the standard memory model and discover why that doesn't 
make sense.

Memory ordering can be tricky to get your head around at first -- it's a 
good idea to run any atomic algorithm you implement through a sanity 
checker such as RRD or ThreadSanitizer to help catch subtle bugs.

If in doubt, stick with seq_cst memory ordering (the default).  On 
x86/x64 there is very little performance difference between seq_cst and 
the weaker orders -- cacheline sharing tends to be more problematic.