On Jun 21, 2011, at 7:41 AM, Alasdair Grant wrote:> what's the current status of the memory-ordered operations described in
>
https://docs.google.com/Doc?docid=0AYWBeVVqyP7dZGRiNG1oeHpfMjJkejVnOThkZA&hl=en.&pli=1
> i.e. the ones for "load acquire", "store release" etc.
for C++0x atomics,
> not the older ones for the __sync intrinsics? The specification looks good
-
> is it just waiting to be implemented?
>
> Al
I just reread the memory model proposal myself. Initially I wasn't excited
by an implementation that represents memory operations as intrinsics, but I now
see the this footnote: "atomic load and store should be done with some
SubclassData bits on the existing instructions"
Representing atomic loads and stores and load/store instructions makes the whole
thing worthwhile to me. That said, I will not personally be able to work
implementing this proposal any time in the near future.
Generally, the spec looks great. There is only one thing I would like to change.
The definition of sequential consistency is not quite right. The LLVM proposal
claims that sequentially consitent operations have aquire+release semantics.
Here is an excerpt from C++0x n3242, section 29.3:
The enumeration memory_order specifies the detailed regular
(non-atomic) memory synchronization order as defined in 1.10 and may
provide for operation ordering. Its enumerated values and their
meanings are as follows:
- memory_order_relaxed: no operation orders memory.
- memory_order_release, memory_order_acq_rel, and memory_order_seq_cst:
a store operation performs a release operation on the affected
memory location.
- memory_order_consume: a load operation performs a consume
operation on the affected memory location.
- memory_order_acquire, memory_order_acq_rel, and memory_order_seq_cst:
a load operation performs an acquire operation on the affected
memory location.
The upshot is that sequentially consistent stores have release semantics, and
sequentially consistent loads have acquire semantics. Additionally, sequentially
consistent operations have a total order among themselves. By reading between
the lines, you can see that sequentially consistent stores do not need acquire
semantics.
I'm not just being pendantic. The only memory_order that matters much to me
is memory_order_seq_cst, which I believe is the default mode for atomic types
and the only sane model for programmers to use. Giving stores acquire semantics
effectively forces full fences following every atomic store. Even if the target
architecture were to provide a "store-acquire", implementing a store
with acquire semantics is hideously expensive on modern microarchitectures. Yes,
the implementation still needs a way to implement the total order among
sequentially consistent operations. But that can potentially be optimized.
-Andy