[cpp-threads]atomic operations package

[Boehm, Hans]

The URL you cite uses membar_producer() as a StoreStore barrier.
Giving the following store (to environ) release semantics would
be uglier, but more correct (atomicity of the load and store are
critical,
if you specify that correctly, you get the ugliness already).
Under SPARC TSO, I suspect it should generate identical code,
though either one has subtle advantages in terms of compiler
reordering, which probably don't really matter.  I'm not sure it
makes a difference under weaker models either.

The Itanium definition is different, in that instructions
executed after a data-dependent branch, but which would be
executed whether or not the branch is taken, are not data
dependent on the original computation.  A processor
implementation is allowed to look ahead, and execute
stores that will be executed independent of the control
path, even if an earlier branch isn't yet resolved.
Effectively a branch over an instruction is allowed to
be executed like a predicated/conditional instruction.
I also don't think there is a difference between the load
and store cases.

The details don't matter.  But processors are all subtlely
different.  And compilers can remove or add the dependencies
observed by the hardware in cases that don't seem to be easy
to characterize.

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: Wednesday, August 24, 2005 6:13 AM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads]atomic operations package
> 
> 
> 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_th
> e_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.or
> > g.
> > 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.
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk