[erlang-questions] Changing scheduler behaviour to make tests less deterministic

Ulf Wiger ulf@REDACTED
Wed Dec 27 21:55:26 CET 2006


Den 2006-12-27 12:57:00 skrev Thomas Lindgren <thomasl_erlang@REDACTED>:

> --- Chris Newcombe <chris.newcombe@REDACTED> wrote:
>
>>
>> I'd prefer to introduce some more controlable
>> determinism, e.g. by changing the size of the
>> process quantum (the number of reductions it
>> is allowed execute before it is pre-empted).
>> Obviously we need to be careful to preserve
>> fairness, avoid thrash etc.

I was pretty sure that I had suggested a runtime-
configurable CONTEXT_REDS rather than a compile-
time setting, but I couldn't find it in the archives.

Having different settings per process seems like
a bad idea, esp given that erlang already has
'normal' and 'low' priority processes.


> Here are some other possibilities:
>
> If future proofing is not an issue, and it doesn't
> sound like it is, there is also the BIF
> bump_reductions(N). You could, in principle, insert
> conditional macroized calls to this to reschedule
> earlier by draining more reductions. (Combined with
> process_info to get the current number of reductions?)

One simpler way to change the interleaving is to insert
calls to yield() e.g. after each "->".


> Or you could record the trace of events with judicious
> use of the trace BIFs and capture/process the faulty
> ones. There is some scattered support for doing this
> here and there in the OTP distribution, I believe.
> That could be combined with your C code too,
> presumably.
>
> Another option might be to license QuickCheck :-)

QuickCheck has this problem too. It's very good at
shaking out timing bugs if the timeslice can be made
short enough.

BR,
Ulf W
-- 
Ulf Wiger



More information about the erlang-questions mailing list