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: 115aec,4e85c9881f4b1a8c X-Google-Attributes: gid115aec,public X-Google-Thread: 103376,606be1fd5adb96fc,start X-Google-Attributes: gid103376,public From: Marin David Condic Subject: Re: Ada95 concurrency -- any experiences? Date: 1999/02/08 Message-ID: <36BF1FDD.218DCE42@pwfl.com>#1/1 X-Deja-AN: 442010677 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <79f9tk$nmi$1@its.hooked.net> Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: diespammer@pwfl.com Newsgroups: comp.realtime,comp.lang.ada Date: 1999-02-08T00:00:00+00:00 List-Id: 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