Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!amdahl!rtech!wrs!jerry From: jerry@wrs.UUCP (Jerry Fiddler) Newsgroups: comp.os.misc Subject: Re: why rare? [was: Re: Realtime OS's] Message-ID: <549@wrs.UUCP> Date: 12 Jul 88 19:03:13 GMT References: <3574@drivax.UUCP> <36@necbsd.NEC.COM> Reply-To: jerry@wrs.UUCP (Jerry Fiddler) Organization: Wind River Systems, Emeryville, CA Lines: 66 I think Larry has put his finger very well on one aspect of a real-time system; that of being event-driven. Just for discussion's sake, here's a list of some of the other requirements that I usually think of as differentiating a real-time from a non-real-time environment. - Event-Driven This is an essential difference from something like a Unix system. A real-time system's primary function is usually to to respond to real-world events and act upon them in a timely and predictable fashion. - Pre-emptive, multi-tasking scheduler The scheduler must be absolutely pre-emptive; e.g. the highest priority task that is ready to run at any given time must be running. When a high priority task becomes ready (presumably because of a real-world event, I/O completion, or timeout) it must pre-empt any lower priority task that might currently be running. An corrolary of this idea is that is critical to minimize the times that the OS itself does not allow task pre-emption. For instance, when a low priority task is in the OS itself, can it be pre-empted? This is a serious architectural consideration. - Easy Connection To And Prompt Response To Interrupts Because most real-world events announce themselves to the computer as interrupts, it is important for an application to connect and respond to interrupts easily and effectively. - Effective Communications Between Tasks, and Between Task and Interrupt Level Most real-time problems seem to require multiple tasks working on the same problem. This is essentially different than, for instance, a typical timeshare system where there is minimal (hopefully) interaction between, say, two different editors run by two people. Therefore, there is often considerable communications between the tasks. Also, since most processing should be done at task level (for prioritization and queueing purposes) it is important to be able to easily communicate from interrupt to task level. For these reasons, the communications models are usually different for real-time systems. - Closeness to Hardware In Unix-like systems, the application is kept as isolated as possible from the underlying hardware. In a real-time system, where the application needs to interact with the real-world, this is not desirable. - Ability to Run with Available Resources Diskless? ROM-based? Minimal RAM? This, of course, is application-dependent. - Ability to keep things locked in memory When the nuke plant is about to blow up, you don't want the alarm task swapped out to disk! This is just a quick list and I'm sure I've forgotten some things. There are many other properties that are often desirable (distributed systems facilities, multiprocessing, specialized development environments, etc.) that may be desirable or necessary for any given application. Maybe the overriding idea here is that the main difference between real-time and non-real-time systems is not just speed (although that is certainly important) but architecture. OK. Let the flames begin. -- Jerry Fiddler Wind River Systems {sun,rtech}!wrs!jerry