JCStress arbiter question

[Aleksey Shipilev]

On 06/20/2017 07:05 PM, Семухин Дмитрий wrote:
> @JCStressTest
> @Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "Both
> results not visible")
> @Outcome(id = "1", expect = Expect.ACCEPTABLE_INTERESTING, desc = "Single
> result only visible")
> @Outcome(id = "2", expect = Expect.ACCEPTABLE, desc = "Normal outcome")
> @State
> public class UnsafeCountingFactorizerTest {
>     private UnsafeCountingFactorizer toTest = new
> UnsafeCountingFactorizer();
> 
>     @Actor
>     public void actor1() {
>         toTest.service();
>     }
> 
>     @Actor
>     public void actor2() {
>         toTest.service();
>     }
> 
>     @Arbiter
>     public void arbiter(J_Result r) {
>         r.r1 = toTest.getCount();
>     }
> 
>     public class UnsafeCountingFactorizer  {
>         private long count = 0;
> 
>         public long getCount() {
>             return count;
>         }
> 
>         public void service() {
>             count++;
>         }
>     }
> }
> 
> Test results are only outcome=1 and outcome=2 but outcome=0 is valid in
> JMM. Therefore I had a theory that threads are being reused during test
> operatins which has a chance for us not to see outcome=0. I decided to
> write this test:

Except that @Arbiter is specified as "All memory effects from {@link Actor}s are
visible in Arbiter". Which means outcome=0 is forbidden, because it will pick up
the state from one of the actors.


> Obviously it failed with forbidden outcome but I noticed the only 2 classes
> of outcome are x,y,x and x,y,y. This is one of the evidences that arbiter
> logic is executed in one of the threads already used by actors.

Yes, @Arbiter is executed by one of the @Actor threads. This is mostly done as
runtime optimization.

> 1)Am I doing something totally wrong?

Not really, but you think @Arbiter is weaker than it really is.

> 2)Was such behaviour encountered before?

See above.

> 3)If not - should I implement this or any other solution you can think of?

There seem to be contradictory goals here: make @Arbiter observe actor-set state
via the race, and make it happen after both actors.

The mechanics of getting @Arbiter to happen after the actors would preclude
races (mostly), be it running in the same thread, using a Thread.join, using
volatile vars to synchronize the access, etc. If you want something that runs
concurrently with @Actor-s, then it should be @Actor itself. Just running
@Arbiter in a separate thread would not help to get new behaviors.

Thanks,
-Aleksey