Performance Evaluation of Java Architectures in Embedded Real-Time Systems

Carlos Eduardo Pereira, Fernando HenriqueAtaide, Guilherme Oliveira Kunz

Federal University of Rio Grande do SulElectrical Engineering Department90035-190 Porto Alegre, RS, Brazil

{cpereira, fhataide,guilhermekunz I @eletro.ufrgs.br

Abstract

The embedded real-time development community isinvestigating different approaches in order to providemodularity and reuse features for system design in thisarea, as well as a more appropriate mapping techniquebetween requirements and implementation. The Javatechnology is very promising for this community,mainly after the research efforts on its real-timeextension RTSJ - Real-time Specification for Java.However, there are still some critic factors related tothe adoption of Java for real-time applications, andsome of them deserve special attention. This paperreports a study of some of these decisive factors, suchas the choice of the underlying Operating System, theuse of a middleware (virtual machine) or a native code,and the use of the Java real-time API (RTSJ).

1. Introduction

Embedded real-time systems are of utmostimportance nowadays due to its applicability in a greatvariety of safety-critical applications. This family ofsystems may deliver reliable services with predictabletime behavior even in the presence of faults. Amongmany design facilities the use of Java technology hasbeen emphasized due its desirable characteristics suchas reusability, modularity, easy maintenance, and soon. However, the use of Java for real-time systemdesign is not straightforward yet. The resulting timebehavior of the application depends not only on thecode but also on many other aspects like the underlingOS platform, the use of language extensions and theadoption of a virtual machine. It is important toperform a careful analysis of different designalternatives in order to take the best implementationdecision.

The main components related to design of Javaapplications could be assembled in a genericarchitecture consisting of three layers that representsthe application programming interface (API), thevirtual machine and the operating system.

Edison Pignaton Freitas, Elias Teodoro Silva Jr,Fabiano Costa Carvalho

Federal University of Rio Grande do SulComputer Science Institute

90501-970 Porto Alegre, RS, Brazil{ epfreitas, etsilvajr, fccarvalho } @inf.ufrgs.br

The complete knowledge of the entire architecturepresented in Figure 1 is desirable, since it can easilyorientate developers to take more cost-effective designdecisions. It is of fundamental importance to knowwhich layer has more positive or negative impact in thefinal performance.

This paper describes some experiment realizationson a set of different architecture configurations. Themain goal is to show with practical results how distinctdesign decisions can influence the resulting temporalbehavior of the system.

A P I

Figure 1. Generic Architecture

The remaining of this paper is organized as follows:section 2 presents some related works. In section 3, abrief description of the runtime architecture ispresented; section 4 provides the test configurationsused; section 5 describes the periodic thread test benchwhile section 6 describes the asynchronous eventhandling one. Section 7 presents the results of theperiodic thread test, and section 8 the results with theasynchronous RTSJ. Section 9 provides somecomments about RTSJ, and finally, section 10 offerssome final conclusions.

2. Related Works

Some previous works have analyzed performance ofdifferent RTSJ implementations.

Corsaro [1] presented results of bench tests withjRate in relation to the TimeSys reference model. In hiswork an implementation of RTSJ without JVM wasexplored, which are going to be explained in the nextsections.

0-7803-9402-X/05/$20.00 © 2005 IEEE 841 VOLUME 1

In the other hand, Fridtjof [2], working withJamaica set tools, presented a performance study ofreal-time application over an architecture using JVM.In his work no comparison was made with otherimplementation approach.

This work establishes a link between the two studiesrelated above, extending the comparison to differentimplementations in different system architectureconfigurations.

3. Architecture Components Description

Several options were analyzed in order to composethe set of API, Middleware and Operating System tothe proposed architecture. The following sub-sectionspresent those configurations that were evaluated.

3.1. API and Middleware

3.1.1. JDKThe Java Development Kit (JDK) is a package that

contains the Java Runtime Environment (JRE) [3]. It iscomposed of a small set of executables files thatprovides the standard Java platform.

The Java Runtime Environment is composed oflibraries, the Java Virtual Machine (JVM) and othercomponents that are necessary for the execution ofJava applications. The JRE does not have developmentutilities such as compilers and debuggers. Theseutilities are delivered together with the JDK.

The Java Virtual Machine (JVM) is the middlewareresponsible for the interpretation of the bytecodes. Theconcept of virtual machine allows Java applications tobe multi-platform. One of the main features deliveredby the JVM is thread synchronization that providesconcurrent programming mechanisms, automaticmemory allocation for new objects and garbagecollector.

3.1.2. GCJThe GCJ (The GNU Compiler for the JavaTM) [4]

is a front end for the GCC (GNU Compiler Collection)that can translate a Java code into native system code.Both GCJ and GCC are utilities distributed under GPL(GNU General Public License) and can be ported tomany architectures and operating systems.

Applications generated with the GCJ are linked tothe libgcj library, which provides all Java classes,garbage collector and bytecode interpreter. As a result,the final solution does not need the virtual machine,there is no need of middleware and it does not offersupport for language extensions.

Implementations without middleware (JVM) has theadvantage of increasing performance but lackingportability, that is, it is not possible to run theapplication over different operating systems withoutrecompiling.

3.1.3. jRateThe jRate (Java Real-Time Extension) [5] is an

extended utility that provides support for the Real-Time Specification for Java (RTSJ) [6].

jRate was included in this evaluation because it doesnot use Virtual Machine. Like GCJ, Java applicationscompiled with jRate are native executable code andplatform specific.

The RTSJ API, the garbage collector and the real-time threads are accessed through the GCJ and jRatelibraries. Unlike the GCJ, the jRate has only supportfor Linux OS and some of its real-time variants.

3.1.4. JamaicaThe Jamaica package [7] consists of an ensemble of

utilities to develop Java applications for real-timeembedded systems, delivered by Aicas [8]. TheJamaicaVM is the core of the package, which is avirtual machine implementation compatible with theRTSJ extension and with the Java standard. Jamaicawas first designed for real-time embedded applications.

This package has also other development utilities.One of them is the Builder Tool, which is responsiblefor building Java applications running directly on thenative operating system not needing any kind ofmiddleware. Actually, the application layer is tightlycoupled with the OS.

One of the most undesirable shortcomings of Javaapplication with time constraints is the lack ofdeterminism caused by the garbage collector control,which is a primary component of any virtual machine.The JamaicaVM implements the garbage collector in adifferent way, where it is executed in a predictablemanner like any other system thread. This designchoice was taken as an alternative of a final solutionthat runs on a virtual machine and explores the RTSJextension programming facilities.

Jamaica was chosen because it is a Javaimplementation that uses a virtual machine andsupports the RTSJ specification.

3.2. Operating System

3.2. 1. LinuxLinux is an operational system based on Unix,

which supports multiple tasks, virtual memory, sharedlibraries, memory management and IPv4 and IPv6support [9].

This OS was chosen because it is compatible withall Java implementations that will be analyzed in thispaper.

3.2.2. RTAIRTAI (Real-Time Application Interface) [10] [11] is

a patch applied to Linux, which gives the determinismrequired by real-time applications. With this patch, theconventional Linux tasks can only be executed when

VOLUME 1842

there is no real-time task waiting for the CPU. AllLinux tasks can be pre-empted by a real-time task anytime.

With RTAI patch, Linux has an extension of itsstandard environment defined by the RTHAL (Real-Time Hardware Abstraction Layer), and thus, theRTOS controls the interruptions, treating anddispatching them.

RTAI supports everything necessary to the real-timeprocessing related to task management and scheduling,inter process communication, periodic and oneshottimers, and interruptions.

RTAI was included in the experiment because itprovides real-time support on the Operating Systemlevel to compare GCJ, jRate and JDK evaluations.

3.2.3. QNXThe QNX Neutrino RTOS [12] is based on POSIX

specification with micro-kernel architecture. Theapplications are treaded as group of process (withseveral threads) that communicate by messages. Thismethod of changing messages is the primary manner ofinter-process communication (IPC) within this RTOS.

All services, except those provided by the micro-kernel or by the task manager, are manipulated bystandard process. Alike the method used by executionof threads, the micro-kernel is never scheduled. Theoperation system is completely pre-emptive, evenwhen process are sending messages, it will return in themessage that was stopped in the moment of pre-emption.

The Jamaica support for QNX RTOS was the mainreason to use it for the tests in this paper.

4. Environment Settings

Four different base arrangements (calledarchitectures) were tested, according to figure 2. Eachone of the architectures combines differentimplementations of the layers shown in figure 1.

a 2: Tests Configuration

When the analysis of a layer is made, it is necessaryto keep the other two layers unchanged, and vary theimplementation used by the layer under analysis.

The table 1 presents the comparative tests needed toanalyze each layer. The first line indicates tests toevaluate the effects of the use of RTSJ, or not. Thesecond line considers the presence of a Virtual

machine. Finally, the third line evaluates the supportprovided by RTOS.

The Java implementations used in the tests arepresented in the table 2 grouped by the operatingsystem used.

Test benches were executed on a Pentium III933MHz with 256MB of RAM. No extra loading wasincluded during the tests.

RTSJ GCJ X jRate JRE X Jamaica

Virtual Machine GCJ X JRE jRate X Jamaica

Operating jRate (Linux) X Jamaica (Linux) XSystem jRate (RTAI) Jamaica (QNX)

Table 1: Test Configurations

GNU Linux RTAI 3.1 (GNU QNX2.6.7 Linux 2.6.8.1) 6.2.1

a) JRE Sun JDK 1.4.2 Sun JDK 1.4.2 -

b) GCJ GCJ 3.3.5 GCJ 3.3.5

c) jRate JRate 0.3.6- JRate 0.3.6-3.3.33.3.3

d) Jama'ica IJamaica 2.4.10 Ja2.4.4Table 2: Evaluated Versions

5. Periodic Threads Test Bench

Considering timing as a critical feature in real-timesystems, the behavior of periodic thread was traced toanalyze the differences between architectures andconfigurations. All tests performed 500 samples.

Figure 3. Source Code: Standard JavaThread Implementation

In the standard Java tests the periodic thread was an

instance of the class TimerTasr (Figure 3), as definedin standard Java API. The Thread is activated by themethod scheduledAtFixedRate with a 100 milliseconds

VOLUME 1

Comparative Layer Table (configurations)

public class ThreadSUN11 class inicialization

static Timer timerTaskOl = new Timer(;public static void main(String[] args) I

TimerTask taskOl = new TimerTask(public void run(O

actTime[activation++]=java.lang.Math .abs(timers.microTimer.getmicrosecondso);

if (activation >= activationMAX)1 ...

timerTaskOl .cancel(;

timerTaskOl.scheduleAtFixedRate(task0l, O, 100); I

843

period and release time zero. To measure the time withthe necessary precision it was made a native method,using JNI, that captures time in microseconds. Itappears in the timers.microTimer.getmicrosecondso call.

In the RTSJ implementation it a RealtimeThreadobject was used. All timing parameters were defined asa RelativeTime instance. The period was established100 milliseconds like in the standard java test.Costtime and Deadtime parameters were equal toperiod because they were not under evaluation, neithermissing deadline nor thread cost feature. All timingparameters are grouped in the releaseParams object,which is an instance of the PeriodicParameters class.They are passed to the RealtimeThread object,rtThread, with the Runnable object testapp, whichconsists of the logical behavior of the thread. This logicis only a time capture and a call for thewaitForNextPeriod method. The rtThread is initializedby calling the start method, as can be seeing in figurenumber 4.

Figure 4. Source Code: RTSJ ThreadImplementation

6. Asynchronous Event Test Bench

Another critical feature in real-time systems is theasynchronous event handling. Once an event occurs, asystem with real-time requirements has to be able tohandle this kind of event as soon as possible.

In standard Java there is no class to handle explicitlyasynchronous events, so it was used the AWTInvocationEvent class with the dispatch method call, asshown in figure 5. The logic executed when an eventoccurs is contained in the Runnable object calledhandlerLogic. At the end of execution, the Start arraycontains the instants of the events occurrences and theStop array, the instants of the handler activation. Themeasured time shown in table 4 is the differencebetween the Stop and Start time.

Figure 5. Source Code: Standard JavaEvent Handling

Figure 6. Source Code: RTSJAsynchronous Event Handling

VOLUME 1

public class AsyncJaval11 class inicialization

public static void main(String [] args){Runnable handlerLogic = new Runnable( {

public void run(OStop[counterStop++] =

java. lang. Math .abs(timers m icroTimer.getm icrosecondso);} };

Object obj = new Object(;InvocationEvent event =

new InvocationEvent(obj,handlerLogic);for (int i=0; i<500; i++){

Start[counterStart++] =java. lang. Math .abs(timers m icroTimer.getm icrosecondso);

event.dispatch(;

HI...

public class ThreadRT11 class inicializationpublic static void main(String[] args)final Clock clock = Clock.getRealtimeClock(;RelativeTime starttime = new RelativeTime(0,0);RelativeTime periodtime = new RelativeTime(l 00,0);RelativeTime costtime = new RelativeTime(l 00,0);RelativeTime deadtime = new RelativeTime(l 00,0);PeriodicParameters releaseParams =

new PeriodicParameters(starttime,periodtime,costtime,deadtime,null,null);

Runnable testapp = new Runnable( {public void run(O

RealtimeThread rtThread=RealtimeThread.currentRealtimeThread(;

for (int i=0; < count; i++) IrtThread.waitForNextPeriod(;time[i] = clock.getTime(;

} } };RealtimeThread rtThread=

new RealtimeThread(null,releaseParams,null, null, null,testapp);

rtThread.start(;11...

public class AsyncRTSJ{public static void main(String [] args){final Clock clock = Clock.getRealtimeClock(;Runnable handlerLogic = new Runnable( {public synchronized void run(OtimerStop[counterStop++] = clock.getTime(;

} };AsyncEventHandler handler = null;handler = new BoundAsyncEventHandler(null, null, null,

null, null, false,handlerLogic);

AsyncEvent event = new AsyncEvent(;event.addHandler(handler);for (int i=0; i<count; i++){

timerStart[counterStart++] = clock.getTime(;event.fire(;

} 11

844

In the real-time implementation it was used theAsyncEvent class. The RTSJ has the notion of an eventhandler, that is materialized in the AsyncEventHandlerclass, which has some specializations likeBoundAsyncEventHandler. In code shown in figure 6,there is an AsyncEvent object, event, that add a classinstance of BoundAsyncEventHandler as its handler.The execution logic of this handler is within the runmethod of the handlerLogic Runnable object. Toinvoke the event, the method fire is called as shown infigure 6. The time measurement was just explained forstandard Java.

7. Periodic Thread Test Bench Results

7.1. Result PresentationThe results extracted from the execution of the test

bench can be resumed and divided in two sets, oneshowing what happened over the GNU Linux operationsystem, and other over an RTOS. The table 3 showsnumerical results (in milliseconds), divided accordingto the configurations and architectures described inSection 3.

Mean Standard MTBA______Deviation

Linux 100.000 3.009 130.126GCJ RTAI 100.001 1.742 120.570

Java SUN Linux 99.985 3.008 132.800RTAI 99.984 2.073 126.837

Jamaica Linux 99.999 3.314 134.324Jamaica_ QNX 99.999 0.121 100.184

Linux 100.984 0.056 101.220jRate RTAI 100.984 0.057 101.184

Table 3: Periodic Thread Results

The data presented in table 3, Mean, Standarddeviation and Maximum Time Between Activation(MTBA), provide the following information:

- How predictable and stable is the behavior ofeach architecture;

- How much variation can occur in a period of athread, and

- How the maximum activation time is far fromthe target value (100 milliseconds).

7.2. Result AnalysisFigures 7 and 8 show that the GCJ solution,

operating without virtual machine nor RTSJ support,has not too much satisfactory results, since its behavioris not stable. But it is important to mention that over anRTOS the results were better than over Linux.

The solution using the Sun JVM and standard JavaAPI and virtual machine, without RTSJ support , hasalso results that are not satisfactory for real-timeapplications. It has an unstable behavior and henceunpredictable, what can be observed in figures 9 an 10.

Comparing these results with those obtained with GCJ,it is possible to conclude that the GCJ solution has aslight advantage when running over an RTOS,although when both are running over Linux, nosignificant difference is noticed, as one could suppose.

1igr0eBe 4G

Figure 7. Periodic Behavior: GCJ over Linux

18P 20d3B 4G

Figure 8. Periodic Behavior: GCJ over RTAI

Figure 9. Periodic Behavior: Sun JVMover Linux

For the Jamaica solution, which uses virtualmachine and implements RTSJ, a great instability was

observed when the test bench was deployed on Linux,but when it was over an RTOS (QNX), the results were

very satisfactory, reaching real-time requirements. Thedifference between the behavior running over Linuxand RTOS can be observed in figures 11 and 12.

VOLUME 1

w

S U N

..

845

Figure 10. Periodic Behavior: Sun JVMover RTAI

Figure 11. Periodic Behavior: Jamaicaover Linux

Figure 12. Periodic Behavior: Jamaicaover QNX

The evaluation of jRate, which does not use virtualmachine and supports RTSJ, presented good stabilityover both platforms (Linux and RTOS). It isnoteworthy the fact that the mean was about onemillisecond over the target value. This strange, yetconsistent behavior, is reported by Corsaro [1] in hisexperiments, but with a 9 times greater difference.Figure 13 and 14 give a better comprehension of theanalysis made. There is almost no difference betweenthe execution over RTOS and Linux.

Figure 13. Periodic Behavior: jRate overLinux

Figure 14. Periodic Behavior: jRate overRTAI

The results show inter-dependency between thevirtual machine and the Operating system used. This isclear when comparing results obtained by Jamaicarunning over Linux and QNX. They have respectivelythe worst and the best results of all set. It can soundstrange at a first moment, but it reinforces the idea ofthis paper, the importance of the analysis of the three-layer architecture (API, Virtual Machine andOperating system) and their components.

8. Asynchronous Event Test Bench Results

8.1. Result PresentationThe results of this test bench follow the same layout

used in the section 6. They were divided in two sets,one showing what happened over the GNU Linuxoperating system, and other over an RTOS, accordingto the configurations and architectures described inSection 3. The table 4 shows numerical results (inmilliseconds).

The data presented in table 4 show the delaybetween the instant of an event occurrence and theinstant in which its associated run method really startsIn the first column is the Mean time while in thesecond the Standard Deviation. In the last column isthe Maximum Delay Time (MDT).

VOLUME 1

S U N

........... ioo"*H q. .........

... ... ...

J RA

... ... ...

J RA

... ...

846

Mean Standard MDTDeviation

GCJ Linux 0.001 0.001 0.009RTAI 0.001 0.001 0.012Linux 0.003 0.044 0.995Java SUN RTAI 0.004 0.047 1.061

Jamaica Linux 0.407 0.072 1.500________ QNX 0.194 0.395 1.000

Linux 0.029 0.055 1.250jRate RTAI 0.042 0.069 1.572

Table 4: Asynchronous Event Tests Results

8.2. Result Analysis

Analyzing the results of the Asynchronous Eventtest bench presented in table 4, one can have a bedsurprise. Every execution over a real-time operatingsystem was worst than those over a non real-timeoperating system. Something that can explain such badresults is the lack of a direct interface between SunJVM and GCJ with RTAI OS, besides the fact that theasynchronous event handling in real-time Javasolutions (Rate and Jamaica) requires from CPU a lotof processing effort, so the system scheduler couldhave bad influence in the general result for a processthat occupies the CPU for a long time. This analysis isdirectly influenced by the schedule policy that is beingused, i.e. FIFO, Round Robin, between others.

As one can observe in figure 16, the real-timeimplementation for asynchronous event handling has agreat overhead. Even thought it does not justify the badresults obtained, it is something to be remarked.

.. .......

1. 5 -

Figure 15. Asynchronous Event HandlingBehavior: Jamaica over Linux

Another very important fact to notice is that the JavaSun does not have a rigorous asynchronous eventhandling such as the one found in the RTSJ API. Thetest bench implemented to evaluate standard Java,shown in figure 5, was developed intending to be ascloser as possible to the one deployed on the RTSJAPI. At this point, the overhead question is also

important to be considered, because the standard Javadoes not have the same features provided by RTSJ.

Aicas was contacted in order to look for anexplanation for the strange results extracted from theJamaica evaluation, shown in figures 15 and 16. Aicasrelated that better results could be observed if theJamaicaVM Builder (that builds a native code for thehost target) were used, instead of the JamaicaVM.However, it was not the goal of this article analyze thisfeature, because it would eliminate the Virtual Machinelayer. Another point related by Aicas was the fact thatthe QNX version of Jamaica is under continuousdevelopment, so they are working to improve somefeatures in this version.

Analyzing figures 15 and 16, it is possible tounderstand better the values presented in table 4 forJamaica tests. Even though the Mean and the MDT arehigher in the Linux execution, it is noticeable theinstability when running over QNX in comparison tothe test over Linux. The Standard Deviation tries torepresent what is easy to see observing figures 15 and16.

.. ...........

...............................................................................................................................................

..............................................................................................................................................

...............................................................................................................................................

....5.

..- .... ..5.

Figure 16. Asynchronous Event HandlingBehavior: Jamaica over QNX

Figure 17. Asynchronous Event HandlingBehavior: jRate over RTAI

The jRate solution did not present a very goodperformance (it has the higher MDT), maybe due thesame reasons presented above to explain theperformance obtained in the other tests. Something that

VOLUME 1

JRIITE

847

is important to notice is the fact that the tests withjRate for asynchronous events over RTOS and Linuxwere very similar. For this reason it is only presentedthe graph of one of the tests in figure 17.

Graphs for GCJ and Sun JVM tests do not have tomuch information, all relevant information can be findin table 4. The graphs are quite similar and have only ahorizontal line close to zero (except for the respectiveMDT point of each test), so they are not presented inthe paper.

9. Comments on RTSJ Powerful

There are two other implicit factors not shown in theresults above. One is the expressiveness of the sourcecode when RTSJ is used. It provides a gain in theprogrammer's productivity once he/she does not needto have specific knowledge about the underling RTOS.The other is the code legibility provided by RTSJ, oncethe use of this API provides a clear mapping of thereal-time requirements over the application sourcecode. Figure 4 shows the source code used in the testwith RTSJ and, analyzing this code it is possible tounderstand the relation of each parameter with aprecise timing requirement. Using the standard JavaAPI it is not possible to express so precisely the sameset of real-time constraints as it is possible while RTSJis being used [13].

It is clear that as far as there are more symbols in alanguage, more difficult it is to understand it, but in theother hand, you have a richest set to express what youmean. In fact there is an optimal point in which it ispossible to have a rich language (and so veryexpressive), and at the same time clear to beunderstood, it means legible. Using the RTSJ API theprogrammer can find something very close to theoptimal point that meet expressiveness and legibility.

10. Concluding Remarks And FutureWork

This paper presented different alternatives to the useof Java Technology for real-time systemimplementation, with a spot over the performanceobtained by each layer of a proposed architecture underanalysis. It was possible to see that during the projectspecification phase, the three-layer analysis (API,Virtual Machine and Operating system) is veryimportant to achieve the desired performance.

The results show that when a three-layerarchitecture is adopted, if two of them have real-timesupport it does not assure real-time requirements. Inother words, during a project, if it is not possible toprovide real-time feature in all three layers, it is saferto adopt a two-layer architecture (without VM), asshown in the tests that used jRate and GCJ.

It can be observed in the result analysis that theRTSJ API is a powerful tool for the development ofreal-time systems with Java Technology. Besides theclearly mapping between real-time requirements andthe application source code, the offered timingconformity shows that the RTSJ is very efficient. Thereare much to be done to make the Java Technologycompletely able to be used in real-time system, but thepresent study and others, like those described in [14]and [2], indicate that Java will be a technologycompletely adequate to implement real-timerequirements in the near future.

The authors intend to perform some othercomplementary tests in order to evaluate other real-time features, like the memory allocation time,timeliness, and event handling, as well as making aprofound study - together with Aicas - of the reasonsfor those results presented for asynchronous eventtests.

References

[1] Angelo Corsaro and Douglas C. Schmidt, EvaluatingReal-Time Java Features and Performance for Real-time Embedded Systems, RTAS, 2002.

[2] Fridtjof Siebert, Real-Time Garbage Collection inMulti-Threaded Systems on a Single Processor, Aicas,2004.

[3] Sun Microsystems, JavaTM 2 SDK, Standard EditionDocumentation Version 1.4.2, User Manual, SunMicrosystems, 2003.

[4] GNU Compiler for Java, http://gcc.gnu.org/java/[5] Java Real-Time Extension, http://jrate.sourceforge.net/[6] RTSJ - Real-Time Specification for Java -

http:llwww.rtsj .org/specjavadoclbook_index.html[7] Fridtjof Siebert and Andy Walter, JamaicaVM - User

Documentation The Virtual Machine for Real-time andEmbedded Systems - User Manual, Aicas, 2004.

[8] Aicas RealTime, http://www.aicas.com[9] Linux homepage, http://www.kemel.org/[10] E. Bianchi, L. Dozio, P. Mantegazza. "History,

Motivations, and Overview of RTAI". Dipartimento diIngegneria Aerospaziale - Politecnico di Milano (Jan.3, 2000). In:<http://www.linuxdevices.com/articles/AT6298863382.html>

[11] DIAPM. "RTAI Beginner's Guide". In:<http://www.aero.polimi.it/-rtai/documentation/articles/guide.html> (Dec, 2003)

[12] QNX Software Systems, QNX Neutrino RTOS SystemArchitecture, User Manual, QNX Software SystemsLtd., 2004.

[13] A. Wellings, Concurrent and real-time programming inJava, John Wiley & Sons, 2004.

[14] Angelo Corsaro and Douglas C. Schmidt, The Designand Performance of the jRate Real-time JavaImplementation, DOA, 2002.

VOLUME 1848