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=2.1 required=5.0 tests=BAYES_05,INVALID_DATE,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!water!watmath!clyde!ima!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.ada
Subject: Re: Preemption and priorities
Message-ID: <15360@think.UUCP>
Date: 23 Jan 88 00:23:22 GMT
References: <8801221730.AA23176@cs.sei.cmu.edu>
Sender: usenet@think.UUCP
Reply-To: barmar@sauron.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
List-Id: <comp.lang.ada>

In article <8801221730.AA23176@cs.sei.cmu.edu> John.Goodenough@SEI.CMU.EDU writes:
>Expiration of a delay  means  a  task  is  eligible  for  execution.   If  an
>implementation  determines that a delay has expired for a high priority task,
>then that task must be scheduled for execution.

However, I think someone already pointed out that a delay only
specifies a minimum amount of time for the task to be suspended.  An
operative point in your response is "if an implementation determines
that a delay has expired".  It would presumably be legal for an
implementation to only check whether delays have expired when a task
makes an explicit entry call.  In fact, if the only requirement of a
delay is that the task suspend for at least that long, it would
probably be valid for an implementation to never detect that it has
expired; however, the standard should (if it doesn't already) specify
that delays should be checked at entry calls.
Barry Margolin
Thinking Machines Corp.

barmar@think.com
uunet!think!barmar