[cpp-threads]atomic operations package

[Boehm, Hans]

Yes.  But that message discusses what appears to be an assembly routine.

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.

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

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


> -----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: Tuesday, August 23, 2005 3:06 AM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads]atomic operations package
> 
> 
> On 8/23/05, Boehm, Hans <hans.boehm at hp.com> wrote:
> > Doesn't msync::ddhlb just turn into acquire, and msync::ssb into 
> > release?  Thus I think the only issue here is a possible 
> performance 
> > loss.
> 
> Yes, but that was the point. And the loss is quite real on archs like 
> Power (lwsync or isync do take some cycles and ddhlb is for free, for
> example) and Sparc (reportedly hypothetical RMO): 
> 
>
http://groups.google.ca/group/comp.programming.threads/msg/8bdc77efe2472
26c

"the change in membars gave about a 7% performance improvement 
on UltraSparc IIs".

That change is about reliance on implied constraint (hoist barrier) 
for dependent stores. But even with compiler injected fake control 
dependency, you'd still have to include MEMBAR #LoadLoad (under
RMO) for stuff like DCSI with full acquire instead of mere ddhlb.

> 
> There are issues here where I think we still have choices that should 
> be discussed:
> 
> 1) You make the ordering constraint a run-time parameter, and I make 
> it a member template parameter.  My guess is that you almost never 
> want it to be a runtime parameter.

It's not really meant to be a run-time parameter. It just takes a bit 
less characters and is more readable IMO.

http://www.terekhov.de/pthread_refcount_t/experimental/refcount.cpp

op<contraint>();

vs

op(contraint);

I mean.

regards,
alexander.

-- 
cpp-threads mailing list
cpp-threads at decadentplace.org.uk
http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decadentplace.o
rg.uk