RFR: 7902982: jcstress: Add samples for some mutex algorithms [v3]

[Michael Mirwaldt]

On Tue, 29 Jun 2021 13:55:40 GMT, Michael Mirwaldt <github.com+6693355+mmirwaldt at openjdk.org> wrote:

>> Writes to plain, non-volatile fields can be observed by other threads as well �� 
>> 
>> In case you make `taken1` and `taken2` volatiles, you might accidentally re-create IRIW case out of these `taken1`, `taken2`, and a couple of other fields (see https://github.com/openjdk/jcstress/blob/df83b446f187ae0b0fa31fa54decb59db9e955da/tests-custom/src/main/java/org/openjdk/jcstress/tests/volatiles/VolatileIRIWTest.java )
>> 
>> In other words, `17.4.4. Synchronization Order` reads `A synchronization order is a total order over all of the synchronization actions of an execution`, while `A write to a volatile variable v (§8.3.1.4) synchronizes-with all subsequent reads of v by any thread`. That means, if you make `takenX` volatile, you might create new `synchronizes-with` edges thus forbidding program behaviors.
>> 
>> Of course, it might be the case that writes to `taken1` and `taken2` is **never** visible to the other threads (I doubt compilers would be able to do such proof soon), so to play safe, both cases needs to be verified: non-volatile `taken1,2` and making one of them volatile. However, if you keep only one case (e.g. only one implementation of Peterson's algorithm), I would vote for non-volatile `taken1/2`
>
> Ah thanks for that answer. I have not got such deep insights into the "secondary effects" of volatile.
> I have removed it from all 4 samples.
> Just another question: Is it theoretically possible that we get false positives without volatile?
> I mean taken1 and taken2 are updated by their actors but the other actor might not see it.
> Then both actors might enter the critical section at the same time without any actor noticing it in the results.
> Of course, I know there is no free lunch.

What about adding 
"In case you make taken1 and taken2 volatiles, you might accidentally re-create IRIW case out of these taken1, taken2, and a couple of other fields (see https://github.com/openjdk/jcstress/blob/df83b446f187ae0b0fa31fa54decb59db9e955da/tests-custom/src/main/java/org/openjdk/jcstress/tests/volatiles/VolatileIRIWTest.java )" as a comment into Mutex_01_NoAlgorithm? I guess many other users might wonder why taken1 and taken2 are not volatile?

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

PR: https://git.openjdk.java.net/jcstress/pull/85