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,1d321b3a6b8bcab2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-01-23 21:02:57 PST Path: nntp.gmd.de!newsserver.jvnc.net!howland.reston.ans.net!pipex!uunet!svc.portal.com!portal.com!cup.portal.com!R_Tim_Coslet From: R_Tim_Coslet@cup.portal.com Newsgroups: comp.lang.ada Subject: Re: "Subtract C, add Ada" Date: 23 Jan 1995 21:02:57 -0800 Organization: The Portal System (TM) Sender: pccop@unix.portal.com Message-ID: <131598@cup.portal.com> References: <3fdcoi$chn@miranda.gmrc.gecm.com> <3fng3t$2ak@Starbase.NeoSoft.COM> <3fpc7j$mts@cliffy.lfwc.lockheed.com> NNTP-Posting-Host: news1.unix.portal.com Date: 1995-01-23T21:02:57-08:00 List-Id: >Samuel Mize (smize@Starbase.NeoSoft.COM) wrote: >: Sure you do, if there was a programmer error, or a hardware glitch, >: or a bad memory location, etc. These are the things you don't want. >: Given that you can't eliminate those, oh *boy* do you want exceptions, >: given the alternative (core dump at 30,000 feet -- how do I reboot >: my F-16?!?!?!?) > >However, for systems with the capability to degrade cleanly, exceptions are >a very good thing and in fact are widely used in embedded avionics software. > >-------------------------------------------------------------------- The software I'm currently working on for a cockpit display system was specificly designed to USE exceptions to gracefully degrade the system functionality in the presence of serious hardware problems. Each 16ms display frame consists of a series of calls to the various CSCs controlling the sybsystems of the display. If no fatal hardware problems occur it runs completely without exceptions. But in the case of fatal hardware failures (e.g. inability to access a subsystem) an exception is raised within that CSC, terminating any further processing for that subsystem for that frame, letting the other CSCs have the "extra" unused time. Thus the system will gracefully degrade, mo matter how deep it had gotten into the CSC for a given subsystem when the hardware died. No exception is ever allowed to propagate outside of the top level CSC in which it occured to the main task. The exception processing is a little expensive (about 1ms/exception), but with several CSCs consuming 4 or 5ms in normal operation and the overall time budget a bit tight, the exception usually saves time making the remaining 3ms or more available to other CSCs immediately in that frame when such a failure occurs. Same thing with a serious programmer error that was not detected in test: the affected CSC dies gracefully and the system functionality degrades... BUT the REST of the system continues to function! Such graceful degradation in function would have been MUCH harder to implement in this system WITHOUT exceptions. R. Tim Coslet Usenet: R_Tim_Coslet@cup.portal.com technology, n. domesticated natural phenomena