On 13 April 2010 22:05, Chris Muller <asqueaker at gmail.com> wrote:
> 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"?
>

I think it means that scheduler having no guarantee that any given
preempted process within a same priority level
will be able to gain control within _any_ specified time period,
unless there are higher priority process,
which interrupts a currently running one.

>
>
> 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 -
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.