https://issues.dlang.org/show_bug.cgi?id=20837

          Issue ID: 20837
           Summary: [core.atomic] Provide MemoryOrder.con (consume) for
                    atomicLoad
           Product: D
           Version: D2
          Hardware: All
               URL: http://dlang.org/phobos/
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P3
         Component: druntime
          Assignee: nobody@puremagic.com
          Reporter: witold.baryluk+d@gmail.com

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.

--