RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64

[Andrew Haley]

On 06/10/16 23:16, Kim Barrett wrote:

> The key issue here is that we copy obj into new_obj, and then make
> new_obj accessible to other threads via the CAS.  Those other
> threads might attempt to access data in new_obj.  This suggests the
> CAS ought to have at least a release fence to ensure the copy is
> complete before the CAS is performed.  No amount of fencing on the
> read side (such as in the work stealing) can remove that need.

I agree.

> And that might be all that is needed.  On the post-CAS side, we load
> the forwardee and then load values from it.  I thik we can use
> implicit consume with dependent loads (except on Alpha) plus the
> suggested release fence to get the desired effect.

That's probably true, except that there's not really any such thing as
"implicit consume" in C++.  While all of the hardware we use respects
address dependencies, it's not something that the compiler knows
about, and it's explicitly undefined behaviour in the C++ memory
model.  If we're depending on memory_order_consume, perhaps we ought
to think about adding it to Atomic, even though it's just a volatile
load in older compilers.

Andrew.