[cpp-threads] Memory model question

[Dave Butenhof]

Boehm, Hans wrote:

>I agree with Alexander.
>
>Presumably you are asking the question, because the pthread standard
>uses the word "modify", and it's not clear that x is being modified
>here?
>  
>
Sorry for the delay -- I've been out sometimes, and way too busy the 
rest of the time.

While POSIX uses the word "modify", it's not in isolation. The relevant 
phrase from 4.10 is "no thread of control can read or modify a memory 
location while another thread of control may be modifying it". Two reads 
don't make a wrong; but a read and a write do, just as much as two 
writes. ;-)

>I have no idea whether that was intentional or not.  Dave - Do you know?
>  
>
Yes, it was certainly intentional. And, despite the fairly casual 
language, carefully considered.

>After thinking about it for a bit, I think that not calling this a data
>race would disable some compiler optimizations, but perhaps not major
>ones.
>  
>
I think that to avoid calling this a "data race" you'd need to develop a 
very odd (and for most purposes completely useless) definition of "data 
race". But then I prefer to avoid wasting time arguing about definitions.

>("Speculative" code hoisting, which hoists an assignment out of a switch
>statement, even though a different assignment to the same variable
>occurs in one of the branches, seems to be one example.)
>It does seem to make compiler correctness arguments much harder.
>I can't convince myself that it matters much to the programmer, one way
>or the other.
>
>Hans
>  
>
>>-----Original Message-----
>>From: 
>>Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk 
>>[mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
>>.org.uk] On Behalf Of Alexander Terekhov
>>Sent: Friday, August 26, 2005 4:43 AM
>>To: cpp-threads at decadentplace.org.uk
>>Subject: Re: [cpp-threads] Memory model question
>>
>>
>>On 8/26/05, Peter Dimov <pdimov at mmltd.net> wrote:
>>    
>>
>>>In your opinion, does the following example contain a data race?
>>>      
>>>
Yes, it's a data race. It may simultaneously read and write x, with no 
memory visibility/coherence guarantees.  Given atomic read/write 
operations the worst outcome is that you might get either the old or new 
value of x in T2; but since atomicity cannot be portably guaranteed 
(either in hardware or the compiler's code generator), the reality may 
be far worse. This code is non-conforming, incorrect, and non-portable.

>>>// initially x == 0
>>>
>>>T1:
>>>
>>>x = 0;
>>>
>>>T2:
>>>
>>>r1 = x;
>>>      
>>>
>>Yes.
>>
>>regards,
>>alexander.
>>    
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: david.butenhof.vcf
Type: text/x-vcard
Size: 476 bytes
Desc: not available
Url : http://shadbolt.decadentplace.org.uk/pipermail/cpp-threads/attachments/20050906/8c49efd6/david.butenhof.vcf