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

[Robbin Ehn]

On Mon, 9 Dec 2024 13:40:52 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> 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?
>
> Seems to me overflow is fine, it won't affect the test correctness? maybe we could add some comment to state it clearly.
> Or maybe we could use something like barrier or phaser in java API to sync the real starting of different threads in the thread group? But I'm not sure if there are such utilities in hotspot test framework.

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?

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

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