Introduction to Real-time Programming

What is Real-time

Any discussion of real-time systems leads to the consideration of a spectrum of real-time systems At one end are the hard real-time systems In the middle are the soft real-time systems At the other end are the non real-time systems The two ends represent what can also be referred to as Time Deterministic and Throughput Oriented systems

Measure of Real-time

Defined in terms of:

Time Determinism of the Computation

and

Value of the Computation

Hard Real-time

If a deadline is missed (time determinism is not met) then the attempted Computation becomes worthless

You may as well abort and pretend nothing ever happened Should we bother to even produce the Result Should we execute a Recovery Procedure

Utility Function Curve

Deadline was missed Result is worthless Recovery Procedure may cause another failure

Soft Real-time

If the deadline is missed (or will be missed) then you should continue the task to completion as the Result will still have value, even though it may be diminished

Understand

Real-time

Cannot simply mean real fast Must mean predictably responsive Must determine whether or not that predictability is a hard or soft requirement

Application Types

The RTSJ (in its current form) is aimed at single applications running on single processors

The spec does not consider distribution or multiple CPUs or Cores

Application Categories

Normally, Real-time applications can be categorized one of three ways

Class I

Stateless Applications An application that does not have any state, the output depends entirely on the input Applications with a finite and Immutable Set of States Each state of the Application corresponds to a configuration or operational mode. These configurations and modes do not change over time and are completely known at design time Applications with Time Dependent State All applications not like the previous two classes, State changes often require memory allocations

Class II

Class III

Class I Applications

Class I Apps are characterized by the fact that all memory allocations are made while computing a result that can be discarded at the end of the computation For the RTSJ, Class I Apps can be implemented by relying only on Scoped Memory. Since the application has no persistent state, all allocations can happen in Scoped Memory

Class II Applications

Class II Apps are very similar to Finite State Automations Examples include control software, which might switch from one mode to another depending on height, phase of flight, etc For the RTSJ, Class II Applications can be implemented using Immortal Memory to store the persistent state of each mode

Class III Applications

An example of a Class III App can be as simple as an application that maintains a list of targets that have entered a monitored area and have not yet left that area. Targets could represent flights being tracked in an air space. Application state is defined by this variable set of targets, plus application specific data For the RTSJ, there is no easy way to map memory allocations for Class III Applications while maintaining automatic memory reclaimation

RTSJ Model

No problems with Class I or Class II Apps Class III Apps effectively defeat one of the main advantages of Java, its automatic memory management

In order to develop Class III Applications in the current RTSJ we must use some form of manual memory management

Conclusion

You usually see Input and Output processes (detections, sensing, ) as Class I, you may want to run them in their own JVM and CPU (or JVMs and CPUs) You usually see modal processing (fixed processing based on external events) as Class II, you may want to run these in their own JVMs and CPUs Many Class III apps are very difficult to classify above soft real-time. Many have to be separated into realtime and non real-time processes. Here you might have separate JVMs and CPUs

Four Questions

Why is the focus on predictability and not real-fast Why is Pre-emptive Priority Scheduling the primary offering in real-time vendor products Do you really know what Priority means When does real-time technology work well

Axiom

When a computer platform is not overloaded, almost any functionality can be made to work reasonably well. When the platform does become overloaded, its functionality can fail spectacularly This axiom applies to normal throughput platforms as well as real-time platforms