ADA task

ADA task

[Roumen Roupski]

Hi

I am new in ADA programming and I use GNAT Ada version 3.04a for Windows
NT.  I have got couple of questions about "tasking" in ADA.

1. How can I implement a task running at regular intervals, for example
every 50ms +/- 5ms. The task activation must be guaranteed too.

2. What is overhead of running an ADA task, memory usage, task creation
time, and task-switching overhead? Is there any practical limit for maximum
number of simultaneously running tasks?

Regards,
Roumen Roupski

Pika Technologies Inc.
Roumen.Roupski@Pika.Ca

Re: ADA task

[Philip Brashear]

In article <5174qu$o1p@nr1.ottawa.istar.net>,
Roumen Roupski <Roumen.Roupski

>2. What is overhead of running an ADA task, memory usage, task creation
>time, and task-switching overhead? Is there any practical limit for maximum
>number of simultaneously running tasks?


Answers to this sort of question are completely dependent on the compiler,
hardware, OS, etc. (the "implementation").

The best measuring device available for general use is the Ada Compiler
Evaluation System (ACES), freely available via anonymous FTP at
sw-eng.falls-church.va.us, directory public/AdaIC/testing/aces
or by WWW at
http://sw-eng.falls-church.va.us/AdaIC/testing/aces/

My group can provide consultation and ACES-related services, if desired.

Sincerely,
Phil Brashear
CTA INCORPORATED
5100 Springfield Pike, Suite 100
Dayton, OH  45431
(513) 258-0831
brashear.cta@juno.com
brashear@sw-eng.falls-church.va.us

Re: ADA task

[Norman H. Cohen]

In article <5174qu$o1p@nr1.ottawa.istar.net>, "Roumen Roupski"
<Roumen.Roupski@Pika.Ca> writes: 

|> 1. How can I implement a task running at regular intervals, for example
|> every 50ms +/- 5ms. The task activation must be guaranteed too.

By a "task", you seem to mean a piece of code to do certain work one
time. At regular intervals, the task is "run" to accomplish this work.

In Ada, a "task" is a thread of control, and the typical approach to
periodic processing is for this thread to remain in existence throughout
the program, executing a loop in which it spends most of its time
sleeping (thus not consuming CPU) and wakes up at the right times to do
its work: 

   task Cyclic_Processor;

   task body Cyclic_Processor is
      Next_Wakeup : Calendar.Time := Calendar.Clock;
      Interval    : constant Duration := 0.050;
   begin
      loop
         delay until Next_Wakeup;
         Do_Some_Work;
         Next_Wakeup := Next_Wakeup + Interval;
      end loop;
   end Cyclic_Processor;

The "delay until" statement is a new feature in Ada 95.  In Ada 83 you
would write

   delay Next_Wakeup - Calendar.Clock;

which delays for the specified amount of time (in this case, the time
from now until Next_Wakeup).

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: ADA task

[Samuel T. Harris]

Norman H. Cohen wrote:
> ...
          delay until Next_Wakeup;
> ...
> 
> The "delay until" statement is a new feature in Ada 95.  In Ada 83 you
> would write

Yes, this is a very nice addition to Ada 95, especially for us
simulation folks.

> 
>    delay Next_Wakeup - Calendar.Clock;
> 
> which delays for the specified amount of time (in this case, the time
> from now until Next_Wakeup).

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.

An alternative is to use passive tasks with wakeup entries
and tie a master task to a realtime clock interrupt.
The master task then rendevous with the passive tasks.
If all tasks are harmonic, then the least common multiple
frequency is used and a simple clock pulse will suffice.
If all tasks are not harmonic, then a programmable "alarm"
is required based on an interval sequence determined
by the least common multiple of all harmonic groups.
When a "hit" occurs, the master task wakes all passive
tasks on that frequency(ies) and uses the interval table
to adjust the alarm for the next "hit". Of course, this
all assumes only one alarm is available.

If more than one alarm is available, then each harmonic
group gets its own alarm and its own master task. Each
alarm is programmed and used as a simple pulse and we
are back to multiple instance of the first technique
above.

> 
> --
> Norman H. Cohen    ncohen@watson.ibm.com

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"

Re: ADA task

[Roumen Roupski]

Norman H. Cohen <ncohen@watson.ibm.com> wrote in article
<51cjp0$q7k@watnews1.watson.ibm.com>...
> In article <5174qu$o1p@nr1.ottawa.istar.net>, "Roumen Roupski"
> <Roumen.Roupski@Pika.Ca> writes: 
> 
> 
>    task Cyclic_Processor;
> 
>    task body Cyclic_Processor is
>       Next_Wakeup : Calendar.Time := Calendar.Clock;

In your example above you use Calendar package. I saw GNAT has
Ada.Real_Time package. Should I use it instead of Calendar?

Roumen

Re: ADA task

[Robert Dewar]

Samuel Harris

"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.
"

This is true from a formal point of view, but any decent Ada 83 compiler
that has any pretense to being usable for real time or simulation
purposes using tasking should provide an effective delay implementation
corresponding to the Ada 95 semantics.

If your Ada 83 comnpiler has a junk implementation of delay, I would
simply replace the compiler.

Re: ADA task

[Ken Garlington]

Norman H. Cohen wrote:
> 
> In article <5174qu$o1p@nr1.ottawa.istar.net>, "Roumen Roupski"
> <Roumen.Roupski@Pika.Ca> writes:
> 
> |> 1. How can I implement a task running at regular intervals, for example
> |> every 50ms +/- 5ms. The task activation must be guaranteed too.
> 

[answer deleted]

I assume by the last sentence in the original question - "The task activation must 
be guaranteed too." - that some discussion of priorities and/or how to connect a 
task to a hardware interrupt or other aperiodic event is also needed. Anyone want to 
post an expanded answer?

> 
> --
> Norman H. Cohen    ncohen@watson.ibm.com

-- 
LMTAS - "Our Brand Means Quality"

Re: ADA task

[Samuel T. Harris]

Robert Dewar wrote:
> 
> Samuel Harris
> 
> "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.
> "
> 
> This is true from a formal point of view, but any decent Ada 83 compiler
> that has any pretense to being usable for real time or simulation
> purposes using tasking should provide an effective delay implementation
> corresponding to the Ada 95 semantics.
> 
> If your Ada 83 comnpiler has a junk implementation of delay, I would
> simply replace the compiler.

I'm not sure what is the point of contention.
I did not imply good nor bad delay implementations.
I did detail the factors relating to the true fidelity of the
delay implementation (whatever that may be) and formal or not,
these issues are a real concern.

Every compiler will have a fidelity of delay it can support.
On our SGI systems, both VADS and GNAT support a 0.01 second delay
fidelity. Delays command to be less than 0.01 seconds are actually
0.01 seconds. This is not acceptable to high fidelity harmonic
simulations involving a least common multiple rate of greater
than 100 hertz. If no compiler supports the required fidelity,
then replacing the compiler is not really a viable option.

Even the "best" delay implementation will only support a certain
fidelity and as long as one's requirements are within that fidelity,
then okay. The original sender did not specify the required fidelity
so I presented a couple of alternatives implementations which rely
on (presumably) higher accuracy hardware clock devices.

There is also the factor of "drift". Computed delays introduce drift
since the actual delay is not strictly tied to the commanded delay.
No matter how close it is, the current time is still required to
determine the appropriate delay interval to use to arrived at the
next target time hit. That's why the new Ada 95 construct delay until
is so much simpler. I don't need to know what _now_ is each time.
I just need the first _now_ and keep adding the total time interval
to it.

Though I've not tested the new Ada 95 contruction at length yet,
I expect that the use of delay until will be much less sensitive
to the fidelity of the run time system. The time when the delay until
is commanded vs the time the delay until is commanded to use
will need to be above a certain minimum interval to guarantee
good correlation (I suppose). I can tune the load of each processor
to maintain that minimum interval with greater control than I
can keep each iteration to within a specific time band (which
I have to do with simple delay statements).

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"

Re: ADA task

[David C. Hoos, Sr.]

Samuel T. Harris <u61783@gsde.hso.link.com> wrote in article
<323B1F23.2781@gsde.hso.link.com>...

> Every compiler will have a fidelity of delay it can support.
> On our SGI systems, both VADS and GNAT support a 0.01 second delay
> fidelity. Delays command to be less than 0.01 seconds are actually
> 0.01 seconds. This is not acceptable to high fidelity harmonic
> simulations involving a least common multiple rate of greater
> than 100 hertz. If no compiler supports the required fidelity,
> then replacing the compiler is not really a viable option.
> 
You're right about VADS on SGI "out of the box".  However, we (Hughes
Aircraft -- Huntsville, AL) run our process which needs higher-fidelity
delays at non-degrading priority 39 (IRIX 5 & 6), with the fast_Hz clock
set to 2 KHz.  You may also need to change v_usr_conf_b.a (I don't remember
off the top of my head) to reduce that 10 ms. fudge factor to 0.  We have
found worst-case infidelity of 2-3 ms. on a heavily-loaded (development)
machine, but typically under 500 micro-sec., as would be expected.  The Ada
run time gets to check for expired delays usually every 500 micro-sec.
Normally to get priority 39, you have to run with super-user privileges,
but we reconfigured the kernel to allow just the one priority level (the
lowest level using the Fast_Hz clock instead of the 10 ms. sginap) to be
run by users.  Since most don't care enough to find out how to run at that
priority, generally only the "official" executables needing RT priority run
this way.
-- 
David C. Hoos, Sr.,
http://www.dbhwww.com
http://www.ada95.com

Re: ADA task

[Norman H. Cohen]

In article <51ep6c$cut@nr1.ottawa.istar.net>, "Roumen Roupski"
<Roumen.Roupski@Pika.Ca> writes: 

|> In your example above you use Calendar package. I saw GNAT has
|> Ada.Real_Time package. Should I use it instead of Calendar?

Old habits die hard.  Yes, you should.

Ada.Real_Time is provided by every Ada-95 compiler that supports the
Real-Time Annex and is guaranteed to provide more accurate time
measurement than Ada.Calendar is guaranteed to provide.  The delay-until
statement works not only with type Ada.Calendar.Time, but also with type
Ada.Real_Time.Time.

Paragraph D.9(13) of the Ada-95 RM requires an implementation supporting
the Real-Time Annex to guarantee an upper bound on the difference between
the delay time specified in the delay-until statement and the time at
which execution of the delayed task actually resumes.  This can be used
to address Ken Garlington's concerns about guaranteeing on-time execution
of a periodic piece of work.  (Careful analysis, such as rate-monotonic
scheduling, is necessary to ensure that the processor will be available,
i.e., that all other tasks of equal or higher priority will be suspended,
when a delay expires; the guarantees in paragraph D.9(13) ensure that
under those conditions a sleeping task awakens quickly when the delay
expires.)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: ADA task

[Norman H. Cohen]

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.

That is why an Ada-83 programmer should write

      loop
         delay Next_Wakeup - Calendar.Clock;
         Do_Some_Work;
         Next_Wakeup := Next_Wakeup + Interval;
      end loop;

rather than

      loop
         delay Interval;
         Do_Some_Work;
      end loop;

If one iteration takes too long, the delay in the next iteration is
correspondingly shorter.  Thus (assuming the system is not too overloaded
to catch up), the loop executes at the desired frequency ON THE AVERAGE.
Of course this is not sufficient for many real-time applications.  In
crucial feedback loops or in integration algorithms, one needs to know
that each iteration is executed on time.  This depends on the run-time
system having a decent implementation of the delay statement.

|> An alternative is to use passive tasks with wakeup entries
|> and tie a master task to a realtime clock interrupt.
|> The master task then rendevous with the passive tasks.

Like the use of a delay statement, this presumes a decent run-time
system, guaranteed to rendezvous promptly with passive tasks.  The rules
of Ada 83 (or of Ada 95 without the Real-Time Annex) don't provide any
guarantees about the instantaneous resumption of the passive task (or
prompt unblocking of the master task) any more than they provide
guarantees about the resumption of a delayed task.  One must be sure to
use a decent implementation.  The metrics and documentation requirements
in the Ada-95 Real-Time Annex give real-time analysts the information
needed to make that determination.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: ADA task

[Samuel T. Harris]

David C. Hoos, Sr. wrote:
> 
> You're right about VADS on SGI "out of the box".  However, we (Hughes
> Aircraft -- Huntsville, AL) run our process which needs higher-fidelity
> delays at non-degrading priority 39 (IRIX 5 & 6), with the fast_Hz clock
> set to 2 KHz.  You may also need to change v_usr_conf_b.a (I don't remember
> off the top of my head) to reduce that 10 ms. fudge factor to 0.  We have
> found worst-case infidelity of 2-3 ms. on a heavily-loaded (development)
> machine, but typically under 500 micro-sec., as would be expected.  The Ada
> run time gets to check for expired delays usually every 500 micro-sec.
> Normally to get priority 39, you have to run with super-user privileges,
> but we reconfigured the kernel to allow just the one priority level (the
> lowest level using the Fast_Hz clock instead of the 10 ms. sginap) to be
> run by users.  Since most don't care enough to find out how to run at that
> priority, generally only the "official" executables needing RT priority run
> this way.
> --

Except for the requirement to be super-user and the limitations
on priority levels, that is a good way to "configure" VADS to
meet the need. Some folks might find the limitations a problem
but it seems to work for you.

For us, the clock driven approach is best since we MUST stay in sync
with other distributed session hosts. All simulation assets are driven
by a central GPS coordinated CTE clock setup.

As a side note related to another thread, the package v_usr_conf_b.a
is also were one would place a custom heap memory manager, perhaps
with garbage collection (which is being discussed elsewhere in the
group).

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"

Re: ADA task

[Robert I. Eachus]

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...

Re: ADA task

[Marin David Condic, 407.796.8997, M/S 731-93]

"Norman H. Cohen" <ncohen@WATSON.IBM.COM> writes:
>The "delay until" statement is a new feature in Ada 95.  In Ada 83 you
>would write
>
>   delay Next_Wakeup - Calendar.Clock;
>
>which delays for the specified amount of time (in this case, the time
>from now until Next_Wakeup).
>
    Out of curiosity & ignorance, is there anything in the LRM which
    guarantees some minimal latency or predictability with the "delay
    until" statement? I recall one of the big criticisms of Ada83 was
    that the "delay" statement (and other language semantics) made it
    very difficult, if not impossible, to write a task which could
    schedule itself in a predictable manner. (That is, if one wanted
    to fire off a task every 20 milliseconds, one would like to know
    that any fraction of scheduling error is detected and corrected in
    the next pass to the limit of the accuracy of the clock and that,
    if at all possible, you get no "jitter" in the interval between
    cycles.)

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
   "Don't say yes until I finish talking."

        -- Darryl F. Zanuck
===============================================================================

Re: ADA task

[Marin David Condic, 407.796.8997, M/S 731-93]

Robert Dewar <dewar@CS.NYU.EDU> writes:
>This is true from a formal point of view, but any decent Ada 83 compiler
>that has any pretense to being usable for real time or simulation
>purposes using tasking should provide an effective delay implementation
>corresponding to the Ada 95 semantics.
>
    Yes, but as I alluded to in an earlier post, there was (is?) a
    problem with Ada83 delay semantics - at least from a "pure Ada"
    viewpoint. (Any given implementation may not have exhibited the
    problem, but you couldn't know that it *wouldn't* just from
    language semantics.) Consider this:

       task Cyclic_Processor;

       task body Cyclic_Processor is
          INTERVAL    : constant Duration := 0.050;
          NEXT        : Time := Calendar.Clock + INTERVAL ;
          TEMP        : Duration := INTERVAL;
       begin
          loop
             TEMP := Next - Calendar.Clock;
             delay TEMP;
             Do_Some_Work;
             Next := Next + INTERVAL;
          end loop;
       end Cyclic_Processor;

    I borrowed & modified this example from the Ada83 LRM (Section
    9.6) and added a temporary variable to illustrate a point: The
    computation of "Next - Calendar.Clock" is not "atomic". It could
    be interrupted by a higher priority task after sampling
    Calendar.Clock and before performing the subtraction. (not real
    likely, but it _could_ happen, eh?) If the task remains suspended
    for a small amount of time, you get jitter. If it is a relatively
    large amount of time, you will start missing cycles.

    I don't know if the "delay until" semantics of Ada95 guarantees
    any better predictability, but it at least eliminates the sampling
    of Calendar.Clock for computing when the next cycle should happen
    and (presumably) it's easier for the runtime environment to
    provide uninterruptability where needed and likely provide a
    "fixed" error between the requested wakeup and the actual wakeup.
    Given a static, constant computation of Next := Next + INTERVAL;
    it would be a lot easier for Ada95 to give you what you want.

    Correct me if I'm wrong on this. I believe this was a problem with
    Ada83 which needed correcting specifically because implementations
    had a hard time providing behavior which could be guaranteed to be
    predictable given the semantics of the language.

    MDC
Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
   "Don't say yes until I finish talking."

        -- Darryl F. Zanuck
===============================================================================

Re: ADA task

[tmoran]

> This depends on the run-time system having a decent implementation
> of the delay statement.
  What is an indecent implementation?  They all have to wait for
higher priority tasks, and the race condition can happen to any Ada 83
system, so what else can go wrong?  Slow code?  Slow OS?
  On the MS-Intel platforms, the OS is the main impediment, with a
very large clock'tick and a very slow Calendar.Clock call.  That
could be easily fixed in DOS, but not in modern MS OSes.

Re: ADA task

[Norman H. Cohen]

Marin David Condic, 407.796.8997, M/S 731-93 wrote:

>     Out of curiosity & ignorance, is there anything in the LRM which
>     guarantees some minimal latency or predictability with the "delay
>     until" statement? 

The Ada-95 Real-Time Annex defines certain "metrics" of real-time
performance, including metrics of the performance of both kinds of delay
statement.  (See RM Section D.9.)  The Annex requires implementations
claiming conformance to the Annex to document their performance with
respect to these metrics as well as with respect to several
nonquantitative aspects of real-time performance.

>                       I recall one of the big criticisms of Ada83 was
>     that the "delay" statement (and other language semantics) made it
>     very difficult, if not impossible, to write a task which could
>     schedule itself in a predictable manner. (That is, if one wanted
>     to fire off a task every 20 milliseconds, one would like to know
>     that any fraction of scheduling error is detected and corrected in
>     the next pass to the limit of the accuracy of the clock and that,
>     if at all possible, you get no "jitter" in the interval between
>     cycles.)

You are confusing jitter and cumulative drift.  Programming

   Next_Execution_Time := Next_Execution_Time + Iteration_Interval;
   delay Next_Execution_Time - Clock;

rather than

   delay Iteration_Interval;

corrects the "scheduling error" on one iteration by making the scheduled
delay on the next iteration correspondingly shorter.  However, this
eliminates cumulative drift, not jitter.  Elimination of jitter does
indeed depend on a ready task whose delay has expired being dispatched
promptly upon expiration of the delay.  It is up to the programmer to
ensure that all resources will be available by then and no equal or
higher priority tasks are still eligible to execute.  It is up to the
runtime system to ensure that the dispatching is efficient.  Many
successful real-time projects were written in Ada 83, by teams that
worked closely with the compiler vendor to ensure that the runtime
system met their performance requirements.

-- 
Norman H. Cohen    
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: ADA task

[Robert A Duff]

In article <96091716583421@psavax.pwfl.com>,
Marin David Condic, 407.796.8997, M/S 731-93 <condicma@PWFL.COM> wrote:
>    I borrowed & modified this example from the Ada83 LRM (Section
>    9.6) and added a temporary variable to illustrate a point: The
>    computation of "Next - Calendar.Clock" is not "atomic". 

Right.  That's exactly why "delay until" was added.  There's still a
finite, non-zero, amount of time involved in waking up a delay-ed task,
but this particular race condition is fixed.

- Bob

Re: ADA task

[Robert A Duff]

In article <324159A2.6220@watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>The Ada-95 Real-Time Annex defines certain "metrics" of real-time
>performance, including metrics of the performance of both kinds of delay
>statement.  (See RM Section D.9.)  The Annex requires implementations
>claiming conformance to the Annex to document their performance with
>respect to these metrics as well as with respect to several
>nonquantitative aspects of real-time performance.

Yeah, but let's not get carried away with this.  Ada doesn't define
performance, in general, and neither does any other language I know of.
How long does "X := Y;" take, when X and Y are of type Integer?  The RM
doesn't say.  So why are we so worried about the fact that delay
statments might take too long?  Suppose the Ada compiler makes "X := Y;"
take 1 second.  Is that acceptable?  Well, no, but it has nothing to do
with the RM.  Likewise, suppose a task's delay expires, and the run-time
system doesn't notice that fact for 1 second.  Is that acceptable?  No,
but it's not the fault of the language.  It's the fault of the Ada
implementation, or maybe the OS it's running on top of.  (I'm appalled
that certain OS's can't measure time more accurately than 1/18 second!)

- Bob