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