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!ames!pasteur!ucbvax!MITRE-BEDFORD.ARPA!eachus
From: eachus@MITRE-BEDFORD.ARPA
Newsgroups: comp.lang.ada
Subject: Re: ..for at least the duration specified...
Message-ID: <8801281558.AA22014@mitre-bedford.ARPA>
Date: 28 Jan 88 15:58:35 GMT
References: <8801280924.AA11782@mitre-bedford.ARPA>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>


     I had hoped that this boogy man had been laid to rest.  But some
people in the waiver community still use this argument as an attempted
justification for not using Ada.  These words were not put there to
allow implementors to impose unreasonable delays.
The intention  of this    paragraph  {9.6(1)} is to  insure  that
implementations are not allowed to  terminate a delay before the delay
expires.  Other rules (and some latitude allowed to an implementation)
determine when a task resumes execution.  

     When the delayed task become eligible  to run, if its priority is
higher than  some task   that  is  executing,  then  paragraph  9.8(4)
requires that a lower priority task be preempted.  It does not require
that the higher priority task execute, since an  interrupt could occur
or another high priority task could become eligible to  run during the
task switching  process.   The rules  also  allow  for  multiprocessor
implementations,    and the     phrase "...could sensibly  be executed
using..."  is to allow  for  distributed  and   heterogenous processor
systems.  Paragraph 9.8(5) deals with  the cases where the running and
newly eligible tasks have the same  priority, or one  or both tasks do
not have  defined priorities, and   specifies that  a   rendezvous  is
executed at the higher of the priorities of the tasks involved.

     The  intent of all  this  was  to  require  preemtive scheduling.
Since  the rules  intentionally do  not specify what happens  when two
tasks of equal priority  are eligible to  run, or  the delay statement
can occur in  a low priority task, it  is expected that there will  be
times  when  a task is  delayed  for longer than the  specified delay.
(There is  also another tricky  little case which  implementations are
starting  to get  right.  Due  to  granularity of representation it is
necessary to add one tick to the computed delay.)

     The rules do allow  implementations to restrict the  range of the
subtype priority and  implement some other  form of  scheduler. If the
actual hardware does not provide  a clock, an Ada implementation could
be validated where all tasks have the same priority, and the effect of
a delay statement is  to suspend  the  task indefinitely.  (I can just
imagine the message "Please signal  when three miniutes have elapsed."
appearing   on the  user's    terminal.)   It would,  of   course,  be
inappropriate to choose such   hardware for a  system   which required
timed delays.

     Where  operating  systems  (read  Unix  and MS-DOS)   suspend the
executing process while waiting for input from the  terminal,  a valid
implementation of the  Ada IO packages will  create a separate process
to do this  waiting.  The ACVC tests do  not currently test for  this,
but that does not make such an implementation  valid.  There is always
the possibility of an AI-325 argument for  some hardware  or operating
system, but for MS-DOS and Unix, I know it is possible to do it right.


					Robert I. Eachus