On Tue, Apr 13, 2010 at 12:05 PM, 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"?
>

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.

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.

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.

So having the VM not put processes to the back of the queue is generally
more useful and flexible.

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.

cheers
Eliot

>
>
>
> 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 -
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100413/499595f8/attachment.htm