On Sunday, 28 August 2016 at 21:52:48 UTC, Illuminati wrote:
The interlocked functions generate memory barriers, does
atomicOp do that?
Also D doesn't seem to have a volitile keyword anymore which is
required to prevent the compiler from prematurely optimizing
critical code.
I'm under the impression that atomicOp does not generate memory
barriers. In fact, in its implementation, it uses atomicLoad with
relaxed memory ordering.
There is however a function in core.atomic to generate a full
memory barrier, if you need it.
By the way, can I ask you why you need this? Is it for low-level
data sharing or for hardware access? If it is for low-level data
sharing, then you probably don't need volatile, as shared should
be enough. If it is for hardware access, the situation is more
complex, but I'm sure I've seen some threads about how to
implement Volatile!T in a few lines of code recently.
