Real-Time Programming with GNAT - DIT - Universidad Politécnica ...

Real-Time Programming with GNAT:Specialised Kernels versus POSIX ThreadsJuan A. de la Puente 1 , José F. Ruiz 1 , and Jesús M. González-Barahona 2 ,1 Universidad Politécnica de Madrid2 Universidad Carlos III de MadridE-mail: jpuente@dit.upm.es, jfruiz@dit.upm.es, jgb@computer.orgAbstractThe fact that most of the GNAT ports are based on non realtimeoperating systems leads to a reduced usability fordeveloping real-time systems. Otherwise, existing portsover real-time operating systems are excessively complex,since GNAT uses only a reduced set of their functionality,and with a very specific semantic. This paper describes theimplementation of a low-level tasking support for the GNATrun-time. In order to achieve a predictable real-timebehaviour we have developed a very simple library, built tofit only the GNAT tasking requirements. We have alsodesigned a bare machine kernel which provides theminimum environment needed by the upper layers.Keywords: Ada-95, GNAT, run-time system, real-timekernels1. IntroductionThe development of GNAT was a decisive step towards thewidespread availability of an efficient, high qualitycompiling environment to Ada programmers. The fact thatGNAT is free software is of great interest for researchers,since it allows new developments from existing sourcecode.Although GNAT provides an effective, high qualitycompiling environment for Ada 95, its usability for realtimesystems development is limited, as most of the GNATports are based on non real-time operating systems.Although all GNAT ports implement most of the Annex Cand D functionality, many important features, such as truepre-emptive priority scheduling, monotonic time, ceilinglocking, and kernel metrics, are not provided as specified inthe LRM. As a result, most GNAT implementations cannotbe used to program real-time systems with a predictablebehaviour.Looking at GNAT ports over real-time operatingsystems, we can cite RTEMS[8], a free real-time executivewith a POSIX interface and support for multiprocessorsystems. But it has been designed for a generic use, andthere is a big overhead and an excessive complexity whenusing it as low-level support for the GNAT tasking system.The most common way of implementing GNARL 1 is ontop of native threads (usually POSIX threads or Pthreadsfor short) for the given architecture. But GNAT taskingimplementation is very complete and specific, and whenimplementing GNARL on top of Pthreads there is a highoverhead motivated by the similar level of abstraction ofAda tasks and Pthreads[4]. Aside from the loss ofperformance, it increases the complexity, leading to adifficult measuring and bounding of the kernel metrics.Indeed, in the case of many embedded systems a fullblownimplementation of Pthreads is usually considered tobe too expensive, and then the existence of a reduced andsimple thread support could be of great help.Therefore, our purpose is to develop a very simple andefficient real-time support for the GNAT tasking system,adapted to its requirements. By not requiring support forthe more complex thread features, this approach permits animplementation with very tight efficiency and timingpredictability requirements. The library that implementsthe low level tasking (we call our library JTK from Jose’sTasking Kernel) provides GNARL semantics and is writtenin Ada 2 . The kernel that interacts with the underlyinghardware is written in C, with a small amount of assemblycode.Our intention is to provide a freely available test-bed forexperimentation in language, compiler, and run-timesupport for developers of real-time embedded systems.1. GNU Ada Runtime Library.2. About 1000 lines of code, not including test programs.

This is a first implementation to explore the validity of thisapproach.This paper is targeted on the real-time community.There is a previous paper[9] that describes more deeply themain design goals and implementation choices of JTKfrom a wider point of view.The remainder of this paper is organized as follows.Section 2 is a brief overview of the JTK architecture and itsintegration with GNARL. Section 3 explains the mainimplementation details of JTK and how they areimplemented. Section 4 shows some performance results toendorse the feasibility of our approach. Section 5concludes with a summary of assessments, comments andpossible future work of this implementation.2. The architecture of JTKOne of the goals of the GNARL development was toprovide an easily portable implementation, by means of alayered design. Each layer provides all of the taskingrelatedservices required by the next higher layer through aprocedural interface. The architecture independentcomponents are clearly separated from the machinedependent parts by means of a well defined interface,called GNULLI 1 [1].Therefore, the replacement of the lower-level taskingimplementation can be carried out in a very straightforwardmanner. There are two ways of implementing a new runtimesystem using this interface:• A GNULLI interface can be built for an already existingthread library. This is the most common approach tobuilding new non real-time GNAT ports. This is also theway the RTEMS and VxWorks ports have been built.This approach has clear advantages: most real-timeoperating systems have a POSIX.1c compliant interface,and it is currently well known how to build a GNULLIon top of Pthreads. However, it is neither efficient norclear for two main reasons: First, the Pthread interface isoften built as a library which masks the native threadinterface for the operating system. And second, theGNAT run-time library already provides a lot of supportfor tasks, and implementing the high level part ofGNARL on top of Pthreads induces abstractioninversion which causes inefficiency in theimplementation.• The other way to build a real-time GNARL is toimplement a minimum kernel for task support with a1. GNU Lower-Level Interface.GNULL interface, which does not make use of anythread mechanism from the underlying operatingsystem. We believe that this approach, although harderto implement, leads to more efficient and predictablerun-time support. Since GNARL provides most of thefunctionality needed for tasking, only the missing, lowerlevel functions, have to be implemented, which resultsin a comparatively small executive.At the lowest level, we have developed a very simplekernel that offers the functionality that a minimal real-timeoperating system should provide. It has also been designedto fit Ada tasks semantics as tightly as possible. In order toprovide an easily predictable environment, this kernel hasbeen designed with this objective in mind, from hardwareup. Therefore it operates in a single virtual address space(no paging), it does not have a file system, and the onlydevices supported are a timer and a serial port. Thesesimplifications eliminate unpredictable time delays due topage faults, waiting for completion of I/O, and I/Ocompletion interrupt processing[2].Ada 95 Application ProgramTimer ServiceGNU Ada Run-Time LayerGNU Lower-Level LayerJTK LibraryMinimum KernelBare ix86 MachineFigure 1. Structure of the developed GNATtasking system.JTK offers a priority driven scheduler with pre-emption.It has a FIFO queue for each priority level in order toprovide for scalability. Tasks run until they are blocked oruntil another task with a higher priority becomes ready toexecute.It also provides two basic synchronization methods:mutual exclusion and conditional synchronization. Formutual exclusion two kinds of mutex objects are provided:one operating as a simple binary semaphore, and the otherone using the Immediate Priority Ceiling Protocol, whichoffers the possibility for read and write locking. Forconditional synchronization, JTK implements conditionvariables, which are used by the timer and protectedobjects.The lower level task objects, as well as the scheduler,have been defined as tagged objects, so there is an easy andclean way of extending the implementation with newscheduling policies. There are different scheduling

schemes in the literature, none of them fitting all thedifferent kinds of applications. Therefore we have tried toestablish a flexible framework to allow the user toimplement the scheduling policy that is really needed.3. ImplementationWhen thinking about developing a real-time application,one of the most difficult aspects is bounding the worst-caseexecution time (WCET). To obtain analytically a tightmeasurement of this value, two issues are very important:to have access to the source code (application, run-timelibraries and operating system) and to work with animplementation as simple as possible. Since we areworking with GNAT the source code is accessible (ourlibraries and kernel are also free software), and simplicityis the most important issue that we have had in mind in ourdesign.The low-level task management exerts a high influenceon the overall behaviour of the whole system. Tasks changetheir execution states frequently and it is important toperform these actions in a predictable and efficient manner.In our implementation the ready tasks are kept in a queuesorted by priorities. When a task enters or exits the readystate, the system must insert or remove the task from theready queue. All ready queue operations are executed infast, bounded time, without need for search loops. In ourlibrary the kernel and tasks run in the same address space.It allows task switching to be very fast, and eliminates theneed for system call traps.Signal management is an important issue for improvingPthreads behaviour. GNARL has a very specific way ofmanaging signals[7], similar in many senses to the wayused by Pthreads. What happens is that GNARL doesalmost all the job on its own, and uses the low level supportin a minimal mode. Since Pthread does not offer thepossibility of a reduced use there is a lot of redundant andcomplex processing that obscures the measurement of thekernel metrics. Our approach is to notify the GNARL layerof the occurrence of the signal and let this layer process thesignal. All the low-level management has been reduced to aminimum. There is a table with a one-to-onecorrespondence between the waiting tasks and their relatedsignals, leading to a very simple and efficient signaldelivery model.As for the timer support, we have modified the GNARLlayer so that only one timer request can be issued at a time(using a timer server task). Therefore the underlying librarydoes not have to deal with more than one simultaneousrequest. This simplification leads to reducing the overheadinvolved in managing different queues, and to an easierway of understanding what these layers do. This alsomakes it easier to bound execution times. Moreover, theway used to program the timer is very similar to the way itis done in RT-Linux[10], achieving microsecond resolutiontimers.The implementation of Ada ATC (AsynchronousTransfer of Control) in GNARL is based on per-threadsignals (when it is layered over Pthreads). If we are usingJTK for low-level support the design can be simplified. Aswe have access to the saved state of the target task, andconsequently its program counter, we can change this stateto redirect control. The target task will begin the transfer ofcontrol as soon as it is next scheduled to execute.4. PerformanceTo evaluate the performance of this implementation wehave tested two kinds of programs as a first attempt:1. Two tasks which only perform context switches.The times reported are averages taken over 100000 iterations of each task.2. Two tasks executing 100 loops inside which theyperform a select statement with a delayalternative. The measurements indicate theamount of processor time that a third task coulduse normalized to the maximum value obtained.In this way, changing the value of the delayalternative produces results which are of the sameamount.The tests have been executed on the same machine(Pentium II at 233 MHz). The measurements have beentaken over three different GNAT implementations:1. GNAT 3.10p over JTK.2. GNAT 3.10p over Linux, using the FSUimplementation of Pthreads.3. GNAT 3.10p over DOS, using the FSUimplementation of Pthreads.Context switch time is a very important feature in realtimesystems, with a high influence on timing behaviour.The notion of cheap concurrency has been around inPthreads and related works, which try to offer lightweightprocesses. Figure 2 shows the results of the first test, fromwhich we can see that there is an increase of 170% ofefficiency in context switch time with respect to the Linuximplementation, and of 300% compared to the DOSimplementation.

3,5time for context switch(microseconds)32,521,510,5JTKPthreads over LinuxPthreads over DOS01 2 3 4 5 6 7 8 9 10trial numberFigure 2. Time taken by a task context switchnormalized free CPU utilization1.210.80.60.40.201 2 3 4 5 6 7 8 9 10JTKPthreads over Linuxtrial numberFigure 3: Free CPU when using select statements with a delay alternative

One aspect where we have tried to enhance is timemanagement. The second test is focused on showing ameasurement of this improvement. This test has not beenapplied to the GNAT port that uses Pthreads over DOSbecause it does not run well with priorities. In fact, theDOS implementation has not a true pre-emptive priorityscheduling. Figure 3 displays the results of this test, whichshow that there is an improvement of about 20% in theamount of CPU time which is needed for the execution ofdelay statements.Efficiency is certainly an issue, but in real-timeapplications predictability is the main problem. Figure 3has not enough resolution to show this aspect, but from theexperiments that we have carried out we have measured adifference between the best and the worst trial which isabout 350 times bigger on the Linux implementation thanon JTK.5. ConclusionWe have shown that it is possible to significantly improvethe predictability and efficiency of tasking in GNAT bydesigning a simple multitasking kernel which is directlytailored to support the Ada 95 functionality. By eliminatingdependence on Pthreads, we have achieved a bare machineimplementation with a predictable execution timing. Wealso have eliminated the very unpredictable delays due tooperating system processes. In summary, we believe thattrue real-time programming in Ada 95 is a real possibilitywith our approach.Of course, since the POSIX interface and semantics arenot used, there is a loss in portability and generality. Webelieve that is the price that has to be paid for improveddeterminism and efficiency, which is the primary goal ofreal-time systems.The JTK library is available from:References[1] T.P. Baker and E.W. Giering, GNU Low-Level InterfaceDefinition. Technical Report, Florida State University, June1993. Available by anonymous ftp from ftp.cs.fsu.edu.[2] T.P. Baker, Frank Mueller and Viresh Rustagi, Experiencewith a Prototype of the POSIX Minimal Realtime SystemProfile, Proceedings of the 11th IEEE Workshop on Real-TimeOperating Systems and Software, May 1994.[3] T.P. Baker, Dong-Ik Oh and Seung-Jin Moon, Low-Level AdaTasking Support for GNAT Performance and PortabilityImprovements, Wadas’96 Proceedings, 1996.[4] E.W. Giering and T.P. Baker, POSIX/Ada Realtime Bindings:Description of Work in Progress, In Proceedings of the NinthAnnual Washington Ada Symposium, ACM, July 1992.[5] Dong-Ik Oh and T.P. Baker, Gnu Ada’95 TaskingImplementation: Real-Time Features and Optimization, InProceedings of the 1997 Workshop of Languages, Compilersand Tools for Real-Time Systems (LCT-RTS), Las Vegas,Nevada, 1997.[6] Dong-Ik Oh and T.P. Baker, Optimization of Ada’95 TaskingConstructs, Triada’97, St. Louis, Missouri, 1997.[7] Dong-Ik Oh, T.P. Baker and Seung-Jin Moon, The GNARLImplementation of POSIX/Ada Signal Services, In Ada-Europe’96 Proceedings, pages 276-286.[8] On-Line Applications Research Corporation, RTEMSApplications C User’s Guide, Sep 1997, http://www.gnatrtems.com.[9] José F. Ruiz and Jesús M. González-Barahona, Implementinga New Low-Level Tasking Support for the GNAT RuntimeSystem, In Ada-Europe’99 Proceedings, Santander, Spain,June 1999.[10]V. Yodaiken, The RT-Linux Approach to Hard Real-Time.Available at http://rtlinux.cs.nmt.edu/~rtlinuxwhitepaper/short.html.ftp://ftp.dit.upm.es/str/software/jtk/and is covered by a modified GPL license. Moreinformation about the JTK library can be consulted at:http://www.dit.upm.es/~jfruiz/jtk.htmlAcknowledgmentsThis work has been partially supported by CICYT underproject TIC96-0614.