JCStress arbiter question

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

Hello Aleksey,

What I meant was this:

@JCStressTest(Mode.Termination)
@Outcome(id = "TERMINATED", expect = Expect.ACCEPTABLE, desc = "1 XOR 2
observed")
@Outcome(id = "STALE", expect = Expect.ACCEPTABLE_INTERESTING, desc = "0
observed")
@State
public class TwoIncrementsAndZeroObserved {

    int v;

    @Actor
    public void actor1() {
        while (v == 0) {
            // spin
        }
    }

    @Signal
    public void signal1() {
        v++;
    }

    @Signal
    public void signal2() {
        v++;
    }

Attached patch to actual Hg codebase of jcstress as a proof of concept.

2017-08-31 10:02 GMT+03:00 Aleksey Shipilev <shade at redhat.com>:

> On 08/30/2017 12:59 PM, Семухин Дмитрий wrote:
> >>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.
>
> I am going to repeat my answer verbatim:
>
> 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.
>
>
> > 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.
> It does not help in this case, I think. You have to spell what you want in
> code to see if it even
> works in theory.
>
> -Aleksey
>
>