JCStress arbiter question

[Aleksey Shipilev]

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