RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants

[Robbin Ehn]

On Tue, 10 Dec 2024 02:29:31 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Those have the same issue, it may take several ms to schedule a thread after it have been release form a barrier thus a short loop taking a few hundreds of nanos have a big chance of not running in parallel.
>> If you do busy-wait you risk running out of run-quote thus prempted instead.
>> 
>> Perfably one should record the CAS failure and when all threads have had failures we know that they did run concurrently.
>> 
>> So maybe:
>> Run loops from TESTSIZE min to max, re-run this loop until we record CAS failures or something like that?
>
>> So maybe: Run loops from TESTSIZE min to max, re-run this loop until we record CAS failures or something like that?
> 
> Seens to me that would be very similar with the current approach. How about we make the wrap around here explicit? Say, when the `oldvalue` reaches TESTSIZE max, we set the `newvalue` to TESTSIZE min. And we set the final expect value in `data` accordingly instead of doing a type truncation. Then we don't depend on the implementation of the compiler.

The truncation is well defined, it's just signess overflow that is not spec.
As TESTSIZE may be 64 bits and we don't simply increase by one that check itself will overflow.

Note that even if compiler do something else than wrap around, it would do the same in both cases so it should produce the same result.

Also note that this cast is no worse than doing (signed char)0xff.

Anyhow I tested trying to add max and min, the code just becomes very ugly and complicated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1877594494