Re: ADA task

[ncohen@watson.ibm.com (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