Re: ADA os talk

[Kilgallen@SpamCop.net (Larry Kilgallen)]

In article <9mg7fr$rm1$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> We used VMS on engine test stands to collect & process temperature/pressure
> sensor data in real time. I wasn't in on developing the software, but the
> requirements were that you could detect the interrupt and have a predictable
> latency to when you got to the ISR, even if other apps were running. (You
> had to record the data points at even time intervals - as you say, not
> necessarily "fast" but predictable.) We were able to run GUI apps at the
> same time an engine test was going on - albeit with the probability that
> mouse/window response was going to degrade, but it didn't stop the realtime
> app from getting serviced when it needed to.
> 
> IIRC, VMS itself didn't guarantee realtime behavior, but if you took some
> smart guys and let them study it long enough, they could figure out how to
> get VMS to do what you wanted it to do. We accomplished the same sort of
> thing with MS-DOS because basically, you could get your real time app to
> move MS-DOS aside and just take over.

I don't suppose this "study" time was billed by the hour ?
Of course it is possible the documentation was worse during
the time period you are discussion.

> What would be nice is to have a workstation OS that didn't require you to
> become an expert or circumvent the OS to do realtime - just declare a
> process to be "realtime" and know that it can get certain services with
> certain predictable latencies and be sure that it has priority over anything
> else. (Dangerous, but necessary for realtime programming.)

Based on the real-time people I have met, I would say that each
shop is still going to study the situation to ensure they
are not making inwarranted assumptions.