JCStress arbiter question

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

Hello all,

Retrying previous attempt to get opinion on the patch.

Best regards, Dmitry.

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

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

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