No memory model

[Moritz Maxeiner]

On Tuesday, 22 October 2013 at 09:07:38 UTC, qznc wrote:
> On Tuesday, 22 October 2013 at 00:26:48 UTC, deadalnix wrote:
>> On Monday, 21 October 2013 at 20:50:28 UTC, qznc wrote:
>>> As far as I google, D has not specified a memory model.
>>>
>>> However, I assume it should basically be the same as the C++ 
>>> memory model: Sequential consistency for data-race-free 
>>> programs.
>>
>> shared = sequential consistency.
>> immutable = immutable.
>> TL = do whatever you want to make my program faster.
>
> So Ds shared has a similar effect as Javas volatile. The 
> difference is transitivity like with const.
>
> Nevertheless, core.atomic also plays into this. Why do we need 
> atomicStore, if we have shared? Why does atomicStore require 
> its argument to be shared?

Without wanting to directly contradict he previous response(s), 
as far as I understand the documentation 
(http://dlang.org/migrate-to-shared.html#shared), the shared 
keyword guarantees only the following for a variable:
- it goes into global storage, not thread-local one
- it's effects of being shared are transitive

Sequential consistency would - afaik - mean, that executing the 
threads of a nonsequential program in *any* interleaved order on 
a single processor in the relative order the program specifies 
for each thread internally would yield the same results as 
executing it in a true non-sequential environment, such as each 
thread being executed by one processor without any necessary 
interleaving.

Again, as far as I understand the concept, it you truly had 
sequential consistency, you would not need atomic operations, but 
I don't think marking a variable as "shared" would really provide 
that, because then the compiler would need to inject locks for 
every shared variable and use them for all read/writes of that 
variable.

So as far as I can see it "shared" does not prevent two threads 
from writing at the same time / reading/writing at the same time 
the same way as "volatile" does not do it for Java.

This means you still need to provide correct synchronisation with 
via locking / lock-free algorithms; also, don't forget __gshared 
which only guarantees the variable goes into global storage, 
nothing more, so you definiely need atmic operations there for 
non-sequential programs.

Anyway, if I'm wrong, please do correct me here, because I 
patched this together from the documentation, which I find 
somewhat thin at a few parts regarding this subject.