RFR: 8315856: RISC-V: Use Zacas extension for cmpxchg [v3]

[Robbin Ehn]

On Tue, 12 Dec 2023 01:17:33 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> That `dmb` is not present in the AArch64 port because we want a release when the CAS fails, because if it fails nothing was stored, so there is literally nothing for a subsequent load from that address to synchronize with.
>> 
>> It's there because of this re-ordering:
>> 
>> 
>> 
>> 	<Access [A]>
>> 
>> 	// atomic_op (B)
>> 1:	ldaxr	x0, [B]		// Exclusive load with acquire
>> 	<op(B)>
>> 	stlxr	w1, x0, [B]	// Exclusive store with release
>> 	cbnz	w1, 1b
>> 
>> 	<Access [C]>
>> 
>> It doesn't forbid orderings such as
>> 
>> Load [B] -> Load [C] -> Store [A] -> Store [B]
>> 
>> 
>> [See here](https://mail.openjdk.org/pipermail/aarch64-port-dev/2014-February/000706.html)
>> 
>> The Arm memory model has been strengthened, and this reasoning looks a bit shaky today. At the time we did not know if any of the usages of `cmpxchgptr`required "full barrier" semantics, so we put a full barrier in for safety's sake.
>
> Wow, thanks for finding that history. It's very helpful for us to understand the existence of this barrier.

I have seen code, do not find it anymore in code base, which use cmpxchg for Atomic::release_store_fence().
(which is "new");

Atomic::store(_x, true);
Atomic::store_release_fence(_one_way_barrier, true);
bool z = Atomic::load(_z);

But it is written as:

Atomic::store(_x, true);
Atomic::cmpxchg(_one_way_barrier, false, true);
bool z = Atomic::load(_z);

Where load Z happens after store X. But without release the store may happens after.

As we say:
"All of the atomic operations that imply a read-modify-write action guarantee a two-way memory barrier across that operation."

I have look over the cmpxchg uses and not releasing 'seems' okay at first glance.
But I think before this line changes we should release on failed CAS.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16910#discussion_r1423631241