Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!necntc!necssd!necbsd!baker From: baker@necbsd.NEC.COM (L. BAKER) Newsgroups: comp.os.misc Subject: Re: why rare? [was: Re: Realtime OS's] Message-ID: <36@necbsd.NEC.COM> Date: 6 Jul 88 15:21:59 GMT References: <3574@drivax.UUCP> Organization: NEC America Inc. Lines: 66 From article <3574@drivax.UUCP>, by braun@drivax.UUCP (Kral): > 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. ...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 ... do most of the work themselves (the OS just provides a > kernel). I do real-time programming for a living, and I have a few comments. I don't claim to be a wizard or even merely knowledgable about generic real-time operating systems, but I have learned a few things over the last year that apply. First, it's not the interrupt itself that requires a minimum response time, it's the event that that interrupt represents. Consider, for example, a thing that acts as a `timer' - causing a prescheduled `time-out' event to occur at a specific moment. This may not work well with a hardware clock, since only a finite number of time-out interrupts can be set. To handle a large number of prescheduled events, or events that are scheduled beyond the immediate resolution of the clock, a `clock handler' has to exist that repeatedly resets the clock and checks to see what's being activated at this particurlar interrupt. The time-out `event' that the clock interrupt would represent, and the task/process/code that will have to be started to handle it are what require the fixed minimum latency. The actual hardware clock handler is itself really an interrupt handler. Anything it activates is an event handler. With this model of real-time computation the events, as initiated by the hardware interrupt-handlers, are the fundamental schedulable entities. It may be more important, for example, to handle something that requires 0.001 sec. resolution than something that requires 1.0 sec resolution. Rather than treat the individual event handlers as time-share entities with priority levels, the higher-priority item is handled first, because of the priority level of the event that activated it, then the lower priority one. This gaurentees that the events requiring the lowest latency times receive the fastest response. So to me the difference between a generic real-time system and a generic something else kind of system *is* the scheduler. The scheduler is no longer scheduling processes per se, but scheduling events. Any additional scheduling that is required in the traditional sense, e.g. spreading around unused CPU to other processes that can use it, becomes a `background' consideration. Also, If you accept this distinction then there really isn't an application layer; the event driven nature of the system turns the entire application into one huge state-machine model of the computation being performed. Thus the `applications' are really the event handlers and the subsystems they control. In a sense, the `events' are themselves software interrupts. But since they are software entities, similar to messages in a message passing operating system, they can be traced, controlled and simulated. This makes software development and testing for these systems far more manageable since the scenaios being tested are much easier to simulate and reproduce. Larry Baker, NEC America Switching Systems Division, Dallas TX Uucp: { harvard | husc6 | ames }!ut-sally!necssd!baker Internet: baker%necssd.uucp@cs.utexas.edu