Case 17373 had an erroneous failure from
ProcessTest>>testHighPriorityOverridesWaitTime
and several others seem also to have suffered...
* https://pharo.fogbugz.com/default.asp?17373
* https://pharo.fogbugz.com/default.asp?17496
* https://pharo.fogbugz.com/default.asp?17445
* https://pharo.fogbugz.com/default.asp?7444
These have comments that the problem can't be reproduced, which is
common of occasional race conditions. So rather than just try to
solve this on the issue tracker, I thought I'd share a tip how to
isolate and squash such intermittent failures, essentially by
stressing that single test a large number of times like this...
1 to: 100 do: [ :n | Transcript crShow: 'Try ' , n printString.
ProcessTest debug: #testHighPriorityOverridesWaitTime. ]
Since the debugger only focusses on a point in time snapshot of the
running system, some Transcript instrumentation was useful to overview
the dynamic behaviour, like this...
ProcessTest>>testHighPriorityOverridesWaitTime
| lowerPriorityWaitingLonger higherPriorityWaitingLess
nextReadyProcess |
lowerPriorityWaitingLonger := [ ] forkAt: 11
higherPriorityWaitingLess := [ ] forkAt: 12.
nextReadyProcess := Processor nextReadyProcess.
Transcript cr;
tab;show: (lowerPriorityWaitingLonger priority ->
lowerPriorityWaitingLonger identityHash); cr;
tab;show: (higherPriorityWaitingLess priority ->
higherPriorityWaitingLess identityHash); cr;
tab;show: (nextReadyProcess priority -> nextReadyProcess
identityHash).
self assert: nextReadyProcess equals: higherPriorityWaitingLess.
which produces...
Try 1
11->343137024
12->40659200
12->40659200
Try 2
11->461794304
12->374996992
12->40659200
Observe on the second try nextReadyProcess refers to same process as
from the first try. This can be cleaned up just prior to the asset
check by adding ...
lowerPriorityWaitingLonger terminate.
higherPriorityWaitingLess terminate.
which produces...
Try 1
11->1005688064
12->833273600
12->833273600
...
Try 100
11->764450816
12->807973888
12->807973888
However this is still a little fragile, since some process with
priority greater than the running test could slip in before the call
to nextReadyProcess, as can be seen by pushing the #to:do: loop out to
100000, which produces...
Try 32044
11->784361216
12->431928576
40->397533952
or wrapping it by [ ]forkAt:39, which produces...
Try 1
11->431897088
12->400972288
30->338363648
After several awkward failed attempts to fix this, it seemed best to
observe actual behaviour rather than peeking into the dynamic data
structures. Thus I propose...
ProcessTest>>testHighPriorityOverridesWaitTime
"The first process to resume will pass straight through the gate
while the other waits for the assert to whichRan."
| gate checkAssert priorityRan |
gate := Semaphore new signal.
checkAssert := Semaphore new.
[ gate wait. priorityRan := 11. checkAssert signal ] forkAt: 11.
[ gate wait. priorityRan := 12. checkAssert signal ] forkAt: 12.
checkAssert wait.
self assert: priorityRan=12 description: 'Second scheduled but
higher priority should run first'.
gate signal.
checkAssert wait.
self assert: whichRan=11 description: 'First scheduled but lower
priority should run after'.
https://pharo.fogbugz.com/default.asp?17501
