JCStress arbiter question
shade at redhat.com
Thu Aug 31 07:02:39 UTC 2017
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.
More information about the jcstress-dev