comp.lang.ada
 help / color / mirror / Atom feed
* Re: Ada95 concurrency -- any experiences?
       [not found] <79f9tk$nmi$1@its.hooked.net>
@ 1999-02-08  0:00 ` Marin David Condic
  0 siblings, 0 replies; only message in thread
From: Marin David Condic @ 1999-02-08  0:00 UTC (permalink / raw)


Mike Silva wrote:
> 
> Hello all,
> 
> I've just started learning Ada95 (longtime C / RT / embedded background) and
> I'm quite intrigued by the concurrency features built into the language.
> I'd like to hear from people who have used these features "in anger" whether
> or not they were fabulous, adequate, quirky, useless or ???  Thanks.
> 
I'm not sure what you mean about using tasking "in anger". I've used
tasking in systems which operate warplanes - they tend not to get used
when one is "in love", if that's what you mean. :-)

You can certainly find some historical information at:
http://www.adahome.com/ There are various "success stories" as well as
other material that may be of use to you. You can also find lots of
information from the Comp.Lang.Ada newsgroup.

I've used tasking in some fairly simple forms for real time engine
controls. I had a rocket engine control which had 1 interrupt driven
procedure, 3 periodic tasks and two aperiodic tasks. We kept the model
very simple - avoiding complex rendesvous mechanisms, etc. It worked
quite well and did not present a level of overhead significantly larger
than we would have seen with any other executive implementation. (we
were getting between 5% and 7% of CPU used for the executive when it was
doing nothing but cycling & periodically reading/writing data. Not bad
for an old 1750a microprocessor and Ada83 generation of compiler.) The
use of tasks made our workload scheduling dramatically simpler and kept
the executive very reliable. The only down-side was where we had data
latency issues - if something was running at the 5mSec rate, you could
not tell precisely where in the 1mSec schedule it was going to execute.
Since our A/D reads were scheduled at 1mSec ticks, you wanted to
schedule the loop closure and it's associated A/D read very close
together so it was operating on the freshest possible data. So we had to
circumvent the "pure" task scheduling to put this code into a more
traditional cyclic schedule.

If we had had a faster processor and a more advanced compiler, (and MORE
MEMORY!) the task experience probably would have been even smoother. But
even where it was, I didn't see any reason not to recommend using them.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

"Government is not reason. It is not eloquence. It is a force. 
Like fire, a dangerous servant and a fearful master."

    --  George Washington




^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~1999-02-08  0:00 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <79f9tk$nmi$1@its.hooked.net>
1999-02-08  0:00 ` Ada95 concurrency -- any experiences? Marin David Condic

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox