Hi,

On Tuesday, 13 June 2017 at 06:12:46 UTC, gzp wrote:
the docs are quite minimal

That's true. In fact, this applies not only to atomic intrinsics, but all of `shared`. We need to sit down and properly specify things at some point. Andrei has been trying to get an initiative going to do just that recently.

There is no consume in D.

There is indeed no equivalent to memory_order_consume. Note, however, that consume is about to be deprecated in C/C++, as it turned out to be more or less unimplementable in its current form (at least while still being useful). Introducing the notion of source-level dependencies into a language that otherwise operates with as-if semantics on an abstract machine is a tricky business.

But what about compare_exchange (CAS) ? […] Does it mean,
it is the strongest sequaential all the time

Yes, core.atomic.cas() is always seq_cst for the time being (we should fix this).

Another issue is the fence. In D there is no memoryordering for fence, only the strongest one exists. Is it intentional?

No; it is just a questionable design decision/unnecessary limitation which can easily be remedied by adding an optional parameter.

 — David

Reply via email to