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

[Robbin Ehn]

On Mon, 9 Dec 2024 10:28:53 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Strictly speaking the first overflow happens here:
>> `TESTSIZE newvalue = oldvalue + 1;`
>> As '1' is an integer, oldvalue is promoted to an integer and as 128 is not in range of int8_t.
>> This is implementation defined, but de facto we know this will wrap around.
>> 
>> The casting of 40000 to TESTIZE the same thing happens, but first the higher bits are truncated and then it may wrap around depending on the MSB.
>> 
>> AFIACT it always produces the same result.
>> 
>> If we don't trust the wrap around as it's outside the spec both cases should be handled.
>
> Yeah. But seems avoidable if we make the loop count smaller for the narrow cases? I think it will be simpler and more readable for people then.

Yes, but doing just 127 incs there, then it is big chance of the threads not running at the same time.
The point is that they should run parallel a period of time.

I can nest loops?

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

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