ProcessTest>>testHighPriorityOverridesWaitTime intermittent failures

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