[cpp-threads] Memory model question

[Boehm, Hans]

Dave -

I think you are saying that the Posix intent was that any assignment
to x is a "modification" of x, even if we can prove that the value
doesn't change?

Thus x = 0; in the below example is a modification, and creates a
data race, even though we knew that x == 0 initially, and thus the
assignment doesn't change anything?

Thanks.

Hans

> -----Original Message-----
> From: Butenhof, David (iCAP/PPU) 
> Sent: Tuesday, September 06, 2005 5:33 AM
> To: Boehm, Hans
> Cc: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] Memory model question
> 
> 
> 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.
> >>    
> >>
>