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: "Marin David Condic, 407.796.8997, M/S 731-93" <condicma@PWFL.COM>
Subject: Re: ADA task
Date: 1996/09/17
Message-ID: <96091716583421@psavax.pwfl.com>#1/1
X-Deja-AN: 183925278
sender: Ada programming language <INFO-ADA@LISTSERV.NODAK.EDU>
comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
x-vms-to: SMTP%"INFO-ADA@VM1.NODAK.EDU"
newsgroups: comp.lang.ada
x-vms-cc: CONDIC
Date: 1996-09-17T00:00:00+00:00
List-Id: <comp.lang.ada>


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