Since JamaicaVM 2.0, the Realtime Specification for Java (RTSJ) is fully supported, except for the PhysicalMemory classes. The specifiction is available at http://www.rtj.org/. The API documentation of the implementation can be found at http://www.aicas.com/jamaica/doc/rtsj_api/index.html.
The aim of the Realtime Specification for Java (RTSJ) is to extend the Java language definition and the Java standard libraries to support realtime threads, i.e., threads whose execution conforms to certain timing constraints. Nevertheless, the specification is compatible with different Java environments and backwards compatible with existing, non realtime Java applications.
The most important improvements of the RTSJ affect the following seven areas:
thread scheduling,
memory management,
synchronization,
asynchronous events,
asynchronous flow of control,
thread termination, and
physical memory access.
With this, the RTSJ also covers areas that are not directly related to realtime applications. However, these areas are of great importance to many embedded realtime applications such as direct access to physical memory (e.g., memory mapped I/O) or asynchronous mechanisms.
Thread Scheduling To enable the development of realtime software in an environment with a garbage collector that stops the execution of application threads in an unpredictable way, new thread classes RealtimeThread and NoHeapRealtimeThread are defined. These thread types are unaffected or at least less heavily affected by garbage collection activity. Also, at least 28 new priority levels, logically higher than the priority of the garbage collector, are available for these threads.
Realtime thread classes can interrupt garbage collector activity
Memory Management For realtime threads not to be affected by garbage collector activity, these threads need to use memory areas that are not under the control of the garbage collector. New memory classes, ImmortalMemory and ScopedMemory, provide these memory areas. One important consequence of the use of special memory areas is, of course, that the advantages of dynamic memory management is not fully available to realtime threads.
Synchronization In realtime systems with threads of different priority levels, priority inversion situations must be avoided. Priority inversion occurs when a thread of high priority is blocked by waiting for a monitor that is owned by a thread of a lower priority. The RTSJ provides the alternatives priority inheritance and the priority ceiling protocol to avoid priority inversion.
The RTSJ offers powerful features that enable the development of realtime applications. The following program shows an example how the RTSJ can be used in practice.
/* * Small demonstration of a periodic thread in Java: */ import javax.realtime.*; public class HelloRT { public static void main(String [] args) { /* priority for new thread: min+10 */ int pri = PriorityScheduler.instance().getMinPriority()+10; PriorityParameters prip = new PriorityParameters(pri); /* period: 20ms */ RelativeTime period = new RelativeTime(20 /* ms */, 0 /* ns */); /* release parameters for periodic thread: */ PeriodicParameters perp = new PeriodicParameters(null, period, null, null, null, null); /* create periodic thread: */ RealtimeThread rt= new RealtimeThread(prip, perp) { public void run() { int n=1; while (waitForNextPeriod() && (n<100)) { System.out.println("Hello "+n); n++; } } }; /* start periodic thread: */ rt.start(); } } |
In this example, a periodic thread is created. This thread becomes active every 20ms and creates a short output onto the standard console. A RealtimeThread is used to implement this task. The priority and the length of the period of this periodic thread need to be provided. A call to waitForNextPeriod() causes the thread to wait after the completion of one activation for the start of the next period. An introduction to the RTSJ with numerous further examples is given in the book by Peter Dibble [4].
The RTSJ provides a solution for realtime programming, but it also brings new difficulties to the developer. The most important consequence is that applications have to be split strictly into two parts: a realtime and a non-realtime part. The communication between these parts is heavily restricted: realtime threads cannot performnor memory operations such as the allocation of objects on the normal heap which is under the control of the garbage collector. Synchronization between realtime and non-realtime threads is heavily restricted since it could otherwise cause realtime threads to be blocked by the garbage collector.