How to test lock mode compatibility?

[Adam Retter]

Apologies for the name misspelling. Obviously it is Aleksey
On Tue, 9 Oct 2018 at 19:28, Adam Retter <adam.retter at googlemail.com> wrote:
>
> Alexsey,
>
> Yes!
>
> As I didn't get much response here I eventually cross-posted to StackOverflow, where actually we discovered this through some help from "teppic" on StackOverflow - https://stackoverflow.com/questions/52502306/confused-by-jcstress-test-on-reentrantreadwritelocktrylock-failing/52583870?noredirect=1#comment92168301_52583870
>
> I guess I cannot say if this is a bug in jcstress or expected behaviour. That would be down to you ;-)
> On Tue, 9 Oct 2018 at 19:25, Aleksey Shipilev <shade at redhat.com> wrote:
> >
> > On 08/31/2018 08:12 PM, Adam Retter wrote:
> > > Hmm, before I understand how to test with #lock(), it seems I am still
> > > far from understanding JCStress or the JMM correctly. I just realised
> > > that my ReentrantReadWriteLockBooleanCompatibilityTest actually fails
> > > on JCStress.
> > >
> > > The following test fails:
> > >
> > > @JCStressTest
> > > @Outcome(id = "true, false", expect = Expect.ACCEPTABLE, desc = "T1
> > > acquired X, and T2 could not acquire X")
> > > @Outcome(id = "false, true", expect = Expect.ACCEPTABLE, desc = "T2
> > > acquired X and T1 could not acquire X")
> > > public static class X_X {
> > >     @Actor
> > >     public void actor1(S s, ZZ_Result r) { r.r1 = s.exclusive(); }
> > >     @Actor
> > >     public void actor2(S s, ZZ_Result r) { r.r2 = s.exclusive(); }
> > > }
> > >
> > > It reports, Observed forbidden state: true, true.
> >
> > This looks like a bug -- actors are executed by the same thread, probably during initial sanity
> > checks, hm.
> >
> > -Aleksey
> >
> >
>
>
> --
> Adam Retter
>
> skype: adam.retter
> tweet: adamretter
> http://www.adamretter.org.uk



-- 
Adam Retter

skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk