Re: [boost] [atomic] Help understanding consume order

On Monday 02 June 2014 12:42:04 Giovanni Piero Deretta wrote:

On Sun, Jun 1, 2014 at 11:58 AM, Andrey Semashev wrote:

ARM and many other RMO architectures (like PPC and unlike Alpha), guarantee that a load and the load it depends on won't be reordered, so, together with the release operation on the writer side, the load_consume guarantees the visibility of the string body.

Ok, so basically, on ARM and PPC consume operation should be equivalent to relaxed + a compiler barrier to prevent possible code reordering, am I right?

The exact definition of load dependency (basically the address of the dependent load is computed as a function of the value returned by the depending load) is defined at the instruction level and is quite tricky to recover at the high level C++ language. C++11 tried to do it, but according to a few the current working is both very hard to implement and both not strong enough and too strict in some cases.

In the meantime GCC (and a few other compilers) punts on load_consume and simply promotes it to load_acquire.

Yes, I noticed that. MSVC seems to follow the same route as well.

...

I guess, that's the ultimate question: how should consume ordering be handled on conventional architectures.

That's hard to do without compiler help unfortunately. Compilers have started doing some quite aggressive optimisations (like value speculation and PGO) that can break loads dependencies. The linux kernel for example gets by by explicitly disabling those optimisations, not doing PGO and targeting a specific compiler.

I hope, speculative loads and stores can be prevented with compiler barriers. But it looks like PGO/IPO/LTO may ruin the code involving this memory ordering. I suppose, even if I put a compiler barrier (which in case of gcc is an empty asm statement with memory in the clobber list) it will not be in effect during the optimization phase?

See n2664 and the recent epic thread on gcc-dev.

Is it this thread? https://gcc.gnu.org/ml/gcc/2014-02/msg00052.html I'm reading it now, very interesting, thank you for the tip.