JCStress arbiter question

[Семухин Дмитрий]

Hi Aleksey,

Many thanks for the answer!

> "All memory effects from {@link Actor}s are visible in Arbiter"

Yes, my bad.

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

Thought so.

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

In mean of JMM - yes. If only there would have been a trickier way to just
trigger cache update for 1 variable(boolean stop flag) without all the
happens-before guarantees to see the artifacts of wrong multi-threaded
approaches(wishful thinking:)).

>If you want something that runs concurrently with @Actor-s, then it should
be @Actor itself

Then I cannot guarantee that it happens after the actors.

The only thing I happened to think of is one of the samples -
Actor-Signal-Termination approach(signal mutates the variable, actor is
busy-spin waiting on it). The only problem is that there is a restriction
of only 1 signal.

Therefore I have these questions:

1)Is it viable to have a feature of multiple signals?
2)If the answer to (1) is yes, then how/when/who will do it?
3)If the answer to (2) is no - I ran out of ideas on how to simulate this
behavior on JCStress. Do you have any ideas?

Best regards, Dmitry.

2017-07-07 15:22 GMT+02:00 Aleksey Shipilev <shade at redhat.com>:

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