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