On Sunday 17 April 2005 10:50 am, Ramiro Diaz Trepat wrote:
> But why did that guy have to write those Processor yields in that code
> snippet to get it filled unsequentially (not '11111...22222222' ) on
> two equal processes forked trying to insert the numbers in the same
> shared queue ?

Because that's the way that Squeak processes work.

Just because his expectation of how the processes *should* fill the queue did 
not match the way they *did* fill the queue does not mean that there's a bug.

It just means there is a mismatch between his expectations and reality.

This could easily be a problem with the documentation, or it could just be 
that his expectations were based on experience with some other threading 
model that worked differently.

As has been noted before, if he were to do this prior to running his two 
forked processes to fill the queue, he'd have the expected behavior (assuming 
that the queue-filling processes were started at a priority below Processor 
userInterruptPriority). (Warning: untested code!)

[ | d | d := Delay forMilliseconds: 1.
 [ d wait ] repeat ] forkAt: Processor userInterruptPriority.

The way this works is this: every time the higher-priority process wakes back 
up (which it will do more or less every millisecond), it will preempt any 
lower-priority process that is running at that time. And that process will be 
put at the back of its priority's queue, so when the higher-priority process 
goes back to sleep, the next queue-filling process will have a chance to run 
for a millisecond.

I suppose you could also do:

 [ [ Processor yield ] repeat ] forkAt: Processor userInterruptPriority

if you really wanted to stir things up more (but this would eat more CPU time 
in the higher-priority process).

-- 
Ned Konz
http://bike-nomad.com/squeak/