atomic operations compared to c++
David Nadlinger via Digitalmars-d
digitalmars-d at puremagic.com
Wed Jun 14 10:32:54 PDT 2017
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
More information about the Digitalmars-d
mailing list