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,d5977aa20216d24a X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-04-04 11:35:30 PST Path: supernews.google.com!sn-xit-02!supernews.com!news.tele.dk!209.98.98.64!news-out.visi.com!hermes.visi.com!pulsar.dimensional.com!dimensional.com!coop.net!newsfeed1.global.lmco.com!svlnews.lmms.lmco.com!news1.lmtas.lmco.com!not-for-mail From: Gary Scott Newsgroups: comp.lang.ada Subject: Re: Ada Tasks vs Linux processes Date: Wed, 04 Apr 2001 12:18:59 -0500 Organization: LM Aeronautics Message-ID: <3ACB5783.474B0834@lmtas.lmco.com> References: <3AC8FA76.C6AD4B53@boeing.com> NNTP-Posting-Host: CAA261517.lmtas.lmco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.72 [en]C-CCK-MCD {C-UDP; LMTAS} (WinNT; U) X-Accept-Language: en,pdf Xref: supernews.google.com comp.lang.ada:6471 Date: 2001-04-04T12:18:59-05:00 List-Id: A more fundamental issue would be why would hardware be designed that did not provide a positive status indication that it was "ready" for further access. Using delays to handle interface issues with slow, poorly designed hardware has caused a huge number of anomalies in avionic systems that I've dealt with over the last 20 years. It's really tiring... tmoran@acm.org wrote: > > > ... by delaying until the next clock tick. > Note this is a change from Ada 83, where the delay had to be "at > least" that specified. Suppose there's a piece of hardware that > needs 500 mics to settle after some operation, before it can next > be accessed. Given a Duration'small of 10*mics, the unsuspecting > programmer might write "delay 500*mics;". With a System.Tick of > 1000 mics, that would delay somewhere between 1 and 2 ms, a safe > time for the hardware to settle down, when compiled with Ada 83. > In Ada 95 it need only take a single tick, which might happen > within a few mics of reaching the "delay" statement and thus long > before the hardware is ready. Crash and burn.