From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!GWUVM.BITNET!MFELDMAN
From: MFELDMAN@GWUVM.BITNET (Mike Feldman)
Newsgroups: comp.lang.ada
Subject: Susan Flynn's remarks about task priorities
Message-ID: <8801170549.AA03235@ajpo.sei.cmu.edu>
Date: 17 Jan 88 04:26:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
List-Id: <comp.lang.ada>

First let me express my joy and satisfaction at the high technical plane
of the list these days. Now to the issue: Flynn asserts that the Ada
standard requires a pre-emptive scheduler, implying that a running task
must be interrupted by a ready-to-run task of higher priority. I have
always been under the impression that a "run-until-blocked" model was
legal, that is, that a _running_ task was not required to be interrupted
by another (even of higher priority) that merely became _ready_. On a
uniprocessor, for example, is the scheduler required to _interrupt_
all running tasks and reschedule just because one task's delay has
expired? Indeed, it seems possible that we won't even know the delay
has expired until the currently running task "goes to sleep" for
some reason.

The ALRM (p. 9-16) is a bit vague here:

  If two tasks with different priorities are both _eligible for execution_
  (emphasis mine) could be sensibly executed using the same physical proc-
  essors and the same other processing resources, then it cannot be the case
  that the task with the lower priority is executing while the task with
  the higher priority is not.

The question: what does the ALRM mean by "eligible for execution"? At what
point do we determine that the higher-priority task is eligible? Suppose
a lower-priority task has had control of the CPU and no timeslicing is in
effect; suppose that task doesn't do anything to block itself; suppose the
higher priority task was waiting on a delay which expires. Now - does the
paragraph above require that we immediately discover the "eligibility to
run"? I have always understood the answer was "no" - that the decision is
allowed to be deferred until the next "synchronization point". At _that_
point surely the higher-priority task will be scheduled.

BTW - I have never seen a clearly-stated definition of the points at
which - at a minimum - rescheduling _must_ be done. Clearly there are
many possibilities, like expiration of a time slice, that are definitely
_not_ required (timeslicing isn't required at all). But where are the
points at which rescheduling _is_ required? The closest I have come to it
in the ALRM is p. 9-18, in the section on ABORT, of all places (sect 9.10,
paragraph 6, too long to copy here). But this seems like an obscure place
to bury such an important point. Robert Firth (or whoever) - can you
comment for us? Susan, how about you?