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