<br><br><div class="gmail_quote">On Tue, Apr 13, 2010 at 12:05 PM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi, I'm not very well-versed in process-scheduling, but I'm having<br>
trouble understanding why you don't like sending the last pre-empted<br>
process to the back of its queue of processes waiting at that level.<br>
Doesn't that seem more "fair" and also, allow "smoother" multi-tasking<br>
since those other processes at that level would get a turn?<br>
<br>
Your reason was: "It means one cannot rely on cooperative scheduling<br>
within a priority level." but I don't understand what you mean by<br>
"rely on"?<br></blockquote><div><br></div><div>A cooperative scheduler is one in which it is guaranteed that another process does not run until the active process chooses to yield. This makes it easy to implement particular forms of synchronisation because processes are not preemptive. The Smalltalk scheduler is a form of real-time scheduler in which processes have fixed priorities and are only preempted by higher-priroity processes. This also makes it easy to implement various kinds of multi-process behaviour because one is guaranteed that a lower-priority process is never running while a higher priority process is able to run.</div>
<div><br></div><div>If one arranges that the scheduler does not put processes to the back of the run queue on preemption then within a priority level scheduling is cooperative and those simple synchronisation algorithms can still function when used by processes within the same priority.</div>
<div><br></div><div>One can still implement moving to the back of the queue on preemption with Smalltalk code if the VM does not, but one cannot prevent being put to the back if the VM does.</div><div><br></div><div>So having the VM not put processes to the back of the queue is generally more useful and flexible.</div>
<div><br></div><div>Your point about fairness is an important one, but being put to the back of the run queue on preemption does not in any way guarantee fairness. Consider examples where some lower-priority process needs to kick a higher-priority process briefly, but the lower-priority process is contending with other lower-priroity processes. The lower-priroity kicker can't avoid giving up the processor to the other contending processes and so the result could be unfairness. Fairness is going to have to be defined in some context and a policy implemented to maintain that regime. merely having the VM scheduler force an implicit yield on preemption is not enough to implement fairness.</div>
<div><br></div><div>cheers</div><div>Eliot</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
<br>
<br>
On Tue, Apr 13, 2010 at 12:24 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
><br>
> On Tue, Apr 13, 2010 at 9:53 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>><br>
> wrote:<br>
>><br>
>> On 13.04.2010, at 18:46, Eliot Miranda wrote:<br>
>><br>
>> On Tue, Apr 13, 2010 at 9:24 AM, Randal L. Schwartz<br>
>> <<a href="mailto:merlyn@stonehenge.com">merlyn@stonehenge.com</a>> wrote:<br>
>>><br>
>>> >>>>> "Ang" == Ang BeePeng <<a href="mailto:beepeng86@yahoo.com">beepeng86@yahoo.com</a>> writes:<br>
>>><br>
>>> Ang> Are Squeak processes pre-emptive? Are infinite loop processes safe<br>
>>> Ang> to run?<br>
>>><br>
>>> Squeak uses a simple priority scheme.<br>
>>><br>
>>> A Squeak process runs until it yields or it is interrupted by a higher<br>
>>> priority process event. When it is interrupted, it goes to the back of<br>
>>> the queue, so when the higher priority process pauses or completes,<br>
>>> other processes at the same priority are likely to be run instead.<br>
>><br>
>> IMO the sending of the preempted process to the back of the queue is a<br>
>> bug. It means one cannot rely on cooperative scheduling within a priority<br>
>> level. On the other hand, if the VM does not send the preempted process to<br>
>> the back of the queue there is nothing to prevent a higher-priority process<br>
>> altering the run queues of lower priority processes, achieving the same<br>
>> thing. But it is flexible if the scheduler code does it rather than the VM.<br>
>> One can imagine per-process priorities being examined so that by default a<br>
>> process gets moved to the back of its run queue when preempted, but if a<br>
>> process has a "don't preempt me" property it is not.<br>
>><br>
>> My guess is this odd behavior was like an accidental round-robin scheduler<br>
>> ... But changing it now might provoke rather obscure problems, no?<br>
><br>
> That's certainly possible, but not the VisualWorks experience. One can<br>
> simply add a yield to allow other processes at the same priority level to<br>
> run. If there aren't any high-priroity processes running sporadically then<br>
> one needs yields anyway. So it is highly likely that in cases where the<br>
> programmer wants to yield they have explicitly used a yield. I think it<br>
> much more likely that the current behaviour creates obscure problems because<br>
> sometimes implicit yields occur and at other times they don't, depending on<br>
> the state of finalization, whether delays are in progress or not, etc.<br>
> But I agree it seems like a big change. I just think it's a change for the<br>
> better :)<br>
> best<br>
> Eliot<br>
>><br>
>> - Bert -<br>
>><br>
>><br>
>><br>
>><br>
><br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br>