[squeak-dev] Are Squeak processes pre-emptive?

Chris Muller asqueaker at gmail.com
Tue Apr 13 19:05:03 UTC 2010


Hi, I'm not very well-versed in process-scheduling, but I'm having
trouble understanding why you don't like sending the last pre-empted
process to the back of its queue of processes waiting at that level.
Doesn't that seem more "fair" and also, allow "smoother" multi-tasking
since those other processes at that level would get a turn?

Your reason was:  "It means one cannot rely on cooperative scheduling
within a priority level."  but I don't understand what you mean by
"rely on"?



On Tue, Apr 13, 2010 at 12:24 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
> On Tue, Apr 13, 2010 at 9:53 AM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
>>
>> On 13.04.2010, at 18:46, Eliot Miranda wrote:
>>
>> On Tue, Apr 13, 2010 at 9:24 AM, Randal L. Schwartz
>> <merlyn at stonehenge.com> wrote:
>>>
>>> >>>>> "Ang" == Ang BeePeng <beepeng86 at yahoo.com> writes:
>>>
>>> Ang> Are Squeak processes pre-emptive? Are infinite loop processes safe
>>> Ang> to run?
>>>
>>> Squeak uses a simple priority scheme.
>>>
>>> A Squeak process runs until it yields or it is interrupted by a higher
>>> priority process event.  When it is interrupted, it goes to the back of
>>> the queue, so when the higher priority process pauses or completes,
>>> other processes at the same priority are likely to be run instead.
>>
>> IMO the sending of the preempted process to the back of the queue is a
>> bug.  It means one cannot rely on cooperative scheduling within a priority
>> level.  On the other hand, if the VM does not send the preempted process to
>> the back of the queue there is nothing to prevent a higher-priority process
>> altering the run queues of lower priority processes, achieving the same
>> thing.  But it is flexible if the scheduler code does it rather than the VM.
>>  One can imagine per-process priorities being examined so that by default a
>> process gets moved to the back of its run queue when preempted, but if a
>> process has a "don't preempt me" property it is not.
>>
>> My guess is this odd behavior was like an accidental round-robin scheduler
>> ... But changing it now might provoke rather obscure problems, no?
>
> That's certainly possible, but not the VisualWorks experience.  One can
> simply add a yield to allow other processes at the same priority level to
> run.  If there aren't any high-priroity processes running sporadically then
> one needs yields anyway.  So it is highly likely that in cases where the
> programmer wants to yield they have explicitly used a yield.  I think it
> much more likely that the current behaviour creates obscure problems because
> sometimes implicit yields occur and at other times they don't, depending on
> the state of finalization, whether delays are in progress or not, etc.
> But I agree it seems like a big change.  I just think it's a change for the
> better :)
> best
> Eliot
>>
>> - Bert -
>>
>>
>>
>>
>
>
>
>
>



More information about the Squeak-dev mailing list