[dmd-concurrency] draft 7

[Fawzi Mohamed]

On 2-feb-10, at 05:12, 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.

by the way the article you linked is correct, and points to a real  
problem of naive double lock patterns, but not relevant in the current  
context, the details of concurrency are difficult, I also get confused  
at times :).

Fawzi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100202/667fe9db/attachment.htm>