Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!bloom-beacon!husc6!cfa!ward
From: ward@cfa.harvard.EDU (Steve Ward)
Newsgroups: comp.os.misc
Subject: Re: why rare? [was: Re: Realtime OS's]
Summary: realtime
Message-ID: <1063@cfa.cfa.harvard.EDU>
Date: 14 Jul 88 14:33:12 GMT
References: <3574@drivax.UUCP> <36@necbsd.NEC.COM> <549@wrs.UUCP>
Organization: Harvard-Smithsonian Ctr. for Astrophysics
Lines: 78

....
....

Many features and functions of realtime OS's have been put forth to
describe what is a realtime OS.  I have a few "peanut gallery" comments
to add:

I would be  more rigid in stating that a realtime OS is predictable --
a realtime OS is totally deterministic by design.  Indeed, this is the
cornerstone of a realtime OS.  This means for any given description of
the current state of the machine/OS/application (state of the machine)
it can be exactly determined what the machine function/action/timing
will be (next machine state).  I emphasize "determine exact timing."

A realtime OS must be event driven and use preemptive task scheduling
and allow full, direct, and "easy" use of interrupts, as has already
been stated.  Additionally, this must mean that interrupt support
allows interrupt routine context switch activation.  This means that
not only must one be able to change process priorities from an
interrupt routine and then request a context switch but the request
for the context switch (or request to reschedule a process or however
you want to describe it) must be immediately and predictably executed.
Many "realtime" OS's will accept the context switch request but will
wait until a future realtime clock timeslice to actually perform
the task rescheduling.

The interprocess communication mechanisms (signals, or whatever)
should also be "reliable."  It should not be possible to lose
signals (or whatever the IPC method).  Either the set/reset/arm
protocol must be bulletproof, preventing the possibility of loss
of signals by design of the protocol, or (or both) signals must
be queued.  In fact, any realtime communication mechanism must
be guaranteed by design to be totally reliable.  This is not
needed (and not available!) for timeshare systems since if one
signal generated by a character arrival is lost or not sent, not
to worry, the next character in will generate a signal or its
signal will be received.  The application code is usually  written
to accomodate such "loose" signalling and the resultant "loose"
timing is not an issue. (except when one is really trying to do
realtime programming on UNIX :-)  This is admittedly simplistic
example, but it hopefully makes the point.

Another galling point is the difficulty one often encounters in
dealing with OS modes.  The OS may purport to be realtime and
do many desirable realtime things, but one finds out that many
of the functions can only be used/invoked in protected OS or
hardware machine modes.  Further, it is common to find it difficult
to use or invoke these modes.  This is ridiculous.  All realtime
OS functions and machine modes should be easily manipulable by
the realtime programmer.  If doing this is complicated, arcane,
or mystical, then the OS should include full libraries and
certainly full documentation.  In any case, the realtime programmer
should not have to do what would otherwise be construed as
system programming to do realtime programming.  This philosophy
should extend to all programming areas such as device drivers and
interrupt handlers.  For timeshare systems and users these ARE
system (programming) functions, but for the realtime programmer
these are USER APPLICATION programming functions.  The realtime
OS should make programming in these areas as simple and direct
as most timeshare user programming interfaces/environments.

As an aside, I personally feel that the true realtime engine is best
implemented in hardware without paging/swapping MMU hardware.  Simple
memory protection-only schemes are fine, but virtual memory inflicts
complication and unpredictability.  If one must implement a realtime
OS on hardware with an MMU, particularly with virtual memory, the
realtime OS ought to turn the thing off and leave it off.  If the
MMU presence inflicts itself in any way on the hardware operation
then there should be libraries to simply deal with any possible
MMU interaction (ex. mapping hardware I/O registers into a process
space at any chosen process/machine level such as user, kernel or
whatever).

Steven Ward
Harvard-Smithsonian Observatory
ward@cfa (BITNIT, UUCP)
NASA SPAN: CFA3::SWARD
.