[Vm-dev] ProcessTest>>testSchedulingIsFirstComeFirstServed
Ben Coman
btc at openinworld.com
Sun Jan 31 10:16:55 UTC 2016
My general understanding of process scheduling is that it is FIFO
within same priority. Indeed Pharo has a test for this
ProcessTest>>testSchedulingIsFirstComeFirstServed, which however I
thought was a bit fragile and I was looking to revise.
But now I'm curious whether same-priority-process FIFO scheduling is
an expected guarantee?
On both Pharo 5 build 50560 & Squeak 5 build 15113 the following test fails...
[ 1 to: 100000 do: [ :n |
| ranFirst ranSecond |
[ [ ranFirst ifNil: [ ranFirst := 1 ] ifNotNil: [ ranSecond
:= 1] ] forkAt: 78.
[ ranFirst ifNil: [ ranFirst := 2 ] ifNotNil: [ ranSecond
:= 2] ] forkAt: 78.
] forkAt: 79.
self assert: ranFirst=1.
self assert: ranSecond=2. ]
] fork.
... but only after 20k iterations, which seems an "almost" guarantee.
Interestingly, it doesn't fail when run without the outer fork.
Also if I take an alternate approach with less message calls...
faults := OrderedCollection new.
done := Semaphore new.
[ 1 to: 10000000 do: [ :n | | ranFirst ranSecond |
[ [ ranFirst ifNil: [ ranFirst := 1 ] ifNotNil: [ ranSecond
:= 1] ] forkAt: 78.
[ ranFirst ifNil: [ ranFirst := 2 ] ifNotNil: [ ranSecond
:= 2] ] forkAt: 78.
] forkAt: 79.
(ranFirst=1 and: ranSecond=2) ifFalse: [ faults add: { n .
ranFirst . ranSecond } ].
].
done signal.
] fork.
done wait.
faults inspect.
I only get seven failures in 10 million iterations.
"an OrderedCollection(
#( 258535 2 1)
#(1148605 2 1)
#(3502820 2 1)
#(4010935 2 1)
#(4533713 2 1)
#(6301878 2 1)
#(8497001 2 1))"
So what I'm wondering is if there is a bug to hunt down, or if FIFO
scheduling is simply not an expected guarantee?
cheers -ben
More information about the Vm-dev
mailing list