Bug 20837 – [core.atomic] Provide MemoryOrder.con (consume) for atomicLoad

MemoryOrder.consume for atomicLoad on platforms (compiler and hardware) that support it would use normal read, but ensure that subsequent operations that might depend on its value, including access to other atomics, are not reordered before this load. On platforms or compilers that do not support it, MemoryOrder.consume would fallback to MemoryOrder.acquire, which is slightly stronger memory order, but provides required guarantees. MemoryOrder.consume can be cheaper than MemoryOrder.acquire on some platforms (like ARM, PowerPC, Itanium and Alpha), while providing necessary compiler optimization safety. On platforms with strong memory ordering and specification prohibiting CPU to speculatively reorder reads, the MemoryOrder.consume would be the same as MemoryOrder.acquire, but allow compiler to performs some allowed optimizations. On very weak memory ordering systems (like Alpha), compiler would need to insert extra fences to ensure CPU doesn't reorder memory references before such load, even speculatively. But again, if the compiler doesn't want to support it, it can just revert to doing the same as MemoryOrder.acquire. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0098r0.pdf C++11 do have memory order consume. LLVM as of now doesn't provide consume memory order, and for this cases frontends fallback to acquire. I believe GCC does have special support for consume tho that differs from acquire. The use case for using consume is in tight hot code paths dealing with atomics.

FYI: memory_order_consume is temporarily discouraged. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0371r1.html

Hiroki, yes, you are right, I did Hans Boehm other papers, but I did miss this one. To make memory_order_consume worthwile and actually do something better than memory_order_acquire it requires extra support from compiler (including possibly annotations for killing dependencies) and defining precisely how it work. This is missing right now (the current specification is not workable, and not possible to really implement in compilers). So, yes, to be postponed. And I guess, it is good phobos core.atomics and LLVM didn't blindly pick it up. Will close it for the time being.

Lets ignore it. Consume is too complex to be really implementable at this point, it requires very sophisticated machinery in compiler to even be possible to done correctly.