On Feb 20, 2007, at 11:05 , Michael Davies wrote:
George,
You'll find that writing to the Transcript always slows things down. I assume it's the time for writing to the Transcript that also causes the second process to start after a different interval each time.
Besides, it interferes with processes because it has a Mutex nowadays. Which is good, but it distorts what you would observe without the Transcript involved.
Writing the results into an OrderedCollection will be much faster, and more predictable:
a := OrderedCollection new. [10 timesRepeat: [a addLast: '2'. (Delay forMilliseconds: 1) wait]] fork. [10 timesRepeat: [a addLast: '1'. (Delay forMilliseconds: 1) wait]] fork. a inspect.
consistently gives 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1.
This is because waiting on Delay (or, rather on the Semaphore inside) causes the current process to block, and the next process on the same priority to run. The same could be achieved by "Processor yield" instead of waiting on the Delay. This is "cooperative". Or, you could have a higher-priority scheduler that time-slices the lower-priority ones by suspending them in turn, which does not need cooperation.
Without the delay:
a := OrderedCollection new. [10 timesRepeat: [a addLast: '2']] fork. [10 timesRepeat: [a addLast: '1']] fork. a inspect.
consistently gives 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1.
These processes are too short-lived to ever get interrupted by a higher priority process. So the first one runs to completion, then the second one. Try this instead:
a := String new writeStream. p1 := [[a nextPut: $1] repeat] forkAt: Processor userBackgroundPriority. p2 := [[a nextPut: $2] repeat] forkAt: Processor userBackgroundPriority. 10 timesRepeat: [(Delay forMilliseconds: 1) wait]. p1 terminate. p2 terminate. a contents
This puts the two processes into a lower priority than the UI process. We then stop the UI process 10 times for one millisecond - this is our scheduler. Each time, the next lower-priority process is given time to run - that is the default scheduling behavior. The result are nicely alternating runs of ones and twos as you would expect: '111111111122222222222111111111111122222222222...'
- Bert -