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

[Raul Silvera]

Hans wrote on 06/15/2007 12:09:39 PM:

> Unfortunately, I think I posted some misinformation here, with respect
> to flickering.  I believe the version of the example that I posted:
> 
> > > Thread 1:
> > > store_relaxed(&x, 1);
> > >
> > > Thread 2:
> > > store_relaxed(&x, 2);
> > >
> > > Thread 3:
> > > r1 = load_acquire(&x); (1)
> > > r2 = load_acquire(&x); (2)
> > > r3 = load_acquire(&x); (1)
> > >
> is already allowed to flicker under the D2300 rules.  And looking back
> at Sarita's example, weakening this doesn't seem to help.  (The example
> that we should really have been discussing would have had release 
stores.
> That's the one that's currently constrained by the modification order
> rule.  And having that flicker does seem dubious.)

I find this very troubling. From T3's point of view, it is just doing 
acquire
operations, and it is not expecting any flickering, regardless of which 
stores
are going to satisfy its loads.

> I think the kind of flickering that we already allow is unavoidable if
> we assume that unpaired acquires behave like relaxed operations. 
Consider
> the above example with thread 3 replaced by:
> 
> p = &x;
> q = &x;
> ...
> while (...) {
>   // Loop does not store to potentially shared variables.
>   r1 = load_relaxed(p);  // loads *p, i.e. x
>   r2 = load_relaxed(q);  // loads *q, i.e. x
> }
> 
> Assume the ellipses code confounds the compiler enough that it no longer
> knows that *p and *q are aliases.  (That's easy to arrange.)  The 
compiler
> might then move the loads out of the loop, without combining them, which
> could potentially result in exactly this flickering.  (If you don't like
> moving loop invariant load_relaxed operations, think of it as splitting
> the
> loop into two, each one of which contains one of the loads, and then
> combining all the load_relaxed ops in each loop.  Even without combining
> them you have the same problem.)

I think this is a good justification for not treating unpaired acquires as
relaxed operations. Even though they do share some attributes with relaxed
operations, they are not completely relaxed: they cannot be locally 
reordered,
so they expose cache coherence.

> The D2300 proposal doesn't change this, but it does move to the weaker
> synchronizes-with model, as Paul points out below.
> 
> I think I agree with Paul's general direction for the rest of this, but
> I need to think more about the details.  I think we want to aim for
> 
> - Basically the D2300 model, but
> - some way to strengthen 1.10p7 to explicitly add "synchronizes-with"
> relationships for certain later reads, if the intervening operatons on
> that
> variable were all RMW ops.
> 
> Based on attempts to tweak this in the past, I think that sort of
> formulation
> is most likely to work.

Yes, I agree with this direction; I have been calling for such an 
exception
mechanism for RMW operations.

--
Raúl E. Silvera         IBM Toronto Lab         Team Lead, Toronto 
Portable Optimizer (TPO)
Tel: 905-413-4188       T/L: 969-4188           Fax: 905-413-4854 
D2/KC9/8200/MKM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.decadentplace.org.uk/pipermail/cpp-threads/attachments/20070618/bcdcb86d/attachment.html