Difference between I_N and S_N in ReentrantRWLockMutexTests?

[Adam Retter]

Thanks for the explanation Also set, things are now clearer

On Sun, 2 Sep 2018, 14:46 Aleksey Shipilev, <shade at redhat.com> wrote:

> 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
>
>