Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amdahl!drivax!braun
From: braun@drivax.UUCP (Kral)
Newsgroups: comp.os.misc
Subject: Re: why rare? [was: Re: Realtime OS's]
Keywords: Realtime
Message-ID: <3574@drivax.UUCP>
Date: 4 Jul 88 18:15:57 GMT
References: <10450@udenva.cair.du.edu> <8411@pur-ee.UUCP> <797@taux01.UUCP> <11053@sol.ARPA> 
Reply-To: braun@drivax.UUCP (Kral)
Organization: Digital Research, Inc.
Lines: 25

In article  webber@aramis.rutgers.edu (Bob Webber) writes:
>I guess the first question is: why are realtime OS's rare.  Is it really
>so difficult to modify schedulers to give a certain process a guarenteed
>slice of cpu, guarenteed memory residence, and perhaps even priority on
>disk fetches?  

In my opinion the difficulty in Real Time OSs is *not* in the scheduler
algorithm, but in guaranteeing a low maximum interrupt latency, and still
providing useful services for the applications people to use.

You have to be able to guarantee that any interrupt, or at least any interrupt
of a set of classes of interrupt, be able to get service in a minimum amount
of time.  Furthermore, you have to be able to transfer control to high priority
applications logic within a guaranteed amount of time.

There is a trade off between offering a good set of services for the
appications people (while still guaranteeing response time) - and thus giving
them quick development time - and letting them have control over everthing,
which means they have to do most of the work themselves (the OS just provides a
kernel).

-- 
kral 	408/647-6112			...{ism780|amdahl}!drivax!braun
"I'll let you be in my dream                      If I can be in yours"
DISCLAIMER: If DRI knew I was saying this stuff, they would shut me d~-~oxx