[dmd-concurrency] draft 7

Michel Fortin michel.fortin at michelf.com
Mon Feb 1 14:43:10 PST 2010


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?

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/





More information about the dmd-concurrency mailing list