Re: Ada Tasks vs Linux processes

[Gary Scott <Gary.L.Scott@lmtas.lmco.com>]

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.