From: "Marin David Condic, 407.796.8997, M/S 731-93" <condicma@PWFL.COM>
Subject: Re: ADA task
Date: 1996/09/17
Date: 1996-09-17T00:00:00+00:00 [thread overview]
Message-ID: <96091716583421@psavax.pwfl.com> (raw)
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
===============================================================================
next reply other threads:[~1996-09-17 0:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
1996-09-17 0:00 Marin David Condic, 407.796.8997, M/S 731-93 [this message]
1996-09-20 0:00 ` ADA task Robert A Duff
-- strict thread matches above, loose matches on Subject: below --
1996-09-18 0:00 tmoran
1996-09-17 0:00 Marin David Condic, 407.796.8997, M/S 731-93
1996-09-19 0:00 ` Norman H. Cohen
1996-09-20 0:00 ` Robert A Duff
1996-09-11 0:00 Roumen Roupski
1996-09-12 0:00 ` Philip Brashear
1996-09-13 0:00 ` Norman H. Cohen
1996-09-13 0:00 ` Samuel T. Harris
1996-09-14 0:00 ` Robert Dewar
1996-09-14 0:00 ` Samuel T. Harris
1996-09-15 0:00 ` David C. Hoos, Sr.
1996-09-16 0:00 ` Samuel T. Harris
1996-09-16 0:00 ` Norman H. Cohen
1996-09-14 0:00 ` Ken Garlington
1996-09-14 0:00 ` Roumen Roupski
1996-09-16 0:00 ` Norman H. Cohen
1996-09-16 0:00 ` Robert I. Eachus
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox