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"