DIP 1024--Shared Atomics--Community Review Round 1

[Ola Fosheim Grøstad]

On Wednesday, 9 October 2019 at 18:25:36 UTC, Manu wrote:
> This made exactly no sense to me. I don't know what you're 
> saying here. That said, based on your past posts, I think I 
> need to assure you that it is **NEVER** acceptable to freely 
> read/write to shared data, and that doesn't only apply to @safe 
> code.

Maybe set up a list of what problems and opportunities "shared" 
is supposed to deal with? What will it solve, and just as 
importantly, list explicitly which issues it won't deal with.

As far as I can tell, one could get better optimization if one 
could assume that certain memory areas are not accessed by other 
threads and avoid C++-ish sequencing points even in code that use 
concurrency-primitives. That seems to be out of scope?

If C++ is supposed to interface with D, then the spec ought to 
present an argument for how D's memory model is compatible with 
C++, which may be summed up as (quoting cppreference.com):

«Any thread can potentially access any object in the program 
(objects with automatic and thread-local storage duration may 
still be accessed by another thread through a pointer or by 
reference).

Different threads of execution are always allowed to access (read 
and modify) different memory locations concurrently, with no 
interference and no synchronization requirements.»