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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,59dddae4a1f01e1a X-Google-Attributes: gid103376,public From: Richard Riehle Subject: Re: Need help with PowerPC/Ada and realtime tasking Date: 1996/05/21 Message-ID: X-Deja-AN: 156082076 references: <1026696wnr@diphi.demon.co.uk> to: JP Thornley content-type: TEXT/PLAIN; charset=US-ASCII organization: National University, San Diego mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-05-21T00:00:00+00:00 List-Id: On Sat, 18 May 1996, JP Thornley wrote: > > This is very "hard" real time -- life critical application and > > interrupts occurring at a frequency roughly 1/100 the speed of > > the memory during peak situations (although most of the > > time it is somewhat less frequently). > > > > My first response is that safety-critical software does not go well > with interrupts and the use of tasking. The main requirement of > safety-critical code is predictability, which is made impossible if > you are coping with unpredictable interrupts and with hard-to-analyse > tasking syncronisations. I would like to offer a slightly different view of this. The main requirement of safety-critical code is that it be "safe." The suggestion that a cyclic executive is safer than tasking is not necessarily true. While predictability is essential, the important elemement of predictability is that the system is schedulable such that it can service all of its required tasks. A cyclic executive does not guarantee schedulability. It does not even guarantee predictability. In fact, a cyclic executive can guarantee that one actually fails to trap events as they occur. An interrupt intelligent design can detect an interrupt and choose to ignore it, store it for later processing, etc. Using the Ada 95 tasking model, along with protected types, along with a healthy dose of rate-monotonic analysis, one can design an interrupt driven application that is predictable. While it is is true that the Ada 83 tasking model was somewhat frail in its range of options for effective interrupt-driven applications, especially in being able to guarantee schedulability, Ada 95 is a more robust model. The underlying problem, as usual, is designing an architecture that gurantees predictable schedulability. An additional problem with the cyclic executive model is ist lack of portability. Since it is dependent on the timings of the platform to which it is targeted, it can fail to meet its goals when ported to a new platform. With tasking, one is more dependent on the hardware- independent logic represented by the interaction of the tasks. Again, the Ada 95 tasking model makes this fairly clean. Please do not think I am underestimating the difficulty of designing an architecture based on interrupt-driven protocol. I am simply suggesting that Ada tasks should not be ruled out based on experience with the earlier Ada 83 design. Also, I want to recommend a little caution in being too quick to believe that cyclic executives are any easier when one must depend on trapping interrupts in a timely fashion. > I wouldn't expect to see anything other than a cyclic executive in > safety-critical software. My note, above reflects my view on this. > Have a look at Concurrency in Ada - Alan Burns, Andy Wellings, > Cambridge University Press 1995, ISBN 0 521 41471 7, hardback I agree. Except for a few minor syntactic errors, this is an excellent book. Great exposition of protected types, and their role in object techonology. > > The kinds of information/questions I have are: > > > > 1) What sorts of approaches do people use for tasking when > > the Ada tasking model is too slow? How machine independent > > can these be? Tasking can be designed to be machine independent. As far as too slow, that is an issue which varies from compiler to compiler. It is also an issue that often originates in poorly design tasking architectures, misunderstaning of the rendezvous, and overall incorrect design. For example, in an attempt to reduce the effect of tasking on a design, the software engineer sometimes uses too few tasks rather than too many. In this case, each task is given too much work, and the system fails to meet its design goals. Ideally, the tasking environment is designed so each task spends most of its life waiting for something to do. That way, it is always ready to do what it was assigned to do. When I hear people say that tasking is too slow, and blame it on the compiler, or the RTE, I am inclined to ask for a closer look at the design. Don't underestimate the power of tasking. > In safety-critical systems, predictability of operation comes first, > second and third - factors such as speed and platform independence > come a long way behind - in fact I don't see any way that you can > qualify the system without defining the hardware it will be running > on as software cannot be qualified on its own. Actually, this is one of the benefits of using tasking to define the architecture. Remember that I speak here of Ada 95 tasking. > > 2) What approaches can be used for sharing memory between > > processes that may or may not be located in the same processor > > (but the processors do have some shared memory and some > > local memory) An excellent example of this is the Silicon Graphics workstation. The way SGI has implemented tasking for sharing memory, processes, threads, etc. establishes that tasking is certainly useful for environments where performance and predictability are important. Richard Riehle