[dmd-concurrency] draft 7

[Fawzi Mohamed]

On 1-feb-10, at 23:43, Michel Fortin wrote:

> Le 2010-02-01 à 17:26, Fawzi Mohamed a écrit :
>
>> On 1-feb-10, at 23:10, Andrei Alexandrescu wrote:
>>
>>> Fawzi Mohamed wrote:
>>>> I gave a quick reading about the fact that reading needs a lock  
>>>> because otherwise it might not be updated almost forever, this is  
>>>> (as far as I know) wrong.
>>>> Yes the view of one thread might be offset with respect with the  
>>>> one of another, but not indefinitely so.
>>>> The main reason to put the sync is to ensure that one sees a  
>>>> consistent view of the value.
>>>> If a value is always updated in an atomic way then the sync is  
>>>> not needed.
>>>
>>> It's a classic that if you read (without handshake) a value in a  
>>> loop thinking you're doing spinning, various compiler and  
>>> processor optimizations will cache the value and spin forever. The  
>>> synchronization in there is needed for the handshake, and can be  
>>> optimized by the compiler if a simple barrier is needed.
>>
>> you don't need a barrier, you need a volatile statement to avoid  
>> compiler optimizations
>
> Is that something the compiler could do in an optimization pass, I  
> mean determining when a barrier isn't necessary and volatile is  
> enough? For instance when periodically checking a shared variable in  
> a loop?

I think that there is some confusion about what barriers do, they just  
introduces a partial ordering In general a compiler cannot decide  
automatically to remove them.

The handshake Andrei was talking about really isn't the point here.
The thing is that the compiler should avoid some optimizations, in the  
sense that it should always load from memory (and not store it in a  
register and read it from there).
A barrier alone has nothing to do with that, but a read barrier can  
ensure that what is visible after the read is for sure the status  
after a corresponding write barrier.

Fawzi
>
> -- 
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/
>
>
>
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency