[cpp-threads] Slightly revised memory model proposal (D2300)

[Alexander Terekhov]

On 7/5/07, Sarita V Adve <sadve at cs.uiuc.edu> wrote:
> > But if A and B are non-atomic, we aren't even guaranteeing that
> > simple loads and stores will be indivisible operations.  Why would
> > we be making SC guarantees about variables that don't provide even
> > the very weak guarantees provided by relaxed atomics?  Shouldn't the
> > developer be using atomic variables in multithreaded situations
> > exactly so that the program wil be easy to reason about?
> >
> > Or are A and B really intended to be atomic variables?
>
>
> Paul,
>
> The variables in the example below are NOT atomic.
>
> > > > > > T1: if (A==1) B=1;
> > > > > > T2: if (B==1) A=1
>
> Yes, we do want programmers to use atomics so their program will be easy
> to reason about.
>
> But how do we explain when to use atomics so the program will be easy to
> reason about? Minimally, one would expect that atomics would only be
> needed in situations where two threads access the same variable. Agreed?
>
> For the example above, the only way in which two threads can access the
> same variable is if the threads perform speculative writes.

I suggest you call it "opportunistic" writes (vs "speculative" reads
that are redone on speculation miss) and thereby decree implicit code
conditional and data dependent hoist store barriers. No problem for
Power and all other current hardware archs, as far as I known.

regards,
alexander.