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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: "Norman H. Cohen" Subject: Re: ADA task Date: 1996/09/19 Message-ID: <324159A2.6220@watson.ibm.com>#1/1 X-Deja-AN: 183947424 references: <96091716303787@psavax.pwfl.com> content-type: text/plain; charset=us-ascii organization: IBM Thomas J. Watson Research Center mime-version: 1.0 reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.ada x-mailer: Mozilla 3.0 (Win95; I) Date: 1996-09-19T00:00:00+00:00 List-Id: 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