Posted to thread in comp.lang.smalltalk:
[the thread is discussing the Smalltalk scheduling model, where processes of the same priority are scheduled cooperatively, while higher-priority processes preempt lower-priority processes. Eliot points out that if a higher-priority preemption caused the preempted process to be added to the back of its priority queue instead of the front, then this is an implicit yield which can break the cooperative scheduling model]
In article 35C00BEA.7BA02C3D@best.com, Pete Cockerell petec@best.com wrote:
| Eliot & Linda wrote: | >[Blue book/VSE task switching bug] | | Still, at least ST has a standard process model, arf arf... | | > I don't know what happens in VisualAge, Dolphin, Smalltalk MT, et al. | > Can anyone say what happens?
Squeak, not surprisingly, follows the Blue Book and causes an implicit yield.
| > Any other implementors agree/disagree that | > the blue book spec's implicit yield on preemption is a bug? | | Not speaking as an implementor, I would say it strikes me as anomolous, to | say the least. It breaks the model of equal-priority processes not being | pre-empted by their 'siblings', albeit indirectly.
I tend to agree with Eliot. The benefit of the cooperative model is that one can know and control exactly at what points yields to same-priority processes occur, so explicit exclusion code can be avoided in many cases. With higher-priority processes causing an implicit yield, this breaks.
Also, if an implicit yield is desired, it could be coded in the higher-priority process by explicitly manipulating the process queues. The converse isn't true; the higher-priority process has no knowledge of which lower-priority process was preempted, so it doesn't know which priority queue to manipulate.
I don't know, however, what might break if Squeak were to put preempted processes at the front of their queue instead of the back. Any Squeak VM hackers want to try this?
-- tim