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 .