Next: Operational Concepts
Up: Resource Allocation
Previous: Soft Realtime
There are many systems that obviously have hard-realtime requirements, such as control or data-acquisition systems. But there also are a large number of systems that don't have quite so obvious hard-realtime demands: those systems that need to react to special events in a defined small time interval. These systems may be performing non-time-critical tasks in general, but emergency shutdown routines must still be serviced with a very small delay independent of the current machine state. In such cases a hard-realtime system is required to guarantee that no such critical event will ever be missed, even if the system goes up to an enormous system load or a user-space application blocks altogether. The criteria for requiring hard-realtime as opposed to soft-realtime are the following:
- No event of a specific category may be missed under any circumstances (e.g. emergency shutdown procedure)
- the system should have low latency in response to a specific type of event.
- periodic events should be generated with a worst case deviation guaranteed.
Note that these three criteria do overlap in a certain respect and could be reduced to a single one, that being to guarantee worst case timing variance of a specific event class, but that's not what I would call a self-explanatory definition.
RTLinux and a derivative of it RTAI fall into the class of hard-realtime Linux variants (if you know of any others let me know). These are based on three principles:
- Unconditional Interrupt interception.
- delivery of non-realtime interrupts to the general-purpose OS as soft-interrupts.
- Run the general-purpose OS as the idle task of the RTOS.
Next: Operational Concepts
Up: Resource Allocation
Previous: Soft Realtime
Der Herr Hofrat
2002-03-08