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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,1356f4179c1e4ef4
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: ADA task
Date: 1996/09/16
Message-ID: <EACHUS.96Sep16142455@spectre.mitre.org>#1/1
X-Deja-AN: 180943831
references: <5174qu$o1p@nr1.ottawa.istar.net>
 <51cjp0$q7k@watnews1.watson.ibm.com>
organization: The Mitre Corp., Bedford, MA.
newsgroups: comp.lang.ada
Date: 1996-09-16T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <323A1FF2.2781@gsde.hso.link.com> "Samuel T. Harris" <u61783@gsde.hso.link.com> writes:

  > Unfortunately, Ada 83 semantics specify only that the delay
  > will be at least as long as the delay. It can be more then
  > the delay (possible much more). It depends on the fidelity
  > of the runtime system, the desired frequency, and the load
  > caused by other tasks.

    Yes, it depends on a lot of things, including those, and whether
or not all available resouces are being used by higher priority tasks,
and whether the processor is halted and restarted in between, etc.

    But the propensity of real-time developers to fixate on 9.6(1) and
to ignore both the remainder of 9.6 and all of 9.8 has always amazed
me.  To refresh your memory 9.8(4) says:

    "If two tasks with different priorities are both eligible for
execution, and could sensibly be executed using the same physical
processors 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."

    So, yes, 9.8(4) specifies cases when a task does not immediately
resume after a delay.  But it also specifies that if the expiration of
a delay makes a task the highest priority eligible task, then it will
execute immediately.  (Assuming that there is at least one processor
available to the program.  For real-time programs this will be the
case, but an Ada program on a time-sharing computer may be preempted
by some other--higher system, not Ada, priority--program, including
the OS itself.)

     Now it can also be the case that there is NO sufficiently
accurate hardware clock available.  But, 9.6(4) requires a (real-time)
clock interval of at most 20 milliseconds, and "whenever possible, a
value not greater than 50 microseconds..."  So if the implementation
supports several clocks, the one used for delay must be chose to be
the most accurate one, unless there are two with accuracies of less
than 50 microseconds.  This paragraph is not there to prevent you from
running Ada programs on computers without real-time clocks.  It is
there to insist that the best clocks available should be used by the
Ada run-time.

    Yes, this is a hot-button of mine.  When it was written, the
requirements of Ada 83 were the most stringent real-time requirements
in any language or operating system standard.  And, in my opinion, it
is still the tightest.  Ada 95 is more lenient in some areas to help
support real-time applications, but it also has some additional
documentation requirements in Annex D.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...