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 at best.com>, Pete Cockerell <petec at 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