[cpp-threads]atomic operations package

[Alexander Terekhov]

On 8/24/05, Boehm, Hans <hans.boehm at hp.com> wrote:
> Yes.  But that message discusses what appears to be an assembly routine.

Uhmm,

http://blogs.sun.com/roller/comments/pgdh/Weblog/caring_for_the_environment_making

appears to be about C{++}, not assembly.

> 
> At the C++ level, we seem to be unable to define ddhlb and friends
> sufficiently well.  Peter proposed a definition at
> 
> http://jupiter.robustserver.com/pipermail/cpp-threads_decadentplace.org.
> uk/2005-May/000322.html
> 
> But those definitions are different from the SPARC definitions,
> which consider everything following a conditional branch on a loaded
> value to be data-dependent on that value, but only for stores.

Well, cchsb is implied on Sparc (for load... stuff) just like ddhlb, ddhsb, 
and ddacq (ddhlb+ddhsb). But cchlb does require a memory barrier (in 
RMO), the same (trailing) MEMBAR #LoadLoad as ccacq (cchlb+cchsb).

That's how I read the Sparc rules D.3.3 (1) and (2).

> 
> And that's different from the Itanium definition, which in

I think it's the same on Itanic. 

I don't quite follow the rest of your message.

> 
> r0 = x
> if (r0) r1 = y;
> r2 = z;
> 
> considers the load of y, but not z, to be dependent on that of x.
> 
> And pretty much all of these have the problem that standard compiler
> transformations can affect whether or not there is a dependency.  And
> these transformations may take place in a separate compilation unit from
> the one containing the atomic<> reference.
> 
> The SPARC definition, for example, makes no sense at the C++ level,
> even aside from the fact that it treats loads and stores differently.
> 
> If we had
> 
> r0 = x
> if (r0) r1 = y;
> z = r2;
> 
> the store of z would appear to be data dependent on that of x.  But
> if the middle statement is implemented with a conditional or
> predicated load/move instruction, there is no longer a branch,
> and the dependency disappears.  Since not all of this code has
> to be in the same compilation unit, this would prevent the compiler
> from performing if-conversion anywhere, which would be a clear
> disaster.
> 
> The only ways out of this that I can think of are:
> 
> 1) Someone can propose a robust definition of dependency that
> makes sense at the C++ source level.  I think that anything
> that interferes substantially with optimization of code not
> containing atomic<> references won't fly.  This seems hard.
> 
> 2) We can consider coarser operations on atomics that perform
> say a load, a null test, and a load of a field of the resulting
> object if the initial load returned non-null, enforcing only
> ordering between the two loads.  This seems messy and not
> terribly useful, at least not at this stage.
> 
> Hans

regards,
alexander.