Institut für Informatik Arbeitsgruppe Softwaretechnik Warburger Str Paderborn. Java Real-Time. Seminarausarbeitung im Rahmen des Seminars

Transkript

1 Institut für Informatik Arbeitsgruppe Softwaretechnik Warburger Str Paderborn Java Real-Time Seminarausarbeitung im Rahmen des Seminars Trends in der Softwaretechnik für Echtzeitsysteme Sommersemester 2003 von Stefan Scharberth Bodenfelder Str Uslar betreut von Dr. Holger Giese Paderborn, September 2003

2 Inhaltsverzeichnis 1 Einleitung Echtzeitsysteme Vorteile von Java Echtzeitfähigkeit von Java Realtime Specification for Java Aufbau eines Java RT Systems Speichermanagement HeapMemory ImmortalMemory Scoped Memory Mögliche Referenzen Threads Java Thread RealtimeThread NoHeapRealtimeThread Periodisch / Aperiodisch AysncEventHandler BoundAsyncEventHandler Scheduling PriorityScheduler ReleaseParameter Thread Synchronisation Priority Inversion Wait-Free-Queues WaitFreeWriteQueue WaitFreeReadQueue WaitFreeDeQueue Allgemeine Methoden Beispiel SteamBoiler Umsetzung mit Java RT Zusammenfassung und Fazit... 21

3 1 Einleitung 3 1 Einleitung Der Markt für Echtzeitsysteme (engl. realtime system) ist in den letzten Jahren stark gewachsen. Echtzeitsysteme werden in vielen Bereichen eingesetzt, von der Raumfahrt über Telekommunikation bis hin zu Haushaltsgeräten sind sie nicht mehr wegzudenken. Durch den ständig wachsenden Kostendruck, werden Firmen dazu gezwungen, Echtzeitsysteme immer effizienter zu entwickelt und schneller auf den Markt zu bringen. Aus diesen Gründen ist die Sprache Java sehr interessant für den Echtzeitbereich geworden, da es mit ihr möglich ist, schnell komplexe Software zu entwickeln. Bevor diese Arbeit jedoch näher auf Java und ihre Vorteile eingeht, werden erst einmal Echtzeitsysteme eingeführt. 1.1 Echtzeitsysteme Echtzeitsysteme werden dadurch charakterisiert, dass sie neben der Forderung ein korrektes Ergebnis zu liefern, Zeitrestriktionen einhalten müssen. Dies bedeutet, dass alle Aufgaben, die ein Echtzeitsystem erfüllen muss, Zeitvorgaben (engl. Deadline) haben. Es werden zwei Arten von Echtzeitsystemen unterschieden, harte und weiche. Unter harten Echtzeitsystemen werden solche Systeme verstanden, bei denen die Zeitvorgaben zu 100 % einzuhalten sind. Bei nicht einhalten ist das Ergebnis als falsch zu interpretieren, selbst wenn es korrekt ist. Harte Echtzeitsysteme werden dort eingesetzt, wo das Verfehlen von Zeitanforderungen katastrophale Folgen haben kann, z.b. Kernkraftwerk, Robotersteuerung oder Airbagsystem bei einem Auto. Bei weichen Echtzeitsystemen hingegen werden einzelne Verstöße gegen die Zeitvorgaben toleriert. Dies bedeutet, dass die Güte des Ergebnisses abgestuft wird, wenn es die Zeitanforderungen überschreitet. Weiche Echtzeitsysteme werden oft in Multimediabereich eingesetzt, z.b. bei Video- oder Audioübertragungen, wo eine kurze Verzögerung akzeptabel ist. Schaden Deadline Schaden Deadline Zeit harte Echtzeit weiche Echtzeit Abbildung 1-1: harte und weiche Echtzeit Zeit 1.2 Vorteile von Java Es existieren bereits viele Möglichkeiten Echtzeitsysteme zu entwickeln. Warum ist es also interessant Java Real-Time als Programmiersprache einzusetzen und nicht eine andere, bewährtere Sprache zu nutzen? In der Einleitung wurde bereits erwähnt, dass in den letzten Jahren ein immer größerer Kostendruck, bei der Entwicklung von Echtzeitsystemen, entstanden ist. Dies führt dazu, dass neben dem Kriterium sicher funktionierende Software herzustellen, immer mehr eine günstige und schnelle Entwicklung in den Vordergrund rückt. Genau hier hat Java seine Vorteile. Jeder, der schon einmal mit Java gearbeitet hat, kennt den Slogan write once run everywhere, der das bekannteste Feature von Java wiedergibt, die Portabilität. Portabilität bedeutet, dass der Java Bytecode ohne Veränderungen auf jeder Plattform ausführbar ist, falls eine Java Virtual Machine für diese Plattform existiert. Dies ist ein entscheidender Vorteil bei der Entwicklung, da jetzt nur noch eine Anwendung für alle

4 1 Einleitung 4 Plattformen programmiert werden muss. Auch die Wiederverwendung wird durch die Portabilität entscheidend verbessert, da man auch Klassen aus Projekten wieder verwenden kann, die für andere Plattformen entwickelt wurden. Weitere Vorteile von Java sind unter anderem Objektorientierung, Robustheit, Sicherheit, Dynamik und Verteilung. Um diese Vorteile zu vertiefen sei auf weiterführende Literatur [JavaNut97] verwiesen. 1.3 Echtzeitfähigkeit von Java Java hat sich in den letzten Jahren auf Grund der oben genannten Vorteile weit verbreitet und auch im Umfeld von Echtzeitanwendungen wurden Entwickler darauf aufmerksam. In der ursprünglichen Form ist Java für Echtzeitsysteme wenig geeignet. Das hat den Grund, dass es nie für den Einsatz in zeitkritische Anwendungen konzipiert war. Die folgenden Punkte stellen die Probleme von Java in Echtzeitsystemen dar. Speicherverwaltung: In Java gibt es nur einen Speicherbereich, den Heap Memmory in dem alle Objekte abgespeichert werden. Es gibt keine Möglichkeit die Lebensdauer von Objekten zu bestimmen, da der Garbarge Collector (GC) für das Löschen von nicht mehr referenzierten Objekten zuständig ist. Nichtdeterministisches Verhalten: Der Garbage Collector schaltet sich in undefinierten Zeitabständen ein und löscht nicht mehr referenzierte Objekte. Da der GC die höchste Ausführungspriorität in Java besitzt, verdrängt er den gerade ausführenden Thread auf unvorhersagbare Zeit. Dadurch ist die genaue Laufzeit der einzelnen Thread nicht bestimmbar. Scheduling: Der Java Scheduler genügt den Echtzeitanforderungen nicht. In Echtzeitsystemen müssen Startzeitpunkt, Deadline und Periode definiert werden können. In Java existiert nur die Möglichkeit einem Thread eine Priorität zu zuweisen oder ihn mit Thread.sleep(millSec) zu unterbrechen. Um Java trotz dieser Probleme in Echtzeit Systemen einzusetzen zu können, musste die Sprache erweitert werden. Diese Erweiterungen wurden in der Realtime Specification for Java [RTSJ00] zusammengefasst. 1.4 Realtime Specification for Java Bevor die Realtime Specification for Java entwickelt wurde, wurden Richtlinien für diese Spezifikation festgelegt. Zu diesen Richtlinien gehören: Abwärtskompatibel, d.h. es sollen Standard Java Programme uneingeschränkt lauffähig sein. Portabilität soll weiterhin unterstützt werden. Eine deterministische Ausführung von Java Code muss möglich sein. Es soll keine syntaktische Erweiterung geben, wie z.b. neue Schlüsselwörter. RTSJ soll den aktuellen Stand der Echtzeitentwicklung abdecken und für spätere Erweiterungen offen sein. In Realtime Specification for Java werden die die Erweiterungen beschrieben, die vorgenommen wurden, um Java echtzeitfähig zu machen. Für diese Echtzeiterweiterungen musste eine Ergänzungen der bestehenden API (Application Programming Interface) vorgenommen werden. Die neue API wird dem Programmierer im dem Package javax.realtime.* zur Verfügung gestellt und beinhaltet unter anderen echtzeitfähige Threads und neue Speicherbereiche. Die wichtigsten Erweiterungen, die das Package zur Verfügung stellt, werden in den Kapiteln Speichermanagement, Threads, Scheduling und Thread

5 1 Einleitung 5 Synchronisation vorgestellt. Um diese Erweiterungen nutzen zu können, wird ein echtzeitfähiges System benötigt. Der Aufbau eines solchen Systems wird im folgenden Kapitel, Aufbau eines Java RT Systems, vorgestellt. 1.5 Aufbau eines Java RT Systems Der Aufbau eines Java Echtzeitsystems besteht aus den drei Schichten Echtzeitbetriebsystem (Realtime Operation System, RTOS), Echtzeit Java Virtual Machine (TJVM 1 ) und Java Sourecode bzw. Java Libraries. Die unterste Schicht bildet das Echtzeitbetriebsystem. Es dient als Schnittstelle zwischen der Hardware und der TJVM. Weiterhin stellt das RTOS einen Scheduler zur Verfügung welches den entscheidenden Unterschied zu einen nicht echtzeitfähigen Betriebsystem (OS) ausmacht. In der mittleren Schicht ist die TJVM, die als Laufzeitumgebung für das Java Echtzeitprogramm dient. Die Unterschiede zu einer normalen JVM bestehen darin, dass die TJVM die Echtzeiterweiterungen, die im Package javax.realtime.* zusammengefasst sind, unterstützt. In der obersten Schicht befindet sich der Java Sourcecode und die zur Verfügung gestellten Java Libraries. Bei einem Echtzeitsystem enthalten die Libraries zusätzlich das Package javax.realtime.*, welches bei Java RT einfach importiert werden kann. Damit stehen dann alle Echtzeit spezifischen Erweiterungen für Java zur Verfügung. Java Application Java Libraries Java Application Java + JavaRealTime Libraries JVM TJVM OS RTOS Abbildung 1-2: Java und Java RT Schichten In den folgenden Kapitel dieser Arbeit wird eine Übersicht über die wichtigsten Echtzeit Erweiterungen von Java RT gegeben. Das Kapitel Speichermanagement zeigt die Erweiterung des Speicherbereiches. Es wird vorgestellt wie die Lebensdauer von Objekten vom Garbage Collector entkoppelt werden kann. Im Kapitel Threads wird gezeigt, wie Threads eine höhere Priorität wie der Garbage Collector erhalten können, damit sie ein deterministisches Verhalten bekommen. Außerdem geht dieses Kapitel darauf ein, wie den Threads Zeitvorgaben zugeteilt werden können. Das Kapitel Scheduling werden die Scheduling Parameter der Threads erläutert und der Standard Java RT Scheduler, der PriorityScheduler, wird vorgestellt. Da in Echtzeitsystemen mehrere Threads existierten können, müssen diese untereinander synchronisiert werden. Das Kapitel Thread Synchronisation beschriebt wie Echtzeit Threads untereinander und Echtzeit Threads mit normalen Java Threads synchronisiert werden können. Zum Schluss dieser Arbeit wird im Kapitel SteamBoiler Beispiel eine Beschreibung 1 Timesys Java Virtual Machine. Timesys ist das Unternehmen welches die erste Referenz Implementation von RTSJ auf den Markt gebracht hat. [TS]

6 1 Einleitung 6 eines Echtzeitsystems und dessen Umsetzung in Java RT gegeben. Zu diesem Beispiel existiert eine Implementation, die im Anhang zu finden ist. 2 Speichermanagement in Java RT In Java werden alle Objekte im Heap Speicher angelegt, der vom GC verwaltet wird. Da der Heap deswegen nicht echtzeitfähig ist, wurden in der RTSJ zusätzlich neben dem Heap Memory zwei weitere Speicherbereiche definiert, Immortal Memory und Scope Memory. 2.1 Heap Memory Jede echtzeit JVM und jede normale JVM hat genau eine HeapMemory Instanz. Der Vorteil des Heapspeichers besteht darin, dass der Programmierer nicht selbst den Speicher verwalten muss, da diese Arbeit der GC übernimmt. Objekte können mit dem Aufruf new Class() angelegt werden. Auf alles was darüber hinaus geht, hat der Programmierer keinen Einfluss mehr. Da der GC den Heap Memory verwaltet, hat er von allen Threads, die diesen Speicherbereich benutzen, die höchste Priorität. Dies führt dazu, dass er alle Thread für unbestimmte Zeit verdrängen kann, die auf dem Heap arbeiten. Dadurch ist eine Ausführung von harten Echtzeitanwendungen auf dem Heap Memory nicht möglich. Lediglich für weiche Echtzeitanwendungen, wo eine Verzögerung durch den GC toleriert werden kann, ist dieser Speicherbereich geeignet. Wenn ein Java RT Anwendung gestartet wird, befindet sie sich zunächst im Heap Memory. Das bedeutet, wird ein neues Objekt angelegt, so liegt dieses im Heap. Wurde der Heap Memory durch deinen Speicherwechsel verlassen ist es weiterhin möglich darin Objekte anzulegen oder java.lang.runable auszuführen, wie das folgende Beispiel zeigt. HeapMemory hm = HeapMemory.instance(); //Referenz auf Heap Memory holen hm.enter(runable); // ein Runable im Heap ausführen, Threads Object obj = hm.newinstance(class); //ein Objekt im Heap anlegen 2.2 Immortal Memory Wie auch beim Heap Memory existiert in einer echtzeit JVM nur eine ImmortalMemory Instanz. Der Unterschied zu dem Heap Memory besteht darin, dass der GC keinen Zugriff auf diesen Speicherbereich hat. Hier angelegt Objekte existieren bis zum Ende der Anwendung. Es gibt keine Möglichkeit vor Ende der Applikation das Objekt aus dem Speicher zu entfernen. Aus diesem Grund sollten man hier nur Objekte angelegen, die während der gesamten Anwendung gebraucht werden. Da der GC auf diesen Speicherbereich keinen Zugriff hat, ist er für harte Echtzeitanwendungen geeignet. Hier angelegte Objekte dürfen auch auf Objekte im Heap Memory oder auf andere Objekte im Immortal Memory referenzieren. Im Heap angelegte Objekte ist es ebenfalls gestattet auf Immortal Objekte zu verweisen. Die Ausführung von java.lang.runable Klasse und das Anlegen eines Objektes im Immortal Memory, falls sich der aktuelle Thread in einem anderen Speicherberich befindet, ist analog zum Heap Memory. //Referenz auf Immortal Memory holen ImmortalMemory im = ImmortalMemory.instance(); im.enter(runable); // ein Runable im Immortal ausführen Object obj = im.newinstance(class); // ein Objekt im Immortal anlegen

7 3 Threads Scoped Memory Anderes als bei Immortal und Heap können vom Scoped Memory mehrere Instanzen in einer echtzeit JVM existieren. Der GC bereinigt den Scope nicht automatisch, daher ist er für harte Echtzeitanwendungen verwendbar. Ein Objekt im Scoped Memory hat aber dennoch eine beschränke Lebenszeit. Jeder Scoped Memory hat einen Referenzzähler, der angibt wie viele Threads Zugriff auf ihn haben. Hat der Zähler den Wert Null, so werden alle Objekte, die sich in diesem Scoped Memory befinden gelöscht. Es besteht keine Möglichkeit einzelne Objekte zulöschen, nur der komplette Scope kann gelöscht werden. In einem Scope können weitere Scopes angelegt werden, diese werden dann als Children und der Erzeuger als Parent bezeichnet. Es ist möglich, dass ein Scope beliebig viele Children hat, aber er besitzt einen eindeutigen Parent Scope. Diese Verschachtelung von Scope Bereichen wird auf einen Stack abgebildet wie die Abbildung 2-1 zeigt. T1 A T2 A A Parent B D B D C E C Abbildung 2-1: Scope Stack E Child Thread T1 befindet sich im Scope C, der B als Parent hat. Thread T2 befindet sich im Scope E, der D als Parent hat. Die beiden Scope Bereiche B und D haben einen gemeinsamen Parent Scoped A. Auch A hat einen Parent Scope, den so genannten Primordial-Scope, der den Heap und Immortal repräsentiert und gleichzeitig das unterste Element im Stack darstellt. Referenzen auf Objekte eines Scope Bereichs sind nur aus dem gleichen Scope oder aus einen seiner Child Scopes möglich. Das bedeutet das Thread T1 Referenzen auf Objekte im Bereich C, B, A, Heap und Immortal haben kann, aber nicht auf Objekte aus D und E. Analog für Thread T2, er darf Referenzen auf die Scopes E, D, A, Heap und Immortal haben, aber nicht auf B und C. Falls ein Thread T3 im Scope B existiert, kann er auf Objekte in B, A, Heap und Immortal referenzieren aber nicht auf C, da C ein Child Scope von B ist somit nicht referenziert werden darf. Diese Einschränkungen haben den Grund, dass eine Referenz nie länger existieren darf als das Objekt auf welches referenziert wird. Da im Scope Stack immer nur der oberste Scope gelöscht werden kann, dürfen aus einem Scope alle Objekte referenziert werden die in Scopes darunter liegen, da diese mindestens genau so lange existieren wie die Referenz. Würde Java RT das Referenzieren des darüber liegenden Scopes erlauben, so kann es passieren, dass eine Referenz auf ein Objekt zeigt welches nicht mehr existiert. Dies würde zu einem Fehler führen und ist deswegen verboten. Zugriff auf einen Scopebereich haben damit alle Thread die in dem selben Scope oder in einem darüber liegenden Scope laufen. Existieren keine Thread mehr in diesen Scopes, so ist der Referenzzähler auf Null und alle Objekte im Scope werden gelöscht. Den Zugriff auf einen darunter liegenden Scope zeigt das folgende Beispiel:

8 3 Threads 8 // die aktuelle Stack tiefe int depth = RealtimeThread.getMemoryAreaStackDepth(); // hole den eine Referenz auf den Parent Scoped MemoryArea mem = RealtimeThread.getOuterMemoryArea(depth - 1); Object obj = mem.newinstance(class); // ein Objekt im ParentScope anlegen Vor der Benutzung eines Scoped Memories, muss er erst einmal angelegt werden, dass geschieht durch eine Objekt Erzeugung der Klasse LTMemory oder VTMemory. LTMemory mem = new LTMemory( 1024 * 16, 1024 * 16); Dieser Aufruf legt einen neuen Scoped Memory mit der Größe von 16 Kilobyte an wobei der erste Parameter die initiale Größe und der zweite Parameter die maximale Größe angibt. Wie schon erwähnt existieren zwei Arten von Scope Memories LTMemory (linear time memory) und VTMemory (variable time memory). Der Unterschied zwischen den beiden Speicherarten ist der Algorithmus der den freien Speicher verwaltet. Der LTMemory garantiert eine lineare Zeit bei der Zuordnung eines neuen Objektes zu dem noch freien Speicher. Die Zeit ist dabei abhängig von der Größe des neuen Objektes. Beim VTMemory kann der Programmierer einen eigenen Algorithmus verwenden, um den Speicher zu verwalten, näheres dazu [Dib02]. Da alle Objekte in einem Scope Memory gelöscht werden, wenn sich kein Thread mehr in ihm befindet, bietet er somit eine Möglichkeit dynamische Datenstrukturen in harter Echtzeit zu verwenden. Das folgende Beispiel ist aus dem [Dib02] entnommen und zeigt die Run Methode eines Threads, die bei jedem Schleifendurchlauf eine Runnable Klasse in einem Scoped Memory ausführt. Nach jeder Ausführung wird der Scope Bereich wieder verlassen und somit werden alle Objekte in ihm gelöscht. Beim nächsten Schleifedurchlauf steht somit wieder ein leerer Scope zur Verfügung. public void run() { LTMemory mem=new LTMemory(1024*16, 1024*16) //Scoped Memory anlegen while (true) { mem.enter (java.lang.runnable); // Runnable im Scope ausführen } } 2.4 Mögliche Referenzierungen zwischen den Speicherbereichen Wie schon bei den einzelnen Speicherbereichen kurz erwähnt, besteht die Möglichkeit, dass Objekte aus anderen Speicherbereichen referenziert werden können. Ein Objekt das in einem Scope Memory liegt kann beispielsweise eine Referenz auf ein Objekt im Immortal Memory besitzen, aber ein Objekt im Immortal Memory darf keine Referenz auf ein Objekt in einem Scope Memory halten. Der Grund für diese eingeschränkten Referenzierungen ist, dass so keine Referenzen länger existieren können als die Objekte auf die sie referenzieren. Die nachstehende Tabelle gibt einen Überblick über alle Referenzen die in RTSJ erlaubt sind.

9 3 Threads 9 Referenz zum Heap Referenz zum Referenz zum Immortal Scope Heap Ja Ja Nein Immortal Ja Ja Nein Scope Ja Ja eingeschränkt 2 Abbildung 2-2: mögliche Speicherreferenzen 3 Threads Um das Problem zulösen, dass Threads vom Garbage Collector verdrängt werden können, wurde die Java RT API um zwei neue Threads erweitert. Neben dem normalen Java Thread gibt es in Java RT noch zwei weitere Threads, die für Echtzeitanwendungen geeignet sind. Die beiden neuen Threads, RealtimeThread und NoHeapRealtimeThread, erben vom normalen Java Thread und haben spezifische Echtzeit Erweiterungen. In folgenden Kapitel werden alle drei Threads mit ihren Eigenschaften und ihren Anwendungsbereichen vorgestellt. Thread RealtimeThread NoHeapRealtimeThread Abbildung 3-1: Thread Hierarchie 3.1 Java Thread Für nicht zeitkritische Aufgaben ist es weiterhin möglich einen normalen Java Thread zu verwenden. Dieser hat immer eine niedrigere Priorität als ein Echtzeit Thread und bekommt daher nur Ausführungszeit zugewiesen, wenn alle Echtzeit Threads abgearbeitet sind. 2 Eingeschränkt bedeutet, Referenzen auf den gleichen oder im Stack darunter befindliche Scopes sind möglich.

10 3 Threads 10 Priority NoHeap Realtime Thread Realtime Thread Thread Garbarge Collector Realtime No Realtime Abbildung 3-2: Thread Prioritäten 3.2 RealtimeThread Ein RealtimeThread eignet sich nur für weiche Echtzeitanwendungen, da er eine niedrigere Priorität als der GC hat und jederzeit durch ihn unterbrochen werden kann. Der Vorteil von der niedrigeren Priorität ist, dass er den Heap Speicher weiterhin benutzen kann, was nicht möglich wäre wenn er eine höhere Priorität als der GC hätte. Wie schon im Kapitel Speichermanagement erwähnt, hat der Heap Memory den Vorteil, dass der GC die gesamte Verwaltung dieses Speichers übernimmt und dem Entwickler somit die Arbeit erleichtert. Die wichtigsten Unterschiede zu einem normalen Java Thread sind, dass er einen anderer Prioritätsbereich hat und das ihm Zeitrestriktionen vorgegeben werden können. Während ein Thread eine Priorität von 1 bis 10 besitzt, hat ein Realtime Thread eine Priorität über 11. Diese wird beim Erzeugen des Threads mit dem Scheduling Parameter gesetzt. Die Zeitrestriktionen werden durch den Release Parameter dem Thread übergeben. Der Parameter beinhaltet eine Startzeit, eine Periode, eine Deadline, eine maximale Ausführungszeit, ein OverRunHandler und ein MissHandler. Auf die Bedeutung der einzelnen Release Parameter wird im Kapitel Scheduling genau eingegangen. Zusätzlich zu einem normalen Thread bietet ein RealtimeThread die Möglichkeit an, dem Konstruktor den Speicherbereich (engl. memoryarea) zu übergeben in dem der Thread gestartet werden soll. Es können Instanzen von allen drei Speicherbereichen, Heap, Immortal und Scope, übergeben werden. So kann der neue Thread in einen anderen Speicherbereich wie der aktuelle Thread erzeugt werden. Ein weiterer Parameter, der Speicherparameter (engl. memoryparameter), spezifiziert die Speicherbeschränkungen. Über diesen Parameter kann eine maximale Grösse des ImmortalMemory beziehungsweise des HeapMemory angegeben werden, die der Thread benutzen darf. Wird dieser Parameter nicht gesetzt, so darf der Thread beliebig viel Speicher verwenden. Bei der Thread Erzeugung kann der Thread einer Gruppe zugeteilt werden. Dies geschieht mit dem ProcessingGroupParameter. Der ProcessingGroupParameter besteht, wie auch der ReleaseParameter, aus einer Startzeit, einer Periode, einer Deadline, einer maximalen Ausführungszeit, einem OverRunHandler und einem MissHandler. Soll ein Thread einer Gruppe zugeteilt werden, so wird dem Konstruktor des Thread, die Referenz auf das ProcessingGroupParameter Objekt übergeben. Alle Threads, die das gleiche ProcessingGroupParameter Objekt bekommenhaben, befinden sich in der selben Gruppe. Ein Vorteil der Gruppeneinteilung ist beispielsweise, dass mehrere Threads eine gemeinsame

11 3 Threads 11 maximale Ausführungszeit haben. Dies bedeutete, steht der Gruppe 200 Millisekunden Ausführungszeit zur Verfügung und verbraucht der erste Thread davon 80 Millisekunden, so haben die restlichen Threads dieser Gruppe noch 120 Millisekunden zur Verfügung. Im folgenden Beispiel wird die Erzeugung eines Realtime Thread dargestellt. Die Priorität und die Release Parameter wurden zur Vollständigkeit in diesem Beispiel mit aufgenommen. Eine ausführliche Beschreibung dieser Parameter folgt im Kapitel Scheduling. //Priorität setzen PriorityParameters priority = new PriorityParameters (50); //Release Parameter RelativeTime start = new RelativeTime (200, 0); RelativeTime period = new RelativeTime (500, 0); RelativeTime deadline = new RelativeTime (300, 0); RelativeTime cost = new RelativeTime (100, 0); //maximale Ausführungszeit MyMissHandler mmh = new MyMissHandler(); MyOverrunHandler moh = new MyOverrunHandler(); PeriodicParameters periodic = new PeriodicParameters (start, period, cost, deadline, mmh, moh); //Einen neuen Scope Speicherbereich mit der Größe 1 MB anlegen. LTMemory memoryarea = new LTMemory (1024 * 1024, 1024 * 1024); //Ein ProcessingGroupParameter Objekt erzeugen RelativeTime groupstart = new RelativeTime (200, 0); RelativeTime groupperiod = new RelativeTime (500, 0); RelativeTime groupdeadline = new RelativeTime (300, 0); RelativeTime groupcost = new RelativeTime (100, 0); MyMissHandler groupmmh = new MyMissHandler(); MyOverrunHandler groupmoh = new MyOverrunHandler(); ProcessingGroupParameter processinggroupparameter = new ProcessingGroupParameter ( groupstart, groupperiod, groupcost, groupdeadline, groupmmh, groupmoh); //Speicherbeschränkungen festlegen // kein Immortal Speicher, keine Speicherbeschränkung bei Heap MemoryParamters memoryparamters = new MemoryParamters( MemoryParamters.NO_MAX, //Heap 0); //Immortal //Thread erzeugen Realtimethread rt = new RealtimeThread( priority, // Priorität setzen periodic, // Zeitrestriktionen memoryparameters, // Speicherbeschränkungen memoryarea, // Speicherbereich processinggroupparameter, //Gruppenzuteilung java.lang.runnable); 3.3 NoHeapRealtimeThread Im Gegensatz zum RealtimeThread ist der NoHeapRealtimeThread für harte Echtzeitanwendungen geeignet. Er hat eine höhere Priorität als der GC und kann daher nicht von ihm verdrängt werden. Wegen der höheren Priorität kann er aber keine Objekte mehr auf dem Heap referenzieren. Genau wie der RealtimeThread hat er eine höhere Priorität als 11, aber der Entwickler ist selbst dafür verantwortlich dass alle NoHeapRealtimeThreads eine höhere Priorität haben als RealtimeThreads. Es darf nicht vorkommen, dass ein

12 3 Threads 12 NoHeapRealtimeThread eine Priorität von 50 hat und ein RealtimeThread eine Priorität von 60, da sonst der NoHeapRealtimeThread auch von dem GC verdrängt werden könnte. Außer der verschiedenen Priorität und dem Zugriff auf den Heap Memory sind die beiden Echtzeit Threads identisch. Aus diesem Grund wurde auf ein Beispiel für die Erzeugung eines NoHeapRealtimeThreads verzichtet. 3.4 Periodisch / Aperiodisch Eine Ausführung der beiden Echtzeit Threads, RealtimeThread und NoHeapRealtimeThread, ist periodisch und aperiodisch möglich. Aperiodisch bedeutet, der Thread wird in unregelmäßigen und unbekannten Zeitabständen gestartet. Bei einer periodischen Ausführung hingegen wird der Thread in gleichen Zeitabständen regelmäßig neu gestartet. Diese Abstände heißen Periode und können im Release Parameter angegeben werden. Ein periodischer Thread muss innerhalb seiner Periode beendet sein, da das System ihn sonst in der nächsten Periode nicht neu starten kann. Jeder periodische Echtzeit Thread sollte eine Schleife mit dem Methodenaufruf waitfornextperiod() enhalten. Der Thread legt sich mit diesem Befehl schlafen und wartet auf seine nächste Periode. Sobald die nächste Periode des Thread beginnt, wird dieser automatisch vom System geweckt und arbeitet einmal seine Schleife ab, bis er wieder zu waitfornextperiod() kommt. public void run() { while (true) {... waitfornextperiod(); } } 3.5 AysncEventHandler Zusätzlich zu den Threads gibt es in Java RT AsyncEventHandler (AEH) und AsyncEvent (AE). Diese beiden Klassen dienen dazu, um auf externe Ereignisse zu reagieren. Ein Plattform abhängiger Mechanismus informiert die echtzeit JVM über ein externes Ereignis, beispielsweise das Auslösen eines Interrupt. Jedes Ereignis bekommt einen Namen zugeteilt und kann über asyncevent.bindto( Ereignisname ) an ein Java AsyncEvent Objekt gebunden werden. Zwischen den AysncEvents und den AsyncEventHandlern besteht eine N zu N Beziehung, das heißt ein AE kann mehrere AEH starten und ein AHE kann auf mehrere AE warten. Mit dem Befehl asyncevent.addhandler(handler) kann ein AEH an ein AE gebunden werden. Bei der Erzeugung des Handlers wird per Parameter festgelegt ob ein RealtimeThread oder ein NoHeapRealtimeThread erzeugt wird, wenn der Handler aufgerufen wurde. AsyncEventHandler(boolean nonheap, java.lang.runnable logic); 3.6 BoundAsyncEventHandler Außer dem AEH gibt es noch den BoundAsyncEventHandler (BAEH). Der Unterschied besteht darin, dass beim BAEH in der Initialisierung ein Thread angelegt wird, der sobald ein Aufruf des Handlers erfolgt nur noch starten muss. Beim AEH wird bei jedem Aufruf ein neuer Thread erzeugt und anschließend gestartet. Nach der Ausführung wird der Thread wieder gelöscht. Der Vorteil eines BAEH ist die Reaktionszeit auf ein Ereignis, er kann schneller darauf reagieren, da alle Threads bereits existieren. Dem entgegen steht der Nachteil, dass dadurch mehr Ressourcen belegt sind.

13 4 Scheduling 13 4 Scheduling In einer Java Virtual Machine besteht die Möglichkeit beliebig viele Threads zu starten. Alle Thread brauchen für ihre Ausführung Systemressourcen, die sie vom Scheduler zugeteilt bekommen. Ziel ist es, eine Zuteilung der Ressourcen zu erreichen, so dass jeder Thread rechtzeitig abgearbeitet werden kann und das eine faire Verteilung der Systemressourcen stattfindet. In Java RT existiert eine abstrakte Klasse Scheduler von der alle konkreten Scheduler Implementationen erben. Neben dem Standard Scheduler, dem PriorityScheduler, bietet Java RT die Möglichkeit weitere eigene Scheduler zu implementieren. Dabei muss man selber darauf achten das eine Interaktion zwischen allen verwendeten Scheduler gewährleistet ist. Wie eine konkrete Interaktion aussehen könnte wurde nicht näher spezifiziert. Durch diese Architektur wurde aber erreicht, dass Erweiterungen einfach möglich sind. Alle konkreten Scheduler sind als Singelton zu implementieren, dass bedeutet, es kann nur eine Instanz von der Klasse existieren. Um eine Referenz auf das eine Objekt zubekommen bietet jeder Scheduler eine Static Methode instance() an. Jeder Thread hat genau einen Scheduler, der ihm die Ressourcen zuteilt. Mit dem Methodenaufruf realtimethread.setscheduler(scheduler) kann der Scheduler für einen Thread geändert werden. Wird keiner gesetzt, verwendet Java den Standard Scheduler, den PriorityScheduler. Außerdem bietet die Klasse Scheduler eine static Funktion Scheduler.setDefaultScheduler(scheduler) an, womit ein anderer Scheduler als Standard definiert wird. Bei neu erzeugten Threads verwendet Java RT jetzt den neue Standard Scheduler, wenn kein Anderer explizit gesetzt wurde. Auf bereits existierenden Threads hat dieser Wechsel keinen Einfluss, das bedeutet, falls ein existierender Thread den Standard Scheduler A bisher verwendet hat und der Standard Scheduler nun auf B wechselt, so bekommt er weiterhin den Prozessor von A zugeteilt. 4.1 PriorityScheduler Wie schon erwähnt ist der PriorityScheduler der Standard Scheduler in Java RT. Es ist der Einzige, den die RTSJ mit bestimmten Eigenschaften vorschreibt. Er muss prioritätsbasiert sein, das bedeutet, dass jeder Thread eine Priorität zugewiesen bekommt. Ein Thread mit einer höheren Priorität wird gegenüber einem Thread mit niedrigerer Priorität bevorzugt. Die Priorität kann beim Erzeugen festgelegt werden und ist während der Laufzeit veränderbar. Wird keine festlegt so übernimmt der neue Thread die Priorität vom Erzeugenden, sofern dies möglich ist. So kann z. B. ein NoHeapRealtimeThread die Priorität von einem anderen NoHeapRealtimeThread erben, aber nicht von einem RealtimeThread, da diese in unterschiedlichen Prioritätsbereichen liegen. Kann die Priorität nicht übernommen werden so gibt es für jeden Threadtyp eine Standardpriorität, die er zugeteilt bekommt. In der RTSJ wird vorgeschrieben, dass der PriorityScheduler neben den 10 Prioritäten für normale Java Threads, mindestens 32 Prioritäten für Echtzeit Threads zur Verfügung stellen muss. Der PriorityScheduler von der Firma Timesys [TS] bietet z. B. 255 Prioritäten an. Falls mehrere Thread die gleiche Priorität besitzen bekommt der Thread Vorrang, der zuerst die Systemressource angefordert hat, also First Come First Serve (FCFS). Zusätzlich muss der PriorityScheduler auch preemptives Scheduling unterstützen, das bedeutet, dass jederzeit ein höher priorisierter Thread den laufenden unterbrechen kann. Er muss also nicht warten bis der niedriger priorisierte Thread die Ressourcen selbst wieder frei gibt. Das folgende Beispiel zeigt wie die Priorität bei einem RealtimeThread gesetzt werden kann. //setze die Priorität auf 31 // MIN_PRIRORITY ist eine Konstante mit dem Wert 11 SchedulingParameter sched = new PriorityParameters( PriorityScheduler.MIN_PRIORTITY+20);

14 4 Scheduling 14 RealtimeThread rt = new RealtimeThread(sched); //verändern der Priorität auf 20 SchedulingParameter sched = new PriorityParameters(20); rt.setschedulingparameter(sched); Nach welchem Schedulingverfahren die Prioritäten den Threads zugewiesen werden ist dem Entwickler selbst überlassen. Es wird lediglich darauf verwiesen, dass das Rate Monotonic Verfahren bei periodischen Thread zu guten Ergebnissen führt. Das Rate Monotonic ordnet den Threads mit den niedrigsten Perioden die höchsten Prioritäten zu, näheres dazu kann [Dib02] entnommen werden. 4.2 ReleaseParameter Jeder Echtzeit Thread kann neben seiner Priorität auch ReleaseParameter besitzen. Im Release Parameter sind alle Zeitvorgaben spezifiziert, die der Thread einhalten muss. Da es periodische und aperiodische Echtzeit Threads gibt, müssen auch die ReleaseParameter in PeriodicParameter und AperiodicParameter unterteilt werden. Die PeriodicParameter setzen sich Zusammen aus der Startzeit, der Periode, der Deadline und der Ausführungszeit (starttime, period, deadline, cost). AperiodicParameter beinhalten dagegen nur eine Deadline und die Aufführungszeit. Alle vier Parameter sind Zeitrestriktionen, die mit Hilfe der Klasse RelativeTime gesetzt werden. RelativeTime starttime = new RelativeTime( 1000, 0); // Millisek., Nanosek. RelativeTime period = new RelativeTime( 100, 0); RelativeTime deadline = new RelativeTime( 50, 0); RelativeTime cost = new RelativeTime( 30, 0); Der Konstruktor von RelativeTime hat zwei Parameter, der erste ist Millesekunden und der zweite Nanosekunden. Im oberen Beispiel wurde der Parmameter starttime auf eine Sekunde, der Parameter period auf 100 Millisekunden usw. gesetzt. Zusätzlich zu den Zeitrestriktionen können auch zwei AsyncEventHandler im ReleaseParameter angegeben werden, ein MissHandler und ein OverrunHandler. MyMissHandler mmh = new MyMissHandler(); MyOverrunHandler moh = new MyOverrunHandler(); // für periodische Threads ReleaseParameter release = PeriodicParameter (starttime, period, deadline, cost, mmh, moh); // für aperiodische Threads ReleaseParameter release = AeriodicParameter ( deadline, cost, mmh, moh); // Thread erzeugen und starten RealtimeThread rt = new RealtimeThread( new PriorityParameters(15), // Priorität 15 release); // ReleaseParameter rt.start(); Die Startzeit (starttime) gibt die Verzögerung an zwischen dem Aufruf rt.start() und dem eigentlichen Starten des Threads an. Das heißt, wenn die Startzeit auf eine Sekunde gesetzt ist startet der Thread genau eine Sekunde nachdem rt.start() aufgerufen wurde. Falls keine Startzeit angegeben ist, startet der Thread sofort. Wie im Kapitel Thread schon erwähnt, haben alle periodischen Threads eine Schleife, die sie immer wieder durchlaufen. Am Ende dieser Schleife steht der Befehl waitfornextperiod() mit dem der Thread schlafen gelegt wird.

15 4 Scheduling 15 Der Parameter Periode gibt an, in welchem Zeitabstand die Periode des Threads neu beginnt. Der Scheduler weckt ihn auf und er kann einmal seine Schleife durcharbeiten bis er wieder zu waitfornextperiod() kommt. Die Deadline spezifiziert einen Zeitpunkt, an dem er Thread spätestens abgearbeitet sein muss. Ist die Deadline z. B. auf 50 Millisekunden gesetzt, so muss der Thread spätestens 50 Millisekunden nach seinem Startzeitpunkt abgearbeitet sein, sonst kommt es zu einem Fehler im Echtzeitsystem. Bei einem periodischen Thread muss die Deadline immer kleiner oder gleich der Periode sein, da sonst der Thread noch ausgeführt werden könnte, obwohl schon eine neue Periode für ihn begonnen hat, was nicht vorkommen darf. Ist keine Deadline angegeben, so wird sie bei periodischen Threads gleich der Periode. Der vierte Parameter gibt die maximale Zeit an, die ein Thread den Prozessor maximal benutzen darf, dieser wird als Kosten (engl. cost) bezeichnet. Zum Beispiel, wenn die Kosten 50 Millisekunden sind, darf der Thread zwischen seinem Startzeitpunkt und seiner Deadline maximal 50 Millisekunden ausgeführt werden. Daher müssen die Kosten immer kleiner oder gleich der Deadline sein. Die Ausführung kann dabei in mehrere Blöcke unterteilt werden, falls ihn ein höher priorisierter Thread unterbricht. Alle Blöcke müssen aber vor erreichen der Deadline abgearbeitet sein und dürfen zusammen nicht die maximale Ausführungszeit überschreiten. Falls ein Thread doch seine maximale Ausführungszeit überschreitet, führt das erstmal zu keinem Fehler, falls er seine Deadline einhält. Es besteht aber die Möglichkeit das andere Threads dadurch ihre Deadline verpassen, weil ihnen weniger Ausführungszeit zur Verfügung stand. Werden keine Kosten angegeben so werden sie automatisch auf die Deadline gesetzt. Hält ein Thread seine Zeitvorgaben nicht ein, so wird dies durch einen AsyncEventHandler behandelt. Der MissHandler startet, falls die Deadline verfehlt wurde und der OverrunHandler, wenn der Thread seine maximale Ausführungszeit überschreitet. Bei periodischen Threads wird die Periode während der Ausführung eines Handlers unterbrochen, kann aber durch den Aufruf realtimethread.scheduleperiodic() im Handler wieder gestartet werden. Wie ein Handler auf das Verfehlen der Vorgaben reagieren soll, muss der Entwickler selbst festlegen, da es von der jeweiligen Anwendung abhängig ist. Sind keine Handler angegeben so reagiert der Scheduler nicht auf das Verfehlen der Zeitvorgaben und arbeitet die Threads weiter ab. Thread1 Ausführungszeit > cost > overrunhandler Periode Thread2 deadline > misshandler Start Periode Abbildung 4-1: ReleaseParameter

16 5 Thread Synchronisation 16 5 Thread Synchronisation In einer Echtzeit Java Virtual Machine können Threads parallel laufen. Wenn mehrere Threads auf die gleichen Objekte oder Methoden zugreifen wollen, müssen diese Zugriffe synchronisiert werden, da diese sonst zu Problemen führen können, z. B. ein Thread verändert gerade ein Objekt während ein Anderer dieses gerade liest. Java RT benutzt wie auch Java, Monitore die einen kritischen Bereich überwachen. Ein kritischer Bereich wird mit synchronized { } definiert und darf nicht von zwei Thread gleichzeitig betreten werden. Tritt ein Thread in einen kritischen Bereich ein, sperrt der Monitor diesen für alle Anderen. Will ein Thread einen gesperrten Abschnitt betreten, so wird dieser blockiert und in die Warteschlange eingereiht. Ist der kritische Bereich wieder freigegeben, darf als nächstes der Thread mit der höchsten Priorität eintreten, der sich in der Warteschlage befindet. Habe Threads die gleiche Priorität so wird der Bevorzug, der schon länger wartet (First Come First Serve). 5.1 Priority Inversion Durch Monitore kann es vorkommen, dass höher priorisierter Thread von einem mit niedrigerer Priorität blockiert wird. Im ungünstigsten Fall kann es sogar passieren dass der höchst priorisierte Thread sogar auf alle Anderen warten muss. Dies kann vorkommen, wenn er in einen kritischen Bereich eintreten will, der aber von dem Thread mit der niedrigsten Priorität blockiert wird. Es werden erst alle Anderen ausgeführt bevor der Thread mit der niedrigsten Priorität den Prozessor bekommt und den blockierten Bereichs wieder frei gibt. Erst jetzt kann der höchst priorisierte Thread in den kritischen Abschnitt eintreten und sein Programm weiter abarbeiten. Dieser Effekt wird als Priority Inversion bezeichnet und muss in einem Echtzeitsystem verhindert werden. Um dieses Problem zu lösen existieren 2 Protokolle in Java RT, Priority Inheritance (PI) und Priority Ceiling Emulation (PCE). Beim PI Protokoll wird das Problem gelöst indem Prioritäten kurzfristig vererbt werden. Befindet sich ein Thread in einem kritischen Bereich, kann er die Priorität der Threads aus der Warteschlange erben, falls diese höher ist. Sind mehrere in der Warteschlange so wird die höchste Priorität verwendet. Nach Freigabe des Bereichs wird die Priorität wieder zurückgesetzt. Beim PCE Protokoll hingegen wird den einzelnen Ressourcen selbst eine Priorität zugeteilt. Sie sollte gleich der Priorität sein, die der höchst priorisierte Thread hat, der in diesen Abschnitt eintreten kann. Für ausführlichere Informationen über PI und PCE sei auf [Dib02] verwiesen. Im Gegensatz zu Java muss ein Java RT Monitor immer eins der beiden oberen Protokolle PI oder PCE verwenden. Dabei ist PI der Standard und wird von RTSJ verlangt. Falls PCE auch angeboten wird, kann der Entwickler entscheiden, für welches Protokoll für die jeweilige Ressource verwendet werden soll. MyClass mc = new MyClass(); // für PI PriorityInheritance pi = PriorityInheritance.instance(); MonitorControl.setMonitorControl(mc,pi); // für PCE - Priorität 27 PriorityCeilingEmulation pce = new PriorityCeilingEmulation(27); MonitorControl.setMonitorControl(mc,pce); Beide Protokolle lösen das Problem der Priority Inversion indem sie den Threads kurzfristig neue Prioritäten zuweisen. Das funktioniert nur unter der Voraussetzung, dass allen Threads die gleiche Priorität zugewiesen werden kann. In Java RT gibt es aber drei verschiedene Threads, die alle in unterschiedliche Prioritätsbereichen liegen. Ein normaler Java Thread kann nicht die gleiche Priorität besitzen, wie ein RealtimeThread. Deswegen können die beiden Protokolle nur zur Synchronisation zwischen gleichen Threads verwendet werden.

17 5 Thread Synchronisation Wait-Free-Queues Um zwei unterschiedliche Threads zu synchronisieren, bietet Java RT die so genannten Wait- Free-Queues an, die WaitFreeWriteQueue (WFWQ), die WaitFreeReadQueue (WFRQ) und die WaitFreeDeQueue (WFDQ). Alle drei Queues verbinden jeweils genau zwei Threads miteinander, wobei sich an jedem Ende der Queue genau ein Thread befindet. Beim Anlegen der Queue müssen dem Konstruktor beide Threads übergeben werden. Nur diese Threads können später über die Queue kommunizieren. Falls sich ein Kommunikationspartner ändert, muss eine neue Queue angelegt werden. Außerdem wird beim Erzeugen der Queue genau festgelegt welches Ende für welchen Thread bestimmt ist, dadurch wird verhindert, dass ein Thread auf das falsche Ende zugreifen kann. Alle Queues haben alle ein blockierendes und ein nicht blockierendes Ende. Werden zwei Threads aus unterschiedlichen Prioritätsbereichen damit synchronisiert, so sollte der Thread mit der höheren Priorität das nicht blockierende Ende bekommen, damit der niedrigere Thread ihn nicht bei seiner Ausführung behindern kann WaitFreeWriteQueue Die WaitFreeWriteQueue erlaubt ein nicht blockierendes Schreiben und ein blockierendes Lesen. Sie biete nur die Möglichkeit einer unidirektionalen Kommunikation, wobei der höher priorisierte Thread am nicht blockierenden Ende schreibt (Writer-Thread) und der niedriger priorisierte Thread am blockierenden Ende liest (Reader-Thread). Es können so nur Daten von einem höher priorisierten zu einem niedriger priorisierten Thread geschickt werden. Ein Anwendungsfall für diese Queue ist beispielsweise eine Visualisierung eines Echtzeitsystems. Die Visualisierung selbst muss dazu nicht unbedingt in Echtzeit laufen, sie muss aber Daten von dem Echtzeit Threads erhalten, um diese visualisieren zu können. Weiterhin ist es nicht nötig, dass die Visualisierung Daten zum Echtzeit Thread schicken muss, weswegen eine unidirektionale Verbindung ausreicht. Der Writer-Thread kann mit dem Methodeaufruf wfwq.write(myobject) Objekte in Queue legen. Wurde ein Objekt erfolgreich hineingelegt so wird der Booleanwert True zurückgegeben. Lautet der Rückgabewert False, so deutet das darauf hin, dass die Queue voll ist und keine weiteren Objekte aufnehmen kann. In diesem Fall bleib dem Writer Thread die Möglichkeit statt write die Methode force zu benutzen, die das letzte Element in der Queue überschreibt. Auf der anderen Seite der Queue kann der Reader Thread die hineingelegten Objekte mit dem Aufruf wfwq.read() wieder herausholen. Ist sie leer, so wird der Thread blockiert bis sich wieder ein Element in der Queue befindet. WaitFreeWriteQueue wfwq = new WaitFreeWriteQueue( mynoheaprealtimethread, // Threads der in die Queue schreibt myrealtimethread, // Threads der aus der Queue liest elements, // Größe der Queue memmoryarea); // Speicherbereich wo die Queue angelegt wird WaitFreeReadQueue Die WaitFreeReadQueue ist genau wie die WaitFreeWriteQueue für eine unidirektionale Kommunikation. Der Unterschied ist das sie blockierendes Schreiben und ein nicht blockierendes Lesen erlaubt. Dadurch bildet sie genau die entgegengesetzte Kommunikationsrichtung ab. Das bedeutet Daten können nur von einem niedriger priorisierten Thread zu einem höher priorisierten Thread geschickt werden. Mit dem Aufruf wfrq.read() kann der Reader ein Element aus der Queue holen. Ist diese leer, so wird Null zurückgegeben. Zusätzlich können auch Elemente mit dem Befehl wfrq.waitfordata() aus der Queue gelesen werden. Dabei wird der Thread allerdings solange blockiert bis mindesten ein

18 5 Thread Synchronisation 18 Element wieder in der Queue ist. WaitForData sollte also nur in Fällen benutzt werden, wenn der Thread ohne das Element aus der Queue ist weiterarbeiten kann. Um diese Methode benutzen zu können, muss im Konstruktor der WFRQ eine Boolean Variable gesetzt werden. Um in die Queue zu schreiben wird wfrq.write(myobject) verwendet. Ist die maximale Anzahl von Elementen bereits erreicht so wird der Writer Thread solange blockiert bis wieder mindestens ein Speicherplatz frei ist WaitFreeDeQueue Soll eine bidirektionale Kommunikation zwischen zwei Threads realisiert werden, muss man entweder eine WFWQ und eine WFRQ verwenden oder eine WaitFreeDeQueue. Die WFDQ hat die Methoden blockingread, blockingwrite, force, nonblockingread und nonblockingwrite. Sie legt im Hintergrund eine WFWQ und eine WFRQ an und leite die Methodenaufrufe einfach an die dementsprechende Queue weiter Allgemeine Methoden Alle drei Queues haben zusätzlich noch allgemeine Methoden. Dazu gehören size, clear, isemty und isfull. Size liefert die Anzahl der Elemente zurück, die sich gerade in der Queue befinden, während clear diese löscht. IsEmpty und isfull liefern jeweils einen Boolean Wert, ob die Queue leer bzw. voll ist. Mit IsEmpty kann man z. B. vor dem Lesen am blockierenden Ende überprüfen, ob die Operation möglich ist ohne zu warten, weil die Queue nicht leer ist. IsFull kann analog vor dem Schreiben verwendet werden. if (!(wfwq.isempty())) Object myobject = wfwq.read(); // falls WFWQ nicht leer ist // lese Element 6 Beispiel SteamBoiler Im folgenden Beispiel soll der Wasserstand eines SteamBoilers (Durchlauferhitzer) geregelt werden. Dazu werden Sensoren und Aktoren verwendet. Sie dienen als Schnittstelle zwischen dem Echtzeitcomputersystem und der physikalischen Welt. Über Sensoren werden Daten für das Echtzeitcomputersystem erfasst während über Aktoren das System die physikalische Welt steuern kann. In diesem Beispiel gibt es zwei Sensoren und sechs Aktoren. Der erste Sensor gibt den Wasserstand (engl. waterlevel) des SteamBoilers an und der zweite den austretenden Dampf (engl. exiting Steam). Die sechs Aktoren bestehen aus vier Pumpen (engl. pump) einem Ventil (engl. valve) und einer Heizung. Die Aufgabe des Echtzeitcomputersystems ist es den Wasserstand in dem Steamboiler zwischen dem maximalen (Wmax) und dem minimalen (Wmin) Wasserstand zuhalten. Wird die Heizung des SteamBoilers eingeschaltet so wird das Wasser erwärmt bis des verdunstet und als Dampf den Steamboiler verlässt. Dadurch wird der Wasserstand im Boiler immer niedriger und das Echtzeitsystem muss eine oder mehrere Pumpen aktiveren um Wasser hineinzupumpen. Ist wieder genug Wasser im Boiler können die Pumpen wieder abgeschaltet werden. Erreicht der Wasserstand die maximale Grenze, so öffnet das Echtzeitsystem das Ventil und lässt solange Wasser ab bis er sich wieder im normalen Bereich befindet. Im normalen Betrieb hat das Echtzeitcomputersystem also die Aufgaben die Sensoren auszulesen, mit Hilfe der Sensordaten neue Aktorwerte zu berechnen und diese in die Aktoren zu schreiben. Dabei müssen bestimmte Zeitvorgaben eingehalten werden, sonst könnte es beispielsweise passieren das der Steamboiler ganz leer ist, bevor sich die Pumpen einschalten.

19 6 Beispiel SteamBoiler 19 Bei einem Steamboiler darf das nicht vorkommen, da er sonst beschädigt wird. Deswegen muss für diesen Anwendungsfall ein Echtzeitcomputersystem eingesetzt werden. Exiting Steam Wmax 4 Pumps Waterlevel Wmin Valve Abbildung 6-1: SteamBoiler 6.1 Umsetzung mit Java RT Dieses Beispiele wurde in Java RT mit drei periodischen Threads umgesetzt. Der erste Thread, SteamBoilerSimulation, simuliert die Hardware, also den Steamboiler. Er liest die Aktoren, berechtet die neuen Werte für die Sensordaten und schreibt diese in die Sensoren. Da Hardware in Echtzeit läuft, wurde hierfür ein NoHeapRealtimeThread verwendet, der im Immortal Speicher liegt. Der zweite Thread, SteamBoilerControl, ist für die Steuerung und Überwachung des Steamboilers zuständig. Dieser Thread kann sich in den drei Zuständen Stop, Init und Run befinden. Im Stop Zustand werden einfach alle Aktorwerte auf null. Von Stop kann der Thread in Init wechseln, hier wird überprüft, ob der SteamBoiler betriebsbereit ist. Dazu wird beispielsweide der Wasserstand kontrolliert, ist dieser nicht im vorgeschrieben Bereich werden die Pumpen aktiviert bzw. das Ventil geöffnet. Ist er danach betriebsbereit so wird die Heizung aktiviert und der Zustand des Threads wechselt nach Run. Dort werden periodisch die Sensoren ausgelesen, neue Aktorwerte berechnet und in die Aktoren geschrieben. Tritt ein Fehler auf oder wird der SteamBoiler abgeschaltet, wechselt der Zustand wieder nach Stop und alle Aktorwerte werden auf null gesetzt. Da dieser Thread ein Echtzeitsystem darstellt ist der ebenfalls ein NoheapRealtimeThread. Aber er läuft im Gegensatz zu dem ersten Thread im Scope Memory und nicht im Immortal. Das hat den Vorteil, dass es möglich ist während der Laufzeit neue Objekte und Variablen anzulegen. Der dritte Thread, SteamBoilerVisualization, ist für die Visualisierung des Steamboilers auf dem Bildschirm zuständig. Da die Visualisierung keinen Echtzeitanforderungen unterliegt, reicht ein normaler Java Thread aus, der im Heap Memory läuft.

20 6 Beispiel SteamBoiler 20 Init if (waterlevel < wmin) pumpson(); if (waterlevel > wmax) vavleopen(); if (waterlevel <= wmax && waterlevel >= wmin) init = true; initcycles ; [initcycles == 0] / pumpsoff() & valveclose() Stop stopactors(); initialization / init = false & initcycles = initcyclesconst [init == true] / pumpsoff() & valveclose() & steamboileron() readsensors(); decide(); writeactors(); Run stop Abbildung 6-2: Zustandsdiagramm von SteamBoilerControl Damit das System lauffähig ist, muss der Thread SteamBoilerSimulation mit den beiden Anderen kommunizieren können. Die Kommunikation zu SteamBoilerControl ist über Monitore realisiert, da beide NoHeapRealtimeTreads sind. Für jeden Actor bzw. Sensor existiert ein Monitor, der im Immortal Memmory liegen muss. Würde die Monitore im Scope Memmory liegen so könnte SteamBoilerSimulation nicht darauf zugreifen, weil keine Referenzen vom Immortal auf den Scope erlaubt sind, siehe dazu Kapitel Scoped Memory. Die Kommunikation zwischen den beiden Threads SteamBoilerSimulation und SteamBoilerVisualization dagegen kann nicht über einen Monitor realisiert werden, da der eine ein NoHeapRealtimeThread und der andere ein normaler Java Thread ist. Hierzu muss eine WaitFreeQueue benutzt werden. Da lediglich Daten von der Simulation zur Visualisierung geschickt werden, also nur von einem höher priorisierten zu einem niedriger priorisierten Thread, ist hierfür die WaitFreeWriteQueue geeignet. Die Queue muss im Immortal Memmory liegen, da die Simulation ein NoHeapRealtimeThread ist und deshalb nicht auf den HeapMemmory zugreifen darf. Die folgende Abbildung zeigt die verwendeten Klassen und in welchem Speicherbereich sie sich befinden.