[cpp-threads] SC on PPC

Raul Silvera rauls at ca.ibm.com
Wed May 9 21:14:39 BST 2007


Hans Boehm wrote on 05/04/2007 05:49:08 PM:

> > > On Wed, 2 May 2007, Alexander Terekhov wrote:
> > > > P1: x.store_relaxed(1)
> > > > P2: if (x.load_relaxed()==1) { y.store_release(1) }
> > > > P3: if (y.load_acquire()==1) { Assert(x.load_relaxed()==1) }

> I had unfortunately misread Alexander's example slightly, and read the
> load_relaxed in P2 as a load_acquire.  I believe you really need to
> change the store_relaxed/load_relaxed in P1/P2 to
> store_release/load_acquire in order to guarantee that the assertion will
> not fail in our proposal.  The P3 load of x can remain unchanged.
>
> In the release/acquire version
>
> x_initialization hb x.store_relaxed(P1) hb x.load_relaxed(P2) hb
> y.store_release(P2) hb y.load_acquire(P3) hb x.load_relaxed(P3).

I assume you meant "x_initialization hb x.store_release(P1) hb
x.load_relaxed(P2) hb ..."

> It follows that P3s load of x cannot see the zero initialization of x,
> since there is a store that "happens between" them.
>
> If either of the P1/P2 operations on x are "relaxed", there is no
> ordering between (a)x.store_relaxed(P1) and x.load_relaxed(P2).  Hence
> (a) can become visible to either of the other threads at any time.  You
> don't get causality in the sense in which it's used here.  But you do
> get a transitive happens-before relation; it's just a very sparse one.
>
> This is consistent with the Java approach, if you view "relaxed" C++
> atomics as equivalent to ordinary (non-atomic/volatile) Java variables.

I find this troublesome. As a programmer I don't see the rationale of why
you would need a release store on P1. A release operation is needed to
order a store with respect to preceding operations, but there are no
preceding operations from P1 on this example.

It seems natural to me that if an atomic relaxed load observes the value
stored by an atomic relaxed store, then the relaxed store hb the relaxed
load.

I don't think relaxed C++ atomics are equivalent ordinary Java variables;
instead, I believe they are a middle ground between ordinary variables and
SC atomics. The fundamental issue is that, unlike ordinary Java variables,
relaxed operations can provide reliable communication between threads, and
that should be part of the memory model.

--
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





More information about the cpp-threads mailing list