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(a)best.com>, Pete Cockerell <petec(a)best.com>
| 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
| > 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,
| 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?