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,5bcf30769d6d9599
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-08-28 08:50:49 PST
Path: 
 archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!chcgil2-snf1.gtei.net!news.gtei.net!news.binc.net!kilgallen
From: Kilgallen@SpamCop.net (Larry Kilgallen)
Newsgroups: comp.lang.ada
Subject: Re: ADA os talk
Date: 28 Aug 2001 10:50:45 -0500
Organization: LJK Software
Message-ID: <3CeB8M0VaOC6@eisner.encompasserve.org>
References: <mailman.998888394.11895.comp.lang.ada@ada.eu.org>
 <9mdmck$rs1$1@nh.pace.co.uk> <9me6q4$aai1@news.cis.okstate.edu>
 <MIj1nYP7aabe@eisner.encompasserve.org> <9mg7fr$rm1$1@nh.pace.co.uk>
NNTP-Posting-Host: eisner.encompasserve.org
X-Trace: grandcanyon.binc.net 999013342 16327 192.135.80.34 (28 Aug 2001
 15:42:22 GMT)
X-Complaints-To: abuse@binc.net
NNTP-Posting-Date: Tue, 28 Aug 2001 15:42:22 +0000 (UTC)
Xref: archiver1.google.com comp.lang.ada:12520
Date: 2001-08-28T10:50:45-05:00
List-Id: <comp.lang.ada>

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.