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!rutgers!ucla-cs!cit-vax!elroy!ames!umd5!brl-adm!husc6!bbn!inmet!ishmael!inmet!ada-uts!stt
From: stt@ada-uts
Newsgroups: comp.lang.ada
Subject: Re: M. Feldman's questions on prioritie
Message-ID: <57900062@ada-uts>
Date: 17 Feb 88 17:04:00 GMT
References: <94857@<021688>
Nf-ID: #R:<021688:-9485700:ada-uts:57900062:000:1229
Nf-From: ada-uts!stt    Feb 17 12:04:00 1988
List-Id: <comp.lang.ada>


Preemption is not required to implement the delay, even
when multiple priorities are supported, because...
"The execution of a delay statement ... suspends further execution of the
task ... for *at least* the duration specified..." (LRM 9.6:1).

The "at least" part allows the delay statement to result in a delay
until the next "natural" scheduling point following its
expiration.  I certainly agree that this defeats the usual
purpose for delay, and the LRM should have made statements
indicating that the implementation must preempt at the first
possible time after expiration, but alas, it didn't, and so
implementations need not support preemption.

Note however that multi-processor implementations
must support preemption for another reason -- namely that
a high priority task on one processor may start a middle priority
task, and if some other processor is at that time running
a lower priority task, it must be preempted (presuming
that the new task can "sensibly be executed using the same physical
processor" (LRM 9.8:4).  Of course "sensibly" is not well defined,
and so this preemption requirement might also be avoided by appropriate
definition gymnastics.

Tucker Taft
c/o Intermetrics, Inc.
Cambridge, MA  02138