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