[dmd-concurrency] draft 7

[Andrei Alexandrescu]

Fawzi Mohamed wrote:
> 
> On 2-feb-10, at 04:59, Andrei Alexandrescu wrote:
> 
>> Fawzi Mohamed wrote:
>>> On 2-feb-10, at 01:34, Andrei Alexandrescu wrote:
>>>> Fawzi Mohamed wrote:
>>>>> you don't need a barrier, you need a volatile statement to avoid 
>>>>> compiler optimizations
>>>>
>>>> That depends on the platform. On contemporary Intel machines I agree 
>>>> there's no need for a barrier.
>>> as I explained in another post (that I wrote several hours ago, but 
>>> unfortunately was just sent (I closed the computer too fast...) I 
>>> think that you don't really understand what barriers do.
>>
>> It's possible I am not expressing myself clearly. My understanding is 
>> described at length in this article:
>>
>> http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
> 
> yes in that case you need a barrier because you expect that some other 
> memory (the one that holds the singleton) is initialized *if* you are 
> able to read the value of the pointer pointing to it.
> Thus you need to introduce a partial ordering that guarantees that you 
> will never see the pointer pointing to the memory before seeing the 
> initialized memory.
> You need a partial ordering in the memory write/reads.
> This is not connected (in general, maybe on some hardware it is) to 
> reading the updated value read from memory.
> What breaks an access to a single atomic value is not the absence of a 
> barrier, but putting it in a register and not bothering to load it each 
> time (something that a compiler might to in some occasions as 
> optimization).
> I hope now the issue is clearer.

I suggest we resume and start with describing what was unclear, then 
specifying the steps we need to take to clarify things better in the 
draft. Thanks!

Andrei