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

[Vladimir Sitnikov]

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

>> jcstress-samples/src/main/java/org/openjdk/jcstress/samples/concurreny/mutex/Mutex_02_PetersonAlgorithm.java line 56:
>> 
>>> 54:     private final AtomicBoolean flagForActor2 = new AtomicBoolean();
>>> 55:     private final AtomicInteger turn = new AtomicInteger();
>>> 56:     private volatile boolean taken1, taken2;
>> 
>> `flagForActor1`, `flagForActor2`, and `turn` should be volatiles, taken1 and taken2 should be regular fields.
>
> Can you explain me why taken1 and taken2 must not be volatile?
> I mean actor1 and actor2 run in different threads, don't they?
> If so, actor1 won't see the current value of taken2 when actor2 changes taken2 or am I wrong?

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.

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

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