Path: utzoo!yunexus!geac!daveb From: daveb@geac.UUCP (David Collier-Brown) Newsgroups: comp.os.misc Subject: Re: why rare? [was: Re: Realtime OS's] Summary: Difficulties involved, and strategies. Keywords: Realtime strategy Cheriton Message-ID: <2959@geac.UUCP> Date: 6 Jul 88 13:30:41 GMT Article-I.D.: geac.2959 References: <10450@udenva.cair.du.edu> <8411@pur-ee.UUCP> <797@taux01.UUCP> <11053@sol.ARPA><3574@drivax.UUCP> Reply-To: daveb@geac.UUCP (David Collier-Brown) Organization: GEAC Computers, Toronto, CANADA Lines: 57 In article <3574@drivax.UUCP> braun@drivax.UUCP (Kral) writes: >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 guaranteed >>slice of cpu, guaranteed memory residence, and perhaps even priority on >>disk fetches? In article <3574@drivax.UUCP> braun@drivax.UUCP (Kral) writes: >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 >applications people (while still guaranteeing response time) - and thus giving >them quick development time - and letting them have control over everything, >which means they have to do most of the work themselves (the OS just provides a >kernel). Well, you can simplify the problem of providing response substantially by considering different scheduling **strategies**. By "strategy", however, I mean something much different from giving some process a guaranteed slice of cpu (guaranteed memory residence, priority on I/O, etc). David Cheriton proposed scheduling processes at system load time, based on knowledge of the time require to complete a given time-critical task and its frequency. This allows one to put a bound on what processes will be allowed to be run in "real time" on a given processor with known interrupt latency and known process-switch times. The result is that you don't really have priorities at all, you have requirements and resources to satisfy them. It is surprising how much easier this can make the "guarantee performance" problem (:-)). It is, of course, not sufficient. You still need fast interrupts and process switches for faster and faster real-time requirements. It merely takes the risk and kludgery out of the configuring and makes it easier to satisfy some real-time tasks on a machine with a rich (Unix-like) suite of software development capabilities. See Cheriton on "The V System" (sorry, I've lost the correct reference) and the rumor mill re the new Japanese real-time kernel... --dave (I remember Thoth) c-b -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers Ltd., | "His Majesty made you a major 350 Steelcase Road, | because he believed you would Markham, Ontario. | know when not to obey his orders"