Difference between I_N and S_N in ReentrantRWLockMutexTests?

[Aleksey Shipilev]

Hi,

On 08/20/2018 06:36 AM, Adam Retter wrote:
> 1. I_N_State appears to construct and use a Non-fair
> ReentrantReadWriteLock.WriteLock.
> 2. S_N_State uses a reference to a previously declared static final
> Non-fair ReentrantReadWriteLock.WriteLock.
> 
> It would be useful to know what the "I_" and "S_" prefixes stood for?
> At a guess, I am thinking it could be "Instance" and "Static".

Yes.

> I am going out on a limb here, as I am no expert when it comes to the
> JMM, but could the difference in the instantiation of the locks be
> related to publication visibility of the
> ReentrantReadWriteLock.WriteLock object?

The thinking at the time I was writing the test was to put up ReentrantLock under the
constant-folding optimizations. Which is why S_ is really "static final", not only "static":
  https://shipilev.net/jvm-anatomy-park/15-just-in-time-constants/
  https://shipilev.net/jvm-anatomy-park/17-trust-nonstatic-final-fields/

> I was also wondering why there are no tests for shared access i.e.
> ReentrantReadWriteLock.ReadLock, and mixed access patterns where you
> want different threads performing read and write access, possibly also
> with lock downgrading?
> I noticed that there seem to be far more tests for StampedLock, which
> seem to test some of these further capabilities.

That is because no one bothered to write those tests for RRWL. Most of the tests for StampedLock got
in during the initial work on StampedLock, this is why it is better covered. There is a pending todo
item to make these tests properly autogenerated for most classes of locks.

-Aleksey