Hi,
In my understanding, Smalltalk processes are non-preemptive if their priorities are the same.
But when I tried this code in Squeak ("print it"),
--- aStream := WriteStream on: (String new: 200). aSemaphore := Semaphore new. aBlockClosure := [:argument | 0 to: 9 do: [:n | aStream nextPutAll: argument. aStream nextPutAll: '('. aStream nextPutAll: n printString. aStream nextPutAll: ')'. aStream nextPutAll: ' '. 1000 timesRepeat: [100 factorial]. ]. aSemaphore signal]. aBlockClosure2 := [:argument2 | 0 to: 9 do: [:n2 | aStream nextPutAll: argument2. aStream nextPutAll: '('. aStream nextPutAll: n2 printString. aStream nextPutAll: ')'. aStream nextPutAll: ' '. 100 timesRepeat: [100 factorial]. ]. aSemaphore signal]. aBlockClosure3 := [:argument3 | 0 to: 9 do: [:n3 | aStream nextPutAll: argument3. aStream nextPutAll: '('. aStream nextPutAll: n3 printString. aStream nextPutAll: ')'. aStream nextPutAll: ' '. 10 timesRepeat: [100 factorial]. ]. aSemaphore signal]. aStream nextPutAll: 'Black'; nextPutAll: ' '. [aBlockClosure value: 'Red'] fork. [aBlockClosure2 value: 'Green'] fork. [aBlockClosure3 value: 'Blue'] fork. aStream nextPutAll: 'White'; nextPutAll: ' '. 3 timesRepeat: [aSemaphore wait]. aStream contents
---
The result was funny to me:
'Black White Red(0) Red(1) Red(2) Green(0) Green(1) Green(2) Green(3) Green(4) Green(5) Green(6) Green(7) Green(8) Green(9) Blue(0) Blue(1) Blue(2) Blue(3) Blue(4) Blue(5) Blue(6) Blue(7) Blue(8) Blue(9) Red(3) Red(4) Red(5) Red(6) Red(7) Red(8) Red(9) '
(Change the 'xxx timesRepeat:' value. You can get various results).
Are there implicit yields in Squeak?
In, VW and Dolphin, I can get the expected results:
'Black White Red(0) Red(1) Red(2) Red(3) Red(4) Red(5) Red(6) Red(7) Red(8) Red(9) Green(0) Green(1) Green(2) Green(3) Green(4) Green(5) Green(6) Green(7) Green(8) Green(9) Blue(0) Blue(1) Blue(2) Blue(3) Blue(4) Blue(5) Blue(6) Blue(7) Blue(8) Blue(9) '
I've tested it in Squeak 3.6 & 3.7b in Windows.
Cheers, --- [:masashi | ^umezawa]
In my understanding, Smalltalk processes are non-preemptive if their priorities are the same.
[...]
Are there implicit yields in Squeak?
Yes. While it is true that Squeak's processes are non-preemptive if they run at the same priority their behavior is somewhat out of the ordinary when they get preempted by a higher priority process. Rather than being added as the first process in the priority group (which would give you the expected behavior) it is added as the last process thereby implicitly yielding to the next process in this priority group.
Cheers, - Andreas
"Andreas Raab" andreas.raab@gmx.de wrote:
In my understanding, Smalltalk processes are non-preemptive if their priorities are the same.
[...]
Are there implicit yields in Squeak?
Yes. While it is true that Squeak's processes are non-preemptive if they run at the same priority their behavior is somewhat out of the ordinary when they get preempted by a higher priority process. Rather than being added as the first process in the priority group (which would give you the expected behavior) it is added as the last process thereby implicitly yielding to the next process in this priority group.
There's a simple choice that has to be made when suspending Processes; add to the front of the priority queue or the back? To the best of my recollection the Blue Book specified 'back' and that's what Squeak does. VW changed to use 'front' quite a few years ago on the grounds that it would do what you are expecting. I really don't know what the 'proper' answer is; one way makes a process run until it completes and the other allows a sort of 'fair shake' for all the processes at a priority. We could easily change Squeak (especially now we have the primitiveYield) but as to what is correct.... <shrug>.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim M$ are grinning pigs in a sea of buggy code - The Inquirer
Hi,
There's a simple choice that has to be made when suspending Processes; add to the front of the priority queue or the back? To the best of my recollection the Blue Book specified 'back' and that's what Squeak does. VW changed to use 'front' quite a few years ago on the grounds that it would do what you are expecting. I really don't know what the 'proper' answer is; one way makes a process run until it completes and the other allows a sort of 'fair shake' for all the processes at a priority. We could easily change Squeak (especially now we have the primitiveYield) but as to what is correct.... <shrug>.
Thanks. Now I understand there are two parties in this field.
Maybe ANSI Smalltalk should have touched this topic.
Cheers, --- [:masashi | ^umezawa]
Hi,
Mon, 26 Apr 2004 18:01:56 +0200 "Andreas Raab" andreas.raab@gmx.de wrote:
In my understanding, Smalltalk processes are non-preemptive if their priorities are the same.
[...]
Are there implicit yields in Squeak?
Yes. While it is true that Squeak's processes are non-preemptive if they run at the same priority their behavior is somewhat out of the ordinary when they get preempted by a higher priority process. Rather than being added as the first process in the priority group (which would give you the expected behavior) it is added as the last process thereby implicitly yielding to the next process in this priority group.
Aha-. Now I see the results. Thanks!
So, is it intentional? I'm not sure what is the merit. Wouldn't it make the squeak code non-portable?
Cheers, --- [:masashi | ^umezawa]
Masashi Umezawa umejava@mars.dti.ne.jp wrote:
Aha-. Now I see the results. Thanks!
So, is it intentional? I'm not sure what is the merit. Wouldn't it make the squeak code non-portable?
It sounds like would make it non-portable with some Smalltalks and portable with others. So we can do what seems right.
IMHO, the processes should go to the beginning of the queue. That way we have a coherent implementation of at least *one* strategy: namely, processes finish what they are doing before they yield. With the current state (which I admit surprises me to read about!), you neither get fair sharing of the CPU nor do you get a guarantee that your process will finish its current chunk of work.
An alternative choice would be to go whole hog and have preemptive switching. I don't know which way is better, but I know there have been times that I wanted preemption, and I know that I have never yet taken advantage of non-preemption. I would even suggest that preemption across priority levels would be useful; or at least, I would like to have groups of preemptive processes where some processes have higher priority than others.
-Lex
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Lex Spoon -
Masashi Umezawa -
Tim Rowledge