JCStress arbiter question

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

Hello Aleksey,

Tests are green with the patch.

Do you think it will do for a PoC of contribution or this behavior can be
modelled in some other way?

Best regards, Dmitry.

I

2017-09-09 23:38 GMT+03:00 Семухин Дмитрий <asympro at gmail.com>:

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