digitalmars.D.bugs - [Issue 20837] New: [core.atomic] Provide MemoryOrder.con (consume)
- d-bugmail puremagic.com (40/40) May 16 2020 https://issues.dlang.org/show_bug.cgi?id=20837
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. --
May 16 2020