Real Time Specification for Java

Echtzeitfähigkeit mit Java auf Systemen mit geringen Ressourcen

Seite: 2/3

Anbieter zum Thema

Zugriff auf die Systemuhr

Zweitens werden zur Bearbeitung von Zeiten keine Multiplikation und Division angeboten. Dies kann zu Einschränkungen der Implementierung von Applikationen führen. Neben HighResolutionTime wird die Klasse Clock angeboten. Sie bietet Zugriff auf die Systemuhr und kann die Genauigkeit dieser Uhr abfragen. Die Genauigkeit gibt das kleinste Zeitintervall an und damit die kleinste von der Systemuhr unterstützte Genauigkeit. Viele Systeme erreichen die theoretische Nanosekundengenauigkeit von Real-Time Java (RTJ) nicht.

Als dritte Zeitklasse neben HighResolutionTime und Clock wird die Klasse Timer mit OneShotTimer und PeriodicTimer angeboten. Ein OneShotTimer läuft nach dem Start exakt einmal und wird nach dem Auslösen eines asynchronen Events beendet. Ein PeriodicTimer läuft, sofern einmal gestartet bis zum expliziten Beenden weiter und wirft nach jedem Ablauf der eingestellten Zeit ein asynchrones Event. Daruch können einfache zyklische Tasks ersetzt und Ressourcen eingespart werden.

Speicherverwaltung und Speicherzugriff

Standard Java verfügt über ein Heap Memory, das durch den JGC regelmäßig gesäubert wird. Es verwirft Objekte im Speicher, auf die es zurzeit keine Referenzen gibt. Viele Objekte müssen in einem Echtzeitsystem dauerhaft angelegt werden, damit dynamische Speicherallokation vermieden wird. Außerdem ist ein JGC hinderlich, der ohne vorhersagbares Zeitverhalten mit hoher Priorität läuft und das System durcheinander bringt.

RTSJ bietet zwei Möglichkeiten: Die abstrakte Basisklasse heißt MemoryArea. Sie unterteilt sich in das bekannte HeapMemory, ImmortalMemory, ScopedMemory und ImmortalPhysicalMemory. Zur einfacheren Speicherverwaltung und -allokation wird noch die Klasse SizeEstimator definiert.

Das HeapMemory ist die geläufige Speichervariante in Java mit automatischer Speicherverwaltung und JGC Unterstützung. Es wird exakt einmal angelegt und hat eine statische Größe. Es ist nicht für harte Echtzeitanforderungen geeignet, kann aber für Programmteile ohne Echtzeitanforderung komfortabel Speicher zur Verfügung stellen.

Speicherbereich über die gesamte Laufzeit

Das ImmortalMemory ist ein Speicherbereich, der für die gesamte Laufzeit erhalten bleibt. Er wird nicht vom JGC gesäubert und damit auch nicht automatisch verwaltet, sondern muss vom Softwareentwickler bewusst genutzt werden.

Hier sind zwei Nachteile bekannt. Erstens gestaltet sich das Anlegen eines neuen Objektes für den herkömmlichen Javaentwickler umständlich und zweitens kann ein im ImmortalMemory angelegtes Objekt während der gesamten Laufzeit nicht mehr gelöscht werden. Das ImmortalMemory existiert ähnlich dem HeapMemory exakt einmal und hat eine statische Größe. Die dort angelegten Objekte können auch aus allen anderen Speicherbereichen angesprochen werden.

Das ImmortalPhysicalMemory ist in der Anwendungsweise dem ImmortalMemory sehr ähnlich, besitzt allerdings die Möglichkeit, Speicher mit speziellen Eigenschaften zu nutzen. Das ImmortalPhysicalMemory ist weder als Singleton definiert, noch statisch. Zur Verwaltung dieser Speicherbereiche wird der PhysicalMemoryManager zur Verfügung gestellt. Die Spezifikation des ImmortalPhysicalMemory ist allerdings noch nicht ganz ausgereift und wird von einigen VMs entweder noch nicht oder nur ansatzweise unterstützt.

Eingeschränkte Nutzung von Referenzen

Sollen Objekte ohne Einfluss des JGC und mit begrenzter Lebensdauer angelegt werden, empfiehlt sich das ScopedMemory. Diese Speicherbereiche bleiben nur erhalten, solange sie von einem SchedulableObject, wie einem Echtzeit Thread, referenziert werden.

Danach wird der Speicher wieder freigegeben und damit alle enthaltenen Objekte gelöscht. Dadurch kommt es zu Einschränkungen in der Nutzung von Referenzen. Objekte in einem ScopedMemory dürfen nur von Objekten im gleichen oder in einem untergeordneten ScopedMemory referenziert werden, keinesfalls jedoch von HeapMemory oder ImmortalMemory.

Das ScopedMemory wird noch einmal in vier Klassen unterteilt. Dabei unterscheidet man Memory und PhysicalMemory, das für speziellen Speicher konzipiert ist, sowie Speicher mit variabler (VT) und linearer Allokationszeit (LT). Daraus ergeben sich die vier Kombinationen VTPhysicalMemory, VTMemory, LTPhysicalMemory und LTMemory.

(ID:26657820)