Automotive Embedded Systeme: Effizfientes Framework - Vom Design zur Implementierung

Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie und IT-Management aktuell und kompetent relevantes Fachwissen über Technologien und Produkte zur Entwicklung und Anwendung moderner Informationstechnologien.

Joachim Wietzke · Manh Tien Tran

Automotive Embedded Systeme Effizientes Framework – Vom Design zur Implementierung Mit 84 Abbildungen

123

Joachim Wietzke Fachhochschule Darmstadt, Fachbereich Technische Informatik und Grundlagen der Informatik Haardtring 100 64295 Darmstadt [email protected] Manh Tien Tran Fachhochschule Kaiserslautern, Fachbereich IMST Amerikastr. 1 66482 Zweibrücken [email protected]

Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

ISSN 1439-5428 ISBN-10 3-540-24339-9 Springer Berlin Heidelberg New York ISBN-13 978-3-540-24339-7 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2005 Printed in The Netherlands Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutzgesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz: Druckfertige Daten der Autoren Herstellung: LE-TeX Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier 33/3142/YL - 5 4 3 2 1 0

Vorwort

Perfektion ist nicht erreicht, wenn nichts mehr hinzugef¨ ugt werden kann, sondern wenn nichts mehr u ¨brig ist, was man weglassen kann. Antoine de Saint-Exup´ery

Wer hat, als Entwickler in einem Team oder als Manager eines Teams, noch nicht erlebt, dass mit zunehmendem Wachstum der Gruppe die Effizienz immer schlechter wurde? Eine Verdopplung der Gruppe etwa f¨ uhrte zwar ann¨ahernd zu einer Verdopplung der Fehler, nicht aber zur Verdopplung des produzierten Codes. Potenziert wurde das Problem, als dann nicht mehr alle Teammitglieder in einen Raum passten. Einige Meter Abstand waren dann schon so schlecht wie ein ganz anderer Standort. Die u ¨bliche Abhilfemaßnahme war in der folgenden Zeit der Versuch, mehr Objektorientierung in die Implementierung zu bringen, mit dem Ergebnis, dass die Fehler komplizierter waren und langwieriger zu finden, und dass die Implementierungen wie ein Flickenteppich aus verschiedenen Programmiersprachen und Paradigmen erschienen. Außerdem wurde der Speicher schnell knapp und die Performance schlecht. Ger¨ate, die vorher keine Schwierigkeiten machten, zeigten nach der OOPUmstellung bei gleichem Feature-Umfang erh¨ ohte und inakzeptable Startzeiten im zweistelligen Sekundenbereich und vielfache Speichergr¨oßen. Als N¨achstes kamen dann Vorschl¨ age f¨ ur einheitliche Design-Regeln, Testumgebungen und vorgegebene Software-L¨ osungen, die von den wenigen Kollegen, die Objektorientierung studiert hatten, geschrieben werden sollten.

VI

Vorwort

Schließlich setzte sich, oft zu sp¨ at, die Erkenntnis durch, dass es wohl einige Architekturvorgaben geben m¨ usse, die so implementiert waren, dass sie nicht leicht umgangen werden k¨ onnten. Banal war dann noch die Erkenntnis, dass die Kollegen, die das am besten konnten, daf¨ ur freigestellt werden m¨ ussten und nicht die, die daf¨ ur Zeit h¨atten und es gerne mal probieren wollten. Gerade die Mitarbeiter wurden aber gebraucht, die daf¨ ur nie Zeit hatten, weil es ja die besten waren und deshalb u ¨berall alte Br¨ande l¨oschen mussten. Seltsamerweise waren es auch die mit dem besten Dom¨anenwissen, nicht die Gurus der Objektorientierung. Bis sich all diese Erkenntnisse durchgesetzt hatten, war dann das Projekt um Monate u undet und versandet oder das ¨berzogen, einige Task-Forces gegr¨ Projekt war beim Kunden bereits verloren. Im Nachhinein wuchs dann auch die Erkenntnis, dass es hier eigentlich um die Entwicklung eines Frameworks ging, nicht nur um die Implementierung eines Projekts. Beim n¨ achsten Mal w¨ urde man deshalb zun¨achst ein Framework entwickeln und sp¨ ater ein neues Projekt daraus ableiten. Die Effizienz des Frameworks w¨ urde messbar sein und gemessen werden. Die Projektmitarbeiter w¨ urden nur noch Kundenvarianten programmieren, alle wesentlichen Fundamente w¨aren schon im Framework festgelegt. F¨ ur dieses Framework wurde dann eine große Mannschaft u ¨ber mehrere Standorte hinweg berufen, damit auch alles Expertenwissen einfließen konnte. Schließlich wurde ein Steering-Committee dar¨ uber gestellt, dem strategische Entscheidungen vorgelegt werden sollten. Das Schicksal dieses Frameworks kennen Sie schon, es war zu groß, zu langsam und wurde nicht fertig. Es konnte auch nicht angewendet werden oder vielleicht nur f¨ ur ein einziges unvermeidliches Projekt. Wenn sich dann schließlich beim n¨ achsten Versuch hoffentlich vier bis f¨ unf Kollegen finden, ausgestattet mit Motivation und Expertenwissen ihrer Dom¨ane, Gummib¨ archen, Cola, besten Arbeitsmitteln und ohne politisches Gremium dar¨ uber, dann gibt es Hoffnung auf eine gute L¨osung. Wenn diese Pioniere dann ein kleines Nachschlagewerk brauchen, aus dem sie manche Erfahrungen oder neue Ideen sch¨ opfen k¨ onnen, dann nutzt Ihnen, meine Damen und Herren, hoffentlich dieses Buch. Viel Spaß bei der Arbeit! Manh Tien Tran, Joachim Wietzke

Inhaltsverzeichnis

1

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

Teil I Bausteine eines Embedded Frameworks 2

Ein Infotainment-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Die Headunit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2 Ger¨ ate/Devices im System . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3 Begriffskl¨ arung: Was ist ein Framework . . . . . . . . . . . . . . . . 10 2.4 Fokus unserer Framework-Betrachtungen . . . . . . . . . . . . . . 11

3

Anforderungen an ein Embedded Automotive Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Verteilte Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 MVC, Organisationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Speicheranforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Startzeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Men¨ uwechselzeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Konfiguration versus Dynamik . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Datenfluss/Kontrollfluss/Zustandssteuerung . . . . . . . . . . . .

13 13 13 15 15 16 16 16

Betriebssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Prozesse, Tasks, Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Der Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Pr¨ aemptive Priorit¨ atssteuerung . . . . . . . . . . . . . . . . . 4.2.2 Round-Robin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Priorit¨ ats-Inversion, Priorit¨ats-Vererbung . . . . . . . . 4.2.4 Task-Switch, Kontextwechsel . . . . . . . . . . . . . . . . . . . 4.3 Zusammenspiel mit der MMU . . . . . . . . . . . . . . . . . . . . . . . .

17 18 19 19 19 19 20 20

4

VIII

Inhaltsverzeichnis

5

Design-Rules und Konventionen . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Namenskonventionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Shared-Verzeichnisse, Libraries . . . . . . . . . . . . . . . . . . . . . . . 5.3 Eigene Definitionen im Shared . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Standard-Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.3 Little-Endian, Big-Endian . . . . . . . . . . . . . . . . . . . . . 5.3.4 Zahlengrenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.5 Const Definitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.6 Eigene Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.7 Exceptions und Signale . . . . . . . . . . . . . . . . . . . . . . . . 5.3.8 Eigene Ausgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21 22 22 22 22 23 24 25 25 26 27 27

6

Speicherverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Statische Speicherverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Dynamische Speicherverwaltung . . . . . . . . . . . . . . . . . . . . . . 6.3 Start-Up-Strategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Speicherbedarf und kleine Pittfalls . . . . . . . . . . . . . . . . . . . . 6.4.1 Welche Variable wo? . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.2 Alternative Strategie 1: Sp¨ate Konstruktion . . . . . . 6.4.3 Alternative Strategie 2: Sp¨ate Initialisierung . . . . . 6.4.4 Alternative Strategie 3: Lokale statische Variablen 6.4.5 Speicherort von Konstanten . . . . . . . . . . . . . . . . . . . . 6.4.6 Speicherbedarf eines einfachen Objekts . . . . . . . . . . 6.4.7 Speicherbedarf eines einfachen Objekts mit virtueller Methode . . . . . . . . . . . . . . . . . . . . . . . . 6.4.8 Speicherbedarf eines Objekts einer abgeleiteten einfachen Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.9 Speicherbedarf eines Objekts einer abgeleiteten Klasse mit virtueller Methode . . . . . . . . . . . . . . 6.4.10 Speicherbedarf eines Objekts einer abgeleiteten Klasse mit virtueller Basis-Methode . . . . . . . . . 6.4.11 Mehrfachvererbung und Pittfall . . . . . . . . . . . . . . . . . 6.4.12 Speicherbedarf dynamischer Variablen . . . . . . . . . . . 6.4.13 Schlechte Parameter¨ ubergabe . . . . . . . . . . . . . . . . . . 6.4.14 Probleme mit dem Kopierkonstruktor . . . . . . . . . . . 6.4.15 Probleme mit dem Zuweisungsoperator . . . . . . . . . . 6.4.16 Schlechte R¨ uckgaben . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.17 Padding-Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.18 Alignment-Probleme, Endian-Probleme . . . . . . . . . . 6.4.19 Speicherfragmentierung . . . . . . . . . . . . . . . . . . . . . . . . 6.4.20 Vektoren, STL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29 31 31 33 33 33 36 38 39 40 43 44 46 48 50 52 55 56 57 57 57 59 60 60 61

Inhaltsverzeichnis

IX

7

Embedded Speicherkonzepte, spezielle Muster . . . . . . . . . . 7.1 Statische Variablen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.1 Reihenfolge der Konstruktoren . . . . . . . . . . . . . . . . . 7.2 Quasi-statische Allokation aus festem Pufferspeicher . . . . . 7.2.1 Anlegen eines statischen Puffers . . . . . . . . . . . . . . . . 7.2.2 Placement-new . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.3 Makros zur Allokation . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Allokator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Statische Allokation . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.2 Dynamische Allokation mit tempor¨arem Heap . . . . 7.3.3 Object-Pool-Allokation . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Datencontainer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Gemeinsam benutzte Objekte (Shared-Objects) . . . . . . . . . 7.6 Referenzz¨ ahler (reference counting) . . . . . . . . . . . . . . . . . . . . 7.7 Garbage-Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8 Die Captain-Oates Strategie . . . . . . . . . . . . . . . . . . . . . . . . . . 7.9 Speicherlimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.10 Partieller Fehler (Partial Failure) . . . . . . . . . . . . . . . . . . . . . 7.11 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63 63 63 66 67 67 68 70 73 75 78 82 82 83 85 85 86 87 87

8

Prozesse und POSIX-Threads . . . . . . . . . . . . . . . . . . . . . . . . . . 89 8.1 Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 8.1.1 Der Lebenszyklus eines Prozesses . . . . . . . . . . . . . . 90 8.1.2 Prozesszust¨ ande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 8.1.3 Zombies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 8.1.4 Bestandteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 8.1.5 Prozess mit fork erzeugen . . . . . . . . . . . . . . . . . . . . . . 93 8.1.6 Prozess mit exec erzeugen . . . . . . . . . . . . . . . . . . . . . 94 8.1.7 Prozess mit spawn erzeugen . . . . . . . . . . . . . . . . . . . . 96 8.1.8 Prozessvererbung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 8.1.9 Prozessattribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 ¨ 8.1.10 Uber Prozessgrenzen hinweg . . . . . . . . . . . . . . . . . . . 98 8.2 Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 8.2.1 Erzeugung von POSIX-Threads . . . . . . . . . . . . . . . . . 99 8.2.2 Allgemeine Gestaltung eines Threads in eingebetteten Anwendungen . . . . . . . . . . . . . . . . 100 8.2.3 Thread-Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 ¨ 8.2.4 Uber Threadgrenzen hinweg . . . . . . . . . . . . . . . . . . . . 104 8.2.5 Thread-spezifische Daten . . . . . . . . . . . . . . . . . . . . . . 106 8.2.6 Thread-Tr¨ ager und Thread-Objekte . . . . . . . . . . . . . 108 8.3 Designentscheidung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

X

Inhaltsverzeichnis

9

Inter-Prozess-Kommunikationskan¨ ale, IPC . . . . . . . . . . . . . . 121 9.1 Pipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 9.2 FIFO, Named-Pipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 9.3 Socket, local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 9.4 Socket-Verbindung zwischen Prozessoren . . . . . . . . . . . . . . . 127 9.5 Message-Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 9.5.1 System V Message-Queues . . . . . . . . . . . . . . . . . . . . . 134 9.5.2 POSIX Message-Queues . . . . . . . . . . . . . . . . . . . . . . . 134 9.6 QNX-Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 9.7 Shared-Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 ¨ 9.8 Shared-Memory gegen Uberschreiben sch¨ utzen . . . . . . . . . . 144 9.9 Zeitverhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 9.10 Designentscheidung und prinzipielle Implementierung . . . . 150

10

Gemeinsame Nutzung von Code . . . . . . . . . . . . . . . . . . . . . . . . 151 10.1 DLLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 10.2 Shared-Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 10.3 Designentscheidung und prinzipielle Implementierung . . . . 152

11

Synchronisierungsmechanismen f¨ ur Prozesse und Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 11.1 Semaphore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 11.2 Unbenannter Semaphor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 11.3 Benannter Semaphor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 11.4 Mutex, rekursiver Mutex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 11.5 Mutex-Guard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 11.6 Signale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 11.7 Bedingungsvariablen (Condition Variables) . . . . . . . . . . . . . 168 11.8 Zeitverhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 11.9 Deadlock, Livelock und Priorit¨ atsinversion . . . . . . . . . . . . . 177 11.10 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

12

Kommunikation per Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 12.1 Wichtige Event-Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 12.1.1 Signal-Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 12.1.2 Events mit Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 12.1.3 Call-Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 12.1.4 Timer-Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 12.1.5 Change-Events (Notifikation - Das HollywoodPrinzip) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 12.2 Realisierungen von Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 12.2.1 Einfache Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 12.2.2 C-Strukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 12.2.3 Funktionszeiger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 12.2.4 Event-Klassen und Objekte . . . . . . . . . . . . . . . . . . . . 190

Inhaltsverzeichnis

12.3

XI

12.2.5 Zeiger auf Event-Objekte verschicken . . . . . . . . . . . . 192 12.2.6 Events am Beispiel von MOST . . . . . . . . . . . . . . . . . 195 Designentscheidung und prinzipielle Implementierung . . . . 196

13

Event-Verarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 13.1 Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 13.1.1 Externe Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 13.1.2 Interne Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 13.1.3 System-Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 13.1.4 Queue mit verbesserter Inversions-Eigenschaft . . . . 205 13.2 Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 13.2.1 Der System-Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . 211 13.2.2 Der lokale Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . 212 13.2.3 Signalisation im Dispatcher . . . . . . . . . . . . . . . . . . . . 213 13.2.4 Registrierung im Dispatcher . . . . . . . . . . . . . . . . . . . . 213 13.3 Synchrone Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

14

Zustandsautomaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 14.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 14.2 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 14.3 Automaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 14.4 Statechart-Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 14.5 Probleme mit Statecharts und Ersatzl¨osungen . . . . . . . . . . 221 14.6 Implementierung dynamischen Verhaltens . . . . . . . . . . . . . . 223 14.6.1 Definition der Events . . . . . . . . . . . . . . . . . . . . . . . . . . 224 14.6.2 Implementierung der Aktionen . . . . . . . . . . . . . . . . . 225 14.7 Implementierung der Statecharts . . . . . . . . . . . . . . . . . . . . . . 226 14.7.1 Implementierung durch Aufz¨ahlung f¨ ur Zust¨ande und Unterzust¨ ande . . . . . . . . . . . . . . . . . . . . . . . . 226 14.7.2 Zustandsmuster (State-Pattern) . . . . . . . . . . . . . . . . 231 14.7.3 Verbesserte Aufz¨ ahlungsmethode . . . . . . . . . . . . . . . 240 14.8 Implementierung nach Samek . . . . . . . . . . . . . . . . . . . . . . . . 246

15

Externer Kommunikationskanal: MOST-Bus . . . . . . . . . . . . 253 15.1 Der synchrone Kanal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 15.2 Der asynchrone Kanal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 15.3 Der Kontrollkanal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 15.4 Ger¨ ate/Devices im Framework . . . . . . . . . . . . . . . . . . . . . . . . 255 15.4.1 Logische Ger¨ ate, Modelle . . . . . . . . . . . . . . . . . . . . . . 257 15.4.2 Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 15.4.3 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 15.4.4 MOST-Adressierung . . . . . . . . . . . . . . . . . . . . . . . . . . 259 15.4.5 Adressierungsbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . 265 15.4.6 MOST-Events, prinzipielle Dekodierung des Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

XII

Inhaltsverzeichnis

15.4.7 MOST-Events, prinzipielle Dekodierung der Daten 268 15.4.8 MOST-Konstanten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 15.4.9 MOST-Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Teil II Das Framework 16

Das Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

17

OS-Grundmechanismen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

18

Komponentenarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 18.1 Event-Handler und Event-Formate . . . . . . . . . . . . . . . . . . . . 281 18.2 Implementierung von Schnittstellen, Proxy und Handler . 285 18.3 Komponentenarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 18.3.1 Komponentenkontext und Daten im Shared-Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 18.3.2 Erzeugung der Kontexte . . . . . . . . . . . . . . . . . . . . . . . 295 18.3.3 Main-/Admin-Task . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 18.3.4 Signale, Mechanismen u ¨ber den Kontext . . . . . . . . . 302 18.3.5 Komponenten-Dispatcher . . . . . . . . . . . . . . . . . . . . . . 308 18.3.6 Softtimer und Timer-Manager . . . . . . . . . . . . . . . . . . 310 18.3.7 Registrierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 18.3.8 Die Basisklasse AComponentBase und das Zusammenspiel mit der Umgebung . . . . . . . . . . 319 18.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

19

Main-Dispatcher-Komponente . . . . . . . . . . . . . . . . . . . . . . . . . . 331 19.1 Dispatcher-Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 19.2 Dispatcher-Main-Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

20

Modell-Komponenten, logische Ger¨ ate . . . . . . . . . . . . . . . . . . 341 20.1 Aufgaben des logischen Ger¨ ats . . . . . . . . . . . . . . . . . . . . . . . . 342 20.2 Was erwartet die HMI von einem logischen Ger¨at? . . . . . . 343 20.3 Zust¨ ande des Ger¨ ats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 20.4 G¨ ultigkeit der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 20.5 Kommunikationsanforderung . . . . . . . . . . . . . . . . . . . . . . . . . 347 20.6 Struktur eines logischen Ger¨ ats . . . . . . . . . . . . . . . . . . . . . . . 347 20.7 Datencontainer versus Event-Prinzip . . . . . . . . . . . . . . . . . . 347 20.8 Architektur eines Datencontainers . . . . . . . . . . . . . . . . . . . . 349 20.8.1 Struktur des Datencontainers . . . . . . . . . . . . . . . . . . 350 20.8.2 Lesezugriffe der HMI . . . . . . . . . . . . . . . . . . . . . . . . . . 356 20.8.3 Versenden eines HMI-Befehls . . . . . . . . . . . . . . . . . . . 357 20.8.4 Menge der erlaubten High-Level-Aktionen . . . . . . . 358 20.8.5 Abstrakte Klasse ADataContainerAccessor . . . . . . . 359 20.9 MOST-Codec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

Inhaltsverzeichnis

XIII

20.9.1 20.9.2 20.9.3 20.9.4 20.9.5

Vorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 Einfache Implementierung eines MOST-Decoders . 367 Objektorientierter Ansatz . . . . . . . . . . . . . . . . . . . . . . 370 Objekte zur Kompilierzeit . . . . . . . . . . . . . . . . . . . . . 372 Konstante Objekte zur Dekodierung der MOST-Nachrichten . . . . . . . . . . . . . . . . . . . . . . . . 374 20.10 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 21

HMI-Komponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

22

Persistenz-Controller und On/Off-Konzepte . . . . . . . . . . . . 391

23

Codegenerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 23.1 Erstellen der XML-Eingabe-Dateien . . . . . . . . . . . . . . . . . . . 395 23.2 Erzeugen des Quellcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 ¨ 23.3 Ubersicht der erzeugten Dateien . . . . . . . . . . . . . . . . . . . . . . 398 ¨ 23.4 Ubersetzen des Quellcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

24

Sonstige Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 24.1 Internes non-MOST-Device, Beispiel Mediaplayer . . . . . . . 405 24.2 Internes MOST-Device, Beispiel Tastatur . . . . . . . . . . . . . . 405 24.3 Treiber im Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 24.4 Einfaches Debugging-Konzept . . . . . . . . . . . . . . . . . . . . . . . . 406 ¨ 24.5 Uberlastverhalten des Systems . . . . . . . . . . . . . . . . . . . . . . . . 408 24.6 Anmerkungen zur Komplexit¨ at und zum Testing . . . . . . . . 409

Anhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 25.1 Timer und Zeitmessung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412 25.1.1 Sleep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 25.1.2 Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 25.2 Socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 25.2.1 InetAddr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 25.2.2 CSockAcceptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 25.2.3 CSockConnector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 25.2.4 CSockStream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 25.3 Keyboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 25.4 Shared-Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 25.5 CBinarySemaphore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 25.6 Extern const . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443

Die Listings

5-1 5-2 5-3 5-4 5-5 6-1 6-2 6-3 6-4 6-5 6-6 6-7 6-8 6-9 6-10 6-11 6-12 6-13 6-14 6-15 6-16 6-17 6-18 6-19 6-20 6-21 6-22 6-23

Standard-Typen und Konstanten, Global.h . . . . . . . . . . . . . . . Alignment-Makro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Makros zur Endian-Format-Anpassung . . . . . . . . . . . . . . . . . . . Max/Min-Typedefs f¨ ur eigene Datentypen . . . . . . . . . . . . . . . . . Eigene Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Globales Objekt gem¨ aß Singleton-Pattern . . . . . . . . . . . . . . . . . Sp¨ate Konstruktion des globalen Singleton-Objekts . . . . . . . . . Sp¨ate Konstruktion des globalen Singleton-Objekts mit Mutex-Schutz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Singleton mit Doppel-Checking . . . . . . . . . . . . . . . . . . . . . . . . . . Sp¨ate Initialisierung eines Singletons . . . . . . . . . . . . . . . . . . . . . Lokale statische Variablen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Struktur mit plain old Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Struktur mit Konstruktor-Aufruf . . . . . . . . . . . . . . . . . . . . . . . . . Struktur mit Konstruktor im Code-Segment . . . . . . . . . . . . . . . Instanz einer einfachen Klasse A . . . . . . . . . . . . . . . . . . . . . . . . . Speicherbedarf eines Objekts einer einfachen Klasse mit virtueller Methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Speicherbedarf eines Objekts einer einfachen abgeleiteten Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel f¨ ur einen impliziten Up-Cast“ . . . . . . . . . . . . . . . . . . . ” Abgeleitete Klasse einer abstrakten Klasse . . . . . . . . . . . . . . . . Mehrfachvererbung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mehrfachvererbung, Up-Cast und Down-Cast, Testausgaben . Beispiel-Interface in C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Speicherbedarf f¨ ur int- und char-Variablen unter VC++ . . . Schlechte R¨ uckgabe, Beispiel 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . Schlechte R¨ uckgabe, Beispiel 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . Schlechte R¨ uckgabe, Beispiel 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . Schlechte R¨ uckgabe, Beispiel 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . Bessere R¨ uckgabe, Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23 23 25 25 26 35 36 37 38 39 40 41 42 42 43 45 47 49 51 52 53 55 56 57 58 58 58 59

XVI

Die Listings

6-24 6-25 7-1 7-2 7-3 7-4 7-5 7-6 7-7 7-8 7-9 7-10 7-11 7-12 7-13 7-14 7-15 7-16 7-17 7-18 7-19 8-1 8-2 8-3 8-4 8-5 8-6 8-7 8-8 8-9 8-10 8-11 8-12 8-13 8-14 9-1 9-2 9-3 9-4 9-5 9-6 9-7 9-8 9-9

Achtlos platzierte Member-Variablen . . . . . . . . . . . . . . . . . . . . . 59 Zeitmessungen zu Arrays und Vektoren, [Klein] . . . . . . . . . . . . 62 Systemobjekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Systemobjekt mit reserviertem Speicherbereich . . . . . . . . . . . . 66 Anlegen eines statischen Puffers . . . . . . . . . . . . . . . . . . . . . . . . . 67 Nutzung des Puffers durch eine C-Funktion . . . . . . . . . . . . . . . 67 Einsatz des Placement-new-Operators . . . . . . . . . . . . . . . . . . . . . 68 Syntax des Placement-new-Operators . . . . . . . . . . . . . . . . . . . . . 68 ¨ Eigenes Uberladen des Placement-new-Operators, [Nob] . . . . . 68 Alle Makros in FWMemory.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Interface-Definition IAllocator.h . . . . . . . . . . . . . . . . . . . . . . . 72 Makros zur Allokation von Objekten . . . . . . . . . . . . . . . . . . . . . 73 Der Basisklassen-Prototyp CStaticAllocator.h . . . . . . . . . . . 74 Auszug aus CStaticAllocator.cpp . . . . . . . . . . . . . . . . . . . . . . 74 Vereinbarung eines Allocators . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Aufruf der Allocator-Methode . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Klasse CTemporaryHeapAllocator, Prototyp . . . . . . . . . . . . . . 77 CTemporaryHeapAllocator, Implementierung . . . . . . . . . . . . . 78 Prototyp der Klasse CObjectPool . . . . . . . . . . . . . . . . . . . . . . . . 79 Implementierung der Klasse CObjectPool . . . . . . . . . . . . . . . . . 81 Eigene Smart-Pointer-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Syntax von fork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Beispiel f¨ ur Prozess-Erzeugung mit fork . . . . . . . . . . . . . . . . . . 94 Aufruf von execlp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Start eines POSIX-Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Thread-Vereinbarung unter QNX, mit Lesen der Attribute . . 104 Erzeugung eines Threads mit eigenen Attributen . . . . . . . . . . . 104 Implementierung der TSD-Initialisierung . . . . . . . . . . . . . . . . . . 108 Zugriff auf TSD u ¨ber Makro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Basis-Interface IRunnable.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Prototyp der Thread-Klasse CThread.h . . . . . . . . . . . . . . . . . . . 112 Instantiierung eines CThread-Objekts . . . . . . . . . . . . . . . . . . . . 112 Instantiierung als Main-Thread . . . . . . . . . . . . . . . . . . . . . . . . . . 112 CThread-Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Kontextwechsel-Messungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Pipe erzeugen, Implementierung der Sendeseite . . . . . . . . . . . . 122 Pipe schreiben, lesen, schließen, Prototypen . . . . . . . . . . . . . . . 122 Erzeugen eines Socket-Paares, Prototyp . . . . . . . . . . . . . . . . . . . 126 Socket-Applikation, mit select-Implementierung . . . . . . . . . . 127 Prototyp f¨ ur Socket-Wrapper CSockStream.h . . . . . . . . . . . . . . 128 Implementierung des Socket-Wrapper CSockStream.cpp . . . . 129 Header-Datei des Connector-Wrappers CSockConnector.h . . 129 Implementierung des Connector-Wrappers CSockConnector.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Header-Datei des Acceptor-Wrappers CSockAcceptor.h . . . . 130

Die Listings

9-10 9-11 9-12 9-13 9-14 9-15 9-16 9-17 9-18 9-19 9-20 9-21 9-22 9-23 9-24 11-1 11-2 11-3 11-4 11-5 11-6 11-7 11-8 11-9 11-10 11-11 11-12 11-13 12-1 12-2 12-3 12-4 12-5 12-6 12-7 12-8 12-9 12-10 12-11 13-1 13-2 13-3 13-4

XVII

Internet-Adress-Struktur sockaddr in in . . 131 Implementierung des Acceptor-Wrappers CSockAcceptor.cpp132 Wrapper zum Setzen der Socket-Adresse . . . . . . . . . . . . . . . . . . 133 Verwendete #includes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Klasse CMessageQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Erzeugen Shared-Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Einblenden des Shared-Memory in den Speicherbereich . . . . . 139 Linux Kommandos f¨ ur Shared-Memory . . . . . . . . . . . . . . . . . . . 140 QNX Shared-Memory anlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Schreiben ins QNX Shared-Memory . . . . . . . . . . . . . . . . . . . . . . 142 Lesen aus dem Shared-Memory . . . . . . . . . . . . . . . . . . . . . . . . . . 143 CMemoryProtector.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 CMemoryProtector.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Beispiel-Klasse CProtectedSharedMemory . . . . . . . . . . . . . . . . . 148 Demonstration des Shared-Memory-Schutzes . . . . . . . . . . . . . . 148 Semaphor und die Zugriffsfunktionen V(s) und P(s) . . . . . . . 155 C-Funktionen f¨ ur unbenannte Semaphore . . . . . . . . . . . . . . . . . 158 Synchronisierter Produzenten-/Konsumenten-Zugriff zweier Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Erzeugen und Schließen eines benannten Semaphors . . . . . . . . 161 Erzeugung einer Mutex-Variablen . . . . . . . . . . . . . . . . . . . . . . . . 162 Lesen der Thread-Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Implementierung eines Mutex-Schutzes f¨ ur eine Zugriffsfunktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Klasse CMutex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Guard-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Typische Bedingungsvariablen-Anwendung . . . . . . . . . . . . . . . . 171 Code-Beispiel f¨ ur die Freigabe einer Bedingungsvariablen . . . 172 CBinarySemaphore.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Objektorientierte Implementierung CBinarySemaphore.cpp . 176 Enum f¨ ur einfache Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Dispatcher f¨ ur Enum-Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Event als C-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Event als C-Struktur mit Union . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Event als C-Struktur mit Funktionszeiger und Parameter . . . 189 Implementierung der dispatch-Methode der Struktur . . . . . . 189 Event als Klasse CMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Event-Klasse mit eigenen Methoden und Attributen . . . . . . . . 192 Verwendung von Event-Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Event-Basisklasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Beispiele f¨ ur MOST-Events gem¨ aß MOST-Spezifikation . . . . . 195 Queue-Klassendefinition, Prototyp . . . . . . . . . . . . . . . . . . . . . . . 198 Eine Queue-Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Produzent-Konsument mit Counting-Semaphor . . . . . . . . . . . . 203 Teilimplementierung einer internen Queue . . . . . . . . . . . . . . . . . 205

XVIII Die Listings

13-5 13-6 13-7 13-8 14-1 14-2 14-3 14-4 14-5 14-6 14-7 14-8 14-9 14-10 14-11 14-12 14-13 14-14 14-15 14-16 14-17 14-18 14-19 14-20 15-1 15-2 15-3 15-4 15-5 15-6 18-1 18-2 18-3 18-4

Die Queue-Klasse CCommQueue.h, Prototyp . . . . . . . . . . . . . . . . 206 Basisklasse CCommQueue.cpp, Implementierung . . . . . . . . . . . . 211 Lokaler Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Registrierung und Deregistrierung in CDispatcher . . . . . . . . . 214 Methoden zum Beispielautomaten . . . . . . . . . . . . . . . . . . . . . . . . 225 Exit-Methoden von CFSM1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Die on Entry-Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Beispiel von Event-Handler-Methoden . . . . . . . . . . . . . . . . . . . . 230 Basisklasse CBasisState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Der inEntry Oberzustand A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Klasse f¨ ur SuperState A, Implementierung . . . . . . . . . . . . . . . . . 236 Zustandsmaschine CFSM3, Header . . . . . . . . . . . . . . . . . . . . . . . . 236 Konstruktor von CFSM3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Reaktion von CFSM3 auf EV 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Zustandsmaschine CFSM3, Ereignisverteilung . . . . . . . . . . . . . . . 238 Wirkung von Event als Parameter . . . . . . . . . . . . . . . . . . . . . . . . 239 Verbesserte Aufz¨ ahlungsmethoden, Klassendeklaration . . . . . . 241 Dispatch-Methode von CSuperStateA . . . . . . . . . . . . . . . . . . . . 242 Verbesserte Aufz¨ ahlungsmethode, Implementierung . . . . . . . . . 245 Definition eines Funktionszeigers auf eine CFSM-Methode . . . 248 Makro f¨ ur den Funktionszeiger . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Basisklasse CFSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 SuperState als abgeleitete Klasse . . . . . . . . . . . . . . . . . . . . . . . . . 250 FSM CFSM5 mit Funktionen als Zust¨anden . . . . . . . . . . . . . . . . 251 MOST-Event, Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Beispiel eines NetBlock-Aufrufs . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Aufbau der zentralen Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Beispiele f¨ ur die Adressierung gem¨ aß MOST . . . . . . . . . . . . . . . 265 MOST-Sequenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Die Sammlung vieler Most-Konstanten, MOSTConst.h . . . . . . . 271 Schnittstelle IMessageHandler . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Ausschnitt aus CMessage.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Der Kontext-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Beschreibung des Komponentenkontexts, CComponentContext.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 18-5 Die createComponentContext-Methode der Klasse, Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 18-6 sDescriptionTable f¨ ur die Erzeugung von Kontexten . . . . . . 297 18-7 Klasse zur Erzeugung und Verwaltung der Kontexte . . . . . . . . 298 18-8 Code zur Erzeugung von Kontexten und Datencontainer . . . . 300 18-9 Pseudocode f¨ ur main . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 18-10 Auszug aus der run-Methode des Admin-Tasks, Watchdog-Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 18-11 Auszug aus der run-Methode des Admin-Tasks, Watchdog-Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Die Listings

18-12 18-13 18-14 18-15 18-16 18-17 18-18 18-19 18-20 18-21 18-22 18-23 19-1 19-2 19-3 19-4 19-5 19-6 19-7 20-1 20-2 20-3 20-4 20-5 20-6 20-7 20-8 20-9 20-10 20-11 20-12 20-13 20-14 20-15 20-16 20-17 20-18 20-19 20-20 20-21 20-22 20-23 20-24 20-25

XIX

Auszug aus der run-Methode einer Komponente . . . . . . . . . . . 303 handleTick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 Auszug aus der Klasse CDispatcher . . . . . . . . . . . . . . . . . . . . . . 310 Klasse f¨ ur Softtimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Timer-Manager , CTimerManager.h . . . . . . . . . . . . . . . . . . . . . . 313 Auszug aus CObserverRegistry.cpp . . . . . . . . . . . . . . . . . . . . . 319 Headerfile der Klasse CComponentContext . . . . . . . . . . . . . . . . . 321 Komponentenservice-Klasse, CComponentServices.cpp . . . . . 323 init-Methode, Klasse AComponentBase . . . . . . . . . . . . . . . . . . 324 Hilfsklasse CSystemEventHandler . . . . . . . . . . . . . . . . . . . . . . . 325 cleanup-Methode, Klasse AComponentBase . . . . . . . . . . . . . . . 325 run-Methode, Klasse AComponentBase . . . . . . . . . . . . . . . . . . . 326 Start des MostDispatcher Receiver-Threads . . . . . . . . . . . . . . . 333 Zeiger auf Struktur MostHandle . . . . . . . . . . . . . . . . . . . . . . . . . 334 MOST-Empf¨ anger-Klasse CMostdispatcherReceiver . . . . . . 335 init-Methode von Dispatcher-Main-Thread . . . . . . . . . . . . . . . 336 Reaktionen von Dispatcher-Main-Thread . . . . . . . . . . . . . . . . . . 337 Reaktion auf Lock- und Unlock-Events . . . . . . . . . . . . . . . . . . . 337 Verteilung der MOST-Nachrichten im System-Dispatcher . . . 340 Datencontainer-Struktur f¨ ur AudioDiscInfo . . . . . . . . . . . . . . 352 Struktur StringBuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 Struktur DataBuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 MOST-Datencontainer f¨ ur AudioDiscPlayer . . . . . . . . . . . . . . . 355 Einige get-Methoden f¨ ur AudioDiscInfo . . . . . . . . . . . . . . . . . . 356 Implementierung der get-Methoden f¨ ur AudioDiscInfo . . . . . 357 Abstrakte Klasse ADataContainerAccessor.h . . . . . . . . . . . . . 361 Teilimplementierung CAudioDiscPlayerDCAccessor . . . . . . . . 361 Enum-Index f¨ ur den Datenzugriff . . . . . . . . . . . . . . . . . . . . . . . . . 362 Adapterklasse zum Lesen einer MOST-Nachricht . . . . . . . . . . . 365 Einige Methoden aus CMOSTInStream . . . . . . . . . . . . . . . . . . . . . 367 Dekodierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Weitere Dekodierm¨ oglichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 Objekte zur Kompilierzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 Objekte im Code- und Datensegment . . . . . . . . . . . . . . . . . . . . . 373 MOST-Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 CTypeInfo und CMOSTEnum zur Beschreibung der MOST-Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 Die Methode invokeRead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 Hilfsstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 ModelTypeEnum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 Basis-Struktur CModelInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 Beschreibungen von MOST-Properties, Prototyp . . . . . . . . . . . 380 Polymorphie-Ersatz f¨ ur CModelInfo . . . . . . . . . . . . . . . . . . . . . . 381 ModellInfo f¨ ur Array of Record, CArrayRecordProp.h . . . . . 381 CArrayRecordProp-Struktur f¨ ur AudioDiscInfo . . . . . . . . . . . 382

XX

Die Listings

20-26 20-27 20-28 22-1 23-1 23-2 23-3 23-4 23-5 23-6 23-7 23-8 23-9 23-10 23-11 23-12 24-1 25-1 25-2 25-3 25-4 25-5 25-6 25-7 25-8 25-9 25-10 25-11 25-12 25-13 25-14 25-15 25-16 25-17 25-18 25-19

Vom mType abh¨ angige Lesefunktion . . . . . . . . . . . . . . . . . . . . . . 383 Lesefunktion f¨ ur Array of Record . . . . . . . . . . . . . . . . . . . . . . . . 386 Lesen von Enum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 Persistenz-Manager, Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 Schnittstellenbeschreibung f¨ ur die Code-Generierung . . . . . . . 396 Komponenten f¨ ur den Code-Generator . . . . . . . . . . . . . . . . . . . . 397 Generierung des Projekts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 Starten einer Komponente als Thread . . . . . . . . . . . . . . . . . . . . 398 Starten einer Komponente als Prozess am Beispiel MostDispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 Der Watchdog, der innerhalb main() ausgef¨ uhrt wird . . . . . . . 399 Schleife zum Erzeugen der Kontexte . . . . . . . . . . . . . . . . . . . . . . 400 Projekt mit Amp-, Debug- und Dispatcher-Komponente . . . . 401 DebugConfig.cpp am Beispiel eines Audioamplifiers . . . . . . . . 401 Beispiel f¨ ur den Audioamplifier . . . . . . . . . . . . . . . . . . . . . . . . . . 402 AudioamplifierPort.cpp, AudioamplifierPort.h . . . . . . . . 403 AudioamplifierHandler.cpp und AudioamplifierHandler.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 Implementation of CCommQueue . . . . . . . . . . . . . . . . . . . . . . . . . . 408 Timer und Zeitmessung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 OS-Abh¨ angigkeiten f¨ ur eine sleep-Methode . . . . . . . . . . . . . . . 413 Abh¨angige includes f¨ ur Sem.take mit timeout . . . . . . . . . . . . 414 OS-abh¨ angige includes f¨ ur CInetAddr.h, Header . . . . . . . . . . 415 OS-abh¨ angige Implementierungen in CInetAddr . . . . . . . . . . . 415 OS-abh¨ angige includes und Definitionen f¨ ur CSockAcceptor, Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 OS-abh¨ angige Implementierungen f¨ ur CSockAcceptor . . . . . . 417 OS-abh¨ angige Includes f¨ ur CSockConnector, Header . . . . . . 418 OS-abh¨ angige Implementierungen f¨ ur CSockConnector . . . . . 420 OS-abh¨ angige Includes f¨ ur CSockStream, Header . . . . . . . . . . 421 OS-abh¨ angige Implementierungen f¨ ur CSockStream . . . . . . . . . 422 OS-abh¨ angige Terminierung von Socket . . . . . . . . . . . . . . . . . . . 422 Tastatur- und Keyboard-Eingaben . . . . . . . . . . . . . . . . . . . . . . . 423 Abh¨angige Definitionen f¨ ur Shared-Memory . . . . . . . . . . . . . . . 424 PosixShm.h f¨ ur WIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 PosixShm.cpp f¨ ur WIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 OS-abh¨ angige CBinarySemaphore.h . . . . . . . . . . . . . . . . . . . . . . 433 OS-abh¨ angige Implementierungen f¨ ur CBinarySemaphore . . . 438 Abh¨angige externe const-Definitionen . . . . . . . . . . . . . . . . . . . . 439

Abbildungsverzeichnis

2.1 2.2

Beispiel eines Infotainment-Systems . . . . . . . . . . . . . . . . . . . . . . . Beispiel eines Funktions-Blockbilds einer Headunit . . . . . . . . . .

7 9

3.1

MVC-Architektur am Beispiel Tuner . . . . . . . . . . . . . . . . . . . . . . 14

5.1

Big/Little-Endian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.1 6.2 6.3 6.4 6.5 6.6 6.7

Speichermap, siehe auch [Mad] . . . . . . . . . . . . . . . . . . . . . . . . . . . Heap- und Stack im Adressraum . . . . . . . . . . . . . . . . . . . . . . . . . . Speicher-Layout eines Objekts mit virtueller Methode . . . . . . . Speicher-Layout eines B-Objekts mit virtueller Methode . . . . . Impliziter Up-Cast“, Speicher-Layout . . . . . . . . . . . . . . . . . . . . . ” Speicher-Layout zweier virtueller Klassen-Objekte . . . . . . . . . . . Mehrfach-Vererbung und falscher Cast . . . . . . . . . . . . . . . . . . . . .

7.1 7.2 7.3

Abh¨angige Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Klassendiagramm Allocator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Statisches Allocator-Objekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8.1 8.2 8.3

Speicherlayout nach fork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Nachrichtenkopplung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Speicherkopplung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

9.1 9.2 9.3 9.4 9.5 9.6

Pipe-Erzeugung, fork und Schließen der Pipe-Enden . . . . . . . . 123 Kommunikation mit Pipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Message-Queue Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 QNX-Message-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Bildliche Darstellung eines Shared-Memory Bereichs . . . . . . . . . 138 Zeitmessungen der unterschiedlichen IPC-Methoden, [Klein] . . 149

11.1 11.2

Zustandsdiagramm der m¨ oglichen Semaphore-Zust¨ande . . . . . . 155 Semaphore zwischen zwei Prozessen . . . . . . . . . . . . . . . . . . . . . . . 157

30 32 45 47 50 51 53

XXII

Abbildungsverzeichnis

11.3 11.4 11.5 11.6 11.7

Zustandsdiagramm der m¨ oglichen Mutex-Zust¨ande . . . . . . . . . . 162 Zeitverhalten der Synchronisationsmethoden . . . . . . . . . . . . . . . . 177 Deadlock-Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Begrenzte Inversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Priorit¨atsinversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

12.1

Die Nutzung eines Pools zur Event-Erzeugung . . . . . . . . . . . . . . 192

13.1 13.2 13.3

Symbolische Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Reale Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Handshake zwischen Produzenten und Konsument . . . . . . . . . . 208

14.1 14.2 14.3 14.4 14.5 14.6 14.7 14.8 14.9 14.10 14.11 14.12 14.13 14.14 14.15 14.16 14.17

Zustandsloses Objekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Zustandsbehaftetes Objekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Bedingter Zustands¨ ubergang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Zustands¨ ubergangstabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Aktionen im Zustandskontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Zustandshierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 ¨ Uberg¨ ange in der Zustandshierarchie . . . . . . . . . . . . . . . . . . . . . . 220 Default-Start- und End-Zust¨ ande . . . . . . . . . . . . . . . . . . . . . . . . . 220 Statechart mit Ged¨ achtnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Statechart mit tiefer Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Statechart mit Parallelismus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Zustands¨ uberg¨ ange in Hierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Beispiel eines Statecharts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Abge¨andertes Statechart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Klassendiagramm des Zustandsmusters . . . . . . . . . . . . . . . . . . . . 233 Die FSM im Oberzustand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Klassendiagramm von CFSM5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

15.1 15.2 15.3 15.4 15.5 15.6 15.7 15.8 15.9 15.10

MOST-Ring mit Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Mehrere Function-Blocks in einem Ger¨at . . . . . . . . . . . . . . . . . . . 256 MOST-Funktionsaufruf, Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Beispiel einer DeviceID-Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Beispiel einiger FblockID-Tabellen . . . . . . . . . . . . . . . . . . . . . . . . 261 Verwendung der FktIDs am Beispiel eines Multimedia-Changers262 OPTypes f¨ ur Methoden und Eigenschaften . . . . . . . . . . . . . . . . . 262 Datentypen in MOST, aus [MOST] . . . . . . . . . . . . . . . . . . . . . . . . 263 Zentrale Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Beispiel einer Notifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

18.1 18.2 18.3 18.4 18.5

Tasks der Headunit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Klassendiagramm zu einer Komponente . . . . . . . . . . . . . . . . . . . . 289 Kontext-Header der Komponenten . . . . . . . . . . . . . . . . . . . . . . . . 291 Kontext einer Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Eingebauter Watchdog-Mechanismus . . . . . . . . . . . . . . . . . . . . . . 304

Abbildungsverzeichnis XXIII

18.6 18.7 18.8 18.9

Tickservice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Mechanismus zum Auffordern eines Zustandswechsels . . . . . . . . 307 Empfang eines Tick-Events, Timer-Manager und -Client . . . . . 317 Beispiel einer Komponente (logisches Tuner-Device) . . . . . . . . . 328

19.1 19.2

Main-Dispatcher-Komponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 MOST-Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

20.1 20.2 20.3 20.4 20.5 20.6 20.7 20.8 20.9 20.10 20.11 20.12

Blockbild des logischen Ger¨ ats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 Anforderungen der HMI an das logische Ger¨at . . . . . . . . . . . . . . 345 Zust¨ande des logischen Ger¨ ats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 Daten-Container f¨ ur die HMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 Container f¨ ur Soll- und Ist-Daten . . . . . . . . . . . . . . . . . . . . . . . . . 350 Klassendiagramm des Datencontainers . . . . . . . . . . . . . . . . . . . . . 351 Struktur des Datencontainers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Adapter f¨ ur die HMI zum Lesen des Datencontainers . . . . . . . . 356 Versenden eines HMI-Befehls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 Expertenwissen in der Ger¨ atesteuerung . . . . . . . . . . . . . . . . . . . . 359 Hierarchie der elementaren MOST-Datentypen . . . . . . . . . . . . . . 374 Vier Varianten von CModelInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

21.1

HMI-Komponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

1 Einleitung

Es gibt in der derzeitigen Fachliteratur einige Ausf¨ uhrungen u ¨ber EmbeddedSysteme. Ihre Schwerpunkte liegen oft auf den daf¨ ur verwendeten Betriebssystemen oder auf Applikationen in kompakter, nicht vernetzter Umgebung. Beide Autoren haben in den letzten Jahren die Einf¨ uhrung von modernen SW-Strukturen ins Auto miterlebt und mitgestaltet. Die Ausf¨ uhrungen beziehen sich deshalb im Folgenden beispielhaft auf vernetzte Systeme im Auto. Im Moment ist der europ¨aische Standard daf¨ ur ein optischer Bus, MOST-Bus genannt (media oriented system transport), [MOST]. Die Ausf¨ uhrungen sind aber allgemein genug, um auch f¨ ur andere Vernetzungen verwendbar zu sein. Das Buch ist in zwei Teile gegliedert. Teil 1: Welche Bausteine zu einem Framework geh¨oren, welche Dinge festgelegt werden m¨ ussen und welche Anforderungen an ein Framework gestellt werden, wird in diesem ersten Teil des Buches besprochen. Insbesondere der erste Teil l¨ asst sich auf viele Dom¨anen der Embedded Software anwenden. Da es vielen, auch erfahrenen SW-Ingenieuren nicht bekannt ist, wie sich ihre Programme im Speicher auswirken, beginnt der Teil 1 mit einigen Grundlagen dazu. Anschließend werden Grundkonzepte und Grundbausteine von Embedded Systemen er¨ ortert. Ein Schwerpunkt der Diskussion ist dabei das Speicherverhalten und die Startperformance. Grundmechanismen der Betriebssysteme werden erl¨autert und ausgemessen, um Speicherverwendung, Kommunikation und Synchronisationen effizient zu gestalten. Dabei wird darauf geachtet, dass Implementierungen unter Linux, QNX und Windows lauff¨ ahig sind. Dieser Teil ist sowohl an Studierende als auch an Embedded Experten gerichtet.

2

1 Einleitung

Teil 2: Im zweiten Teil des Buches wird eine prototypische objektorientierte Framework-Implementierung besprochen. Diese diente zur Erprobung besonders effizienter Synchronisations- und Kommunikationsans¨atze. Außerdem sollte das Framework besonders klein sein und gute Startzeiten haben. Die Vors¨atze sind in dem kleinen Rahmen recht gut gegl¨ uckt, ein Framework entsprechend der vorgestellten Erkenntnisse mit mittlerer Applikationsausstattung bewegte sich im Rahmen von 2,5 s Startzeit und einer Gr¨oße von einigen 100 kByte. Noch viel wichtiger betrug die Umsetzungszeit nur wenige Mannmonate. Neue Ideen In dieses Buch sind einige Konzepte eingeflossen, die den Autoren aus der Literatur noch nicht bekannt waren. Es sind dies: • Flexible, aber einheitliche Konfiguration f¨ ur Threads und Prozesse, • daf¨ ur intensive Nutzung des Shared-Memories in Verbindung mit dem fork-Konstrukt und von Thread-specific-Data; • Queue-Konstrukte mit Vorrichtungen gegen Priorit¨ats-Inversion; • Komponenten-Klassen mit festem Set von Queues und Services; • Hintergrundsysteme: Watchdog, Timer; • spezielle FSM-Architekturen f¨ ur Embedded Systeme; • Lauff¨ahigkeit auf QNX, Linux, Windows; • const-Objekte im Code-Segment zum Dekodieren der MOST-Nachrichten zur Performance-Optimierung. Eine Schwierigkeit bei der Erstellung war das Ziel, im Text verallgemeinert genug zu bleiben, um noch lesbar zu sein und doch gleichzeitig auch Quellcodes zu zeigen, damit sich der Leser ein substanzielles Bild machen kann, wie die Erkl¨arungen gemeint sind und umgesetzt werden k¨onnten. Ein Versuch, dieses Dilemma zu l¨ osen, war, die Quelltexte auf das N¨otigste zu k¨ urzen. S¨amtliche Includes wurden weggelassen. Nach dem Vorbild von [Stev] wurden alle wichtigen Includes in einen Abschnitt im Anhang verlagert. Weiterhin wurden viele Programmzeilen durch . . .“ ersetzt. ” Alle Sourcen laufen prinzipiell auf QNX, Linux und Windows. Allerdings wurden auch hier einige ifdefs herausgek¨ urzt, die n¨otig waren, um auf die Eigenheiten der Betriebssysteme einzugehen. Im Anhang finden sich daf¨ ur Hinweise. Ohne dass ein ganzes Framework in allen Einzelheiten vorgestellt wird, kann der Leser sicher manche Erkenntnisse aus den Beispielen gewinnen, sie umsetzen oder eigene Implementierungen an den vorgestellten Implementierungen messen. Unter dem Link www.fbi.fh-darmstadt.de/∼jwietzke/Das Buch k¨onnen viele Quellen angesehen und heruntergeladen werden. Auch ein aktueller Stand eines studentischen Framework-Projektes wird dort ab Juli 2005 zu finden sein.

1 Einleitung

3

Anmerkungen zur Dom¨ ane und zur Sprache: Ein Framework ist immer dom¨ anenspezifisch, auch viele SW-Muster (Pattern) sind dom¨anenspezifisch, in unseren Beispielen spezifisch f¨ ur Embedded Automotive Systeme. In jeder Dom¨ ane gibt es Fachbegriffe, die sich nur schwer u ¨bersetzen lassen. Wir werden auf die Eindeutschung von englischen Begriffen verzichten, ein Thread wird nicht als Laufzeitfaden u ¨bersetzt, sondern bleibt, nach einer inhaltlichen Erl¨auterung, ein Thread. Auch die Frage der Groß- oder Kleinschreibung englischer Begriffe, die eventuell im Deutschen schon bekannt sind, wird systematisch ignoriert. Wir w¨ ahlen, wann immer wir darauf achten, die Großschreibung oder die Kleinschreibung. Auch die Frage, welche Sprache in den Kommentaren der Implementierung gew¨ahlt wird, soll ohne Bedeutung sein, wesentlich ist nur das Vorhandensein hoffentlich aufschlussreicher Kommentare.

Teil I

Bausteine eines Embedded Frameworks

2 Ein Infotainment-System

Ein typisches so genanntes Infotainment-System im KFZ besteht aus einigen miteinander vernetzten Komponenten. In unseren Beispielen und Bildern gehen wir von einer MOST-Vernetzung aus. (Der MOST-Bus ist ein optischer Bus, der f¨ ur automobile Anwendungen definiert wurde. Die Details, die wir f¨ ur unsere Software-Betrachtungen brauchen, werden wir an passender Stelle er¨ ortern und verwenden bis dahin den MOST-Bus als Platzhalter f¨ ur irgendeine Vernetzung).

Abbildung 2.1. Beispiel eines Infotainment-Systems

Minimalumfang ist die Headunit, die als Bedieneinheit (HMI= human machine interface) f¨ ur das System und ggf. auch f¨ ur weitere Funktionalit¨aten des KFZ dient. Beispielsweise steuert sie auch Klimaanlage, Sitzverstellung und Diagnosefunktionen. Die Headunit ist die Kommandozentrale (HMI) des Multimedia-Systems. An ihr sind das Display und die meisten Bedienelemen-

8

2 Ein Infotainment-System

te angeschlossen. In einem vernetzten System u ¨bernimmt sie normalerweise auch die Masterfunktionen im Netz bez¨ uglich On/Off, Audiokanalvergabe, Display-Vergabe und die Priorit¨ atsvergabe von Ressourcen. Sie befindet sich sichtbar im Armaturenbrett mit einem Display und einigen Bedienschaltern und beinhaltet den Hauptrechner, welcher die Masterfunktion im Netzwerk hat. Zum System selbst geh¨ oren je nach Ausstattungsgrad: Die Headunit Gateway Audiokomponenten

Display, Bedienelemente, Netzwerkmaster Br¨ ucke zu Kfz-Bussystemen wie CAN Tuner, Amplifier, Soundsystem, Kopfh¨ orerverst¨arker, CD-Laufwerk, CD-Wechsler, DVD-Laufwerk, Kassettenlaufwerk Videokomponenten Video-/DVD-Laufwerk, TV-Tuner andere Komponenten Navigation mit Sensorik wie GPS, Radimpulse, R¨ uckw¨artsgang Kommunikationskomponenten Telefon/Telematik-Box Rear Seat Entertainment Unterhaltung f¨ ur Fonds-Passagiere, zweite Slave-Headunit

2.1 Die Headunit In der Headunit werden alle Funktionen des Netzwerkes gesteuert. Sie ist gleichzeitig der Bedienknoten f¨ ur den Benutzer. F¨ahigkeiten, die einzelne angeschlossene Ger¨ate haben, k¨ onnen in der Headunit miteinander zu neuen Funktionen kombiniert werden. Die Hinterleuchtung des Displays kann vom Fahrlicht abh¨angen, Fenster k¨ onnen geschlossen werden, wenn das Telefon klingelt, abh¨angig vom Z¨ undschl¨ ussel k¨ onnen Nutzerprofile mit unterschiedlichen Bediensprachen, Sitzeinstellungen und Sender-Favoritenlisten angeboten werden. Ersichtlich ist die Headunit der Netzwerkknoten mit der h¨ochsten Funktionalit¨ at und Komplexit¨ at im Netzwerk, eine gew¨ ahlte Software-Architektur muss sich mit vielen Eigenheiten der angeschlossenen Ger¨ate auseinandersetzen. Hinzu kommt, dass die Hardware im Wesentlichen einem Embedded System entspricht, das heißt vor allem, dass Speicher knapp und Rechenleistung nicht allzu hoch sind. Da immer kritische Ruhe- und/oder Betriebsstromforderungen gestellt werden, sind die Hardware-Kenngr¨oßen eine bis zwei Generationen hinter den allgemeinen PC-Trends. Zudem sind die Systeme nicht immer in ihrer Software nachladbar und m¨ ussen ca. 20 Jahre schadlos u ¨berdauern und wartbar bleiben. Ein wenn auch kleiner Teil der Embedded Anforderungen an die Software beinhaltet Echtzeit-Anforderungen. Protokoll-Zeiten im MOST-System

2.2 Ger¨ ate/Devices im System

9

m¨ ussen eingehalten werden, Positionsgenauigkeiten der Navigation, Reaktionszeiten in der Bedienung und schnelle Startzeiten der Systeme (2 sec).

Abbildung 2.2. Beispiel eines Funktions-Blockbilds einer Headunit

2.2 Ger¨ ate/Devices im System Devices sind Ger¨ ate mit abgegrenzter Funktion. Wir werden sp¨ater sehen, dass jedes Device einen eigenen Namen im Netzwerk hat, beispielsweise sind Tuner und Amplifier einzelne Devices, auch wenn sie sich tats¨achlich im gleichen Geh¨ause auf der gleichen Hardware befinden k¨onnen. Sie sind normalerweise u ¨ber eine Vernetzung an der Headunit angeschlossen, durch die heutige Hochintegration gibt es aber auch Devices, die im selben Geh¨ause wie die eigentliche Headunit verbaut sind. Es gibt die Unterscheidung in interne Devices und externe, d.h. vernetzte Devices. Wir unterscheiden weiterhin in MOST- und non-MOST-Devices, also Devices, die dem Vernetzungsprotokoll folgen, und solche, die andere, normalerweise low-level APIs (Application Programming Interface) haben. Ein u ¨ber das MOST-System angeschlossener DVD-Player w¨are demnach ein externes

10

2 Ein Infotainment-System

MOST-Device; die in der Headunit integrierte Navigation w¨are ein internes MOST-Device, der DVD-Mediaplayer, der u ¨ber ein ATAPI-Interface angesprochen wird, w¨ are ein internes non-MOST-Device.

2.3 Begriffskl¨ arung: Was ist ein Framework Ein Framework ist normalerweise nicht explizit n¨otig bei kleinen Arbeitsgruppen, die ein einmaliges Projekt ohne geplante Wiederverwendung realisieren. Alle Regeln, Schnittstellen und Abstraktionen geschehen auf Zuruf, Dokumentation ist eher schwach ausgepr¨ agt. Sobald gr¨oßere Gruppen, eventuell sogar verteilt u ¨ber Standorte, an einem oder mehreren Projekten arbeiten, m¨ ussen Regeln und L¨osungen festgelegt werden, die im Framework niedergelegt werden. Das Framework legt fest: • • • • • • • • • • • • • • • • •

Design Rules, Namenskonventionen, do’s und don’ts; die Definition der Komponenten als Threads oder Prozesse; die Kommunikation zwischen Komponenten; Speicherdefinitionen, viele effiziente Mechanismen f¨ ur Embedded Systeme; Kapselung des Expertenwissens bez¨ uglich Vernetzung, OS-Spezialit¨aten, Prozessverwaltung, Prozesskommunikation, On/Off . . . und damit Trennung von Schnittstellen und Implementierungen; Kapselung und Trennung von Information/Daten/Zust¨anden und algorithmischer Implementierung; Hardware-Abstraktionen; OS-Abstraktionen; Portabilit¨atsdefinition; Basisklassen und Patterns f¨ ur Strukturen, Controller, Proxies, Treiber, Anzeigen; Header, Interfaces, Beispiele; Verwendbarkeit: Wartbarkeit, Erweiterbarkeit, Restrukturierbarkeit, Portabilit¨at; Interoperabilit¨ at; Effizienz; Testbarkeit; Wiederverwendbarkeit; das Framework legt Performance und Ressourcen grunds¨atzlich fest, Fehler, die hier gemacht werden, k¨ onnen durch sp¨atere Korrekturen im Handwerk nicht mehr verbessert werden. Normalerweise werden solche Fehler erst kurz vor Abschluss eines Projektes entdeckt und k¨onnen nicht mehr ¨ zufriedenstellend beseitigt werden. Ublicherweise haben Kunden in Folgeprojekten kein Verst¨ andnis f¨ ur eine Alles-neu-Entwicklung“, weshalb sich ” die Fehler durch mehrere Generationen fortpflanzen.

2.4 Fokus unserer Framework-Betrachtungen

11

In Erg¨anzung zum Framework (und hier von nicht scharf unterscheidbar) wird normalerweise eine Architektur definiert, in der z.B. die Partitionierung in einzelne Baugruppen, Komponenten und Aufgaben festgelegt wird. Ein Framework ist ein nur teilweise komplettes Fundament, das f¨ ur ein konkretes Projekt abgeleitet und konkretisiert wird. Diese Konkretisierungen sind die projektvarianten Teile (Hot Spots), wie zum Beispiel: Bedienphilosophien und Darstellungseigenarten, konkrete Speicherpartitionierungen und Hardware-Anpassungen. In anderen Teilen ist Expertenwissen u ¨ber Abl¨aufe, Protokolle und Performance implementiert und gekapselt (Frozen Spots), diese Teile sind projektinvariant. Es gibt in der Literatur verschiedene Prinzipien f¨ ur Frameworks, die auch kombiniert werden k¨ onnen. • Vererbung: Basisklassen-Framework. Die Aufgabenstellungen sind vorher klar, virtuelle Methoden, die vom Applikateur ausprogrammiert werden m¨ ussen. • Plug-In: Variante Methoden u ¨ber Schnittstellen. • Templates: Kompliziert, bedingt debugf¨ ahig durch neue Compiler, Erlernen eigener Syntax und Semantik erforderlich. • Codegeneratoren: Vereinfachung der Templates durch lesbare Beschreibungen, z.B. in XML. Aber: Statische Source-Code-Generierung, keine Interpretation zur Laufzeit. Die letzte Variante liegt diesem Buch zu Grunde, etwa die H¨alfte des vorgestellten Anwendungscodes wird mit einem Codegenerator erzeugt. Dennoch wird u ¨ber Code-Generierung nur sehr wenig zu lesen sein, da es gute Tradition ist, ein Konzept und eine Implementierung ein erstes Mal per Kopf und Hand zu verstehen und zu implementieren, dabei zu lernen und erst dann die entsprechenden Generatoren zu erfinden. Die Codegenerierung k¨onnte einmal Teil des Inhalts eines folgenden Bandes sein. Die dahinter liegende Codegenerierung erkl¨art (und entschuldigt hoffentlich) aber auch die verteilten Informationen, die im Zusammenhang mit dem Hinzuf¨ ugen neuer Komponenten bearbeitet werden m¨ ussen.

2.4 Fokus unserer Framework-Betrachtungen Wenn wir im Folgenden u uste ¨ber Frameworks sprechen, so sind damit SW-Ger¨ f¨ ur eine umfangreiche Headunit-Funktionalit¨ at gemeint. Eine Headunit ist die Bedieneinheit im Armaturenbrett, von der aus vielf¨altige InfotainmentFunktionen wie Radio, Navigation, Telefon, Sound, TV, Internet, Sprachbedienung etc. bedient und gesteuert werden. Auch KFZ-Funktionen wie Klimaanlage, Schließsysteme, Diagnose etc. k¨ onnen Teil des Steuerumfangs sein.

12

2 Ein Infotainment-System

Nat¨ urlich k¨onnen gr¨ oßere Teile eines solchen Frameworks auch in Einzelkomponenten im Fahrzeug verwendet werden, die umfassendsten Anforderungen an Parallelit¨ at, Speicher, Darstellung und Bedienung stellen sich aber in der Headunit, weshalb wir ein Framework von hier aus entwickeln.

3 Anforderungen an ein Embedded Automotive Framework

Es gibt die u ¨blichen Anforderungen an Erweiterbarkeit, Robustheit, aber auch Anforderungen an die verteilte Entwicklung, die oft durch Zuk¨aufe von Kompetenzfirmen entsteht.

3.1 Verteilte Entwicklung Wie bereits erw¨ ahnt, sind bei u ¨blichen Projekten die Entwicklergruppen u ur ¨ber mehrere Standorte verteilt. Historisch bedingt gibt es Standorte f¨ Navigations-Systeme, andere sind spezialisiert f¨ ur Sprachbedienung oder f¨ ur Systemintegration. Zumeist sind in Automotiv-Systemen auch mehrere Lieferanten beteiligt. Selbst wenn alle Expertengruppen an einem Standort arbeiten, reicht schon der Abstand von einigen 10 Metern oder Geschossen, um von einer verteilten Entwicklung sprechen zu m¨ ussen. Ein Framework muss also Designregeln, Ressourcenverteilung und anderes so festlegen, dass nicht st¨andige Kommunikation erforderlich ist.

3.2 MVC, Organisationen Software-Architekturen werden oft unbewusst so entwickelt, dass sie ein Abbild der Organisation sind, die mit ihnen arbeiten muss. Beispielsweise werden Prozesse so verteilt, dass jede Abteilung ihren eigenen Prozess hat, mit klaren Abteilungsschnittstellen nach außen. Dies ist sicher kein sinnvoller Ansatz bei der Suche nach der technisch besten L¨ osung. Andererseits muss große Software so zerlegt werden, dass sie in Modulen und in Arbeitsgruppen erarbeitet werden kann. Eine sinnvolle Aufteilung ist die Zerlegung in Schichten. Eine protokollnahe Schicht kapselt das Wissen, das f¨ ur die Kommunikation zwischen Ger¨aten erforderlich ist, das Kommunikationswissen.

14

3 Anforderungen an ein Embedded Automotive Framework

Eine dar¨ uber liegende Schicht verarbeitet die Eingangsanregungen aus der Kommunikation und bereitet Ausgaben auf. Es kapselt das Ger¨ atewissen und implementiert die eigentliche Ger¨ atesteuerung. Diese Schicht ist weitgehend projektinvariant, solange nicht die Hardware ge¨andert wird. In dem bekannten MVC-Pattern [Bus] w¨ are das die Modell-Schicht. Dar¨ uber stellt eine Schicht die Bedienfunktionalit¨at des Systems und deren Darstellung zur Verf¨ ugung. Hier wird System- und Bedienwissen gekapselt, wann welches Men¨ u zur Verf¨ ugung steht und welche Daten angezeigt werden. Man spricht hier von der Controller-Schicht, die projektvariant ist. Schließlich gibt es eine Darstellungsschicht, in der die Art der Datenanzeige definiert ist. Auch kleine Animationen werden hier lokal realisiert. Diese Schicht, im MVC-Pattern View genannt, ist der varianteste Teil in einem ¨ Projekt und unterliegt st¨ andiger Anderungen durch Kunden und Vorgesetz¨ te. Es ist deshalb sehr sinnvoll, die Anderungen hier lokal vorzunehmen und m¨oglichst andere Schichten nicht anzutasten.

Abbildung 3.1. MVC-Architektur am Beispiel Tuner

Ersichtlich nimmt die projektabh¨ angige Varianz von oben nach unten ab. Normalerweise wird nach einmaliger Festlegung innerhalb eines Projektes nicht mehr viel an den Bedienfolgen ver¨ andert und nur noch ganz wenig an den Komponenten selbst, sofern die HW konstant bleibt. Diese Architektur wird sp¨ ater noch erweitert, da wir es mit vernetzten Systemen zu tun haben, in denen das eigentliche Ger¨at u ¨ber eine zeitverz¨ogernde Vernetzung angeschlossen ist und durch lokale Stellvertreter (Proxies) ersetzt werden muss. Dies wird sp¨ ater im Realisierungsteil noch genauer besprochen.

3.4 Startzeiten

15

3.3 Speicheranforderungen Im Gegensatz zur PC-Welt ist der Speicher in der Embedded Welt knapp. Speichergr¨oßen von 32 Mbyte RAM und 16 Mbyte Flash sind typisch und schon komfortabel. Es gibt normalerweise keine Hard-Disk oder andere Massenspeicher. Mit einem solch knappen Speicherplatz und einer Vielzahl von geforderten Features muss das Framework Vorgaben zur Speicherorganisation machen, so dass nicht jeder Entwickler alle Tricks der sparsamen Speicherorganisation kennen muss. Auch das Thema Speicherfragmentierung, das in der PC-Welt keine große Rolle spielt, hat f¨ ur automotive Systeme, die auch Dauerl¨aufe u ussen, Relevanz1 . Tabu ist dabei zurzeit noch eine ¨ber Wochen u ¨berstehen m¨ Garbage-Collection“, die die Zeitanforderungen an das System st¨oren w¨ urde. ”

3.4 Startzeiten Die Vorgabe lautet hier zurzeit 2 Sekunden vom Anlegen der Betriebsspannung bis zum vollst¨ andigen Funktionieren der Schl¨ usselfunktionen Ton (Audio), Bild (Display) und Bedienbarkeit. Hintergrund ist der sicherheitsrelevante Parkdistanzwarner, der sp¨ atestens 2 Sekunden nach Start des Motors funktionieren und Hindernisse akustisch und optisch auf dem System melden muss. ¨ Vorstartkonzepte, die das System schon beim Offnen der T¨ uren starten, helfen hier nicht wirklich, da auch nach einem Start aus einem UnterspannungsReset (Winterbetrieb bei schwacher Batterie) oder wenn der Fahrer nach einer Schlafpause bereits im Auto sitzend startet, das System nach 2 Sekunden funktionieren muss. ¨ Ublicherweise ist eine Embedded Hardware so ausgelegt, dass Code- und Datensegmente aus einem Flash-Speicher in einen Arbeitsspeicher (RAM) entpackt und kopiert werden. Anschließend wird aus dem RAM gestartet (boot). Es gibt erste Vorschl¨ age, diese Images so zu generieren, dass sie bereits einen Zustand im oder nach dem Booten darstellen, um so Startzeiten zu verk¨ urzen. 1

Ein anschauliches Beispiel f¨ ur Speicherfragmentierung ist ein Parkplatz f¨ ur PKWs. Jeder hat sich schon dar¨ uber ge¨ argert, dass eigentlich noch Platz f¨ ur das eigene Auto w¨ are, h¨ atten nicht Vorg¨ anger so dusselig“ geparkt, dass die L¨ ucken ” gerade so eng sind, dass kein Auto mehr dazwischen passt. In Summe w¨ are bei geschickterem Parken noch Platz f¨ ur einige Autos. Oft liegt diese Parkplatzfragmentierung nicht an der fehlenden Kompetenz der Fahrer, sondern einfach nur an der Vorgeschichte und verschieden breiten Autos.

16

3 Anforderungen an ein Embedded Automotive Framework

3.5 Menu ¨ wechselzeiten Erfahrungsgem¨aß werden Men¨ uwechselzeiten von 50 Millisekunden akzeptiert. L¨ angere Zeiten werden vom Kunden als Performance-Problem des Systems gedeutet.

3.6 Konfiguration versus Dynamik Ein großes Thema der letzten Jahre war die Dynamik in Automotive Systemen. Die Vorstellung eines Plug&Play im Auto war bestechend. Am besten noch u ¨ber Ger¨ate verschiedener Lieferanten hinweg. Daraus entstanden Konzepte, die in der Startphase die Eigenschaften der angeschlossenen Ger¨ate abfragten und registrierten. Um den Busverkehr im Betrieb zu reduzieren, wurden Notifizierungsmechanismen implementiert. Die Erfahrungen zeigen aber, dass diese Dynamik zwischen Komponenten oft nicht beherrscht wird, speziell in Fehlerf¨allen zwischen den Komponenten gibt es bis heute Probleme, die erst durch Neustart zu beheben sind. Kurzfristig ist deshalb die statische Konfiguration der Systeme vorzuziehen, dies spart Startzeit, ist in Fehlerf¨ allen unkritischer und generell weniger komplex. Es hat sich auch gezeigt, dass die urspr¨ unglich geforderte hohe Flexibilit¨at am Ende ohnehin nicht an den Kunden weitergegeben wurde.

3.7 Datenfluss/Kontrollfluss/Zustandssteuerung Automotive Infotainment Systeme sind hochgradig zustandsorientiert. Die meisten Abl¨aufe lassen sich gut mit Zustandsautomaten oder Sequenzdiagrammen beschreiben. Die wenigen Abl¨ aufe, die von Daten (zum Beispiel Feldst¨arken) abh¨ angen, lassen sich durch Entscheidungsschwellen auf Zust¨ande abbilden. Wir werden uns daher in einem sp¨ ateren Kapitel ausf¨ uhrlicher mit den Konzepten von Zustandsautomaten befassen.

4 Betriebssysteme

In fr¨ uhen Embedded Systemen war kein Betriebssystem notwendig. Das Ger¨at basierte auf einer einfachen Hauptschleife, die nacheinander Bedienelemente abfragte und entsprechende Ger¨ atefunktionen ansteuerte. Wegen zunehmender Funktionalit¨ aten, sich ¨ andernder Hardware-Plattformen und wegen der hohen Anforderungen an gef¨ uhlte Bedienbarkeit kam man bereits fr¨ uh zur Notwendigkeit von Betriebssystemen, die eine scheinbare Parallelit¨at erlaubten, so dass nun, wenn z.B. in einer Applikation auf eine Tastatureingabe gewartet wird, eine andere inzwischen weiterarbeiten kann. Betriebssysteme organisieren die • • • •

quasi parallele Abarbeitung verschiedener Prozesse oder Threads; sie verwalten Hardware- und Software-Ressourcen; sie kapseln und abstrahieren Hardware-Funktionen und Schnittstellen; sie stellen zum Teil standardisierte Services zur Verf¨ ugung, wie z.B. Speicherverwaltung, Kommunikations-Schnittstellen, Lader, Fehlerroutinen, Synchronisations- und Kommunikationsmethoden.

Im Zusammenhang mit der Framework-Diskussion im automotiven Umfeld sind gleichzeitig einige Betriebssysteme in der Diskussion. Diese Verkn¨ upfung ist zun¨achst einmal ungl¨ ucksselig, da die Begriffe Framework und Betriebssystem eigentlich verschiedene Schichten betreffen. Durch das Paket WinCE, das Betriebssystem und Framework fast untrennbar verbindet, kommt es zur Vermischung der Begriffe. Auch ein GUI-Builder (Graphical User Interface) wie Photon f¨ ur QNX vermischt Framework und OS-Schichten. Trotzdem sollten die weitgehend u ¨blichen Betriebssysteme erw¨ahnt werden. Es sind: VxWorks, das sehr erprobt und geeignet in der kleinen Multithread- Umgebung ist, f¨ ur das es aber noch nicht viel Erfahrung in Multiprozess-Systemen gibt. In a¨hnlicher Weise ist I-Tron einzuordnen, das sehr h¨aufig in japanischen Systemen eingesetzt wird.

18

4 Betriebssysteme

Mit m¨achtigeren Prozessoren wie dem SH4 von Hitachi und dem PowerPC von Motorola und anderen kommen die M¨oglichkeit und die Forderung nach Multiprozess-OS auf. Hier greift im Moment QNX, dessen Entwicklungsumgebung (Momentics) allerdings speziell bei großen Projekten viele Schw¨achen hat. Die St¨arken von QNX sind die Echtzeitorientierung und die POSIX-Konformit¨at. WinCE kommt immer wieder in die Diskussion mit der Vorstellung eines Standards, genauso oft stellt sich aber auch heraus, dass die Verquickung von Framework und Betriebssystem bei WinCE von den Entwicklern nicht geliebt wird. Auch sind die Einschr¨ ankungen im Framework noch so groß, dass am Ende im Wesentlichen nur der OS-Teil genutzt und ein eigenes Framework drumherum implementiert wird. Daf¨ ur ist es dann aber zu aufw¨andig und teuer. Die richtige Design-Entscheidung scheint deshalb hier zu sein, sich vom OS zu abstrahieren und mehrere Betriebssysteme zu unterst¨ utzen. Die vorgestellten Implementierungen werden deshalb in der Regel auf VxWorks, QNX und Windows lauff¨ ahig sein, dies zwingt auch wieder dazu, sich nicht zu sehr auf Spezialit¨aten nur eines Betriebssystems einzulassen. In sp¨ateren Kapiteln wird gezeigt, wie Programme wahlweise unter QNX, Windows und Linux laufen k¨ onnen, solange man sich bei der Auswahl der Betriebssystem-Mittel beschr¨ ankt. Deshalb werden wir hier auf Betriebssysteme nicht weiter eingehen, nur drei notwendige Begriffe kurz erl¨ autern und sp¨ater in den Implementierungsbeispielen von Betriebssystem-Funktionalit¨aten einfach nur ohne weitere Erl¨auterung Gebrauch machen.

4.1 Prozesse, Tasks, Threads Die Literatur unterscheidet nicht scharf zwischen Prozessen und Tasks. Beide Begriffe beschreiben den Ablauf eines Programms auf einem quasi eigenen Prozessor. Es gibt Lesarten, nach denen ein Prozess ein Ablauf auf einem idealen Prozessor ist, d.h. Prozesse haben virtuell unendlich viel Speicher und ihr Speicher ist gut gegen andere Prozesse gesch¨ utzt. Eine Memory Management Unit (MMU) wird eingesetzt und kann bei Bedarf weiteren Arbeitsspeicher zuteilen (mappen). Demgegen¨ uber setzen Multitask-Systeme nur einfache MMUs ein, ihre Speicherbereiche sind zwar gegeneinander gesch¨ utzt, es wird jedoch kein Speicher umgemapped. Da diese Unterschiede nicht klar definiert sind und der Gebrauch der Begriffe fließend ist, werden wir den Begriff Task f¨ ur abgegrenzte Aufgaben verwenden, die als Prozess oder als Thread implementiert sein k¨onnen. Der Begriff Prozess wird definiert als oben beschriebener Ablauf in eigenem Speicher.

4.2 Der Scheduler

19

Threads sind ebenfalls eigene Ablauff¨ aden auf einem virtuell eigenen Prozessor, allerdings teilen sich Threads einen gemeinsamen Speicher. Dies wird in einem sp¨ateren Kapitel noch n¨ aher erl¨ autert. Alle drei Begriffe beschreiben Programmabl¨aufe, die zeitlich schnell abwechselnd von einem Betriebssystem-Scheduler organisiert werden, so dass es nach außen erscheint, als liefen die Programme quasi parallel.

4.2 Der Scheduler Der Scheduler organisiert, in welcher Abfolge und f¨ ur wie lange verschiedene Aufgaben quasi parallel abgearbeitet werden. Er teilt Rechenzeit zu und verwaltet die Zust¨ ande (aktiv, blockiert, bereit) der Prozesse. Die Prozesse haben nach ihrer Wichtigkeit unterschiedliche Priorit¨aten, die beim Start eines Prozesses festgelegt werden. Interrupt-Routinen, die HW-Interrupts bedienen, werden nicht vom Scheduler bedient, sondern direkt durch priorit¨ atsgesteuerte Hardware. 4.2.1 Pr¨ aemptive Priorit¨ atssteuerung Es gibt verschiedene Strategien f¨ ur das Scheduling, normalerweise wird f¨ ur Tasks verschiedener Priorit¨ at pr¨ aemptiv und priorit¨atsgesteuert vorgegangen, d.h. ein Task h¨oherer Priorit¨ at l¨ ost, wenn er bereit ist, sofort einen laufenden Task niedrigerer Priorit¨ at ab und versetzt diesen in den Bereit-Zustand. 4.2.2 Round-Robin Normalerweise werden Tasks gleicher Priorit¨ at abwechselnd mit gleichen Zeitschlitzen (im Kreis) bedient. Dieses Prinzip ist meistens als Default eingestellt und nennt sich Round-Robin. Eine andere Variante w¨ are FIFO-Scheduling, bei dem der Task, der zuerst aktiv wurde, solange am Zug“ bleibt, bis er selbst freiwillig abgibt, z.B. durch ” Aufruf von sleep(0). Diese Scheduling-Policy erfordert kooperative Programmierung zwischen Tasks und sehr viel Einsicht in m¨ ogliche Abh¨ angigkeiten und Blockaden. Deshalb wird u ¨blicherweise Round-Robin bevorzugt. Diese Strategie ließe sich auch f¨ ur Tasks mit unterschiedlicher Priorit¨at einsetzen, die Abl¨ aufe w¨ aren dann streng geordnet und determiniert. Allerdings k¨onnten dann zeitkritische Aufgaben eventuell nicht schnell genug an die Reihe kommen (Echtzeitanforderung). 4.2.3 Priorit¨ ats-Inversion, Priorit¨ ats-Vererbung Es kann passieren, dass ein hochpriorer Prozess oder Thread blockiert wird und auf einen niedrigprioren warten muss, dieser aber nicht gescheduled wird,

20

4 Betriebssysteme

da er ja niedrige Priorit¨ at hat und gerade ein Task mittlerer Priorit¨at aktiv ist. Damit w¨ urde ein mittelpriorer Task einen hochprioren blockieren (Priorit¨ats-Inversion), was der Bedeutung der Priorit¨aten widerspr¨ache. Wartet ein Task auf eine Nachricht oder auf die Freigabe eines Synchronisationsobjekts eines anderen, so erbt dieser die Priorit¨at des Wartenden. Damit kann Priorit¨ ats-Inversion vermieden werden. Man nennt diesen Mechanismus im Englischen Priority-Inheritance. Wir werden diesen Abschnitt beim Kapitel Synchronisierungsmechanismen wiederholen und besser verstehen. 4.2.4 Task-Switch, Kontextwechsel Aktiviert der Scheduler den n¨ achsten Task, so erfolgt ein Task-Switch. Hierbei wird der alte Zustand des Prozessors mit allen Registerwerten gespeichert und der Zustand des neuen Tasks geholt. Auch der Sprung in eine InterruptRoutine und der Aufruf von System-Routinen im Kernel beinhalten einen Kontext-Switch.

4.3 Zusammenspiel mit der MMU Es ist zwar ein Thema der Hardware, da die MMU (memory management unit) aber f¨ ur Multi-Prozess-Systeme eine Rolle spielt, sei sie hier kurz erw¨ahnt. Eine MMU setzt logische Adressen des Prozessors in physikalische des Speichers um. Sie mapped daf¨ ur Speicherkacheln, die z.B. 4 KByte groß sind. Der virtuelle, logische Adressraum ist gr¨ oßer als der tats¨achliche physikalische. Die CPU bekommt einen ideal großen Speicher vorgespielt, in dem die MMU nicht gebrauchte Kacheln ummappen kann oder noch relevante Kacheln auf Massenspeicher auslagert (swapping). Weiterhin h¨alt die MMU Attribute der Kacheln, Informationen wie Codeoder Daten-Page, schreibbar, lesbar, ausf¨ uhrbar, User Mode, Privileged Mode. Wird versucht, diese Attribute zu verletzen, l¨ ost die MMU eine Exception, ein Signal oder einen Interrupt beim Prozessor aus. Es gibt einige Betriebssysteme, die nur die Schutzattribute der MMU verwenden, nicht aber die virtuelle Adressierbarkeit. Mit performanten MMUs kann das Problem der m¨oglichen Speicherfragmentierung reduziert werden, da sie freie Kacheln logisch neu zusammenf¨ ugen k¨ onnen.

5 Design-Rules und Konventionen

In der Literatur werden Design-Rules nicht zum Framework gez¨ahlt. Die Praxis zeigt aber, dass eine der ersten Maßnahmen f¨ ur eine funktionierende Teamarbeit und auch f¨ ur die Erstellung eines SW-Frameworks gemeinsam erstellte und akzeptierte Design-Regeln sind. Diese umfassen eine gr¨oßere Sammlung von Namenskonventionen, Dokumentationsregeln, do’s“ und don’ts“ und ” ” ggf. einige zeitliche Randbedingungen f¨ ur Software-Module. Auch der Umgang mit Priorit¨ aten kann in Design-Rules festgelegt sein. Ein kleiner Ausschnitt aus Konventionen zur Diskussion siehe unten: • • • • • • • • • • • • • • •

Interfaces statt Mehrfachvererbung; alle Klassen Pr¨ afix ”C”, alle Interfaces Pr¨ afix ”I”; Attribute: Prefix member ”m”, static ”s”; in Lib-Namen werden die Teams genannt, z.B. Standorte; Methoden mit beschreibendem Verb im ersten Teil des Namens; Ersatz HW abh¨ angiger Datentypen durch eigene Definitionen; Makros f¨ ur Speichervergabe; Vorschriften f¨ ur Assertions, Exceptions und Traces; eigenen Company Namen in alle Klassennamen einbauen; Kopierkonstruktor durch eigene private Deklaration blockieren, ohne Implementierung. Damit kommt es zum Compilerfehler, sollte man den Kopierkonstruktor implizit oder gewollt verwenden. Dito f¨ ur Zuweisungsoperator; ggf. nur asynchrone Kommunikation, asymmetrische Kommunikation; keine Speicherdynamik; abstrakte Klassen; keine Vererbung tiefer als 2 Stufen.

Eine weitere sehr n¨ utzliche Festlegung ist die maximal erlaubte Komplexit¨at eines Moduls, die mit Tools gemessen werden kann.

22

5 Design-Rules und Konventionen

5.1 Namenskonventionen Mindestens bei den Namenskonventionen kann man auf Standards zur¨ uckgreifen, z.B. [Mis]. Es gibt auch schon Tools, die die Einhaltung u berpr¨ u fen. ¨ F¨ ur uns ist f¨ ur die Quelltexte wichtig, dass Basisklassen mit CNameDer” Klasse“ beschrieben werden, abstrakte Klassen mit ANameDerKlasse“ und ” Interface-Klassen mit INameDerKlasse“. ”

5.2 Shared-Verzeichnisse, Libraries Immer wenn es mehrere Projekte gibt, kann man gemeinsame Teile definieren oder finden. Wenn alles optimal verl¨ auft, gibt es bereits ein gemeinsames Framework noch bevor die einzelnen Projekte angefangen werden. Diese Sammlung von Klassen, Werkzeugen, gemeinsamen Utilities und von gemeinsam verwendbaren Programmteilen wird oft in einem Quell-Verzeichnis abgelegt, das man Shared nennt und das von einer separaten Gruppe gepflegt wird. Die Projektgruppen stellen eigenen projektspezifischen Code in diesem Rahmen ein. Ein weiterer zumindest teilweise invarianter Teil der Software sind Treiber und Zusatz-Libraries. Diese werden auf Object-Level den Projekten zur Verf¨ ugung gestellt. Die Organisation dieser Libraries f¨ ur alle wird im Management oft u ¨bersehen, kleine Hardware-Unterschiede in den Projekten verleiten auch dazu, den f¨ unften universellen und generischen CD-Treiber“ zu schrei” ben.

5.3 Eigene Definitionen im Shared Bei C/C++ h¨angt es bei elementaren Datentypen vom Compiler und vom Ziel-Prozessor ab, wie viel Speicher jeweils verwendet wird. So kann ein Integer-Typ 16 oder 32 Bit haben. Soll ein Programm unabh¨angig von Compiler und Hardware sein, muss auf Little- und Big-Endian R¨ ucksicht genommen werden. Mit eigenen elementaren Datentypen kann man sich im eigentlichen Code unabh¨angig von Compilern und Prozessoren machen und somit den Code portierbar halten. Diese Datentypen werden in einem so genannten SharedBereich z.B. als "Global.h" gehalten und gepflegt. 5.3.1 Standard-Typen Zun¨achst werden alle Standardtypen selbst definiert, um von Prozessoren und Compilern unabh¨ angig zu werden.

5.3 Eigene Definitionen im Shared

23

Wenn m¨oglich sollten die Regeln auch nur signed Standardtypen erlauben. Oft wird unsigned vereinbart und dann doch aus Versehen ein (-1) als Returnwert im Fehlerfall u ¨bergeben. Z.B. mit dem sp¨ ater vorgestellten MOST-Protokoll ist unsigned nicht vermeidbar, weil es signed und unsigned Datentypen in der Protokoll-Definition gibt. Anschließend werden ein eigener NULLPTR und ein eigener NULLCHAR festgelegt, deren Verwendung nur zur Klarheit dient.

// synonyme for elementar data types typedef signed char Int8; typedef unsigned char UInt8; typedef signed short Int16; typedef unsigned short UInt16; typedef signed int Int32; typedef unsigned int UInt32; // Definition f¨ ur nullpointer und null character #define NULLPTR 0 #define NULLCHAR 0 Listing 5-1. Standard-Typen und Konstanten, Global.h

5.3.2 Alignment Es wird an vielen Stellen in der Implementierung Alignment-Aufgaben geben. Bei einem 32-Bit Prozessor z.B. m¨ ussen Variablen auf Doppelwortgrenze ausgerichtet sein, damit er mit einem 32-Bit Zugriff auf einen kompletten Integer-Wert zugreifen kann. Ist die Variable nicht ausgerichtet, so gibt es entweder einen Memory-Fault oder der Prozessor muss den Zugriff in mehrere Einzelzugriffe zerlegen und den Wert zusammensetzen. Bei einem 16-Bit Prozessor erfolgt die Ausrichtung normalerweise auf Wortgrenze. Andererseits gibt es 32-Bit Prozessoren, die sogar Byte-weise den Speicher adressieren k¨ onnen. Um von diesen Fragen unabh¨angig zu werden, definieren wir ein eigenes Makro, das die Gr¨oße eines Speicherblocks auf 32-Bit Doppelwortgrenzen ausrichtet.

// Macro used to round up the memory required due to the alignment #define MAKE_ALIGNMENT_SIZE(size) ((( (size) + (sizeof(Int32) - 1) )\ / sizeof(Int32))*sizeof(Int32)) Listing 5-2. Alignment-Makro

24

5 Design-Rules und Konventionen

5.3.3 Little-Endian, Big-Endian Bei der Interpretation einer Integer-Zahl ’1234’ ist zu unterscheiden, ob das niederwertige Byte an der h¨ ochsten Adresse ( Big-Endian“, z.B. Apple) oder ” an der niedrigsten Adresse ( Little-Endian“, z.B. PC) gespeichert wird. Die ” gleiche Frage stellt sich wieder bei 32-Bit Integers, deren niederwertiges Wort an der h¨oheren Adresse und das h¨ oherwertige Wort an der niedrigeren Adresse gespeichert werden.

Abbildung 5.1. Big/Little-Endian

Insbesondere dann, wenn Daten u ¨ber externe Schnittstellen gelesen werden, muss das Format klar sein. Auch wenn Software portierbar bleiben soll, muss das Speicherformat bekannt und anpassbar sein. H¨aufige Fehler sind die Byte-Adressierung innerhalb eines Doppelwortes ohne Ber¨ ucksichtigung des Endian-Formates oder die Zeigeradressierung in Strukturen. An jeder Stelle, an der direkt in ein Speicherlayout adressiert werden soll, muss ein Makro verwendet werden, das die Unabh¨angigkeit vom EndianFormat sicherstellt. Mit einer globalen Typdefinition kann dann auf die ZielHardware angepasst werden.

// Macros for convering 2 bytes to a word (16 bits) #ifdef BIG_ENDIAN // Syntax MAKE_UINT16(FirstByte, SecondByte) #define MAKE_INT16(a,b) Int16( (a << 8) | UInt8(b) ) #define MAKE_UINT16(a,b) UInt16( (a << 8) | UInt8(b) ) // Syntax LOW_BYTE(16 Bit-Word), HIGH_BYTE(16 Bit-Word) #define LOW_BYTE(w) UInt8(w >> 8) #define HIGH_BYTE(w) UInt8(w & 0XFF) #else // little endian

5.3 Eigene Definitionen im Shared

25

#define MAKE_INT16(a,b) Int16( (b << 8) | UInt8(a) ) #define MAKE_UINT16(a,b) UInt16( (b << 8) | UInt8(a) ) // Syntax LOW_BYTE(16 Bit-Word), HIGH_BYTE(16 Bit-Word) #define LOW_BYTE(w) UInt8(w&0xFF) #define HIGH_BYTE(w) UInt8(w >> 8) #endif // BIG_ENDIAN Listing 5-3. Makros zur Endian-Format-Anpassung

5.3.4 Zahlengrenzen Oft wird in Programmen die Abpr¨ ufung von Werten gegen die Grenzen der Zahlendarstellung gebraucht. Diese Compiler- und Hardware-abh¨angigen Konstanten werden ebenfalls in einer include-Datei, z.B. in einer eigenen "ownlimit.h" festgelegt, als Erg¨ anzung zu .

#define #define ... #define #define ... #define #define

INT8_MAX INT8_MIN

(Int8) (0x7F) (Int8) (0x80)

UINT8_MAX UINT8_MIN

(UInt8) (0xFF) (UInt8) (0)

UINT32_MAX UINT32_MIN

(UInt32) (0xFFFFFFFF) (UInt32) (0)

Listing 5-4. Max/Min-Typedefs f¨ ur eigene Datentypen

5.3.5 Const Definitionen Es gibt Konstanten, die f¨ ur alle Projekte gleich sind. Daf¨ ur ist die oben gezeigte Definition in einer "globallimit.h", die in ein Shared-Verzeichnis gelegt wird, sinnvoll. Es gibt aber auch Konstanten, die projektabh¨angig definiert werden m¨ ussen. Dennoch sollten die Namen in allen Projekten gleich sein. Die u osung in Projekten ist, von den Spielregeln f¨ ur Shared¨bliche L¨ Dateien abzuweichen und eigene Global-Dateien zu definieren. Damit gibt es dann aber drei St¨ ande zu pflegen: Die Globals im Shared, die dazugeh¨origen ¨ Implementierungen und die Ubertragung in eigene Globals. Sinnvoller ist es, eine weitere globale Definitionsdatei "GlobalExternal.h" einzuf¨ uhren, in der diese projektvarianten Konstanten extern deklariert, aber nicht definiert werden. Durch die Deklaration als extern wird das Projekt gezwungen, diese Konstanten, wenn sie verwendet werden, an geeigneter Stelle zu definieren, Name und Verwendung der Konstanten in der Implementierung sind aber im Sinne von Shared vorgegeben. Bei der Definition muss

26

5 Design-Rules und Konventionen

ebenfalls extern angegeben werden, sonst antworten manche Compiler mit einem schwer verst¨ andlichen Fehler. ... extern const Int32 TICK_DURATION; // constant specifying the tick duration extern const Int32 AUDIODISCPLAYER_COMPONENT_ID; extern const Int32 AUDIODISCPLAYERDEVICE_COMPONENT_ID; extern const Int32 KEYEVENTDISPATCHER_COMPONENT_ID; .....

In der Implementierung im Projekt werden die Werte dann wie ben¨otigt gesetzt. extern extern extern extern ...

const const const const

Int32 Int32 Int32 Int32

TICK_DURATION = 100; AUDIODISCPLAYER_COMPONENT_ID = 1; AUDIODISCPLAYERDEVICE_COMPONENT_ID = 2; KEYEVENTDISPATCHER_COMPONENT_ID = 3;

5.3.6 Eigene Assertions An einer definierten Stelle werden die Assertions f¨ ur das gesamte System umgelenkt und definiert. Die richtigen Aktionen wie Ausgabe u ¨ber einen DebugPort m¨ ussen entsprechend implementiert werden.

#ifndef ASSERTION_H #define ASSERTION_H // eigene Assertionsbehandlung extern void (*handleAssert) (unsigned int, const char*, const char*); #ifndef NDEBUG #define ASSERTION(cond) do { if (!cond) handleAssert(__LINE__, \ __FILE__, #cond); \ } while (0) #else #define ASSERTION(cond) ((void) 0) #endif #endif // end of ASSERTION_H Listing 5-5. Eigene Assertions

Mit der handleAssert-Funktion kann der Fehler z.B. in einen Fehlerspeicher abgelegt werden und ggf. ein Neustart initiiert werden. Mit dem #ifndefKonstrukt kann abgepr¨ uft werden, ob die Includes und Defines schon in einem anderen, bereits compilierten Modul inkludiert wurden [Thoe]. Damit

5.3 Eigene Definitionen im Shared

27

k¨onnen Doppeldefinitionen und Fehlermeldungen vermieden werden. Diese Vorgehensweise wird grunds¨ atzlich in allen *.h Headerdateien verwendet. Der ¨ Ubersichtlichkeit wegen werden wir diese Zeilen aber in den folgenden Listings einsparen. 5.3.7 Exceptions und Signale Exceptions und Signale werden in Embedded Frameworks verboten. Gr¨ unde sind Performanz und Speichereffizienz [Mey1]. 5.3.8 Eigene Ausgaben Mit Ausgaben sind im Moment eigene Textausgaben gemeint, die normalerweise zum sehr klassischen printf-Debugging“ eingesetzt werden und die ” Ausgaben auf eine Standard-Konsole geben. Diese Konsole kann das Display des Systems nutzen, meistens jedoch eine Schnittstelle des Systems zur Entwicklungsumgebung, wie z.B. Ethernet oder eine serielle Schnittstelle. Bessere Debugging-Konzepte werden in einem sp¨ateren Kapitel vorgestellt. Es kann beobachtet werden, dass bei großen Buffern (ab ca. 2000 Eintr¨ agen) Threads (Round-Robin ist eingestellt) und Prozesse ihre Ausgaben mischen, im Falle von QNX sogar Ausgaben verlieren oder verdoppeln. Die Testprogramme daf¨ ur sind unter unserem Link zu finden. Abhilfe m¨ ussen hier eigene Standard-Ausgaben schaffen, die z.B. je konkurrierender Einheit einen eigenen Kanal bekommen. Dieser wird am Ende der gew¨ unschten Ausgabe per flush im Format Thread-ID Meldungen“ aus” gegeben. Wir haben dieses Vorgehen dadurch angedeutet, dass an allen Ausgabestellen in Listings das u ¨bliche printf und cout symbolisch durch eigene Ausgaben sOwnCout zentral ersetzt werden. Auch die Standard-Funktion perror sollte ersetzt werden, z.B. durch sOwnPerror.

6 Speicherverwaltung

In Embedded Systemen ist der Speicher aus Kostengr¨ unden prinzipiell knapp. In kleinen oder in skalierbaren Systemen kann nicht von so genannten secon” dary“ Speichern (HDD, Flash-B¨ anke...) ausgegangen werden. Durch strikte Qualit¨ats- und Real-Time-Anforderungen k¨ onnen dynamische Speicherverwaltungen nicht unbesehen verwendet werden, wegen langer Betriebszeiten ohne Neustart muss das Entstehen von Memory Leaks prinzipiell vermieden werden. Bevor solche Themen vertieft werden k¨ onnen, sollte zun¨achst in Erinnerung gerufen werden, welche Sprachkonstrukte welchen Speicher beanspruchen. Daf¨ ur ist im Bild unten ein Speichermodell abgebildet. Es gibt dort vier Speichersegmente: Es sind dies das Stack-Segment f¨ ur die tempor¨are Speicherung, hier werden die lokalen Daten abgelegt und die Parameter und R¨ ucksprungadressen von Funktionen. Der Stack ist nach dem LIFO (last in first out) Prinzip organisiert. Er ist nur durch die Operation push und pop implizit zugreifbar, also nicht frei adressierbar. Weiterhin das Heap-Segment, der freie Arbeitsspeicher, in dem Speicher allokiert werden kann. Im Data-Segment werden Daten gehalten, die solange leben wie das Programm selbst. Das umfasst auch alle globalen und statischen Variablen. Das Datensegment wird in einen Bereich f¨ ur initialisierte Daten, einen f¨ ur nicht initialisierte Daten und einen const-Datenbereich unterteilt. Das Code-Segment oder auch Text-Segment speichert die auszuf¨ uhrenden Programmzeilen, den Start-Up Code, der vor der eigentlichen main aufgerufen wird, und den Terminate-Code, der nach Beendigung der main aufgerufen wird. Das Code-Segment ist im Programm-Verlauf nur lesbar (Read-Only). Im Prozessor befinden sich unter anderem zwei Register, ein Stack-Pointer Register und ein Instruction-Pointer Register. Wird ein Programm nach der Compilierung und Bindung in den Prozessorspeicher geladen, so werden die Maschinenbefehle vom Lader in das Code-Segment abgelegt. Der Instruktionszeiger zeigt dann auf den ersten auszuf¨ uhrenden Befehl im Code-Segment.

30

6 Speicherverwaltung

Abbildung 6.1. Speichermap, siehe auch [Mad]

Wird in einem Programm ein Unterprogramm (Funktionsaufruf) per Call aufgerufen, so wird der lineare Programmablauf verlassen und an eine andere Stelle im Code-Segment gesprungen. Daf¨ ur wird der letzte InstruktionsZeigerwert auf dem Stack gespeichert und dann die Einsprungadresse in den Instruktions-Zeiger geladen. Beim Verlassen des Unterprogramms wird die alte Instruktionsadresse zur¨ uckgeholt und das Programm bei der n¨ achsten Adresse fortgesetzt. ¨ Uber den Stack werden auch Parameter (Auto-Variable) f¨ ur das gerufene Unterprogramm u ¨bergeben und im Unterprogramm vom Stack gelesen. Umgekehrt werden Return-Werte u uckgegeben. Dies al¨ber den Stack zur¨ lerdings nur, wenn die Prozessor-Register nicht ausreichen. Die Variablen¨ ubergabe funktioniert in C/C++ per Default als Call-byvalue, also als Wert¨ ubergabe. Dies geschieht durch Kopieren des Werts auf den Stack oder durch Aufruf des Kopierkonstruktors f¨ ur Objekte oder Klassentypen, der dann das Objekt auf den Stack kopiert. Vermeiden l¨asst sich dieser Aufwand durch Referenz¨ ubergabe oder Zeiger¨ ubergabe.

6.2 Dynamische Speicherverwaltung

31

6.1 Statische Speicherverwaltung Im n¨achsten Kapitel werden Begriffe wie Prozess und Thread genauer erkl¨art. Vorweggenommen sei hier, dass jeder Prozess einen eigenen Prozessraum besitzt, mit Stack und Heap im privaten Adressraum, also auch mit eigenem Instruktionszeiger und Stack-Zeiger. Statische Speicherverwaltung wird die Speicherverwaltung genannt, die bereits zur Compile-/Link/Load-Zeit Daten und Datenaufbewahrungsorte definiert. Sie arbeitet also mit dem Datensegment. Zur Kompilierzeit wird definiert, dass es sich um Variablen im Daten-Segment handelt, der Linker legt relokatierbare Adressen fest und der Loader schließlich bildet das Speicherlayout auf endg¨ ultige Adressen ab. Wie erw¨ahnt, werden all die Variablen im Datensegment angelegt, die global außerhalb jeder Funktion definiert werden oder die lokal als static deklariert sind. Sie werden im Start-Up Code noch vor der main angelegt. Tats¨achlich beginnt die Programmausf¨ uhrung im Code-Segment mit dem Start-Up Code, ruft die main als Funktion auf und endet nach der main-Funktion mit einigen Destruktoren und dem R¨ ucksprung zum Betriebssystem. Die Reihenfolge der Datendefinitionen verl¨auft wie folgt: • Konstante Daten mit Initialisierung (const data)1 ; • Daten mit Initialisierung (init data); • Daten mit Default Initialisierung (uninit data = 0); • Klassenobjekte u ¨ber Konstruktor. Anschließend wird main aufgerufen. Die Reihenfolge der Erzeugung der init und uninit Data ist Compilerabh¨angig und nicht festgelegt. Die Reihenfolge der Klassenobjekte folgt innerhalb eines Files der Reihenfolge im Source-Code. Die Reihenfolge ist nicht festgelegt, falls zwei Klassenobjekte in verschiedenen Files definiert werden. Sollte sie wichtig sein, m¨ ussen beide Definitionen in einer Datei erfolgen.

6.2 Dynamische Speicherverwaltung Die dynamische Speicherallokation wird gebraucht, wenn erst zur Laufzeit des Programms feststeht, welche und wie viele Daten ben¨otigt werden. Auch Variablen und Objekte, die nur f¨ ur die Laufzeit einer Funktion ben¨otigt werden, sind im strengen Sinn dynamisch verwendete Variablen. Dies betrifft die 1

Viele Konstanten ben¨ otigen keinen Speicherplatz, sondern werden nur textuell ersetzt. Beispielsweise werden deshalb konstante Texte im Code-Segment angelegt. Dies allerdings nur, wenn der Compiler erkennen kann, dass keine Referenzen und keine Zeiger auf die Konstante mehr verwendet werden. Dies ist bei gr¨ oßeren include-Systemen“ nicht mehr m¨ oglich. ”

32

6 Speicherverwaltung

lokalen Variablen und die Variablen, die f¨ ur die Parameter¨ ubergabe angelegt werden. Da sie alle auf dem Stack angelegt und immer in umgekehrter Reihenfolge wieder vom Stack entfernt werden, ist die Verwaltung dieser Variablen einfach und ohne Probleme, solange die Stack-Gr¨oße nicht u ¨berschritten wird. Unter dynamischer Speicherverwaltung im eigentlichen Sinn versteht man die Allokation von Objekten auf dem Heap. ¨ Ubliche Anwendungsbeispiele sind offene Listen, deren Elementanzahl erst durch den Kunden w¨ ahrend der Nutzung festgelegt wird. Im unten stehenden Beispiel werden Variablen auf dem Heap allokiert, und zwar zur Laufzeit. Das gesamte Heap-Segment wird ebenfalls zur Ladezeit des Programms angelegt, normalerweise zun¨ achst mit fester Gr¨oße. Wie man im Bild unten erkennen kann, ist zwischen Stack und Heap Reservespeicher vorgehalten, so dass Stack, Heap oder beide bei Bedarf zur Laufzeit wachsen k¨ onnen. Es gibt auch Systeme, bei denen Stack und Heap auf benachbarten Adressen starten und voneinander weg wachsen.

Abbildung 6.2. Heap- und Stack im Adressraum

Die Konstrukte zur dynamischen Allokation sind malloc und free in C oder new und delete in C++.

6.4 Speicherbedarf und kleine Pittfalls

33

Der im Hintergrund arbeitende Heap Manager verwaltet den Speicher normalerweise in zwei Listen, einer Liste der freien Bl¨ocke und einer Liste der genutzten Bl¨ocke. Die Laufzeit-Routinen zur dynamischen Allokation von Speicher sind normalerweise auf verschieden definierte Blockgr¨oßen ausgelegt und ber¨ ucksichtigen auch die Ausrichtung (Alignment) des Speichers.

6.3 Start-Up-Strategien 6.4 Speicherbedarf und kleine Pittfalls Ist man sich nicht u ¨ber die Umsetzung der Speicherkonstrukte durch Compiler und ggf. Betriebssystem bewusst, k¨ onnen einige Fehler oder Ineffizienzen passieren. Deshalb frischen wir zun¨ achst unsere Kenntnisse bez¨ uglich der Speicherheimat“ verschiedener Objekte auf. Anschließend betrachten wir den ” Speicherbedarf verschiedener Objekte. Schließlich gibt es einige konkrete Hinweise zu m¨oglicher schlechter Implementierung. Einigen Lesern werden die Abschnitte banal vorkommen, sie m¨ogen die folgenden Unterkapitel gerne u attern. ¨berbl¨ Da solche Speicherfragen jedoch nicht u ¨berall zur Standard-Ausbildung geh¨oren, ist das Wissen u ¨ber den Speicherbedarf konkreter Implementierungen bei vielen auch erfahrenen Ingenieuren zuf¨ allig oder schwach ausgepr¨agt. 6.4.1 Welche Variable wo? Globale Variablen sind im ganzen Programm bekannt und behalten ihren Wert w¨ahrend der gesamten Laufzeit. Sie werden außerhalb jeder Funktion deklariert. Ihr Speicherort ist das Datensegement. Lokale Variable werden innerhalb von Funktionen deklariert. Gelegentlich werden sie auch automatische Variable genannt. Sie sind außerhalb ihres Blocks {} unbekannt. Gespeichert werden sie auf dem Stack. Elementare Daten im Datensegment werden u ¨blicherweise w¨ahrend des Programmstarts noch vor der main-Funktion initialisiert, elementare Daten auf dem Stack nicht. Lokale Daten werden auf dem Stack angelegt und leben“ solange, bis die ” lokale Umgebung (scope), z.B. die Funktion, verlassen wird. Soll die Variable auch im n¨ achsten Funktionsaufruf noch den alten Wert garantieren, so muss sie static deklariert werden. Damit wird sie im Datensegment angelegt. Das Datensegment wird u ¨blicherweise beim Hochstart des Systems einmal mit Nullen u ¨berl¨oscht. Es wird auch BSS-Section genannt. Unter dem angegebenen Link finden sich diverse Programme, mit dem man die Adressen und Segment-Bereiche vereinbarter Variablen u ufen ¨berpr¨

34

6 Speicherverwaltung

kann. In Linux kann man sich die Adressen des Text- und des Datensegments ausgeben lassen. Unter Windows geht das zun¨ achst nicht, man kann allerdings u ber eigene Variablen, deren Platz man kennt, R¨ uckschl¨ usse ziehen. ¨ Folgende Variablen werden untersucht, die Ergebnisse sind jeweils im Kommentar dargestellt. Im Kommentar wird der Begriff Plain-Old-Data verwendet. Plain-Old-Data sind elementare Datentypen, Zeiger, Arrays, Strukturen, Unions und alle Typen, die keinen Konstruktor ben¨otigen. •

• • • • • • • •

const //Code- oder Datensegment, davon abh¨ angig, ob POD, //Plain-old-Data (-> Code-Segment), und ob Referenzen //(-> Data-Segment) verwendet werden const Text //Code-Segment statische Variablen,Standardtyp //Datensegment,init oder uinit Bereich statische eigene Datentypen //Datensegment,init oder uinit Bereich Klassenvariable //Datensegment, init oder uinit Bereich globale Variablen //Datensegment, init oder uinit Bereich lokale Variablen //Stack lokal statische Variablen //Datensegment, init oder uinit Bereich dynamische Variablen //Heap

F¨ ur alle globale Variablen im Datensegment gilt: • Sie werden mit Null gef¨ ullt; • Objekte, die mit definierten Werten belegt werden sollen bzw. u ¨ber den Konstruktor erzeugt werden, werden durch den Start-Up-Code initialisiert; • Lokal statische Variablen werden nur beim ersten Durchlauf initialisiert. Zusammenfassung: Folgende Daten/Objekte werden im Datensegment abgespeichert: •

Globale Variablen (von allen Namensbereichen). Es sind Variablen, die außerhalb einer Funktion ohne das Schl¨ usselwort static definiert sind. Sie k¨onnen ohne weiteres von anderen Einheiten zugegriffen werden. • Modulglobale Variablen. Dies sind Variablen, die außerhalb von Funktionen definiert sind. Sie haben durch die Angabe des Schl¨ usselworts static ¨ eine Sichtbarkeit in der Ubersetzungseinheit, in der sie definiert sind.

6.4 Speicherbedarf und kleine Pittfalls

35

• Klassenvariablen. Dies sind statische Klassenelemente, deren Sichtbarkeit durch Zugriffsmodifikatoren geregelt wird. • Lokale statische Variablen. Dies sind statische Variablen in Funktionen. Globale Objekte werden in C++ h¨ aufig durch das Einzelexemplarmuster (Singleton-Pattern) realisiert. Die L¨ osung in der Literatur sieht vereinfacht etwa so aus: Im Headerfile:

class A { public: static A& getInstance() { return sInstance; } private: // Konstruktor privat. Evtl. mit Parameter A(); ~A(); static A sInstance; }; // Im cpp-File: ... A A::sInstance; // wg. static, evtl mit Parameter ... Listing 6-1. Globales Objekt gem¨ aß Singleton-Pattern

Das Klassenelement sInstance wird beim Starten des Programms angelegt und am Ende zerst¨ ort. Mit ¨alteren Compilern kann man eventuell einen Kompilierfehler erhalten, weil der Destruktor privat (z.B. Visual C++ 6.0) ist [Vlis]. Man erh¨alt auch wegen des privaten Konstruktors eine Warnung. Dies kann man u ¨ber eine Dummy friend Klasse beheben. Die Vorteile sind Einfachheit und deterministische Zugriffszeit. Von Nachteil kann die Verl¨ angerung der Startzeit sein, wenn zur Erzeugung bzw. Initialisierung des Objekts im Konstruktor komplexe Aktivit¨aten ausgef¨ uhrt werden m¨ ussen. In der Praxis k¨ onnen so einige Sekunden f¨ ur den Start-up-Code zusammenkommen. Zur Vermeidung der genannten Nachteile gibt es verschiedene Strategien:

36

6 Speicherverwaltung

6.4.2 Alternative Strategie 1: Sp¨ ate Konstruktion Erst wenn das Objekt ben¨ otigt wird (beim ersten Zugriff), wird es angelegt:

class A { public: static A& getInstance(); private: // Konstruktor privat, evtl. mit Parameter A(); ~A(); static A *sInstancePtr; }; //Im cpp-File: ... A A::*sInstancePtr; A& A::getInstance() { if (0 == sInstancePtr) { sInstancePtr = new A(); } return *sInstancePtr; }

// wg. static

Listing 6-2. Sp¨ ate Konstruktion des globalen Singleton-Objekts

Mit dieser L¨osung hat man allerdings andere Nachteile: • Der Destruktor kann nicht aufgerufen werden, um Aufr¨aumarbeiten zu erledigen. ¨ • Ein Uberpr¨ ufungsprogramm wie Purify wird aufgrund eines fehlenden delete-Aufrufs eine Warnung ausgeben. • Wenn man den Destruktor ¨ offentlich macht und ein globales Objekt verwendet, um verschiedene globale Objekte anzulegen und zu zerst¨oren, siehe unten, so kann der Benutzer ihn auch falsch verwenden. A& a = A::getInstance(); delete &a;

•

// globales Objekt wird zerst¨ ort!

Das Objekt liegt im Heap und soll bis zum Ende des Programms existieren. Die Gefahr der Speicherfragmentierung wird dadurch h¨oher. • Die Zeit des ersten Zugriffs nicht deterministisch.

6.4 Speicherbedarf und kleine Pittfalls

37

• Schließlich kann es einen Wettlauf zwischen Objekten oder Komponenten geben, Objekte werden aus Versehen angesprochen, die noch nicht existieren. Problematisch ist es auch, wenn das Objekt in einer Multithread-Umgebung eingesetzt wird. Es kann unter Umst¨anden mehr als ein Objekt angelegt werden, wenn mehrere Threads gleichzeitig die Abfrage der getInstance-Methode durchf¨ uhren. Um das letztgenannte Problem zu vermeiden, muss man ggf. einen Mutex einf¨ uhren. Der kritische Abschnitt wird dann durch den Mutex gesch¨ utzt2 .

class A { public: static A& getInstance(); private: A(); ~A(); static A *sInstancePtr; static CMutex sMutex; };

// Konstruktor private. Evtl mit Parameter

Im cpp-File: ... A A::*sInstancePtr; CMutex A::sMutex; A& A::getInstance() { sMutex.take(); if (0 == sInstancePtr) { sInstancePtr = new A(); } sMutex.give(); return *sInstancePtr; } Listing 6-3. Sp¨ ate Konstruktion des globalen Singleton-Objekts mit Mutex-Schutz 2

Wir arbeiten hier schon unvermeidbar mit Begriffen, die erst sp¨ ater im richtigen Zusammenhang erl¨ autert werden k¨ onnen. Hier soll die Erkl¨ arung gen¨ ugen, dass in einer Mutithread-Umgebung mehrere Aufgaben quasi gleichzeitig bearbeitet werden k¨ onnen, was auch zu Konflikten und Kollisionen f¨ uhren kann. Deshalb synchronisiert man kritische Bereiche mit Semaphoren oder Mutexen, die nur jeweils eine Aufgabe zulassen. Mit take erfolgt die Sperrung f¨ ur andere, mit give die Freigabe f¨ ur alle.

38

6 Speicherverwaltung

Um den Mutex nicht jedes Mal zuzugreifen und um die Anzahl der verwendeten Mutexen zu reduzieren (nur einen f¨ ur mehrere Klassen, weil der Mutex nur bei der Erzeugung des Objekts ben¨ otigt wird), wird das Doppel-CheckingMuster verwendet:

A& A::getInstance() { if (0 == sInstancePtr) { sMutex.take(); if (0 == sInstancePtr) sInstancePtr = new A(); sMutex.give(); } return *sInstancePtr; }

// erst auf NULL checken // dann nehmen // zweite ¨ Uberpr¨ ufung, immer noch NULL?

Listing 6-4. Singleton mit Doppel-Checking

Das Problem der Allokation auf dem Heap kann man durch Placement-new l¨osen (siehe Abschnitt u ¨ber die quasi statische Allokation) und das oder die Objekte in einen vorreservierten Speicher platzieren. 6.4.3 Alternative Strategie 2: Sp¨ ate Initialisierung Werden in Projekten alle Objekte erst beim Start oder zur Laufzeit angelegt, so kommt es leicht zu inakzeptablen Startzeiten. Deshalb w¨ahlt man oft die Strategie der sp¨aten Initialisierung. Man nennt dies auch lazy Initialisation“ ” oder auch Load/Init on Demand“. ” Der Speicher f¨ ur das Klassenobjekt ist im Datensegment, und das Objekt wird nur beim ersten Zugriff initialisiert. Die L¨osung (f¨ ur MultithreadUmgebung) sieht etwa wie folgt aus:

class A { public: static A& getInstance(); private: //einfacher Konstruktor private. Evtl. mit Parameter A(); ~A(); void init(); static A sInstance; static bool sInitialized;

6.4 Speicherbedarf und kleine Pittfalls static CMutex sMutex; }; /Im cpp-File: ... A A::sInstance; bool A::sInitialized; CMutex A::sMutex; A& A::getInstance() { if (false == sInitialized) { sMutex.take(); if (false == sInitialized) { sInitialized = true; sInstance.init(); } sMutex.give(); } return sInstance; }

39

// standard mit 0 gef¨ ullt. d.h. false

// doppel-checking

Listing 6-5. Sp¨ ate Initialisierung eines Singletons

Mit dieser L¨osung hat man noch den Nachteil, dass der erste Zugriff nicht deterministisch ist. Die Start-Up-Zeit und der Heap werden dadurch aber nicht mehr belastet. 6.4.4 Alternative Strategie 3: Lokale statische Variablen Wenn das Objekt nicht in Multithread-Umgebung eingesetzt wird, kann man es als lokales statisches Objekt definieren. Die L¨osung ist dann

class A { public: static A& getInstance(); private: // einfacher Konstruktor private. Evtl mit Parameter A(); ~A(); }; //Im cpp-File: ... A& A::getInstance() { static A sInstance;

40

6 Speicherverwaltung return sInstance;

} Listing 6-6. Lokale statische Variablen

Der Compiler generiert daraus einen Code, der etwa wie die zweite L¨osung aussieht (mit einer Hilfsvariablen zum Merken, ob das Objekt schon angelegt wurde). Diese L¨ osung hat alle Vorteile der zweiten, kann allerdings ¨ in Multithread-Umgebungen durch Zugriff-Uberschneidungen zum Problem f¨ uhren. Man kann auch eine L¨ osung f¨ ur Multithread-Umgebung mit lokal statischen Variablen bauen. Sie ist allerdings teurer als die zweite Variante. 6.4.5 Speicherort von Konstanten Zu beachten ist, dass globale Konstanten sowohl im Code- als auch in Datensegment platziert werden. Konstanten von primitiven Datentypen (bzw. von Strukturen mit primitiven Datentypen) werden im Code-Segment angelegt, so dass ein Const-Cast unter Umst¨ anden (wenn das Code-Segment gesch¨ utzt wird) unm¨oglich ist. const char* txtptr = "hello\n"; .. const_cast (txtptr)[0] = ’H’;

//Absturzgefahr

Der globale Zeiger textPtr liegt im Datensegment. Er enth¨alt die Adresse der C-Zeichenkette "hello\n". Die Zeichenkette selbst ist im Code-Segment gespeichert und kann nicht modifiziert werden. Dagegen liegen konstante, globale Objekte im Datensegment, so dass Folgendes kein Problem verursacht (die Frage, warum man const verwendet, bleibt außer Betracht). In der Anwendung kann const verwendet werden, um Schattenkonstanten zu realisieren. Dies sind Konstanten, die Kopien von bestimmten Werten sind und von außerhalb gelesen werden k¨onnen. Sie werden nur ge¨andert, wenn sich die Originale ge¨ andert haben.): class A { public: int i; }; ... const A a; ... (const_cast(a)).i = 5;

//¨ Anderung der Daten von a

Ein weiteres Beispiel zeigt, dass eine Struktur mit plain old Data in der Regel im Code-Segment angelegt wird. Hier f¨ uhrt ein Schreibversuch zum Fehler, da das Code-Segement nur gelesen werden kann.

6.4 Speicherbedarf und kleine Pittfalls

41

//Struktur mit plain old type //Initialisierung ben¨ otigt keinen Konstruktor struct B { int a; int b; }; const B obj = {1,2}; int main() { cout << obj.b << endl; //obj liegt im konstanten Segment, so dass folgende Zeilen zu //einer Ausnahme STATUS_ACCESS_VIOLATION f¨ uhrt B& obj2 = const_cast(obj); obj2.a = 3; return 0; } Listing 6-7. Struktur mit plain old Data

Wird f¨ ur die Struktur ein Konstruktor aufgerufen, so legt der Compiler sie ins Datensegment, da der Konstruktoraufruf erst zur Laufzeit in der Startphase erfolgen kann. Der Konstruktor steht hier stellvertretend daf¨ ur, dass es sich nicht um eine einfache Struktur ohne eigene Typen und Methoden handelt.

//Konstruktor wg. Vererbung struct A { int a; A(int i) : a(i) { } }; struct B: public A { int b; B(int i, int j) : A(i), b(j) { } }; const B obj(1,2); int main() { cout << obj.b << endl; //obj liegt nicht im konst. Segment, so dass folg.Zeilen //funktionieren

42

6 Speicherverwaltung B& obj2 = const_cast(obj); obj2.a = 3; return 0;

}

Listing 6-8. Struktur mit Konstruktor-Aufruf

Mit der folgenden Version gelingt es, das Objekt obj2 im Code-Segment anzulegen, obwohl es nicht ausschließlich plain old Data besitzt. Dies wird dadurch erreicht, dass zun¨ achst eine einfache Struktur C im Code-Segment angelegt wird und diese zur Laufzeit gecastet wird.

struct A { int a; A(int i) : a(i) { } }; struct B: public A { int b; B(int i, int j) : A(i), b(j) { } }; struct C { int a; int b; }; const C c = {1 , 2}; const B& obj = reinterpret_cast (c); int main() { cout << obj.b << endl; //obj liegt im konstanten Segment, so dass folgende Zeilen zu //einer Ausnahme STATUS_ACCESS_VIOLATION f¨ uhren B& obj2 = const_cast(obj); obj2.a = 3; return 0; } Listing 6-9. Struktur mit Konstruktor im Code-Segment

Dies scheint nur ein kleiner, nicht sehr seri¨ oser Trick zu sein. Hiermit ist es allerdings m¨oglich, in der Startphase viel Zeit zu sparen. Weder m¨ ussen

6.4 Speicherbedarf und kleine Pittfalls

43

komplexe Konstruktoren in der Init-Phase aufgerufen werden, noch m¨ ussen Objekte dynamisch auf dem Heap angelegt werden. Wir kommen auf dieses Konzept im Teil II in Kapitel MOST-Codec zur¨ uck. Es gibt Anforderungen, nach denen man einen Datensegment-Bereich braucht, der beim Start-Up des Systems nicht u ¨berl¨oscht wird, z.B. wird dieser Speicherbereich auch u ¨ber das Ausschalten des Systems hinweg erhalten. Dort k¨onnen letzte Einstellungen des Ger¨ ats wie Lautst¨arke oder Navigationsposition erhalten werden. Dieser Persistenz-Bereich kann aus einem Flash kopiert werden oder er ist batteriegepuffert oder unterliegt einem Self-Refresh. Es gibt Anwendungen, in denen dieser Bereich No-BSS genannt wird. Wir werden in dem sp¨ ateren Kapitel Persistenz-Komponente darauf zur¨ uckkommen. 6.4.6 Speicherbedarf eines einfachen Objekts Betrachten wir eine Test-Klasse, die nichts erbt und keine virtuelle Methode hat.

class A { public: A(int i): mDummy(0), mValue(i) { } void f() //gibt die Adressen des Objekts und der Attribute aus. { sOwnCout << "Adresse des Objekts = " << this << endl << "Adresse des ersten Attributs "<<&(this->mDummy)<< endl << "Adresse des zweiten Attributs "<<&(this->mValue)<<endl; } private: int mDummy; int mValue; }; int main() //nun testen { A* aPtr = new A(5); sOwnCout << "Gr¨ oße des Objekts " << sizeof(A) << endl; aPtr->f(); delete aPtr; return 0; } // Die Ausgabe ist // Gr¨ oße des Objekts 8 // Adresse des Objekts 0x2f1e20 // Adresse des ersten Attributs 0x2f1e20 // Adresse des zweiten Attributs 0x2f1e24 Listing 6-10. Instanz einer einfachen Klasse A

44

6 Speicherverwaltung

Jedes Objekt der Klasse A braucht 8 Bytes (wie eine einfache C-Struktur) f¨ ur mDummy und mValue. Die Objektmethoden ben¨otigen keinen zus¨atzlichen Platz, da im Objekt keine Referenzen abgelegt werden m¨ ussen. Der Aufruf aPtr->f() wird intern durch den Compiler zu einem C-Aufruf umgewandelt (der Name der C-Methode ist nicht f, sondern etwas anderes Stichworte Name-Mangling und Methoden-Signatur). Werden Objekt-Methoden aufgerufen, setzt der Compiler direkt die richtigen Adressen ein. Diese C-Methode hat einen Zeiger auf ein Objekt vom Typ A als erstem Parameter. Etwa _A_f_v(A* THIS)).

Die Variablen mDummy und mValue werden mit den bekannten Offsets u ¨ber den u ¨bergebenen Zeiger angesprochen. Zugriffe auf die Variable mDummy sind sehr effizient, weil sie dieselbe Adresse hat wie der Zeiger auf das Objekt (Offset = 0). Eine h¨aufig zugegriffene Variable sollte demnach die Erste in der Definition sein. Der Code wird dadurch kleiner (keine Arithmetik f¨ ur den Zugriff auf die erste Variable notwendig) und auch schneller, wenn auf die Variable h¨aufig zugegriffen wird. 6.4.7 Speicherbedarf eines einfachen Objekts mit virtueller Methode Nun folgt ein Beispiel f¨ ur Objekte einer Klasse, die nichts erbt und eine virtuelle Methode hat.

class AVirt { public: AVirt(int i) : mDummy(0), mValue(i) { } virtual ~AVirt(){ } void f() //gibt Adressen des Objekts und der Attribute aus { sOwnCout << "Adresse des Objekts = " << this << endl << "Adresse des ersten Attributs " << &(this->mDummy) << endl << "Adresse des zweiten Attributs " << &(this->mValue) << endl; } private: int mDummy; int mValue; };

6.4 Speicherbedarf und kleine Pittfalls

45

int main() { AVirt* aPtr = new AVirt(5); sOwnCout << "Gr¨ oße des Objekts " << sizeof(AVirt) << endl; aPtr->f(); delete aPtr; return 0; } //Die Ausgabe lautet: //Gr¨ oße des Objekts 12 //Adresse des Objekts 0x2f1e20 //Adresse des ersten Attributs 0x2f1e24 //Adresse des zweiten Attributs 0x2f1e28

Listing 6-11. Speicherbedarf eines Objekts einer einfachen Klasse mit virtueller Methode

Das Objekt belegt also erwartungsgem¨ aß 12 Bytes. F¨ ugen wir in die obige Klasse wie in diesem Beispiel nur einen virtuellen Destruktor oder eine beliebige virtuelle Methode hinzu, dann braucht ein Objekt 4 Bytes mehr. Die ersten vier Bytes sind f¨ ur den Zeiger auf die virtuelle Funktionstabelle (V-Table) erforderlich. Die Attribute haben wie vorher einen Offset, allerdings ist der kleinste Offset 4.

Abbildung 6.3. Speicher-Layout eines Objekts mit virtueller Methode

Wenn von der Klasse keine Vererbung zu erwarten ist, sollte man den Destruktor bzw. die Methoden nicht virtuell deklarieren. Ist umgekehrt mit Vererbung zu rechnen, so muss der Destruktor immer virtuell definiert werden.

46

6 Speicherverwaltung

Eine ausf¨ uhrliche Erkl¨ arung daf¨ ur ist z.B. in [Mey] zu finden. Das Problem ist, dass der Versuch, ein abgeleitetes Objekt durch Aufruf des nicht virtuellen Basisklassendestruktors zu l¨ oschen, zu einem m¨oglichen Speicherleck f¨ uhrt. Wollen wir Vererbung ausdr¨ ucklich verbieten, so m¨ ussen wir die leeren oder implementierten Konstruktoren als privat deklarieren. 6.4.8 Speicherbedarf eines Objekts einer abgeleiteten einfachen Klasse Nun nehmen wir die erste Beispielklasse A und leiten davon eine Klasse B ab.

class B: public A { public: B(): A(0), mBValue(0) { } void f() {//ruft die Methode der Basisklasse A::f(); sOwnCout<<"Adresse des dritten Attributs"<<&(this->mBValue)<<endl; } private: int mBValue; }; int main() { B* bPtr = new B(); A* aPtr = bPtr; //beide Adressen sind gleich! Impliziter CAST sOwnCout << "Adresse von aPtr " << aPtr << endl; sOwnCout << "Adresse von bPtr " << bPtr << endl; sOwnCout << "Gr¨ oße des Objekts " << sizeof(B) << endl; sOwnCout << "Ausgabe ¨ uber A Zeiger " << endl; aPtr->f(); sOwnCout << "Ausgabe ¨ uber B Zeiger " << endl; bPtr->f(); delete bPtr; return 0; } //Die Ausgabe lautet: //Adresse von aPtr 0x2f1e20 //Adresse von bPtr 0x2f1e20 //Gr¨ oße des Objekts 12 //Ausgabe ¨ uber A-Zeiger //Adresse des Objekts 0x2f1e20 //Adresse des ersten Attributs 0x2f1e20 //Adresse des zweiten Attributs 0x2f1e24 //Ausgabe ¨ uber einen B-Zeiger

6.4 Speicherbedarf und kleine Pittfalls //Adresse //Adresse //Adresse //Adresse

des des des des

47

Objekts 0x2f1e20 ersten Attributs 0x2f1e20 zweiten Attributs 0x2f1e24 dritten Attributs 0x2f1e28

Listing 6-12. Speicherbedarf eines Objekts einer einfachen abgeleiteten Klasse

B erbt von A. Klasse B hat aber keine virtuelle Methode. Deshalb hat ein BObjekt 12 Bytes, 8 Bytes f¨ ur die Attribute der Basisklasse und 4 Bytes f¨ ur das neue Attribut mBValue. Ohne Vererbung oder mit einfacher Vererbung und ohne virtuelle Methode: Alle Objekte belegen nur so viel Speicher wie eine normale C-Struktur. Einfachvererbung oder keine Vererbung spielen dabei keine Rolle. F¨ ur den impliziten Cast in diesem Kontext wird kein Code generiert, der Cast dient nur der Typsicherheit der Sprache. Die Basisklassen haben also keine virtuelle Methode. In diesem Fall ist das Layout des Objekts einfach. Alle Methoden werden statisch gelinkt. Ein Objekt der abgeleiteten Klasse ist eine erweiterte Struktur, d.h. es hat einen Teil wie der Teil der Basisklasse und einen eigenen Teil f¨ ur die neuen Attribute. Alle Attribute werden wie vorher u ¨ber einen Offset angesprochen. Die Offsets sind zur Kompilierzeit bekannt.

Abbildung 6.4. Speicher-Layout eines B-Objekts mit virtueller Methode

Die Zeile A* aPtr = bPtr;

ist ein Up-Cast“, d.h. Casten auf eine Basisklasse. Dabei haben aPtr und ” bPtr dieselbe Adresse. Das bedeutet, dass die Attribute der Objekte der Klasse B einen Offset gr¨ oßer oder gleich sizeof(A) haben. In unserem Beispiel ist sizeof(A) = 8. Dabei muss man beachten, dass, obwohl die beiden Zeiger dieselbe Adresse haben, ein Aufruf der Methode f unterschiedliche Ausgaben bewirkt. Der

48

6 Speicherverwaltung

Compiler bestimmt die passende statische Methode zu dem Typ des Zeigers. F¨ uhrt man Down-Cast“ durch, also einen Cast auf eine abgeleitete Klas” se, so generiert der Compiler daf¨ ur keinen Code. Die Adresse wird einfach genommen. Betrachten wir ein Beispiel:

A* aPtr; B* bPtr = (B*) aPtr; //es wird kein Code generiert! //bPtr hat dieselbe Adresse wie aPtr. //Ein Cast ist notwendig wegen der Typstrenge.

Der Cast (B*) aPtr ist ein C-Cast. Der Compiler verwendet dabei die statische Information u ur diesen Fall kein Code ¨ber die Klassen. Es wird f¨ generiert. Man sollte den C++-Stil static cast bevorzugen. Einfache Vererbungen ohne virtuelle Methoden kann der Compiler effizient behandeln, da er u oglichen Informationen verf¨ ugt. Alle Casts in ¨ber alle m¨ diesem Zusammenhang sind C-Casts. Einfache Vererbungen ohne virtuelle Methode sind effizient implementiert. Da alle Offsets gr¨ oßer als Null sind, sollten bei der Deklaration der Attribute nur m¨ ogliche Padding-Effekte (siehe unten) ber¨ ucksichtigt werden. 6.4.9 Speicherbedarf eines Objekts einer abgeleiteten Klasse mit virtueller Methode Nun verwenden wir wieder die Basisklasse A, lassen aber eine Klasse BVirt davon erben, die selbst eine virtuelle Methoden hat.

class BVirt: public A //B erbt von A. B hat eine virtuelle Methode { public: BVirt(): A(0), mBValue(0) { } //Konstruktor virtual void f() { A::f(); //ruft die Methode der Basisklasse sOwnCout<< "Adresse des dritten Attributs" << &(this->mBValue) << endl; } private: int mBValue; }; int main()

6.4 Speicherbedarf und kleine Pittfalls

49

{ BVirt * bPtr = new BVirt(); A* aPtr = bPtr; //up cast, ungleiche Adressen ! sOwnCout << "Adresse von aPtr " << aPtr << endl; sOwnCout << "Adresse von bPtr " << bPtr << endl; sOwnCout << "Gr¨ oße des Objekts " << sizeof(BVirt) << endl; sOwnCout << "Ausgabe ¨ uber einen A-Zeiger " << endl; aPtr->f(); sOwnCout << "Ausgabe ¨ uber einen B-Zeiger " << endl; bPtr->f(); delete bPtr; return 0; } //Die Ausgabe lautet: //Adresse von aPtr 0x2f1e24 //Adresse von bPtr 0x2f1e20 //Gr¨ oße Objekt 16 //Ausgabe ¨ uber A-Zeiger //Adresse des Objekts 0x2f1e24 //Adresse des ersten Attributs 0x2f1e24 //Adresse des zweiten Attributs 0x2f1e28 //Ausgabe ¨ uber einen B-Zeiger //Adresse des Objekts 0x2f1e20 //Adresse des ersten Attributs 0x2f1e24 //Adresse des zweiten Attributs 0x2f1e28 //Adresse des dritten Attributs 0x2f1e2c Listing 6-13. Beispiel f¨ ur einen impliziten Up-Cast“ ”

Die Ausgaben zeigen, dass die Objektadressen nicht gleich sind. Die Gr¨oße eines B–Objekts betr¨ agt 16 Bytes. Die Ausgaben unterscheiden sich wieder f¨ ur aPtr->f() und bPtr->f(). Die unterschiedlichen Adressen k¨ onnen wir am besten am Speicher-Layout erkl¨aren. Da BVirt eine virtuelle Methode hat, m¨ ussen 4 Bytes f¨ ur die so genannte V-Table vorangestellt werden. Der Zeiger aPtr zeigt daher auf eine 4 Bytes gr¨oßere Adresse als bPtr. Im Fall der einfachen Vererbung mit virtuellen Methoden betr¨agt der Overhead nur vier Bytes f¨ ur den Zeiger auf die Funktionstabelle. Es spielt dabei keine Rolle, woher die virtuelle Methode kommt, ob von der Basisklasse oder von der Klasse selbst. Beachte: Die Wirkung von aPtr->f() w¨ are anders, wenn die f-Methode in der Klasse A virtuell w¨ are. Bei der Vererbung wird virtual“ auch geerbt. Das bedeutet, wenn die f” Methode der Klasse A virtuell ist, dann ist auch die gleichnamige Methode mit derselben Methodensignatur automatisch virtuell. Das Schl¨ usselwort virtual ist daf¨ ur nicht erforderlich.

50

6 Speicherverwaltung

Abbildung 6.5. Impliziter Up-Cast“, Speicher-Layout ”

Zur Optimierung ist zu u ufen, ob virtuelle Methoden (Destruktor oder ¨berpr¨ normale Methoden) wirklich notwendig sind. 6.4.10 Speicherbedarf eines Objekts einer abgeleiteten Klasse mit virtueller Basis-Methode Nun betrachten wir erneut die abstrakte Basisklasse AVirt und lassen BVirt von ihr erben. Es ist nicht erforderlich, in BVirt die Funktion f erneut als virtual zu deklarieren.

class BVirt: public AVirt { public: BVirt(): AVirt (0), mBValue(0) { } void f() { AVirt::f(); //ruft die Methode der Basisklasse sOwnCout <<"Adresse des dritten Attributs " << &(this->mBValue) << endl; } private: int mBValue; }; int main() { BVirt* bPtr = new BVirt(); AVirt * aPtr = bPtr; //beide Adressen sind gleich! sOwnCout << "Adresse von aPtr " << aPtr << endl; sOwnCout << "Adresse von bPtr " << bPtr << endl;

6.4 Speicherbedarf und kleine Pittfalls

51

sOwnCout << "Gr¨ oße Objekt " << sizeof(BVirt) << endl; sOwnCout << "Ausgabe ¨ uber einen A-Zeiger " << endl; aPtr->f(); sOwnCout << "Ausgabe ¨ uber einen BVirt-Zeiger " << endl; bPtr->f(); delete bPtr; return 0; } //Die Ausgabe lautet: //Adresse von aPtr 0x2f1e24 //Adresse von bPtr 0x2f1e24 //Gr¨ oße Objekt 16 //Ausgabe ¨ uber A-Zeiger //Adresse des Objekts 0x2f1e24 //Adresse des ersten Attributs 0x2f1e28 //Adresse des zweiten Attributs 0x2f1e2c //Ausgabe ¨ uber einen BVirt-Zeiger //Adresse des Objekts 0x2f1e24 //Adresse des ersten Attributs 0x2f1e28 //Adresse des zweiten Attributs 0x2f1e2c //Adresse des dritten Attributs 0x2f1e30 Listing 6-14. Abgeleitete Klasse einer abstrakten Klasse

Wir erwarten, dass jedes Objekt der Klasse AVirt wie eine einfache C-Struktur 12 Bytes braucht. BVirt erbt von AVirt eine virtuelle Methode. Ein BVirtObjekt hat demnach 16 Bytes.

Abbildung 6.6. Speicher-Layout zweier virtueller Klassen-Objekte

52

6 Speicherverwaltung

6.4.11 Mehrfachvererbung und Pittfall Zum Abschluss der Betrachtungen deklarieren wir drei Klassen, wobei die Klasse C von den Klassen AVirt und BVirt erbt.

class AVirt { public: int a; public: AVirt () : a(1) virtual void f() {} }; class BVirt { public: int b; public: BVirt () : b(2) virtual void g() {} };

{

}

{

}

class C: public AVirt, public BVirt { public: C() : AVirt (), BVirt () { } }; Listing 6-15. Mehrfachvererbung

In der folgenden main instantiieren wir ein Objekt der Klasse C und geben verschiedene Testausgaben.

int main() { C c; sOwnCout << sizeof(AVirt) << " " << sizeof(BVirt) << " " << sizeof(C) << endl; C* cPtr = &c; sOwnCout << "Adresse des C-Zeigers " << cPtr << endl; AVirt * aPtr = cPtr; sOwnCout << "Adresse des

//upcast auf Basisklasse A A-Zeigers" << aPtr << endl;

BVirt * bPtr = cPtr; //upcast auf Basisklasse B sOwnCout << "Adresse des B-Zeigers " << bPtr << endl;

6.4 Speicherbedarf und kleine Pittfalls aPtr = (AVirt *) bPtr; sOwnCout << "Adresse des

53

//falsch gecastet A-Zeigers " << aPtr << endl;

aPtr = (AVirt *) ((C*) bPtr); //downcast dann upcast sOwnCout << "Adresse des A-Zeigers " << aPtr << endl; void *vPtr = (void *) 123; //123 als Adresse in vPtr cPtr = (C*) vPtr; //auf Klasse C gecastet sOwnCout << "Adresse des C-Zeigers " << cPtr << endl; //jetzt Aufruf von Methoden von C -> crash return 0; } Listing 6-16. Mehrfachvererbung, Up-Cast und Down-Cast, Testausgaben

Die Ausgabe lautet: 8 8 16 Adresse Adresse Adresse Adresse Adresse Adresse

des des des des des des

C-Zeigers A-Zeigers B-Zeigers A-Zeigers A-Zeigers C-Zeigers

0x12ff70 0x12ff70 0x12ff78 0x12ff78 0x12ff70 0x7b

Die Situation bei Mehrfachvererbungen ist gef¨ahrlich, weil die Zeiger nicht gleich sind, weil ein Objekt mehrere Zeiger auf Funktionstabellen hat und weil die Zeiger mitten im Objekt stehen. F¨ ur die Casts muss der Compiler eventuell Code generieren.

Abbildung 6.7. Mehrfach-Vererbung und falscher Cast

54

6 Speicherverwaltung

Durch die Anweisungen

C* cPtr = new C(); AVirt* aPtr = cPtr; BVirt* bPtr = cPtr;

haben cPtr und aPtr denselben Inhalt (weil A die erste Basisklasse ist). Der Zeiger bPtr ist dagegen gleich (aPtr + sizeof(A)). Der folgende Cast kann daher zu einem schwerwiegenden Laufzeitfehler f¨ uhren:

aPtr = (AVirt*) bPtr; .... //tue etwas in aPtr und zerst¨ ort dabei evtl. die //folgenden Daten bzw. den Zeiger auf die V-Table

Aus diesem Grund (Quer-Cast von B nach A) wurde der dynamic cast in Ansi-C++ eingef¨ uhrt. Da ¨altere GNU-Compiler f¨ ur VxWork und QNX einen dynamic cast nicht implementieren, muss man das Casten selbst simulieren (z.B. eine Methode castToPtr implementieren, die u ¨ber das Wissen u ¨ber den Aufbau der Klassen verf¨ ugt und die Casts richtig implementiert). Ferner ist dynamic cast sehr teuer bez¨ uglich Platz und Laufzeit. Er ben¨ otigt die Aktivierung von RTTI (run time type information) und Exceptions. Deshalb wird in vielen Embedded Projekten dynamic cast verboten. Der Compiler behandelt eine Mehrfachvererbung wie eine einfache Vererbung mit der ersten Basisklasse. Daten der anderen Klassen werden dazugepackt. Es ist zu u ur Embedded Systeme nicht einfache Vererbungen ¨berlegen, ob f¨ ausreichen. Mehrfachvererbungen k¨ onnten dann in den Design-Regeln verboten werden. Java hat von C++ gelernt. Mehrfachvererbungen sind verboten. Als Ersatz daf¨ ur stehen die Schnittstellen zur Verf¨ ugung, die anders implementiert werden. In C++ hat man leider keine Schnittstelle und muss sie mithilfe der Mehrfachvererbung simulieren. Eine Schnittstelle (Interface) in Java hat nur Klassenkonstanten und reine virtuelle Methoden ohne Implementierung. Da man h¨aufig Zeiger auf Schnittstellen benutzt und die Schnittstelle u ¨ber Vererbung implementiert wird, wird ein virtueller Destruktor geschrieben. In C++ sieht ein Interface etwa so aus:

6.4 Speicherbedarf und kleine Pittfalls

55

class Interface { public: enum Typ { KONST1, KONST2}; //virtueller Destruktor ist ein MUSS, um Fehler zu vermeiden virtual ~Interface() { } //keine weitere Implementierung notwendig virtual void f() = 0; virtual int g(int a) = 0; ... static const Object& getGlobalObject(); //static-Methoden sind OK static const int SIZE = 100; protected: Interface() { } //keine Implementierung private: static const Object a; }; Listing 6-17. Beispiel-Interface in C++

Was man beachten muss: • Globale Variablen und globale Methoden f¨ uhren zu keinem Konflikt bei der Vererbung. Man kann sie innerhalb der Klasse deklarieren. Man sollte sie dennoch vermeiden, weil sie nicht zu dem Konzept einer Schnittstelle (nur virtuelle Methoden) passen. Allgemeine Hilfsfunktionen wie z.B. static double sin(double) sollten in einer anderen Einheit definiert werden. • Werte f¨ ur Klassenkonstanten werden in der Klassendeklaration angegeben! In der cpp-Datei stehen sie wie normale Variable ohne Initialisierung (in der Regel m¨ ussen alle const-Variablen bei der Definition initialisiert werden), [Lip]. class I { public: static const int i = 5; }; //In I.cpp: ... const int I::i; //keine Initialisierung

6.4.12 Speicherbedarf dynamischer Variablen Nutzt man die Speichervergabe von Compiler und Betriebssystem, kann man oft feststellen, dass z.B. f¨ ur eine 4 Bytes int-Variable am Ende viel mehr Speicher verbraucht wird.

56

6 Speicherverwaltung

Unter QNX gibt es Situationen, in denen 12 Bytes mehr f¨ ur lokale intVariablen verbraucht werden, in VCC werden 56 Bytes f¨ ur eine dynamische int-Variable angelegt. Begr¨ undet ist dies durch Overhead-Informationen und Alignment auf Doppelwort- oder Block-Grenzen. Im Folgenden kann man erkennen, dass dynamische int-Variablen im Speicher im Abstand von 56 Bytes angelegt werden, obwohl die eigentlichen Variablen nur 1 bzw. 4 Bytes ben¨ otigen sollten.

int main () { int Local1; int Local2; char * ptr1 = new char; char * ptr2 = new char; sOwnCout << " Local1 " << sOwnCout << " Local2 " << sOwnCout << " ptr1 " << sOwnCout << " ptr2 " << delete ptr1; delete ptr2; return 0; } //Ausgabe //Local1 1245052 //Local2 1245048 //ptr1 3087672 //ptr2 3087728

(int) (int) (int) (int)

&Local1 &Local2 ptr1 << ptr2 <<

<< endl; << endl; endl; endl;

//4 Bytes Differenz //56 Bytes Differenz

Listing 6-18. Speicherbedarf f¨ ur int- und char-Variablen unter VC++

Im Kapitel 10.2 werden Allokatoren vorgestellt, die f¨ ur Embedded Systeme eine spezialisierte und deshalb bessere L¨ osung anbieten. 6.4.13 Schlechte Parameter¨ ubergabe Ein h¨aufig zitiertes Beispiel f¨ ur schlechtes Programmieren ist, innerhalb einer Schleife Objekte zu instantiieren und an andere Funktionen mittels Callby-value zu u ur die Objekte werden dabei Kopierkonstruktoren ¨bergeben. F¨ aufgerufen. Beim Verlassen der Funktion bzw. des Schleifenk¨orpers werden diese wieder per Destruktor gel¨ oscht. Besser ist es, Objekte u ¨ber Referenzen zu u ¨bergeben.

6.4 Speicherbedarf und kleine Pittfalls

57

6.4.14 Probleme mit dem Kopierkonstruktor Speziell bei Parameter¨ ubergaben per Value in Kombination mit Zeigern gibt es eine schwerwiegende Fehlerquelle. Bei dem Aufruf der Funktion mit dem Zeiger-Parameter wird eine lokale Kopie des Zeigers angelegt. Wird innerhalb der Funktion (oder beim Verlassen der Funktion) das Objekt, auf das der Zeiger zeigt, gel¨ oscht, so ist das Objekt auch f¨ ur das aufrufende Programm zerst¨ort. Dies passiert leicht aus Versehen, wenn ein ganzes Objekt per Value u ¨bergeben wird, in dem sich Zeiger befinden. Das lokale Objekt wird per Kopierkonstruktor angelegt und dabei die Zeiger 1:1 kopiert. Beim Verlassen der Funktion wird das lokale Objekt implizit per Destruktor gel¨ oscht, womit die Objekte, auf die die Zeiger gezeigt hatten, je nach Destruktor-Implementierung eventuell ebenfalls zerst¨ort werden. Dies ist in [Mey] ausf¨ uhrlich beschrieben. Um Missverst¨ andnisse in gr¨ oßeren Teams zu vermeiden, sollte f¨ ur diese F¨ alle der Kopierkonstruktor u ber eine private Definition blockiert werden, so ¨ dass bereits der Compiler einen Fehler meldet. private: CBeispiel( const CBeispiel& rhs ); //block Copy.Konstruktor

6.4.15 Probleme mit dem Zuweisungsoperator Das gleiche Problem wie bei dem Kopierkonstruktor kann beim Aufruf des Zuweisungsoperators auftreten. Durch die 1:1 Kopie werden Zeiger u ¨bernommen und eventuell falsch behandelt. Auch dies ist in [Mey] ausf¨ uhrlich beschrieben. Die beste Abhilfe ist das Blockieren des Zweisungsoperators durch private eigene Deklaration, deren Implementierungsteil leer sein darf. private: CBeispiel& operator=( const CBeispiel& rhs ); //block Zuweisungsop.

6.4.16 Schlechte R¨ uckgaben Ein schwerwiegender Fehler, der von Anf¨ angern h¨aufig gemacht wird, ist die R¨ uckgabe eines lokalen Objekts u ¨ber Zeiger oder Referenz: Object& fraglich() { Object grossesObjekt; ... //do some stuff with object return grossesObjekt; } Listing 6-19. Schlechte R¨ uckgabe, Beispiel 1

58

6 Speicherverwaltung

Da das Objekt nur tempor¨ ar existiert, f¨ uhrt eine solche R¨ uckgabe zu einem Programmfehler, der sehr schnell bemerkt werden kann. Schwieriger ist dagegen die R¨ uckgabe der Form:

Object& fraglich() { Object *grossesObjekt = new Object(); ... //do some stuff with object return *grossesObjekt; } Listing 6-20. Schlechte R¨ uckgabe, Beispiel 2

Der Aufrufende kann aufgrund der Signatur der Methode nicht erkennen, dass er das Objekt explizit l¨ oschen muss, wenn er es nicht ben¨otigt. Selbst wenn ein Zeiger anstelle einer Referenz zur¨ uckgegeben wird, so hat man das Problem, dass die Erzeugung und die Zerst¨orung in einer Hand liegen.

Object* fraglich() { Object *grossesObjekt = new Object(); ...//do some stuff with object return grossesObjekt; } Listing 6-21. Schlechte R¨ uckgabe, Beispiel 3

Auch wenn die Methode ausdr¨ ucklich dokumentiert wird und darauf hinweist, dass man das Objekt l¨ oschen muss, ist die Gefahr, dass die Dokumentation nicht oder nur fl¨ uchtig gelesen wird, sehr groß.

Object f() { Object obj; ...//do some stuff with object return obj; } Listing 6-22. Schlechte R¨ uckgabe, Beispiel 4

Eine Wertr¨ uckgabe der Form ist nicht effizient, weil • tempor¨ar ein Objekt angelegt wird, • anschließend ein Zuweisungsoperator aufgerufen wird.

6.4 Speicherbedarf und kleine Pittfalls

59

Besser w¨are eine R¨ uckgabe u ¨ber eine Objekt-Referenz als Parameter.

void f(Object& obj) { ... //do some stuff with obj } Listing 6-23. Bessere R¨ uckgabe, Beispiel

Auch f¨ ur elementare Datentypen, deren Gr¨ oße vier Bytes u ¨berschreitet, ist eine R¨ uckgabe u ¨ber formale Parameter effizienter. 6.4.17 Padding-Probleme ¨ Ubliche Speicherverschwender in der statischen Speicher- oder Typdefinition sind achtlose Vereinbarungen von Strukturen und Klassen, die vom Compiler mit Padding bis zur n¨ achsten Doppelwort-Grenze aufgef¨ ullt werden m¨ ussen.

struct Bad { char a[5]; Int32 b; bool c; }; struct Better { Int32 b; char a[5]; bool c; };

//5 Bytes //4 Bytes //1 Byte

//4 Bytes //5 Bytes //1 Byte

int main( ) { sOwnCout << "sizeof(Bad): " << sizeof(Bad) << endl; sOwnCout << "sizeof(Better): " << sizeof(Better) << endl; //Ausgabe: //sizeof(Bad): 16 //sizeof(Better): 12 return 0; } //end main Listing 6-24. Achtlos platzierte Member-Variablen

60

6 Speicherverwaltung

Die beiden Strukturen ben¨ otigen 16 und 12 Bytes. Durch das erforderliche 4-Bytes Alignment k¨ onnen Integers nur auf Adressen gelegt werden, die ein Vielfaches der Alignment-Gr¨ oße sind. In der Struktur Bad muss der Compiler somit hinter dem Zeichen-Array a[5] mit 3 weiteren Bytes auff¨ ullen, damit Int32 b korrekt adressiert werden kann. Ferner muss hinter bool c ebenfalls mit 3 weiteren Bytes aufgef¨ ullt werden, um die Mindestanforderungen zu erf¨ ullen. Folglich ben¨otigt die Struktur Bad statt 10 Bytes 16 Bytes, es werden somit 6 Bytes an Speicherplatz verschwendet. In der Struktur Better werden die Member-Variablen so deklariert, dass nur noch 2 Bytes aufgef¨ ullt werden m¨ ussen, um den Alignment-Anforderungen zu gen¨ ugen, statt 6 Bytes werden nur noch 2 Bytes verschwendet. 6.4.18 Alignment-Probleme, Endian-Probleme Es gibt viele schwer zu findende Fehler in Applikationen, die auf Unkenntnis des unterschiedlichen Alignment-Verhaltens unterschiedlicher Compiler beruhen. Auch Fehler aufgrund von Big-Endian- versus Little-Endian-Systemen sind typisch und sehr schwer zu finden. Eine Abhilfe k¨onnen die eigenen Definitionen des letzten Kapitels sein. Man sollte niemals mit Zeigerarithmetik Elemente von Strukturen adressieren! 6.4.19 Speicherfragmentierung Ein oft beobachteter Fehler ist das achtlose Allokieren und Deallokieren von Speicher verschiedener Blockgr¨ oßen, was zu Speicherfragmentierungen f¨ uhren kann. So kann man z.B. zun¨ achst eine Vielzahl kleiner Objekte auf dem Heap allokieren und sp¨ ater fast alle Objekte wieder freigeben. Dadurch werden die noch referenzierten Objekte so im Speicher verstreut, dass es nicht mehr m¨oglich ist, gr¨oßere zusammenh¨ angende Bl¨ ocke f¨ ur große Objekte zu allokieren. Ein solches Fragmentieren ist typisch f¨ ur Grafik-Applikationen im Zusammenhang mit Navigationskarten, bei denen verschiedene Grafikbl¨ocke je nach Inhalt sehr unterschiedlich groß sein k¨ onnen. Helfen kann hier eine MMU (Memory Management Unit), die durch logisch/physikalisches Umadressieren (mapping) der Hardware freie Speicherbl¨ocke wieder zusammenlegt oder ein Speicherdefragmentierer (Garbage Collector), der dasselbe in SW bewerkstelligt. F¨ ur beides ist aber die Kenntnis n¨ otig, welche Speicherbl¨ocke wirklich wieder frei sind und von keiner Seite mehr referenziert werden. Das ist speziell bei Shared-Objects, die innerhalb einer Komponente oder zwischen mehreren Komponenten gemeinsam benutzt werden, schwierig.

6.4 Speicherbedarf und kleine Pittfalls

61

Weiterhin sind u ocke 4 kByte groß, die oben genannten ¨bliche Speicherbl¨ Grafikanwendungen nutzen Objekte geringerer Gr¨oße. Zur Garbage-Collection m¨ ussen die normalen SW-Prozesse unterbrochen werden und ein normalerweise nicht unterbrechbarer Prozess wird gestartet, der die Referenzen auf Speicherbl¨ ocke analysiert. Dabei werden unreferenzierte Bl¨ocke markiert und freigegeben oder alle noch referenzierten Bl¨ocke in einen neuen Speicher kopiert und der alte komplett freigegeben. Unter Realtime-Anforderungen ist ein solches Vorgehen nicht m¨oglich, es gibt auf dem KFZ-Markt ein eindrucksvolles Negativbeispiel eines OberklasseFahrzeugs, dessen Infotainment-System immer mal wieder f¨ ur einige Sekunden lang nicht bedienbar ist, weil es gerade Speicher defragmentiert. Ein weiterer Nachteil ist, dass zwischen den Phasen der Speicherdefragmentierung Speicher verschwendet wird und dass w¨ ahrend der Defragmentierung der Stack intensiv genutzt werden muss. Defragmentierungs- und Garbage-Collection-Algorithmen sind normalerweise in Embedded-Systemen nicht zul¨ assig. Besonders leicht“ ist es, versehentlich Speicherl¨ ucken zu erzeugen, wenn ” mehrere Threads auf dem Heap Speicher allokieren. Wir werden in den folgenden Kapiteln noch u ¨ber die Unterschiede zwischen Prozessen und Threads erfahren. Im Moment reicht es zu wissen, dass alle Threads als Tr¨ager verschiedener paralleler Programmabl¨ aufe auf demselben Heap arbeiten. Allokieren nun Threads abwechselnd Speicher auf dem Heap und gibt sp¨ater ein oder mehrere Threads Speicherobjekte wieder frei, so wird der Heap durchl¨ochert. Besonders fatal wirken sich wieder die erw¨ahnten kleinen, stark verstreuten Speicherobjekte einer Grafik-Anwendung aus, die verhindern, dass nach der Deallokierung der Speicher eines anderen Threads gr¨oßere Bl¨ocke wieder zusammengefasst werden k¨ onnen. Multithread-Systeme sind besonders anf¨ allig gegen Speicherfragmentierung durch dynamische Speicherallokation. 6.4.20 Vektoren, STL Ein anderes Kapitel wenig geeigneter Embedded Programmierung ist die Verwendung von Vektoren aus der Standard Library. Die Vektoren haben eine Inkrementvereinbarung, die den Vektor, wenn er f¨ ur die zu speichernden Daten nicht mehr ausreicht, dynamisch um ein festes Inkrement erweitert. Wenn er dann immer noch nicht ausreicht, wird er wieder erweitert usw. Erfahrungsgem¨ aß gibt es aus Unkenntnis dieses Mechanismus sehr schlechte Verwendungen. Wenn ein Vektor der Gr¨ oße 1 kByte in 4 Bytes-Schritten vergr¨oßert werden muss, bis das Grafik-Widget der Gr¨ oße 8 kByte hineinpasst, werden einige Sekunden vergehen.

62

6 Speicherverwaltung

Ersichtlich ist das Laufzeitverhalten langsam, schlecht vorhersagbar und unbegrenzt im Wachstum. Eine andere Strategie ist die Verdopplung der aktuellen Gr¨oße. Diese Strategie ist schnell, aber ggf. speicherintensiv. Auf der Web-Seite werden Routinen f¨ ur die Zeitmessung von Vektoren vorgenommen. Gemessen werden Vektoren beim stackbasierten Einf¨ ugen von Werten und durch wahlfreien Zugriff. Verglichen werden die Zeiten mit einem wahlfreien Zugriff auf ein Array. Hier seien nur die Ergebnisse dargestellt. Die ermittelten Zeiten best¨ atigen die Annahme, dass STL-Vektoren im Durchschnitt mehr Zeit f¨ ur das Einf¨ ugen von Daten ben¨otigen, als statisch allokierte Felder. Die Differenz zwischen dem Einf¨ ugen eines Datums in einen STL-Vektor beziehungsweise in ein statisches Array betr¨agt hier im ung¨ unstigsten Fall 0.38 us. Dieses Ergebnis spricht f¨ ur die Qualit¨at der STLImplementierung (Verdopplung).

// // // // //

Ergebnis auf einem Embedded System (SH4 240 MHz): vector with stackop - insertion time: 4.7 vector with random access - insertion time: 4.54 static arrays - insertion time: 4.32 resizing time for 4 Bytes : 4.1

usecs usecs usecs usecs

Listing 6-25. Zeitmessungen zu Arrays und Vektoren, [Klein]

Am schnellsten ist die Verwendung von lokalen Variablen. Der Grund, dass Stack-orientierte Zugriffe am schnellsten sind, ist die direkte Unterst¨ utzung durch die Hardware; die Variablen werden u ¨ber den Stack-Zeiger zugegriffen. Die Daten im Datensegment werden, auf Grund der MMU, teilweise nur indirekt zugegriffen (mit Ein- und Auslagerung von Cache), was die Geschwindigkeit beeinflusst. Die Verwendung eines Vectors ist erwartungsgem¨aß langsamer.

7 Embedded Speicherkonzepte, spezielle Muster

Zun¨achst wird in streng konzipierten Embedded Systemen dynamische Allokation per Standard new oder delete prinzipiell verboten. Die Verletzung von Real-Time Anforderungen, die drohende Fragmentierung und die zus¨atzlichen Speicherkosten verbieten die dynamische Standard-Allokation von Speicher auf dem Heap. Die dynamische Vereinbarung von Objekten per malloc und new werden ¨ durch Uberladen blockiert oder per Designregeln verboten. Auch Bibliotheks¨ klassen wie Vektoren sollten vermieden werden, da sie bei Uberschreiten der vorgesehenen Gr¨ oße dynamisch vergr¨ oßert werden. Die beste Maßnahme ist, dynamische Allokationen durch eigene definierte Allokationen zu ersetzen. Diese k¨ onnen u.a. aus der folgenden Palette gew¨ahlt werden.

7.1 Statische Variablen Eine Besonderheit weisen lokale statische Variablen auf. Sie werden in der InitPhase noch vor der main-Funktion angelegt und auf 0 gesetzt (uninit data). Erst beim ersten Aufruf zur Laufzeit bekommen sie ihren Initialisierungswert, der in der Implementierung angegeben wurde. 7.1.1 Reihenfolge der Konstruktoren Wie bereits erw¨ahnt, ist die Reihenfolge der Erzeugung der init und uninit Data Compiler-abh¨ angig und nicht festgelegt. Die Reihenfolge der Klassenobjekte folgt innerhalb eines Files der Reihenfolge im Source-Code. Die Reihenfolge ist demnach ebenfalls nicht festgelegt, falls zwei Klassenobjekte in verschiedenen Files definiert werden. Sollte sie wichtig sein, m¨ ussen beide Definitionen in einer Datei erfolgen.

64

7 Embedded Speicherkonzepte, spezielle Muster

Eine M¨oglichkeit wurde in [Doug] implementiert. In einem Klassenobjekt werden im Konstruktor alle statischen Objekte als lokale Objekte der Reihe nach initialisiert. Die Objekte k¨ onnen dann per get-Methoden und Referenzparameter den nutzenden Programmteilen zur Verf¨ ugung gestellt werden. Betrachten wir diese L¨ osung etwas genauer: Ein Systemobjekt wird als globales Objekt angelegt, das daraufhin alle weiteren globalen Objekte anlegt. Wir wollen z.B. f¨ unf globale Objekte a, b, c , d und e anlegen, die eine azyklische Abh¨ angigkeit haben

Abbildung 7.1. Abh¨ angige Objekte

In [Doug] werden primitive Objekte (die zu definierenden globalen Objekte), zusammengesetzte Objekte (Hilfsobjekte) sowie Systemobjekte usw. eingef¨ uhrt, um die Reihenfolge der Erzeugung zu gew¨ahrleisten. Nach dem C++-Standard werden Objekte eines zusammengesetzten Objekts in der Reihenfolge erzeugt, wie sie deklariert sind. Anstatt mehrere Objekte und Klassen wie in [Doug] einzuf¨ uhren, wird die vorhandene Halbordnung durch ein topologisches Sortieren in eine Ordnung u uhrt (siehe z.B. [Knu]). F¨ ur das Beispiel oben haben wir die Ordnung a ¨berf¨ , b, c, d, e (d.h., wenn ein Objekt obj1 vor einem Objekt obj2 steht, dann kann obj2 von obj1 abh¨ angen aber nicht umgekehrt). Das Systemobjekt wird dann etwa wie folgt definiert:

class CSystemObject { public: static A & getA(){ return s.a; } static B & getB(){ return s.b; }

7.1 Statische Variablen

65

static C & getC(){ return s.c; } static D & getD(){ return s.d; } static E & getE(){ return s.e; } private: // Konstruktor private friend class CDummy; // Warnung wegen priv. Konstruktors vermeiden CSystemObject(); static CSystemObject s; A a; // Reihenfolge wichtig, weil Objekte in dieser B b; // Folge in Initialisierungsliste erzeugt werden C c; D d; E e; }; //Im Implementierungs-File: ... CSystemObject CSystemObject::s; CSystemObject::CSystemObject(): a(), b(a), c(a), d(a, b), e(c, d) {}

// // // // //

ggf. mit Parameter b h¨ angt von a ab c h¨ angt von a ab d h¨ angt von a und b ab e h¨ angt von c und d ab

Listing 7-1. Systemobjekt

Innerhalb des Systemobjekts hat man auch die M¨oglichkeit, einen Speicherbereich als Element anzulegen und die primitiven Objekte bei Bedarf zur Laufzeit anzulegen. Dazu wird der Placement-new-Operator verwendet, der weiter unten genauer besprochen wird. Wenn z.B. das Objekt e nur angelegt werden soll, wenn es ben¨otigt wird, dann kann eine L¨ osung etwa wie folgt aussehen:

class CSystemObject { public: static A & getA(){ return static B & getB(){ return static C & getC(){ return static D & getD(){ return static E & getE() ; private: // friend class CDummy; // CSystemObject();

s.a; s.b; s.c; s.d;

} } } }

Konstruktor privat um Warnung zu vermeiden

66

7 Embedded Speicherkonzepte, spezielle Muster static CSystemObject s; // A a; // B b; // C c; D d; E *ePtr; CMutex mMutex; // char mBuffer[sizeof(E)];

Reihenfolge wichtig, weil Objekte in dieser Folge in Initialisierungsliste erzeugt werden

f¨ ur die Synchronisierung in Multithread

}; //Im cpp-File ... CSystemObject CSystemObject::s; CSystemObject::CSystemObject() : a(), // ggf. mit Parameter b(a), // b h¨ angt von a ab c(a), // c h¨ angt von a ab d(a,b), // d h¨ angt von a und b ab ePtr(0), // Zeiger mit Null initialisieren mMutex() {} E & CSystemObject::getE() { if (0 == ePtr) { mMutex.take(); if (0 == ePtr) // doppel checking ePtr = new(mBuffer) E(c,d); // placement new, um das Objekt // im reservierten Speicher anzulegen mMutex.give(); } return *ePtr; } Listing 7-2. Systemobjekt mit reserviertem Speicherbereich

7.2 Quasi-statische Allokation aus festem Pufferspeicher Es gibt Gr¨ unde, warum Objekte im Speicher nicht zur Link/Load-Zeit bzw. in der Init-Phase vor der main angelegt werden k¨ onnen. So m¨ ussen z.B. die Daten f¨ ur ein Device angelegt werden, dessen Instanz-ID noch nicht bekannt ist, oder es fehlen andere Daten, die daf¨ ur gebraucht w¨ urden. Eventuell verl¨angert das Anlegen der Objekte in der Init-Phase auch die Startzeit unzul¨assig.

7.2 Quasi-statische Allokation aus festem Pufferspeicher

67

7.2.1 Anlegen eines statischen Puffers Eine alternative L¨ osung ist das Anlegen eines festen Speicherpuffers im Datensegment w¨ahrend der Startzeit oder zur Kompilier/Link-Zeit. Die Objekte werden dann zu einem sp¨ ateren Zeitpunkt durch Placement-new in diesen Speicherbereich abgelegt. STATIC MEM SIZE ist dabei eine Konstante aus einer config.h Datei, die in der Entwicklungsphase in der Gr¨oße bestimmt werden muss (Buchf¨ uhrung).

static char sMem[STATIC_MEM_SIZE]; // Static Speicher f¨ ur Objekte static char* sCurrentPtr = sMem; // Merker f¨ ur freien Speicher static const char* sMemEndPtr = sMem+STATIC_MEM_SIZE; //Speicherende Listing 7-3. Anlegen eines statischen Puffers

Aus diesem Puffer k¨ onnen nun im Betrieb quasi-statische Objekte angefordert werden. Die Objekte werden nur einmal angelegt und existieren bis zum Herunterfahren des Programms. Die folgende C-Funktion liefert den Zeiger auf statischen Objektspeicher der gew¨ unschten Gr¨oße, angelegt in dem oben generierten statischen Datensegment-Puffer sMem. Mit den Zeilen sMutex.take und sMutex.give werden auch hier wieder Synchronisationsmechanismen um die eigentliche Funktion gelegt, so dass Kollisionen durch konkurrierende Zugriffe vermieden werden. Diese Mechanismen werden an anderer Stelle noch erl¨ autert.

char * getStaticMemory(size_t memSize) { //gibt Zeiger auf Speicher sMutex.take(); ASSERTION(sCurrentPtr + memSize < sMemEndPtr); //eig. Fehlerbehdlng char *retPtr = sCurrentPtr; //ret Zeiger auf freien Speicher sCurrentPtr+=MAKE_ALIGNMENT_SIZE(memSize); sMutex.give(); //und Weiterschaltung return retPtr; } Listing 7-4. Nutzung des Puffers durch eine C-Funktion

7.2.2 Placement-new Mit einem Placement-new-Operator (manchmal auch Replacement-new genannt) kann man eine Variable des gew¨ unschten Typs im Pufferspeicher vereinbaren, [Pla].

68

7 Embedded Speicherkonzepte, spezielle Muster

ObjPtr = new(getStaticMemory(sizeof(int))) int; //Objekt (z.B. int) im vorgegebenen Speicher anlegen Listing 7-5. Einsatz des Placement-new-Operators

Da der Placement-new-Operator, die so genannte Plazierungsform von new, nicht sehr gel¨aufig ist, sei er hier kurz beschrieben:

varPtr = new (location) Type(Param);

//Konstruktor mit Parameter

Listing 7-6. Syntax des Placement-new-Operators

Dem new-Operator wird also der Speicher als Zeiger u ¨bergeben, in dem das neue Objekt angelegt und konstruiert werden soll. Dem Konstruktor k¨onnen auch Parameter zur Initialisierung mitgegeben werden. Falls der Placement-new-Operator nicht Bestandteil der Standard Library ist (WinCE), ist eine eigene Implementierung leicht m¨oglich, vorausgesetzt, die eigentliche Verwaltung geschieht an anderer Stelle, z.B. in der getStaticMemory-Methode.

void * operator new(size_t,void * memorySpace){return memorySpace;} ¨ Listing 7-7. Eigenes Uberladen des Placement-new-Operators, [Nob]

Entweder mit eigenen Placement-new-Konstrukten oder besser mit vorgefertigten Makros kann nun statischer Speicher aus dem Datensegment allokiert werden. 7.2.3 Makros zur Allokation Ein paar Beispiel-Makros sind im Folgenden zu finden: #define NEW_STATIC_DEFAULT(Typ)(new(getStaticMemory(sizeof(Typ)))Typ())

Im n¨achsten Makro wird ein Konstruktor mit einer Liste von Argumenten verwendet. Die Argumente m¨ ussen in Klammern u ¨bergeben werden. Z.B.: x = NEW_STATIC(T, (5, "test"));

Die Definition: #define NEW_STATIC(Typ,ARGS)(new(getStaticMemory(sizeof(Typ)))Typ ARGS)

7.2 Quasi-statische Allokation aus festem Pufferspeicher

69

Auch wenn ARGS nur aus einem Parameter besteht, muss es in Klammern stehen, damit im Konstruktor –Typ (ARGS)- eingesetzt wird. Das Makro NEW_STATIC (string, (5))

wird dann in new(getStaticMemory(sizeof(string))) string(5);

umgesetzt. #define NEW_STATIC_ARRAY(Typ, size) (new(getStaticMemory(sizeof(Typ)*size)) Typ[size])

Die folgenden DELETE STATIC, DELETE ...-Makros haben keinen Effekt, da vereinbarungsgem¨ aß die Objekte bis zum Herunterfahren des Systems existieren. #define DELETE_STATIC(var) #define DELETE_STATIC_ARRAY(array)

//blockieren, keine Aktionen, //falls jd.auf die Idee kommt

Folgende Includes sind an geeigneter Stelle n¨otig: #include <stddef.h> #include

//oder wegen size_t //oder wegen placement new

Um statische und dynamische Allokation in der Entwicklungsphase leicht austauschen zu k¨onnen, werden wir die entsprechenden Makros auch f¨ ur den Heap definieren. In folgendem Beispiel werden new und delete verwendet. Man kann analog zur statischen Speicher-Allokierung austauschbare Makros verwenden, um w¨ ahrend der Entwicklung mehr Kontrolle u ¨ber den dynamischen Speicher zu bekommen. #define NEW_DYNAMIC_DEFAULT(Typ) (new Typ())

Das n¨achste Makro erzeugt wieder ein Objekt mit einem Konstruktor mit einer Liste von Argumenten. Die Argumente m¨ ussen in Klammern u ¨bergeben werden. Z.B.: x = NEW_DYNAMIC_ARGS(T, (5, "test")).

Auch wenn ARGS nur aus einem Parameter besteht, muss es wieder in Klammern stehen.

70

7 Embedded Speicherkonzepte, spezielle Muster

#define NEW_DYNAMIC(Typ, ARGS) (new Typ ARGS)

Ein Makro f¨ ur die Erzeugung eines Arrays: #define NEW_DYNAMIC_ARRAY(Typ, size) (new Typ[size])

Die folgenden Makros leiten einfach auf das Standard delete um. #define DELETE_DYNAMIC(var)(delete var) #define DELETE_DYNAMIC_ARRAY(array)(delete[] array)

Sinnvollerweise werden alle besprochenen Makros und C-Funktionen in einer Header-Datei gesammelt, wir nennen sie FWMemory.h. Noch einmal als gek¨ urzte Zusammenfassung:

extern char * getStaticMemory(size_t memSize); //in FWMemory.cpp //dynamische Speicherallokierung #define NEW_DYNAMIC_DEFAULT(Typ) (new Typ()) #define NEW_DYNAMIC(Typ,ARGS) (new Typ ARGS) #define NEW_DYNAMIC_ARRAY(Typ,size) (new Typ[size]) #define DELETE_DYNAMIC(var)(delete var) #define DELETE_DYNAMIC_ARRAY(array) (delete[] array) /* Statische Speicherallokierung #define NEW_STATIC_DEFAULT(Typ)(new(getStaticMemory(sizeof(Typ)))Typ()) #define NEW_STATIC(Typ,ARGS)(new(getStaticMemory(sizeof(Typ)))Typ ARGS) #define NEW_STATIC_ARRAY(Typ,size) (new(getStaticMemory(sizeof(Typ)*size))Typ[size]) #define DELETE_STATIC(var) #define DELETE_STATIC_ARRAY(array) Listing 7-8. Alle Makros in FWMemory.h

7.3 Allokator Nehmen wir an, in einer Methode m¨ ussten wir sehr viele kleine tempor¨are Objekte erzeugen, z.B. zum Zeichnen einer Karte. Die Objekte werden am Ende der Methode freigegeben. Hier gibt es die Gefahr der Speicherfragmentierung. Legen wir die Objekte auf den Heap, verwendet die Speicherverwaltung, wie wir gesehen haben, zus¨ atzliche Daten. Legen wir die Objekte auf den Stack, entsteht sehr schnell die Gefahr des ¨ Stack-Uberlaufs. Der erste L¨ osungsansatz ist, lokale Objekte auf dem Stack zu verwenden. Wir k¨onnten das etwa so formulieren (in Pseudocode):

7.3 Allokator

void CC::doIt() { CObject array[100]; ... ...

71

//mach was mit a1, a2, ..., a100 //Beim Verlassen werden die Objekte //automatisch freigegeben //die Destruktoren f¨ ur die einzelnen Objekte //a1, a2, .., a100 werden implizit aufgerufen

}

Das oben angedeutete Problem ist: Die Objekte auf dem Stack f¨ uhren dazu, dass die Stack-Gr¨ oße des aktuellen Threads sehr groß gew¨ahlt werden muss (Verschwendung, wenn diese Methode selten ausgef¨ uhrt wird). Hinzu kommt, dass diese Technik in Embedded Systemen leicht zu einem Stack¨ Uberlauf f¨ uhrt, der schwer zu finden ist, da es in der Regel keine Laufzeit¨ Uberpr¨ ufung dazu gibt. Der zweite L¨osungsansatz w¨ are, die Objekte auf dem Heap anzulegen, etwa wie folgt:

void CC::doIt() { CObject *array[] = NEW_DYNAMIC_ARRAY(CObject, 100); ... //mach was mit den Elementen ... //Beim Verlassen m¨ ussen die Objekte //explizit freigegeben werden DELETE_DYNAMIC_ARRAY(array); }

Das Problem bei dieser L¨ osung kann die interne Speicherfragmentierung sein. Solange wir nur einen Thread haben, ist die L¨osung in Ordnung. Das Problem tritt auf, wenn z.B. w¨ ahrend der Erzeugung ein anderer Thread aktiv wird und dabei auch Speicher vom Heap verlangt, eventuell auch in anderen Objektgr¨oßen. Das f¨ uhrt dazu, dass viele kleine nicht zusammenh¨angende Speicherbereiche entstehen k¨ onnen. Der dritte L¨osungsansatz nutzt das Allocator-Pattern. Intention ist, dem Anwender die Komplikationen eines Placement-newOperators oder spezieller Makros zu ersparen. Auch die Bereitstellung des Pufferspeichers mit einer C-Funktion widerspricht der gew¨ unschten Objektorientierung in der Anwenderprogrammierung. Wir wollen Objekte implementieren, die Methoden zur Anlage des Pufferspeichers bereitstellen und Methoden zum Allokieren von Speicher daraus.

72

7 Embedded Speicherkonzepte, spezielle Muster

Allokatoren sind Objekte, die Speicher aus einem Puffer bereitstellen und verwalten. Dabei sind die Daten und die Zugriffsmethoden Teil des Objekts. Ein Objekt hat eine Adresse, Methoden, Identit¨at. Zuvor haben wir mit getStaticMemory Speicherbl¨ocke aus diesem Puffer angefordert. Funktionen wie getStaticMemory sind aber C-Funktionen. M¨ogliche Implementierungen von Allokatoren sind: • Statischer Allokator -> CStaticAllocator; • tempor¨arer Heap: Ein großes Array wird als Heap verwendet -> CTemporaryHeapAllocator; • Objektpool: Ein Pool von Objekten gleicher Gr¨oßer wird verwendet. Objekte werden in den Pool zur¨ uckgegeben (der Speicherplatz wird nicht freigegeben) -> CObjectPool; • der eigentliche ungesch¨ utzte Allokator kann mit einer H¨ ullklasse gegen ineinander greifende Zugriffe gesch¨ utzt werden -> CSyncAllocator. Diese Version wird hier nicht weiter vertieft. Stattdessen implementieren wir schon in CStaticAllocator eine Synchronisierung. Eine Mischung dieser Technik mit dynamischen Listen von Allokatoren ist m¨ oglich. Grundlage aller folgenden Allokatoren ist die Interface-Klasse IAllocator, die alle Klassen einhalten m¨ ussen:

class IAllocator //Schnittstelle f¨ ur alle Allokatoren { public: virtual void * allocate(size_t memSize) = 0; //memSize Gr¨ oße des zu allokierenden Speichers, //return Zeiger auf Speicher virtual void deallocate(void * memPtr) = 0; //gibt Speicher frei }; Listing 7-9. Interface-Definition IAllocator.h

Folgende Makros k¨ onnen dann f¨ ur alle Allokator-Objekte definiert werden:

#define FW_NEW_DEFAULT(Typ, allocator)\ (new(allocator.allocate(sizeof(Typ))) Typ()) #define FW_NEW(Typ, ARGS, allocator)\ (new(allocator.allocate(sizeof(Typ))) Typ ARGS)

7.3 Allokator

73

#define FW_NEW_ARRAY(Typ, size, allocator)\ (new(allocator.allocate(sizeof(Typ)*size)) Typ[size]) #define FW_DELETE(objPtr, allocator) (allocator.deallocate(objPtr)) Listing 7-10. Makros zur Allokation von Objekten

Abbildung 7.2. Klassendiagramm Allocator

7.3.1 Statische Allokation Das erste Beispiel zeigt eine quasi statische Allokation. Die Objekte werden einmal angelegt und nicht mehr gel¨ oscht. Hierbei wird das Singleton-Muster verwendet. Der Basisklassen-Prototyp wird von IAllocator abgeleitet:

class CStaticAllocator : public IAllocator { public: static IAllocator & getAllocator(); //Methode holt einzig. Allocator void *allocate(size_t memSize) { return ::getStaticMemory(memSize); //Block stat. Speicher aus sMem } void deallocate(void * memPtr) //gibt den Speicher frei. memPtr

74

7 Embedded Speicherkonzepte, spezielle Muster

{} //nichts -- static-Speicher wird nicht freigegeben private: friend class CDummy; //Damit Comp nicht meckert, //dass Destruktor privat static CStaticAllocator *sAllocatorPtr; //nur ein Allocator erlaubt! static CMutex sMutex; //Mutex gegen konkurrierende Zugriffe CStaticAllocator() {} //blockieren ~CStaticAllocator() {} }; Listing 7-11. Der Basisklassen-Prototyp CStaticAllocator.h

Es folgt die Implementierung in CStaticAllocator.cpp. Um Schutz gegen quasi parallele Zugriffe durch mehrere Prozesse zu bieten, ist ein Synchronisationsmechanismus um die Allokation herumgelegt (sMutex, sMutex.take, sMutex.give). Dieser wird sp¨ ater noch genauer besprochen.

CStaticAllocator *CStaticAllocator::sAllocatorPtr=NULLPTR; //wg. static CMutex CStaticAllocator::sMutex; //wg. static IAllocator & CStaticAllocator::getAllocator() //Allocator, Singleton { //Muster: Double Check! Vorteil: Mutex nur 1mal am Anf. getriggert if (NULLPTR == sAllocatorPtr) //erste Mal? { sMutex.take(); if (NULLPTR == sAllocatorPtr) { sAllocatorPtr = NEW_STATIC_DEFAULT(CStaticAllocator); //Allocator Objekt in sMem anlegen } sMutex.give(); } return *sAllocatorPtr; //Ptr auf Objekt,das static-Speicher liefert } Listing 7-12. Auszug aus CStaticAllocator.cpp

Der Pufferspeicher sMem wurde schon in FW angelegt. Normalerweise wird ein Objekt auf dem Heap (mit new) oder auf dem Stack (lokale Instantiierung) angelegt. Legt man das Allocator-Objekt auf den Heap, w¨ urde es ihn mittendrin“ f¨ ur die gesamte Programmlaufzeit blockieren. ” Das Objekt als lokales Objekt auf dem Stack anzulegen, w¨ urde die Nutzung durch andere Programmteile verbieten. Daher ist die beste L¨ osung, das Allocator-Objekt selbst in den großen Speicher sMem zu legen. Es soll nur einmal angelegt werden und muss also als Singleton vereinbart werden.

7.3 Allokator

75

Abbildung 7.3. Statisches Allocator-Objekt

Das Anlegen eines Allocators im sMem w¨ urde wie folgt in einer main aufgerufen:

CStaticAllocator * ABC; ABC = CSyncAllocator::getAllocator(); //Intern wird das Allocator Objekt einmal in den Speicher gelegt Listing 7-13. Vereinbarung eines Allocators

Wie wir gesehen haben, gibt es bei dynamischer Speichervergabe Overhead f¨ ur Alignment und Speicherverwaltung. F¨ ur unsere Zwecke k¨onnen wir einen Allokator definieren, der nur eine Datengr¨oße allokieren kann, diese aber optimal mit beispielsweise genau 4 Bytes. 7.3.2 Dynamische Allokation mit tempor¨ arem Heap Die dynamische Allokation in C++ mit Standardimplementierungen new und delete kommt, wie oben mehrfach erkl¨ art, normalerweise in real time Embedded Systemen nicht in Frage. Es gibt F¨alle, in denen doch auch in Embedded Systemen dynamisch erzeugte Objekte schwer vermeidlich sind. Ein Beispiel daf¨ ur sind grafische Objekte, z.B. in der grafischen Kartendarstellung oder Titellisten von MP3-CDs. Diese Objekte sind zus¨ atzlich auch noch verschieden groß und w¨ urden, wie weiter oben besprochen, sehr schnell Speicherfragmentierung verursachen. Statische Allokation w¨ are hier Verschwendung, da es Zeiten gibt, in denen weder der angelegte Speicher noch die Objekte gebraucht werden, der Speicher also f¨ ur andere Zwecke freigegeben werden k¨ onnte. Daf¨ ur gibt es dann doch eine geeignete M¨oglichkeit, quasi dynamische Allokation zu verwenden.

76

7 Embedded Speicherkonzepte, spezielle Muster

Es wird daf¨ ur zu Anfang ein tempor¨ arer, limitierter Heap angelegt, aus dem Bl¨ocke dynamisch vergeben werden d¨ urfen. Dieser tempor¨are Heap wird am Ende allerdings nur en bloc“ zur¨ uckgegeben, so dass keine feink¨ornige ” Fragmentierung entstehen kann. Dies spart gegen¨ uber dem Aufruf vieler einzelner deletes auch Zeit. Dieser tempor¨ are Heap kann sich auf dem Heap oder auf dem Stack oder in einem besonderen Speicherbereich im Datensegment befinden, er wird allerdings nur komplett wieder freigegeben, vermeidet also die Fragmentierung durch die R¨ uckgabe vieler verschieden großer Objekte. Dabei wird ein großer statt vieler kleiner Speicherbl¨ ocke zur¨ uckgegeben, der besser durch das Betriebssystem verwaltet wird. Diese Speicherfreigabe bezeichnet man im Englischen mit Memory Discard.

void CC::doIt() //Allokieren im temp. Heap (in Pseudocode) { //Erzeugt tempor¨ aren Heap; z.B. in großem Speicherblock vom Heap UByte *tempHeapPtr=NEW_DYNAMIC_ARRAY(UByte, 4096); //Erzeugt einen Allokator --Allocator selbst ist hier auf d. Stack! CTemporaryHeapAllocator allocator(tempHeapPtr, 4096); //Nun Objekte mit Allokator erzeugen CObject1 *aPtr1 = FW_NEW_DEFAULT(CObject1, allocator); CObject2 *aPtr2 = FW_NEW_DEFAULT(CObject2, allocator); ... CObject100 *aPtr100 = FW_NEW_DEFAULT(CObject100, allocator); ... //mach was mit aPtr1, aPtr2, .., aPtr100 //Beim Verlassen nur Speicherbereich zur¨ uckgeben, sparen dabei Code DELETE_DYNAMIC_ARRAY(tempHeapPtr); //und verhindern Fragmentierung } Listing 7-14. Aufruf der Allocator-Methode

Diese Freigabe des tempor¨ aren Heap k¨ onnte im oben genannten Beispiel dann geschehen, wenn das Navigations- oder das MP3-Men¨ u verlassen wird. Intern kann der tempor¨ are Heap u ¨ber Zeiger verwaltet werden, in der einfachsten Version wird er durch Zur¨ ucksetzen des Start-Zeigers zur neuen Verwendung geleert. Man sollte nicht versuchen, die Deallokation der einzelnen Objekte zu verwalten. Sehr schnell ist man dabei, eine vollst¨andige dynamische Speicherverwaltung zu implementieren. Insbesondere, wenn man es mit mehreren Referenzen auf ein gemeinsames Objekt zu tun hat, rutscht man in Themen wie Garbage-Collection und Reference-Counting, die einige Abschnitte sp¨ater kurz angesprochen werden.

7.3 Allokator

77

Implementieren wir wieder eine objektorientierte L¨osung, so k¨onnte die gek¨ urzte CTemporaryHeapAllocator.h Datei wie folgt aussehen:

class CTemporaryHeapAllocator:public IAllocator { //Allokator f.temp.Objekte public: CTemporaryHeapAllocator(size_t heapSize); //Erzeugt tmp. Heap mit new CTemporaryHeapAllocator(char * memPtr, size_t heapSize); //Erzeugt einen temp.Heap im explizit ¨ ubergebenen Speicher ~CTemporaryHeapAllocator(); //Der Speicher wird freigegeben void reset() //l¨ oscht alle tempor¨ aren Objekte { mBytesAllocated = 0; } //holt Speicher f¨ ur Objekt aus angelegtem Heap void *allocate(size_t memSize); //nichts, Speicher sp¨ ater auf einmal freigeben void deallocate(void * memPtr) {} private: char * mHeapMemoryPtr; //Zeiger auf den Speicher size_t mHeapSizeInBytes; //Gr¨ oße des Speichers size_t mBytesAllocated; //Anzahl der schon allokierten Bytes bool mDeleteMemNeeded; //merken, ob Objekt Speicher freigibt }; Listing 7-15. Klasse CTemporaryHeapAllocator, Prototyp

Wir geben zwei Konstruktoren an, die sich wie u ¨blich durch ihre Signatur unterscheiden. Der eine erzeugt selbst einen tempor¨aren Heap unter Verwendung von new. Der andere erzeugt ebenfalls einen tempor¨aren Heap, wobei allerdings der Speicher explizit u ur diesen Fall wird der Speicher sp¨ater ¨bergeben wird. F¨ nicht vom Objekt freigegeben. Die Implementierung ist wie folgt:

78

7 Embedded Speicherkonzepte, spezielle Muster

CTemporaryHeapAllocator::CTemporaryHeapAllocator(size_t heapSize) : mHeapMemoryPtr(NEW_DYNAMIC_ARRAY(char, heapSize)), //mit new mHeapSizeInBytes(heapSize), mBytesAllocated(0), mDeleteMemNeeded(true) {} CTemporaryHeapAllocator::CTemporaryHeapAllocator( char * memPtr, size_t heapSize) : mHeapMemoryPtr(memPtr), //v. hier allokieren mHeapSizeInBytes(heapSize), mBytesAllocated(0), mDeleteMemNeeded(false) {} CTemporaryHeapAllocator::~CTemporaryHeapAllocator() { //Speicher freigeben if (true == mDeleteMemNeeded) { DELETE_DYNAMIC_ARRAY(mHeapMemoryPtr); } } void * CTemporaryHeapAllocator::allocate(size_t memSize) { //holt Speicher f¨ ur Objekt aus angelegt.Heap mem void *allocatedPtr = mHeapMemoryPtr + mBytesAllocated; mBytesAllocated += memSize; // ¨ Uberpr¨ ufe, ob gen¨ ugend Speicher ASSERTION(mBytesAllocated <= mHeapSizeInBytes); // Offset anpassen f¨ ur n¨ achsten Zugriff wegen Alignment mBytesAllocated = MAKE_ALIGNMENT_SIZE(mBytesAllocated}; return allocatedPtr; } Listing 7-16. CTemporaryHeapAllocator, Implementierung

7.3.3 Object-Pool-Allokation Eine weitere Variante ist die Pool-Allokation, die man benutzen kann, wenn die zu allokierenden Objekte alle feste und gleiche Gr¨oße haben und nach einer Zeit einzeln nicht mehr gebraucht werden. Ein Beispiel sind EventNachrichten, f¨ ur die man sich aus einem Objekt-Pool Speicher holen kann, der nach der erfolgreichen Versendung und Konsumierung wieder dem Pool zur¨ uckgegeben wird. Anstatt neue Objekte zu erzeugen und sie dann sp¨ater zu l¨oschen, werden also z.B. die Pool-Methoden createObject und freeObject aufgerufen.

7.3 Allokator

79

Gibt es mehrere verschiedene Nachrichtengr¨oßen, werden mehrere typabh¨angige Pools angelegt. Man kann die freien Elemente des Pools derart verketten, dass keine zus¨atzlichen Verwaltungsdaten erforderlich sind, was mindestens 4 Byte pro Speicher-Block spart. Wenn die Anzahl der Objekte gut gew¨ ahlt wird, kann die Erzeugung und Freigabe von Objekten schneller als new und delete sein, da die aufw¨andige Speicherverwaltung des Laufzeitsystems nicht benutzt wird. Damit die Verwendung f¨ ur die Projektprogrammierer einfach bleibt, wird ein sehr schlanker objektorientierter Ansatz implementiert. Die folgende Klasse stellt alle notwendigen Methoden zur Verf¨ ugung, zur ¨ besseren Ubersicht seien zun¨ achst wieder die Prototypen, dann die Implementierung vorgestellt. Im Moment sind auch hier alle Methoden nicht gesch¨ utzt gegen konkurrierende Zugriffe, die die Objekte in inkonsistente Zust¨ande bringen k¨onnten.

class CObjectPool: public IAllocator { public: CObjectPool(size_t numOfObjects, size_t theObjectSize); ~CObjectPool(); //Dtor soll nichts bewirken void * allocate(size_t memSize); //holt Speicher f¨ ur Objekt //Speicher ist nicht initialisiert, memSize wird hier ignoriert //da im Konstruktor schon festgelegt //gibt Speicher frei, memPtr auf freizugebenden Speicher void deallocate(void * memPtr); protected: struct Entry { Entry *nextPtr; }; Entry * mFreeListPtr; //Liste f¨ ur die freien Objekte size_t mObjectSize; //um Gr¨ oße des Objekts zu merken char* mStartAdr; //Anfadr. des Speicherblocks char* mEndAdr; //Endadresse des Speicherblocks private: CObjectPool(const CObjectPool& theOther); CObjectPool& operator=(const CObjectPool& theOther); };//end of CObjectPool.h Listing 7-17. Prototyp der Klasse CObjectPool

Nun die Implementierung von CObjectPool.cpp. Im Konstruktor wird ein Speicherblock vom Heap allokiert. Dieser wird in kleine Strukturen Entry organisiert und diese werden in einer Free-Liste intern verkettet. Die Methode allocate gibt einen Zeiger auf ein Element zur¨ uck, das zuvor aus der Free-List ausgekettet wurde.

80

7 Embedded Speicherkonzepte, spezielle Muster

Mit deallocate wird ein zur¨ uckgegebenes Element wieder in die FreeListe eingekettet.

CObjectPool::CObjectPool(size_t numOfObjects, size_t theObjectSize) : mObjectSize( MAKE_ALIGNMENT_SIZE(theObjectSize)), //Startadr. festlegen + Speicher auf Heap allokieren mStartAdr (NEW_DYNAMIC_ARRAY(char,numOfObjects*mObjectSize) { //eig. Fehlerbehandlung ASSERTION(numOfObjects >0 && theObjectSize >0); //Bestimmung Endadresse mEndAdr = mStartAdr + (numOfObjects*mObjectSize) - 1; //Einh¨ angen in die Liste mFreeListPtr = reinterpret_cast<Entry *> (mStartAdr); char * objPtr = mStartAdr; Entry * tmpPtr = mFreeListPtr; for (int i=0;i < numOfObjects-1; i++) //durchhangeln + einh¨ angen { objPtr += mObjectSize; //Adresse n¨ achsten Objekts tmpPtr->nextPtr = reinterpret_cast<Entry *> (objPtr); tmpPtr = tmpPtr->nextPtr; //tmpPtr aufs n¨ achste Element } tmpPtr->nextPtr = NULLPTR; //letzte Element hat keinen Nachfolger } void* CObjectPool::allocate(size_t memSize)//Dummy,durch Ctor klar { ASSERTION(memSize == mObjectSize); (void) (memSize); //um Warnung zu eliminieren void * objPtr = NULLPTR; //Hilfszeiger initialisieren if (mFreeListPtr != NULLPTR) //ist die Liste nicht leer? { objPtr = mFreeListPtr; //entnimmt das erste Element mFreeListPtr=mFreeListPtr->nextPtr; //zeigt auf n¨ achstes Element } else // voll,Objekt erzeugen { objPtr = NEW_DYNAMIC_ARRAY(char, mObjectSize); } return objPtr; } void CObjectPool::deallocate(void * memPtr) { //gibt Block,auf den memPtr zeigt frei if ((memPtr < mStartAdr)||(memPtr > mEndAdr)) //war der letzte Block {DELETE_DYNAMIC_ARRAY(memPtr);} //also ggf.Pool freigeben else {

7.3 Allokator

81

Entry* tmp = reinterpret_cast<Entry*>(memPtr); tmp->nextPtr = mFreeListPtr; //Block vor FreeList einh¨ angen mFreeListPtr = tmp; } } Listing 7-18. Implementierung der Klasse CObjectPool

Ein m¨oglicher Aufruf zur Erzeugung des Pools sEventpool w¨are in der Initialisierungsphase: //Erzeug.eines glob. Ev.-Pools CObjectPool sEventpool(CEvent::POOLSIZE, sizeof (CEvent)); .... int main() { ... ...

Eine neue Nachricht/Event wird wie folgt erzeugt und per Placement-new typisiert: CEvent * testevent = FW_NEW_DEFAULT(sEventPool, CEvent);

Man k¨onnte die Erzeugung und R¨ uckgabe des Speichers auch als Methoden des Event-Objekts selbst implementieren. Wie in der obigen Implementierung demonstriert, k¨onnen solche Pools sehr vorteilhaft als verkettete Liste mit Embedded Pointers implementiert werden. Die free-List mit freien Bl¨ ocken kann in den Bl¨ocken selbst die Verkettung f¨ uhren, so dass keinerlei Speicher-Overhead f¨ ur die Verkettung entsteht. Der Vorteil dieses Verfahrens ist, dass Objekte recycled werden k¨onnen. Obwohl viele kleine Objekte erzeugt und zerst¨ort werden, ist die Gefahr einer internen Fragmentierung gering. Man gewinnt im Vergleich zur Allokation auf dem Heap auch Geschwindigkeit, da Objekte ohne großen Verwaltungsaufwand entnommen und zur¨ uckgegeben werden. Die Heap-Verwaltung benutzt z.B. Best-Fit- oder First-Fit-Strategien bei der Vergabe von Speicher. Sie versucht auch, benachbarten Speicher zusammen zu verschmelzen, was Zeit kostet. In einem Objekt-Pool hat jedes Objekt aus dem Pool eine feste Gr¨oße, so dass Information u oße nicht mitgespeichert werden muss (was ¨ber ihre Gr¨ u are). ¨ber den Heap aber notwendig w¨ Der Nachteil ist die Gr¨ oße des Pools. Wenn der Pool zu klein gew¨ahlt wird, dann verh¨alt er sich fast wie dynamische Speicherverwaltung, siehe n¨achster Abschnitt. Wird er zu groß gew¨ ahlt, dann hat er einen Overhead, wenn die Objekte selten ben¨ otigt werden.

82

7 Embedded Speicherkonzepte, spezielle Muster

Wird die Grenze des vereinbarten Speichers erreicht, kann der Speicher zur Not dynamisch erweitert werden. Dies ist aber mit Vorsicht zu verwenden, da es alle Nachteile mit sich bringt, die wir bisher erw¨ahnt hatten. Wenn man die im Kapitel Pool-Allokation vorgestellte allocate-Methode betrachtet, kann man erkennen, dass f¨ ur den Fall der aufgebrauchten ObjektListe (free-list)¨ uber das Makro NEW DYNAMIC ARRAY neuer Speicher vom Heap geholt wird. Dort ist als Gr¨ oße des neuen Blocks die Gr¨oße eines Objekts angegeben; ob dies sinnvoll ist, h¨ angt davon ab, wie oft eine solche Puffer¨ uberschreitung auftreten kann. Meistens sind Inkremente von einigen 100 Bl¨ocken sinnvoll.

7.4 Datencontainer Es gibt in der Embedded Umgebung ein Muster, das Gemeinsamkeiten mit Object-Pools hat, es ist der Datencontainer, eine Art Mini-Datenbank f¨ ur Embedded Systeme. Im Unterschied zu diesem Muster gibt der Datencontainer nicht Speicher an andere Objekte, sondern instantiiert ein Objekt, das selbst Speicher bereitstellt, um andere Objekte darin zu halten (oft wird das anschauliche Beispiel eines Einkaufwagens genannt). Die in Kapitel 16 zur Kommunikation verwendeten Queues, FIFOs und Buffer sind Varianten dieses Musters. Auch mit Strategien wie Speicherlimit (siehe weiter unten) hat der Datencontainer Gemeinsamkeiten, da er begrenzten, zur Kompilierzeit/Linkzeit bekannten Speicherplatz zur Verf¨ ugung stellt. Der Datencontainer ist typisiert und stellt eine Ablaufumgebung f¨ ur andere Objekte zur Verf¨ ugung. Dies k¨ onnen Zugriffsfunktionen f¨ ur die einzelnen gespeicherten Objekte sein oder Iteratoren, mit denen die Elemente nacheinander angesprochen werden k¨ onnen. Werden Container zur Kommunikation zwischen Komponenten verwendet, sorgen sie f¨ ur die eventuell erforderliche Persistenz, womit die Erhaltung wichtiger Daten u ¨ber das Abschalten hinaus gemeint ist. Auch die Kommunikation zur anderen Komponente (Messaging) kann in den Zugriffsfunktionen des Containers verborgen werden. Um allgemein g¨ ultige L¨ osungen bereitzustellen, werden Container als abstrakte Basisklasse oder als Template-Klasse definiert. Die abgeleiteten Klassenobjekte sind dann innerhalb ihrer Komponente global realisiert oder sogar innerhalb des gesamten Programms global in einem gemeinsamen SharedMemory implementiert. In einem sp¨ateren Kapitel im Teil II werden wir eine spezielle Implementierung f¨ ur Datencontainer vorstellen.

7.5 Gemeinsam benutzte Objekte (Shared-Objects) Es gibt Situationen, in denen Programm-Module identische Informationen benutzen und daf¨ ur Kopien anlegen. Dies passiert bei getrennt kompilierten

7.6 Referenzz¨ ahler (reference counting)

83

Modulen, die gleiche Bibliotheken benutzen oder z.B. bei der Nutzung von Fonts und grafischen Widgets. Durch Referenzen auf einmal angelegte Objekte k¨onnen diese gemeinsam benutzt werden. Die Gefahr dabei ist allerdings, dass beim Deallokieren des Objekts durch einen Nutzer vagabundierende Referenzen oder Zeiger f¨ ur die anderen Nutzer entstehen. Ein solcher Fehler bringt nach Murphy an einer ganz anderen Stelle zu einem ganz anderen Zeitpunkt die gesamte Software zum Absturz. Auch Object-Pools k¨ onnen im gewissen Sinn gemeinsam benutzte Objekte sein. Allerdings werden sie normalerweise nicht deallokiert. Generiert man aus diesen Pools heraus aber Events, die durch das System verschickt werden, so entsteht sehr wohl die Gefahr des L¨ oschens, obwohl andere noch die Referenz nutzen. Entweder man entwirft das System so, dass immer klar ist, wer die Verantwortung f¨ ur das Objekt/Event hat und es l¨ oschen darf. Zum Beispiel geht die Verantwortung von der Event-Quelle u ¨ber an den Transport-Kanal und schließlich an die Event-Senke, die das Event konsumiert und an den Pool zur¨ uckgibt. Alternativ installiert man den im Folgenden beschriebenen ReferenzCounter, d.h., man nutzt ein Objekt u ¨ber Referenzen mehrmals und z¨ahlt mit. Die dritte M¨ oglichkeit ist Garbage-Collection, die im u ¨bern¨achsten Abschnitt besprochen wird.

7.6 Referenzz¨ ahler (reference counting) Immer wenn ein Verweis oder ein Zeiger auf ein gemeinsames Objekt anlegt wird, wird im Objekt ein Z¨ ahler hochgez¨ ahlt. Entsprechend wird beim L¨oschen des Verweises der Z¨ ahler dekrementiert. Dies erfordert normalerweise hohe Disziplin bei den Implementierern oder wird in einer Kapselung automatisiert. Eine gute und ausf¨ uhrliche Beschreibung daf¨ ur findet sich in [Mey]. Mit dem Konzept Referenzz¨ ahler ist das Konzept Smart-Pointer verwandt. Hier wird f¨ ur ein automatisches delete gesorgt, z.B. bei der Zuweisung von Pointern. Oft werden Referenzz¨ ahler und Smart-Pointer auch zusammen implementiert. Die C++-Standardbibliothek hat eine vordefinierte Klasse f¨ ur smarte Zeiger namens auto ptr. Durch Zuweisung bzw. Kopierkonstruktor wird aber der Zeiger auf ein anderes Objekt u ¨bertragen: auto_ptr aPtr(new A); auto_ptr otherPtr(aPtr); aPtr = otherPtr;

//Kopierkonstruktor //aPtr zeigt nicht mehr auf das Objekt! //nun hat aPtr wieder Zeiger,otherPtr nicht mehr

Kopierkonstruktor und Zuweisungsoperator von auto ptr sind public. Bei falscher Verwendung (etwa Wert¨ ubergabe) wird der Zeiger endg¨ ultig zerst¨ort!

84

7 Embedded Speicherkonzepte, spezielle Muster

void problematisch(auto_ptr aPtr) //Zeigerbesitz wird ¨ ubertragen { ... //destruktor zerst¨ ort aPtr und damit den Zeiger }

Generell sollte man Zeiger vermeiden und mit Referenz arbeiten. Dort, wo ein Zeiger nicht verzichtbar ist, sollte er mithilfe von Smart-Pointer sicher gemacht werden. Eine Implementierung von Smart-Pointer ist z.B.

template class TSmartPointer { public: explicit TSmartPointer(T* p = 0): mPtr(p){} virtual ~TSmartPointer(); T* operator->() const; T& operator*() const; TSmartPointer& operator=(T* p); operator bool() const; void freeObject(); private: //to avoid misuse TSmartPointer(const TSmartPointer&); TSmartPointer& operator=(const TSmartPointer&); T* mPtr; }; template inline TSmartPointer::~TSmartPointer() { ASSERTION(mPtr == 0); freeObject(); } template inline T* TSmartPointer::operator->() const { ASSERTION(mPtr != 0); return mPtr; } template inline T& TSmartPointer::operator*() const { ASSERTION(mPtr != 0); return *mPtr; }

7.8 Die Captain-Oates Strategie

85

template inline TSmartPointer& TSmartPointer::operator=(T* p) { ASSERTION(mPtr == 0); mPtr = p; return *this; } template inline TSmartPointer::operator bool() const { return (mPtr != 0); } template inline void TSmartPointer::freeObject() { delete mPtr; mPtr = 0; } Listing 7-19. Eigene Smart-Pointer-Klasse

Nun k¨onnen wir dieses Konzept um die F¨ahigkeit eines Referenzz¨ahlers erg¨anzen, falls das Objekt der Betrachtung eine gemeinsam benutzte Ressource ist, siehe [Mey].

7.7 Garbage-Collection Statt pro Objekt mitzuf¨ uhren, wer es benutzt, kann ein M¨ ullsammler“ ” (Garbage-Collector) zu ausgewiesenen Zeiten alle dynamisch angelegten Objekte u ufen, ob sie noch gebraucht werden. Daf¨ ur m¨ ussen alle Zeiger und ¨berpr¨ Referenzen nachverfolgt werden. Anschließend werden die noch gebrauchten Speicherobjekte zusammengerutscht oder in einen neuen Bereich umkopiert. Ersichtlich braucht dies Zeit und kann nicht w¨ahrend des normalen Betriebs durchgef¨ uhrt werden.

7.8 Die Captain-Oates Strategie Was kann man tun, wenn der Speicher doch nicht ausreicht? Nach einem Teilnehmer der S¨ udpol-Expedition von Robert Scott ist eine Methode benannt, in der nach und nach unn¨otige oder weniger wichtige Module freigegeben werden. Captain Oates hatte sich als Teilnehmer der Expedition selbst geopfert, als die mitgenommenen Ressourcen knapp wurden.

86

7 Embedded Speicherkonzepte, spezielle Muster

Auf unsere Umgebung angewendet, kann dies heißen, optionale Applikationen abzuschalten, Adress- und Telefonb¨ ucher freizugeben und Sender- und CD-Listen zu k¨ urzen. Dies ist allerdings in kundenrelevanten Embedded Systemen nicht einfach zu realisieren. Funktioniert z.B: ohne ersichtlichen Grund pl¨otzlich das Adressbuch des Telefons nicht mehr, kommt es zu Beanstandungen. Die L¨osung in diesem Beispiel w¨ are, im Falle knappen Speichers nicht das ganze Adressbuch von der SIM-Card in den Hauptspeicher zu kopieren, sondern nur den aktuell ben¨otigten Ausschnitt. Auch im knappen Fall dauert auf diese Weise eine Auswahl aus dem Adressbuch nur l¨ anger und funktioniert noch.

7.9 Speicherlimit Kann dynamische Speicherallokation nicht prinzipiell verboten werden, so k¨onnen Speicherlimits gegen Speicher¨ uberl¨ aufe eingef¨ uhrt werden. Speicherlimits k¨onnen gut mit der vorgenannten Captain-Oates-Strategie kombiniert werden. Das Prinzip ist, dass Module oder Komponenten begrenzten Speicher bekommen, so dass eine Reaktion auf Teil-Speicherknappheit m¨oglich wird, bevor der Speicher der Applikation insgesamt schon an die Grenzen l¨auft und eine Reaktion kaum noch m¨ oglich ist. Jede Komponente oder Modul bekommt bei der Generierung eine feste Heap-Speichergr¨ oße, die u ¨berwacht wird und nicht u ¨berschritten werden kann. Dies kann durch das Betriebssystem bewerkstelligt werden oder durch eigene Allokationen. Die verwendete genauere Definition einer Komponente folgt sp¨ater, im Moment reicht es aus, darunter einen Prozess mit seinen vier privaten Speichersegmenten und einem eigenen Registersatz zu verstehen. Auch in einem sp¨ ater noch erkl¨ arten Thread ist die Implementierung einer Begrenzung einer Komponente durch Anlegen eines eigenen Heap m¨oglich (local oder temporary Heap). Die selbst implementierte Allokation aus einem vordefinierten begrenzten Pufferspeicher ist eine weitere M¨ oglichkeit der Limitierung des Heap. ¨ Eine andere Variante kann durch Uberladen des Standard new-Operators 1 realisiert werden . Die Speichergr¨ oßen werden experimentell w¨ahrend der Ent1

Achtung: Es werden global alle new- und delete-Operatoren u ¨berladen, das be¨ trifft dann auch gebundene Libraries. Vollst¨ andig wird das Uberladen, wenn man die Aufrufe f¨ ur Throw und NoThrow ber¨ ucksichtigt. In ¨ alteren Implementierungen des new-Operators wurde ein Null-Zeiger zur¨ uckgegeben, wenn die Allokation fehlschlug. Neue Implementierungen werfen“ eine Exception, will man die ” alte Version erzwingen, z.B. weil man Exceptions im Framework verbietet, so muss man als Parameter nothrow“ angeben. Man kann auch von Anfang an nur ” Libraries einbinden, die keine Exceptions benutzen (z.B. Option Dinkum w/o Exceptions w¨ ahlen).

7.11 Fazit

87

¨ wicklung bestimmt, das Uberschreiten der Grenzen muss durch eigene Implementierungen zu einem sanften“ Ausstieg f¨ uhren, in dem zum Beispiel ” Teilfunktionen nicht mehr zur Verf¨ ugung stehen (Partial Failure).

7.10 Partieller Fehler (Partial Failure) Ist der verf¨ ugbare Speicher vollst¨ andig vergeben, so bleibt nur, einen Fehler anzuzeigen und ggf. mit der Captain-Oates-Strategie weiterzumachen. In jedem Fall muss bei fehlgeschlagenen Speicheranforderungen eine implementierte Strategie greifen, die Assertions m¨ ussen ausprogrammiert sein, so dass das System stabil bleibt und zumindest das Problem noch anzeigen kann. Schwierig kann dabei werden, dass zumindest die Standard-Anzeigeroutinen selbst ebenfalls dynamisch Speicher beanspruchen. Ein weiterer Grund f¨ ur eigene Ausgaben. Sind solche Speicherassertions zu beobachten, folgt der Schritt zur¨ uck in ¨ die Entwicklung und die generelle Uberpr¨ ufung der Speicherplanung. Oft k¨onnen Konstanten, Fonts und Texte in einen Read-Only Bereich verlegt werden oder die Grafik kann u ¨berarbeitet werden, indem Bitmaps durch Konstruktions-Algorithmen ersetzt werden. Auch die Suche nach nie angesprungenem Code (dead Code) ist normalerweise nach einiger Entwicklung erfolgreich. Statische Komplexit¨ atsanalysen, z.B. mit McCabe-Tools, k¨onnen Programmteile aufzeigen, die zu komplex und zu aufw¨andig programmiert sind. Meistens spart eine bessere L¨ osung auch Speicher ein.

7.11 Fazit Es wurden einige Patterns und Regeln f¨ ur Embedded Systeme vorgestellt. Bei konsequenter Embedded Programmierung sind weder dynamische Speicherallokation vom normalen Heap, Exceptions noch Vektoren der Standard Library erlaubt. Nat¨ urlich gibt es auch Gr¨ unde, dynamische Standard-Allokationen zu erlauben. Werden z.B. nur beim Start der Applikation dynamisch Speicherbl¨ocke allokiert und nie wieder freigegeben, gibt es keine Gefahr der Fragmentierung. Auch Vektoren k¨ onnen gelegentlich sinnvolle Verwendung finden. Die Erfahrung zeigt jedoch, dass teilweise ge¨ offnete T¨ uren nach einer Zeit in großen Projekten dazu f¨ uhren, dass zu viele Entwickler hindurch schl¨ upfen und die Kann-Regeln sowie die Gr¨ unde daf¨ ur verloren gehen. Am Ende bew¨ahrt haben sich dann doch nur die kategorischen Verbote. Eine eigene Fehlerbehandlung bei fehlgeschlagener Speicherallokation ist erforderlich, genauso wie generell ein eigenes Assertion-System und eine eigene Thread- und Ressourcen-sichere Ausgabe. Bei konsequenter Verwendung von Makros haben wir die M¨oglichkeit, Kontrollmechanismen ohne großen Aufwand gezielt einzubauen.

8 Prozesse und POSIX-Threads

Fr¨ uhere kleine“ Embedded Betriebssysteme wie VxWorks oder CMX waren ” Multithread-Systeme, passend zu kleinen“ Prozessoren wie dem SH3 von ” Hitachi. Multithread heißt, dass alle Jobs im gleichen Adressraum ablaufen und die Threads gegenseitig alle Adressen kennen. Das heißt auch, dass die Prozessoren keine MMU (Memory Management Unit) ben¨otigen, mit deren Hilfe man die Speicherbereiche logisch voneinander trennen k¨onnte. Zwar besitzen Threads normalerweise jeweils ein eigenes Stack-Segment, jedoch sind Daten-, Heap und Code-Segmente gemeinsam. Daher k¨onnen z.B. ohne weiteres Daten anderer Threads direkt aufgerufen werden, auch Callbacks sind m¨ oglich, da der Speicher nicht abgeschottet ist. Nachteilig daran ist vor allem, dass Probleme einzelner Threads oft das ganze System zum Absturz bringen, auch Debugger und Tracer st¨ urzen mit ab und k¨onnen so keine Auskunft mehr u ¨ber die Ursachen des Problems geben. Multitask- oder Multiprozess-Systeme dagegen haben privaten Speicher f¨ ur Datensegment, Heap und Stack, durch den Einsatz von m¨achtigeren MMUs auf gr¨oßeren Prozessoren ist es deshalb m¨oglich, fremde Datenzugriffe zu unterbinden. Dementsprechend sind nach einem Absturz eines Prozesses die anderen Prozesse noch aktiv und k¨ onnen beim Debuggen helfen. Beide Ans¨atze erlauben schon die Nebenl¨ aufigkeit, d.h., mehrere Aufgaben k¨onnen quasi parallel bearbeitet werden. Dies stellt hohe Anforderungen an die Auffassungsgabe der Systemprogrammierer. Sie m¨ ussen bei allen gemeinsam genutzten Ressourcen konkurrierende Zugriffe bedenken. Erfahrungsgem¨ aß ist die Gefahr in der Multithread-Programmierung besonders hoch. Es ist bei Threads m¨ oglich, dass durch nebenl¨aufige Aufrufe quasi parallel mehrere Program-Counter durch dasselbe Modul mit denselben Daten laufen. Dies ist der Mehrzahl der Entwickler nur abstrakt bekannt, weshalb sie in der Implementierung die so genannte Threadsafety regelm¨aßig vergessen. Da der Fehler nur sehr statistisch und selten auftritt, gibt es einige Erfahrung

90

8 Prozesse und POSIX-Threads

mit dieser Art sp¨ at auftretender Fehler in bereits freigegebener und verkaufter Produkt-SW.

8.1 Prozesse Prozesse bilden einzelne lauff¨ ahige Software-Einheiten, die prinzipiell einen virtuellen Rechner mit Speicher und CPU nachbilden. Moderne Betriebssysteme erlauben die gleichzeitige Ausf¨ uhrung von mehreren dieser Einheiten, die Zuteilung der tats¨ achlichen Hardware zu jeweils einem Prozess ist Aufgabe des Betriebssystems. Ein Prozess (Task) ist eine dynamische SW-Einheit, die vom Betriebssystem gescheduled“ und kontrolliert wird. Der Prozess besteht mindestens aus ” einem executable“, dem Main-Thread, einem laufenden Programm mit Wer” ten, Zust¨anden und Ressourcen, die vom OS zugewiesen werden. So werden auch die bekannten Speichersegmente vom Betriebssystem f¨ ur den Prozess bereitgestellt. Der Speicher als zugewiesene Ressource steht dem Prozess exklusiv und privat zur Verf¨ ugung, andere Prozesse haben normalerweise keinen Zugriff auf denselben. Man spricht von Ressourcenschutz. Zeiger oder Referenzzugriffe u ¨ber Prozessgrenzen hinweg funktionieren also in der Regel nicht. Mit Einf¨ uhrung von Shared-Memory werden wir noch eine Ausnahme kennenlernen. 8.1.1 Der Lebenszyklus eines Prozesses Ein Prozess durchl¨ auft vier Phasen: Erzeugen Eine Prozesserzeugung besteht aus der Zuteilung einer Prozess-ID f¨ ur den neuen Prozess und dem Bereitstellen der Umgebung des neuen Prozesses. Die meisten dieser Informationen werden von dem Vaterprozess an den neuen Prozess vererbt. Laden Das Laden eines Prozesses wird durch einen Loader-Thread im ProzessManager erledigt. Der Code zum Laden eines Prozesses liegt im Prozess-Manager, er l¨auft jedoch als ein eigener Thread unter der Prozess-ID des neuen Prozesses. Das erm¨oglicht dem Prozess-Manager weitere Anfragen zu verarbeiten, w¨ahrend andere Programme geladen werden.

8.1 Prozesse

91

Ausf¨ uhren Sobald der Programmcode geladen ist, ist der Prozess zur Ausf¨ uhrung bereit und kann CPU-Zeit zugeteilt bekommen. Er konkurriert dabei mit allen anderen Prozessen, auch mit dem Vater. Das Ende eines Vaterprozesses hat nicht automatisch das Ende seines Sohnprozesses zur Folge. Beenden Ein Prozess kann auf zwei Arten beendet werden: •

Der Prozess ruft exit auf, explizit oder als Standardaktion, wenn er von main zur¨ uckkehrt. • Es wird ein Signal an den Prozess gesendet, das den Prozess beendet. Die Prozessbeendung durchl¨ auft zwei Phasen: •

Ein Beendigungs-Thread l¨ auft im Prozess-Manager. Dieser Code liegt im Prozess-Manager, aber er l¨ auft als Thread mit der Prozess-ID des zu beendenden Prozesses. Der Thread schließt alle ge¨offneten Datei-Deskriptoren und gibt die folgenden Ressourcen frei: Alle virtuellen Verbindungen des Prozesses, dem Prozess zugeordneter Speicher, alle symbolischen Namen, alle Hauptger¨ atenummern (nur I/O Manager), alle Interrupt-Handler, alle Proxies, alle Timer. • Nach der Beendigung dieses Threads wird der Vaterprozess dar¨ uber infor¨ miert, dass der Sohnprozess beendet wurde. Uber join z.B. kann er darauf warten.

8.1.2 Prozesszust¨ ande Ein Prozess befindet sich normalerweise in einem der folgenden Zust¨ande: • READY - Der Prozess kann die CPU nutzen. • BLOCKED - Der Prozess befindet sich in einem blockierenden Zustand und wartet auf Freigabe. • HELD - Der Prozess hat ein SIGSTOP-Signal erhalten und wartet auf ein SIGCONT-Signal oder auf Prozesstermination u ¨ber ein Signal. • WAIT - Der Prozess wartet auf Statusinformationen von einem oder mehreren seiner Sohnprozesse. • DEAD - Ein Zombie-Prozess.

92

8 Prozesse und POSIX-Threads

8.1.3 Zombies Bei terminierenden Prozessen kann es zu Problemen kommen: • Ein Vaterprozess terminiert mit exit, w¨ ahrend ein oder mehrere seiner Sohnprozesse noch laufen. • Ein Sohnprozess ruft exit auf, wenn sein Vaterprozess noch kein wait aufgerufen hat. Im ersten Fall beendet der Vaterprozess ganz normal. Die Sohnprozesse und eventuell auftretende Zombies werden dann vom init-Prozess des Systems u uhrt. ¨bernommen und zu Ende gef¨ Bei dem zweiten Fall wird aus dem Sohnprozess ein Zombie, dieser bindet außer einem Eintrag in der Prozess-Tabelle des Kernels keine weiteren Betriebsmittel mehr an sich. Der Zombie wird endg¨ ultig beendet, wenn der Vaterprozess sp¨ater dann noch ein wait aufruft. 8.1.4 Bestandteile Prozesse bestehen aus mehreren Komponenten, die jeweils einen Teil des physikalischen Rechners abstrahieren. Die einzelnen Komponenten sind im Folgenden erl¨autert. Virtueller Adressraum Ein Adressraum ist die abstrakte Repr¨ asentation eines Speichers. Ein solcher virtueller Adressraum ist unendlich groß und die einzelnen Speicherzellen sind durchgehend nummeriert (linearer Adressraum). Threads Ein Thread, auch Aktivit¨ atstr¨ ager oder Laufzeitfaden genannt, ist die abstrakte Repr¨asentation eines Prozessors. Je nach Laufzeitmodell ist es m¨oglich, mehrere dieser virtuellen Prozessoren innerhalb des Adressraums eines Prozesses zu erzeugen und gleichzeitig ablaufen zu lassen. Der erste Thread, der in einem neu erzeugten Prozess l¨ auft, wird Main-Thread genannt. Programm Der Programmcode steuert den virtuellen Rechner. Je nachdem, welche Methode zur Erzeugung eines Prozesses oder Threads benutzt wurde, k¨onnen mehrere Threads mit demselben Programmcode arbeiten oder mit anderen Codefragmenten u ¨berschrieben werden. Prozessmanager Der Prozessmanager ist ein eigener OS-Prozess und erzeugt neue Prozesse. Er arbeitet daf¨ ur beispielsweise unter QNX eng mit dem Micro-Kernel zusammen. Er verwaltet außerdem die meisten Prozess-Ressourcen. Diese Dienste werden alle u ¨ber Nachrichten angeboten. Will z.B. ein laufender Prozess einen

8.1 Prozesse

93

neuen Prozess erzeugen, macht er dies, indem er eine Nachricht an das OS verschickt, welche die Details des neu zu erzeugenden Prozesses beinhaltet. Da Nachrichten netzwerkweit funktionieren, kann eine Nachricht zum Erzeugen eines neuen Prozesses auch an den Prozess-Manager eines entfernten Knoten versendet werden. QNX z.B. bietet drei Funktionen an f¨ ur die Prozesserzeugung fork, exec und spawn. Alle drei Funktionen sind in POSIX definiert. 8.1.5 Prozess mit fork erzeugen Durch die Funktion fork wird ein neuer Prozess erzeugt, indem der laufende, so genannte Vaterprozess vollst¨ andig kopiert und dann in zwei laufende Prozesse verzweigt wird. Da Vater- und Sohn-Prozess (die Kopie) anhand des Funktionsergebnisses unterschieden werden k¨ onnen, kann bei entsprechender Programmanweisung in eigene Programme verzweigt werden. Der neue Prozess teilt den gleichen Code mit dem aufrufenden Prozess und erbt eine Kopie aller Prozessdaten des rufenden Prozesses. Der Systemaufruf fork ist eine der wichtigsten Funktionen u ¨berhaupt in einem Unix System. Alle Prozesse werden durch diesen einen Aufruf erzeugt, mit Ausnahme des init Prozesses mit der Prozess-ID 1. Dieser UrProzess wird beim Starten des Systems fest in die Prozesstabelle eingetragen. Aus diesem gehen dann alle weiteren Prozesse mit fork hervor. Vater- und Sohn-Prozesse unterscheiden sich lediglich in zwei Merkmalen, der ProzessIdentifikation PID und der PPID, der PID des Vaters. Viele weitere Details k¨ onnen in [Stev] nachgelesen werden. Im nachfolgenden Beispiel wird aus einem Prozess ein weiterer Prozess per fork ge¨offnet. Die Syntax von fork lautet:

pid_t fork() //-1 falls Fehler, //0 im Sohnprozess, //sonst ProzessID des Sohnes Listing 8-1. Syntax von fork

Durch die Abfrage kann der laufende Prozess ermitteln, ob er der Vateroder der Sohn-Prozess ist. Spannend an unten stehendem Programm ist, dass nicht vorhersagbar ist, wer zuerst seine Ausgabe gibt, der Vater- oder ein Sohn-Prozess, es wird von Mal zu Mal unterschiedlich sein.

int main(void) { int context;

//Dummy Kontext, kommt sp¨ ater

94

8 Prozesse und POSIX-Threads ... //Dinge initialisieren if (fork() == 0) { sOwnCout<<"Adresse von context-Kind" << &context << endl; ...; //ab hier l¨ auft erster KindProzess } else if (fork() == 0) { sOwnCout<< "Adresse von context-Kind" << &context << endl; ...; //ab hier l¨ auft zweiter KindProzess } else { sOwnCout<< "Adresse von context-Vater" << &context << endl; ...; //ab hier l¨ auft Vaterprozess weiter }

} Listing 8-2. Beispiel f¨ ur Prozess-Erzeugung mit fork

Die Feststellung, dass der gesamte Speicher kopiert w¨ urde, muss ein wenig pr¨azisiert werden: Es gibt das Prinzip copy on write“, das bedeutet, zun¨achst ” teilen sich nach einem fork die Prozesse dieselben Speicherseiten in der MMU. Erst wenn in einem Segment geschrieben werden soll, legt das Betriebssystem mit der MMU einen neuen Speicher an und kopiert die alten Inhalte hinein. Dies bedeutet, dass das Code-Segment f¨ ur alle normalen“ geforkten ” Prozesse gleich bleibt, die nicht das Code-Segment ver¨andern. Solche F¨alle gibt es auch, wenn n¨ amlich nach einem fork ein execKommando aufgerufen wird, um ein Executable an Stelle des alten Programms zu laden und auszuf¨ uhren. Daten-, Stack- und Heap-Segment werden allerdings f¨ ur jeden Prozess neu angelegt und kopiert, sp¨ atestens beim ersten Schreibversuch eines der Prozesse. Fr¨ uhere Systeme nutzten das Prinzip copy on write“ nicht, daf¨ ur gab es ” dann eine separate Funktion vfork. Es ist bemerkenswert und wird sp¨ ater noch intensiv genutzt, dass man mit fork auf einfache und effiziente Weise Code-Sharing f¨ ur alle Prozesse betreibt, ¨ ohne daf¨ ur DLLs oder Ahnliches zu brauchen. 8.1.6 Prozess mit exec erzeugen Die exec Funktion ist ein Systemaufruf und ersetzt das Image des aufrufenden Prozesses durch ein neues Image. Aus einem erfolgreichen exec-Aufruf gibt es keine R¨ uckkehr, da das neue Prozessimage das Image des rufenden Prozesses im Speicher ersetzt. Hierbei wird der Adressraum mit den Daten eines neuen Programms u ¨berschrieben, die Daten des alten Programms gehen dabei verloren.

8.1 Prozesse

95

Abbildung 8.1. Speicherlayout nach fork

Der Aufruf von exec erzeugt keinen neuen Prozess, sondern ein neues Programm im alten Prozess. Es gilt als allgemeine Praxis in POSIX-Systemen, einen neuen Prozess zu kreieren, indem der aufrufende Prozess sich selbst durch fork dupliziert und der Sohnprozess dann seinerseits exec aufruft, um selbst durch einen neuen Prozess ersetzt zu werden. Im folgenden Beispiel werden zwei Programme verwendet, um auch die Wirkungsweise des exec Systemaufrufs verfolgen zu k¨onnen. Der Vaterprozess generiert einen Sohnprozess. Der Sohnprozess, der anschließend an der gleichen Codestelle fortf¨ ahrt, u ¨berlagert den Code des zweiten Programms mit exec. Der Vaterprozess kann sich dann entweder beenden oder durch den Aufruf von wait auf das Ende des von ihm erzeugten Sohnprozesses warten.

bool sWarten=true; int main() { pid_t pid;

//Warten auf Sohn

96

8 Prozesse und POSIX-Threads

pid = fork(); //Prozess duplizieren switch(pid) { case -1: sOwnCout << "Fehler bei fork" << endl; break; case 0 : sohn("Sohnprozess"); break; default: vater(); break; } return 0; }//end main void vater() { int sohnPID; //ProzessID des Sohnprozesses int status; //Exit Status d. Sohnprozesses sOwnCout << "Vater: eigene Prozess ID: " << getpid() << endl; if(sWarten) //Evtl.auf Ende d. Sohnes warten sOwnCout << "Vater: Warte auf Ende des Sohnprozesses ... " << endl; if ((sohnPID = wait(&status)) == ERROR) { exit(1); } sOwnCout << "Vater:Sohnprozess << sohnPID << "beendet, Status" << status << endl; } void sohn(char* progname) { sOwnCout << "Sohn: eigene Prozess ID: " << getpid() << endl; sOwnCout << "Sohn: Vater Prozess ID: " << getppid() << endl; sOwnCout << "Sohn: Aufruf von " << progname << " mit exec " << endl; execlp(progname,progname,"Sohn","eins","1",NULL); } Listing 8-3. Aufruf von execlp

In dem Vaterprozess findet die Prozessduplikation mit fork und die anschließende Funktionsverzweigung statt. Tritt ein Fehler bei fork auf, wird eine Fehlermeldung ausgegeben. Diese Vorgehensweise mit fork und exec bietet die M¨oglichkeit, neue Prozesse geschachtelt zu erzeugen und damit gewissermaßen Prozesshierarchien zu bilden. Die Unix-Shell benutzt genau denselben Mechanismus, wenn sie einen neuen Prozess startet. Die Parameter f¨ ur exec, in unserem Fall -lp, k¨ onnen z.B. in [Gray] nachgeschlagen werden. 8.1.7 Prozess mit spawn erzeugen Die spawn-Funktion erzeugt einen neuen Prozess als Sohnprozess des aufrufenden Prozesses. Sie stellt ein integriertes fork()-then-exec()“ dar, was ” bedeutet, dass die Erzeugung neuer Prozesse schneller und effizienter durchgef¨ uhrt werden kann. Im Gegensatz zu fork und exec, welche nur auf dem

8.1 Prozesse

97

gleichen Knoten wie der aufrufende Prozess operieren k¨onnen, kann die spawnFunktion Prozesse auf jedem Knoten im Netzwerk kreieren. Allerdings verliert man bei der Verwendung von spawn sehr viel an Flexibilit¨at, da dann fork und exec direkt gekoppelt sind. Es gibt spawn-Anwendungen, die ohne MMU auskommen. 8.1.8 Prozessvererbung Wenn ein Prozess durch eine der gerade beschriebenen Funktionen erzeugt wird, erbt er vieles seiner Umgebung von seinem Vaterprozess. In der unten stehenden Tabelle ist dies zusammengefasst.

Tabelle 8.1. Vererbung *optional: Aufrufende kann ausw¨ ahlen [QNX doc] Vererbtes Objekt Prozess-ID Ge¨ offnete Dateien Verriegelungen (file locks) Anstehende Signale Signal-Masken Ignorierte Signale Signalhandler Umgebungsvariablen Session ID Prozessgruppe Echte UID, GID Effektive UID, GID Gegenw¨ artiges Arbeitsverzeichnis Dateierzeugungsmaske Priorit¨ at Scheduler-Methode (scheduler policy) Virtuelle Verbindung Symbolische Namen Echtzeit-Timer

fork() nein ja nein nein ja ja ja ja ja ja ja ja ja ja ja ja nein nein nein

exec() ja optional* ja ja optional optional nein optional ja ja ja optional optional ja optional optional nein nein nein

spawn() nein optional nein nein optional optional nein optional optional optional ja optional optional ja optional optional nein nein nein

8.1.9 Prozessattribute F¨ ur Prozesse geht man davon aus, dass die MMU des Systems ihnen virtuell unbeschr¨ankt Stack und Heap zuteilen k¨ onnen. Einige wenige Attribute lassen sich auch f¨ ur Prozesse setzen Die beiden Wichtigsten sind die Priorit¨ at des Prozesses und die ID des Prozesses. Jeder Prozess besitzt eine eindeutige ID-Kennung, die mit getpid

98

8 Prozesse und POSIX-Threads

herausgefunden werden kann. Mit getppid kann die Kennung der Eltern abgefragt werden. Weiterhin gibt es die Attribute Process Group und Environment, die wir hier nicht besprechen wollen. Es sei auf die einschl¨agige Literatur verwiesen. ¨ 8.1.10 Uber Prozessgrenzen hinweg Da Prozesse, wie besprochen, zun¨ achst einmal keinen gemeinsamen Speicher haben, muss ein Weg gefunden werden, wie sie miteinander Daten und Nachrichten austauschen k¨ onnen. Man ben¨ otigt eine Nachrichtenkopplung. Dies wird im Kapitel Inter-Prozess-Kommunikationskan¨ale betrachtet werden. Es wird drei prinzipielle M¨ oglichkeiten f¨ ur die Kommunikation geben: ¨ • Uber Dateien im File-System, • u ¨ber die noch vorzustellenden IPCs, • u ¨ber einen geteilten Speicher (Shared-Memory).

Abbildung 8.2. Nachrichtenkopplung

Zun¨achst folgt die Er¨ orterung von Threads innerhalb eines oder mehrerer Prozesse.

8.2 Threads

99

8.2 Threads In einem Prozess k¨ onnen mehrere Threads quasi parallel ablaufen, sie k¨onnen ihre Rechenzeit/-Leistung vom OS nach denselben Strategien zugewiesen bekommen, wie sie bei Prozessen angewendet werden. Man nennt Threads auch Light-weighted-Processes, leichtgewichtige Prozesse oder vielleicht leger formuliert: Schmalspur-Prozesse. Die Vorteile von Threads sind vor allem die um einen Faktor 1,5-2 mal schnellere Erzeugung, es m¨ ussen keine Daten kopiert werden wie beim forken von Prozessen und die Kommunikation zwischen Threads gestaltet sich einfach. M¨ ussen große Mengen Daten kopiert werden, so erh¨oht sich der Faktor nat¨ urlich. Zwar adressieren Threads ihren eigenen Variablen-Satz, er ist aber vor anderen Threads im selben Prozess nicht verborgen. Jeder Thread hat seinen eigenen Stack, Thread-spezifische Daten, Register-Satz etc., aber alle Threads arbeiten im selben Adressraum und k¨ onnen beliebig zugreifen. Das bedeutet, dass • • • • • • • •

globale Variablen/Objekte, dynamische Variablen/Objekte, Programminstruktionen, die meisten Daten, Deskriptoren, offene Files, Signal-Handler, Pfade und Directories, und User- und Group-Ids

in allen Threads bekannt und gleich sind. Threads unterscheiden sich lediglich in • • • • • •

der ID, dem Kontext (Register, Stack-Pointer, Program-Counter, Flags,...), dem Stack, errno, der nach einem Systemaufruf vom OS gesetzt wird, Signalmaske und in der Priorit¨ at.

Es muss also ganz besonders darauf geachtet werden, dass sich Threads nicht gegenseitig in die Zugriffe gemeinsamer Ressourcen oder globaler Daten st¨oren. 8.2.1 Erzeugung von POSIX-Threads Mit pthread create wird ein Thread erzeugt, wobei mit ....

void * (*startFunction) (void*) ...

100

8 Prozesse und POSIX-Threads

der Funktionszeiger der Start-Funktion im neuen Thread angegeben wird. Sie ist quasi die main-Funktion im neuen Thread.

#include int pthread_create(pthread_t *neueThreadIDPtr, //Thread_ID R¨ uckgabe const pthread_attr_t *attrPtr, //Attribute des neuen Threads void * (*startFuntion) (void *), //¨ ahnlich main im Prozess void * argPtr) //Zeiger auf Argumente //R¨ uckgabe: EOK (0) OK, sonst Fehler //Bemerkung: Wenn attrPtr NULL, werden //Defaultattr. f¨ ur erz. Thread genommen Listing 8-4. Start eines POSIX-Threads

Wir werden das Starten von Threads in einigen Details besprechen. ¨ Zun¨achst ein Uberblick des Ablaufs. Nach der Erzeugung beginnt ein Thread mit der Ausf¨ uhrung der angegebenen Start-Funktion. Er terminiert, falls • • • • •

das Ende der Funktion erreicht wird oder der Thread explizit pthread exit aufruft oder ein anderer Thread pthread cancel aufruft oder ein Thread ein exec ruft, um einen neuen Prozess zu starten oder der umgebende Prozess terminiert.

Man beachte: • Ein Thread gibt nach seiner Beendigung nicht die belegten Ressourcen frei (Deadlock-Gefahr). • In eingebetteten Anwendungen werden Threads in der Regel nicht dynamisch erzeugt. • Sie werden h¨ aufig am Anfang gestartet. • Das Betriebssystem darf nur EOK zur¨ uckgeben. • Es ist un¨ ublich und gef¨ ahrlich, einen Thread mit pthread cancel zu beenden (Deadlock-Gefahr). Die Bibliothek libpthread.a wird f¨ ur Linux ben¨otigt (-lpthread), f¨ ur QNX nicht. Die Bibliothek libpthread.a ist die statische Variante, bei Angabe von -lpthread versucht der Linker zuerst die dynamische Variante libpthread.so zu linken, sofern nichts anderes angegeben wird. 8.2.2 Allgemeine Gestaltung eines Threads in eingebetteten Anwendungen Der Main-Thread erzeugt die Kinder-Threads und verwaltet sie. F¨ ur Threads wird h¨aufig das folgende Muster verwendet (in C):

8.2 Threads

101

Initialisierung while (!isStopped) { //do something } Cleanup

Die Variable isStopped muss vom Main-Thread zugreifbar sein. Mit ihr kann der Thread zum Beenden aufgefordert werden. Ein Thread kann durch die Funktion pthread_t pthread_self()

seine eigene ID herausfinden. 8.2.3 Thread-Attribute In einer POSIX-Implementierung kann ein Thread andere Attribute als die Defaultwerte haben. Dazu wird ein Attribut-Objekt verwendet. Folgende Schritte sind h¨ aufig zu finden: • Ein Thread-Attribut-Objekt vom Typ pthread attr t definieren. • Objekt mithilfe der Funktion int pthread attr init(pthread attr t * attrPtr) initialisieren. • Mit set-Funktionen Scope, Trennungseigenschaft, Stack-Adresse, StackGr¨oße, Priorit¨ at, Policy usw. bei Bedarf setzen. • Das Objekt wird bei der Erzeugung von Threads verwendet. • Das Objekt mit int pthread attr destroy(pthread attr t *attrPtr) zerst¨oren. Zu beachten ist, dass • Defaultwerte OS-abh¨ angig sind; • nicht alle Attribute in jedem OS m¨ oglich sind (z.B. ist unter Windows set/getstackaddr nicht erlaubt, setscope hat keine Wirkung usw.); • die Stack-Gr¨oße angegeben werden muss, falls ein Thread-Attribut-Objekt explizit verwendet wird! pthread attr init setzt die Stack-Gr¨oße auf 0 (z.B. unter Cygwin)! Bei der Angabe der Stackparameter kann unter QNX auch eine guard size gew¨ ahlt werden, die w¨ahrend der Entwicklungsphase Stack¨ uberl¨aufe detektieren kann; • nicht jede Scheduling-Strategie vom OS unterst¨ utzt wird; • Priorit¨atenstufen OS-abh¨ angig sind. Um plattformunabh¨angig zu bleiben, sollten nur 16 verschiedene Stufen erlaubt werden.

102

8 Prozesse und POSIX-Threads

• Scheduling-Policy nur verwendet wird, wenn PTHREAD EXPLICIT SCHED verwendet wurde (mit pthread attr setinheritedsched); • die Scheduling-Policy ebenfalls OS-abh¨ angig ist. In vielen eingebetteten Systemen wird Round-Robin eingesetzt. Im ersten Beispiel werden in einem Hauptprozess ein Thread gestartet und die Attribute ausgelesen.

#ifndef EOK #define EOK 0 //EOK is defined in the QNX-environment! #endif bool sThreadStopped = false; void firstFunc(void * /* unused */) { //Startfunktion des Threads.Thread l¨ auft endlos sOwnCout<< "init" << endl; int x = 0; while (sThreadStopped == false) { //Kleine Simulation, volatile zur Sicherheit, for (volatile int j = 0; j < 100000; j++) { //damit Compiler Schleife nicht wegoptimiert x += j; } } sOwnCout<< "Hier k¨ ame clean up" << endl; } //zur Vereinfachung geben wir Namen f¨ ur den Typ der Funktionszeiger typedef void * (* threadProc)(void *); int main() { pthread_t threadID; //hiermit holen wir die ID pthread_attr_t attr; //hiermit die Attribute pthread_attr_init(&attr); //Init mit Defaultwerten size_t size = 1000; //f¨ ur Stack-Gr¨ oße pthread_attr_setstacksize(&attr, size); pthread_create(&threadID, &attr, //Defaultwerte (threadProc) firstFunc, //hier wird Threadfkt ¨ ubergeben NULL); sOwnCout<< "Erzeugen des Threads mit dem ID "<
8.2 Threads

103

if (val == PTHREAD_SCOPE_SYSTEM) { //im kernel level sOwnCout<<"Konkurrier. Bereich (contention scope)ist System"<<endl; } else { sOwnCout<<"Konkurrier.Bereich (contention scope)ist Process"<<endl; } //im user level (windows) retVal = pthread_attr_getdetachstate(&attr, &val); //DETACH STATE ASSERTION(retVal == EOK); if (val == PTHREAD_CREATE_JOINABLE) { sOwnCout<< "Thread erzeugt in einem joinable Zustand" << endl; //man kann mit join auf den thread warten } else { sOwnCout<<"Thread erzeugt in abgetrenntem (detached)Zustand"<<endl; //ohne warten, nicht verkn¨ upft } #ifdef QNX //STACK ADDRESS unter QNX int *address; retVal = pthread_attr_getstackaddr(NULL, &address); ASSERTION(retVal == EOK); sOwnCout<< "stack is at address " << int(address) << endl; #endif //STACK SIZE, guard setzen w¨ are m¨ oglich, retVal = pthread_attr_getstacksize(&attr, &size); sOwnCout<< "Stackgr¨ oße " << size << endl; //das ist interessant struct sched_param param; //PRIOTITY retVal = pthread_attr_getschedparam(&attr, ¶m); ASSERTION(retVal == EOK); sOwnCout<< "Priority " << param.sched_priority << endl; retVal=pthread_attr_getschedpolicy(&attr,&val); //SCHEDULING POLICY ASSERTION(retVal == EOK); if (val == SCHED_FIFO) { sOwnCout<< "FIFO scheduling" << endl; } else if (val == SCHED_RR) { sOwnCout<< "Round Robin " << endl; } else { sOwnCout<< "other" << endl; }

104

8 Prozesse und POSIX-Threads retVal=pthread_attr_getinheritsched(&attr,&val); //INHERITED-SCHED ASSERTION(retVal == EOK); if (val == PTHREAD_EXPLICIT_SCHED) { sOwnCout<<"Thread verwendet Scheduling Strategie spezifiziert " << "durch attr bei der Erzeugung" << endl; } else { sOwnCout<<"Thread verwendet vererbte Schedul.Strategie " << endl; } sleep(1); sThreadStopped = true; //dann beenden des Threads pthread_join(threadID, NULL); //damit hat gestoppte Thread noch return 0; //eine Chance, ceanup aufzurufen

} Listing 8-5. Thread-Vereinbarung unter QNX, mit Lesen der Attribute

Die kleine Passage im Folgenden zeigt die Erzeugung eines Threads mit eigenen Attributen:

pthread_t threadID; pthread_attr_t attr; size_t size = 1000; //f¨ ur Stack-Gr¨ oße struct sched_param param; //f¨ ur Priorit¨ at param.sched_priority = PRIORITY_NORM; pthread_attr_init(&attr); //Init mit Defaultwerten pthread_attr_setstacksize(&attr, size); pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM); pthread_attr_setschedparam(&attr, ¶m); pthread_attr_setschedpolicy(&attr, SCHED_RR); pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED); pthread_create(&threadID, &attr, //Defaultwerte (threadProc) firstFunc, NULL); .... Listing 8-6. Erzeugung eines Threads mit eigenen Attributen

¨ 8.2.4 Uber Threadgrenzen hinweg In unten stehender Skizze sind mehrere Threads in einem Adressraum gezeigt. Die Kommunikation zwischen den einzelnen Threads kann u ¨ber gemeinsamen

8.2 Threads

105

Speicher abgewickelt werden, alle Adressen sind allen Threads bekannt. So k¨onnen z.B. einfache globale Variable verwendet werden. Auch gegenseitige Aufrufe von Programmteilen (call, callback) sind u ¨blich. Man spricht von einer speichergekoppelten Kommunikation. Zu beachten ist bei diesem Laufzeitmodell, dass gemeinsam genutzter Speicher und gemeinsam genutzte Codestellen durch geeignete Mechanismen (beispielsweise Mutexe) davor gesch¨ utzt werden m¨ ussen, durch parallele Threads inkonsistent benutzt zu werden.

Abbildung 8.3. Speicherkopplung

Den gemeinsam zugreifbaren Speicher zu sch¨ utzen, ist nicht so schwer, wir werden die Synchronisierungsmechanismen daf¨ ur kennenlernen. ¨ Ahnliche Problemstellungen gibt es bei Prozessen, wenngleich die Fehlerquellen und Missverst¨ andnisse hier nicht so h¨ aufig sind. Schwieriger sind kritische Abschnitte. Dies sind Codeteile, die gemeinsame Daten ver¨andern k¨ onnen. Alle Funktionen z.B., die von mehreren Threads genutzt werden k¨ onnen, m¨ ussen threadsafe“ sein. ” Der Begriff threadsafe bedeutet, dass alle konkurrierenden Zugriffe auf Daten des gemeinsamen Heaps oder des gemeinsamen Datensegments serialisiert werden m¨ ussen, sie m¨ ussen hintereinander erfolgen. Erst muss der Thread, der die Codestelle mit ver¨ anderbaren Daten betreten hat, seine Zugriffe abgeschlossen und die Stelle verlassen haben, damit dann der N¨achste diesen Bereich betreten darf. Reentrant heißt, dass man erlaubt, dass eine Funktion von einem Thread bereits betreten wurde und benutzt wird und zugleich ein anderer Thread diese Funktion ebenfalls betreten darf. Durch Scheduling und Priorit¨aten kann sogar der sp¨atere Thread den fr¨ uheren in der Funktion u ¨berholen. Dies bedeutet, dass alle Daten dieser Funktion entweder auf dem jeweils privaten Stack liegen oder konstant sein m¨ ussen, die Funktion hat keinen kritischen Bereich. L¨agen die Daten auf dem Heap oder w¨ aren global im Datensegment, so zerst¨orten sich die Threads ggf. gegenseitig die Daten. Die Schutzmechanismen sind eigentlich die Gleichen wie die f¨ ur den direkten Schutz von gemeinsamen Daten, jedoch ist es ein allt¨aglicher und sehr schwer zu findender Fehler, wenn Programmierer eine Funktion eines Threads

106

8 Prozesse und POSIX-Threads

nicht threadsafe oder reentrant implementiert haben. Oft wissen sie zum Zeitpunkt der Implementierung auch noch nicht, dass ihr Modul einmal eine solche Verwendung finden wird und mehrere Threads darauf zugreifen werden. Tats¨achlich k¨ onnen Treiber, Hilfsfunktionen, Ausgabe- und Debug-Funktionen von verschiedenen Threads parallel aufgerufen werden und jedes globale Datum kann ver¨ andert werden. 8.2.5 Thread-spezifische Daten In vielen Anwendungen tritt folgende Situation auf: Ein Objekt muss herausfinden, in welchem Thread es l¨ auft. Z.B. um die Nachrichten in die richtige interne Queue des Threads zu senden. Eine M¨oglichkeit besteht darin, einen Zeiger auf den Thread-Kontext im Konstruktor mitzugeben. Diese L¨osung ist nicht sehr geeignet, da •

jedes Objekt dann einen Extrazeiger f¨ ur den Thread-Kontext haben muss (=> RAM); • zus¨atzlicher Code geschrieben werden muss.

Eine weitere L¨osung w¨ are, f¨ ur jeden Thread eigene Routinen mit eigenem Namen und Zugriffen auf z.B. eigene Queues abzuleiten und fest zu implementieren. Dies f¨ uhrt zur Code-Vervielfachung. Eine andere L¨ osung ist die Verwendung einer statischen (Hash-)Tabelle. Jeder Tabelleneintrag besteht aus einer Thread-ID, die bei der Erzeugung zur¨ uckgeliefert wird, und einem Zeiger auf den Thread-Kontext. Ein Objekt kann dann u orige Thread-ID holen und den ent¨ber pthread self die zugeh¨ sprechenden Thread-Kontext erhalten. Diese L¨osung hat ein kleines Problem. Alle Threads greifen gemeinsam auf diese Tabelle, so dass eine Sychronisierung benutzt werden muss. Die beste L¨osung ist die Verwendung der Thread-spezifischen Daten (TSD), die vom Betriebssystem unterst¨ utzt werden. Beschreibung der TSD Unter POSIX kann jedes Datum mit einem Thread assoziiert werden. Dies geschieht u ussel (key) und einen ¨ber einen Schl¨ Zeiger (auf das Datum). Schl¨ ussel f¨ ur TSD sind global, so dass alle Threads in einem Prozess sie kennen. Um TSD zu benutzen, muss ein Thread den eindeutigen Schl¨ ussel erzeugen und ihn mit dem Datum binden. Man kann sich eine Speicherstruktur oder Tabelle vorstellen, die dem lokalen ThreadKontext erg¨anzt wird. Im Einzelnen: Mit int pthread_key_create(pthread_key_t * key,void(*destructor)(void *));

wird ein eindeutiger Schl¨ ussel erzeugt, der allen Threads f¨ ur dieses Datum bekannt ist. Es gibt eine M¨ oglichkeit, diesen Schl¨ ussel nur genau einmal zu erzeugen ohne die Gefahr einer Mehrfacherzeugung durch verschiedene Threads in beliebiger Aufrufreihenfolge. Mit

8.2 Threads

107

int pthread_setspecific ( pthread_key_t key, const void* value )

wird der Schl¨ ussel mit einem Datum assoziiert. Mit void* pthread_getspecific ( pthread_key_t key )

k¨onnen die spezifischen Daten eines Schl¨ ussels abgerufen werden. Die Funktion int pthread_once(pthread_once_t* once_control, void(*init_routine)(void));

stellt die nur einmalige Erzeugung bestimmter TSDs sicher. Beispielimplementierung der TSD Nehmen wir an, dass in jedem Thread in gleicher Weise auf einen Timer¨ die TSDs kann Manager und einen Dispatcher zugegriffen werden soll. Uber ein einheitlicher Code verwendet werden. In der Header-Datei werden in einer Services-Klasse die statischen Keys vereinbart: class CComponentServices {.. static pthread_key_t sTimerManagerKey; //key for the timer manager static pthread_key_t sDispatcherKey; //key for dispatcher .... static pthread_once_t sInit; //ensure init-method called only once }

In der Implementierung wird beim ersten registry-Aufruf (Singleton) die pthread once-Funktion gerufen, die ihrerseits die u ¨bergebene initKeysMethode einmal aufruft und damit alle Schl¨ ussel mit Leereintr¨agen erzeugt. Weitere Aufrufe der registry-Methode registrieren dann nur noch die Schl¨ ussel und die Zeiger auf Manager und Dispatcher, erzeugen aber keine neuen TSDs mehr.

pthread_key_t CComponentServices::sTimerManagerKey; //wg. static pthread_key_t CComponentServices::sDispatcherKey; .... //ensure that init-method called only once; wg.static pthread_once_t CComponentServices::sInit=PTHREAD_ONCE_INIT; void CComponentServices::initKeys(void) {

//init thread specific data

108

8 Prozesse und POSIX-Threads

pthread_key_create(&CComponentServices::sTimerManagerKey, NULLPTR); pthread_key_create(&CComponentServices::sDispatcherKey, NULLPTR); ..... } void CComponentServices::registry(CTimerManager* theTimerManagerPtr) { pthread_once(&sInit, initKeys); pthread_setspecific(sTimerManagerKey, theTimerManagerPtr); } void CComponentServices::registry(CDispatcher* theDispatcherPtr) { pthread_once(&sInit, initKeys); pthread_setspecific(sDispatcherKey, theDispatcherPtr); } .... Listing 8-7. Implementierung der TSD-Initialisierung

Mit einem Makro k¨ onnte der Zugriff auf das im TSD registrierte Objekt vereinfacht werden. Beispielsweise wird in unserem Framework ein Dispatcher registriert. Um eine Nachricht in die interne Queue zu schreiben, muss zuerst der Dispatcher des Threads bestimmt und anschließend die Methode addIntMessage aufgerufen werden. Die Implementierung ist wie folgt:

#define DISPATCHER_PTR (reinterpret_cast \ (pthread_getspecific(CComponentServices::sDispatcherKey))) .... void CComponentServices::addIntMessage(const CMessage& theMsg) { CDispatcher *dispatcherPtr = DISPATCHER_PTR; ASSERTION(NULLPTR != dispatcherPtr); dispatcherPtr->addIntMessage(theMsg); } Listing 8-8. Zugriff auf TSD u ¨ber Makro

8.2.6 Thread-Tr¨ ager und Thread-Objekte Basis jedes Prozesses, jedes Threads und jeder Komponente soll das abstrakte Interface IRunnable sein. Damit gibt es ein gemeinsames Verst¨andnis und Interface f¨ ur alle Prozesse und Threads. Jeder neue Thread (auch im Sinne von main-Thread) muss von IRunnable erben beziehungsweise dieses Interface u ¨ber ein Referenzobjekt nutzen, die Interface-Definitionen mit Implementierungen f¨ ullen und die Schnittstellen bedienen.

8.2 Threads

109

// Interface for all objects which will execute in separate thread or // in main thread of process class IRunnable // INTERFACE DEFINITION { public: //Init and startup actions in thread context. This method will be // called precisely once, within the thread context, prior to the // call of the ’run’ method of this IRunnable object. This allows // the IRunnable to perform any init operations that may be // required within the execution context of the thread. virtual void init(void) = 0; // Perform the work of the IRunnable object of this thread. // This method is not expected to return until either the work of // the thread is completed, or until the stop() method of this // object has been called. virtual void run(void) = 0; // Trigger a shutdown of this thread. The run() method is expected // to react to this call by exiting. This method may not be called // from within the thread context, for that reason cleanup // operations are done separately (see the cleanup method). virtual void stop(void) = 0; // Perform cleanup actions within the thread context. This method // is called immediately following the exit from the run() method, // within the thread context. This is where cleanup actions for // this thread should be performed. virtual void cleanup(void) = 0; // request to the component to prepare the necessary steps due to // possible shutdown */ virtual void prepareForShutdown(void) = 0; // request for resume virtual void reRun() = 0; // request: the component should go to the standby mode virtual void goToStandby() = 0; }; Listing 8-9. Basis-Interface IRunnable.h

Ein Thread wird als Tr¨ ager eines IRunnable-Objekts angesehen. Um einen Thread zu generieren, wird deshalb eine Thread-Klasse definiert, die ein IRunnable-Objekt als Parameter u ¨bergeben bekommt (und dieses tr¨agt

110

8 Prozesse und POSIX-Threads

(carrier)). Die Klasse ruft dann die u ¨blichen IRunnable-Methoden auf, beispielsweise init und run. In der Initialisierung wird auch der TSD-Speicher angelegt und eine genormte Priorit¨at festgelegt. Dies ist wichtig, da unterschiedliche Betriebssysteme Priorit¨atszahlen unterschiedlich deuten. Der Main-Thread kann join aufrufen, so dass Sub-Threads ihre cleanupMethoden korrekt aufrufen k¨ onnen. In unserem Fall werden der Tr¨ ager-Thread/Prozess und das IRunnableObjekt getrennt behandelt. Das IRunnable-Objekt kann deshalb in SingleThread, Multi-Thread oder Multi-Prozess-Umgebung laufen. Dies erleichtert unter anderem das Debugging. Ein Programm-Modul, wir werden sp¨ ater den Begriff Komponente definieren, soll nicht wissen, ob es als Thread oder als Main-Thread eines Prozesses konfiguriert wurde. Sowohl f¨ ur einen Prozess als auch f¨ ur einen Thread werden alle Methoden von CThread verwendet. Diese Vorgehensweise unterscheidet sich von der g¨angigen Literatur. Dort wird zumeist ein Thread-Objekt angelegt, das von IRunnable erbt. Ein Prozess wird manuell mit C-Funktionen erzeugt und attributiert. Zun¨achst das Header-File der Thread-Klasse:

class IRunnable; #define TID pthread_t

//forward declaration //to ease use

class CThread //Utility class to encapsulate thread { public: enum EPriority //only 16 priorities are supported { PRIORITY_IDLE, PRIORITY_ABOVE_IDLE, PRIORITY_BELOW_LOW, PRIORITY_LOW, PRIORITY_ABOVE_LOW, PRIORITY_BELOW_NORM, PRIORITY_NORM, PRIORITY_ABOVE_NORM, PRIORITY_BELOW_HIGH, PRIORITY_HIGH, PRIORITY_ABOVE_HIGH, PRIORITY_BELOW_CRITICAL, PRIORITY_CRITICAL, PRIORITY_ABOVE_CRITICAL, PRIORITY_BELOW_REALTIME, PRIORITY_REALTIME };

control.

8.2 Threads

111

CThread(IRunnable & runnableObj, //runnableObj that run in thread const char * name, //name of the thread Int32 stackSize, //size of the stack EPriority prio, //thread priority bool asMainThread = false ); //if runnable runs in main thread ~CThread(); //Destructor void start(void); //start the object as a thread void join() //join the thread { pthread_join(mOSThreadID, NULLPTR); } TID getThreadID(void) { return mOSThreadID; }

//return the thread ID

static void sleep(Int32 mSecs); //Sleep without consuming CPU static TID getThreadID(const char * name); //ret ID,(0 if not exist) static TID getCurrentThreadID(void) { return pthread_self(); }

//my own

static EPriority getCurrentThreadPrio(void); static const char * getThreadName(TID tid); static const char * getCurrentThreadName(void); //get the thread name, NULLPTR if thread does not exist static const char * getThreadName(TID tid); static const char * getCurrentThreadName(void); //my own //get the pointer to the runnable object static IRunnable * getRunnablePtr(TID tid); static IRunnable * getCurrentRunnablePtr(void); //important method to traverse the list of threads //selects first IRunnable of list. Global mutex is blocked if //at least one runnable exists static IRunnable * selectFirst(void); //selects next runnable. Global mutex is unlocked //if no next runnable is possible ret ptr to a runnable //(NULLPTR if none exists) static IRunnable* selectNext(void); private: friend void init(void);

//C-method to init tsd

112

8 Prozesse und POSIX-Threads friend void *threadProc(void *); //thread-startmethod void run(); //activate thread in its context IRunnable* mRunnablePtr; //object with the thread activity const char* mName; //Name Int32 mStackSize; //stacksize EPriority mPrioBase; //priority of the thread //remember if new thread be started later bool mAsMainThread; pthread_t mOSThreadID; //ID of thread static VoidPtrVector sThreads; //list of all threads static CMutex sMutex; //protect again concur.accesses static pthread_key_t sThreadKey; //to store the thread-local data static pthread_once_t sInit; //ensure init called only once static Int32 sIndex; //for the traversing the list

}; Listing 8-10. Prototyp der Thread-Klasse CThread.h

¨ Eine beispielhafte Instantiierung eines CThread-Objekts mit Ubergabe eines IRunnable-Objekts AudiodiscplayerContext w¨are wie folgt:

CAudiodiscplayerComponent audiodiscplayer (CContext::getAudiodiscplayerContext(),1,1); //Erzeugen Runnable Obj. CThread audiodiscplayerThread ( //Erzeug.d.Tr¨ ager-Threads audiodiscplayer, //Objekt als Parameter CContext::getAudiodiscplayerContext().getContextNamePtr(), //Name CContext::AUDIODISCPLAYER_STACK_SIZE, //stack size CContext::AUDIODISCPLAYER_PRIORITY ); //Prio audiodiscplayerThread.start(); //start des Threads Listing 8-11. Instantiierung eines CThread-Objekts

Die Instantiierung als Main-Thread in einer Tuner-Komponente:

if (0 == fork()) { CTunerComponent tuner( ...); CThread c(tuner, "Tuner", 1024, CThread:: PRIORITY_NORM, true); c.start(); } Listing 8-12. Instantiierung als Main-Thread

8.2 Threads

113

M¨oglich w¨are auch (diesmal mit Tuner- und CD-Komponente):

if (0 == fork()) { CCDComponent cd(...); CTunerComponent tuner( ...); CThread CDThread(cd, "CD", 1024, CThread:: PRIORITY_NORM); CThread tunerThread(tuner,"Tuner",1024,CThread::PRIORITY_NORM,true); CDThread.start(); tunerThread.start(); }

Das bedeutet, CD l¨ auft als normaler Thread und Tuner als Main-Thread. Wir sehen hier die M¨ oglichkeit der Gruppierung von mehreren Threads in einem Prozess. Da die Verwaltung eines Prozesses mehr Overhead ben¨otigt, ist es sinnvoll, Gruppierungen zu schaffen, z.B. wenn mehrere Threads auch auf gleiche Ressourcen zugreifen m¨ ussen. Mit dieser Klasse haben wir die M¨ oglichkeit, Threads und Main-Threads einheitlich zu behandeln. Es folgt die Implementierung der Klasse CThread:

//declaration of static variables of the class CThread VoidPtrVector CThread::sThreads(5,5); CMutex CThread::sMutex; pthread_key_t CThread::sThreadKey; pthread_once_t CThread::sInit = PTHREAD_ONCE_INIT; Int32 CThread::sIndex = 0; void init(void) //method that will called only once { pthread_key_create(&CThread::sThreadKey, NULLPTR); } void* threadProc(void* threadPtr) //Thread start method { pthread_once(&CThread::sInit, init); if (NULLPTR != threadPtr) { CThread *thisThreadPtr = reinterpret_cast(threadPtr); pthread_setspecific( //set thread-local for fast CThread::sThreadKey, //calling the get-methods reinterpret_cast (thisThreadPtr)); thisThreadPtr->run(); //call working method of thread } return NULLPTR; }

114

8 Prozesse und POSIX-Threads

CThread::CThread(IRunnable & runnableObj, //object that run in a thread const char * name, //name of the thread Int32 stackSize, //size of the stack EPriority prio, //thread priority bool asMainThread) //if runnable run in main thread : mRunnablePtr(&runnableObj), mName(name), mStackSize(stackSize), mPrioBase(prio), mAsMainThread(asMainThread) { ASSERTION(asMainThread == false && stackSize > 0); ASSERTION(mName != NULLPTR); sMutex.take(); //add this thread into the list sThreads.add(this); sMutex.give(); } CThread::~CThread() { sMutex.take(); sThreads.removeElement(this); sMutex.give(); }

//destructor

void CThread::start(void) //start thread { Int32 realPrio; int ret; //int bcs. return of pthread-calls struct sched_param threadparam; int max = sched_get_priority_max(SCHED_RR); //calc right prio int min = sched_get_priority_min(SCHED_RR); realPrio = min + (max - min)/(PRIORITY_REALTIME + 1)*mPrioBase; if (false == mAsMainThread) { pthread_attr_t attribute; //Setting thread attributes pthread_attr_init(&attribute); //Set structure to default pthread_attr_setinheritsched(&attribute, PTHREAD_EXPLICIT_SCHED); pthread_attr_setschedpolicy(&attribute, SCHED_RR); pthread_attr_getschedparam(&attribute, &threadparam); //+set prio threadparam.sched_priority = realPrio; pthread_attr_setschedparam(&attribute, &threadparam); ret = pthread_create(&mOSThreadID, &attribute, threadProc, this); ASSERTION (ret == 0 ); pthread_attr_destroy(&attribute); //destroy the attribut } else { //thread object started as main thread - i.e. in this context

8.2 Threads

115

mOSThreadID = getCurrentThreadID(); //threadID of mainThread int policy; //change sheduling and prio pthread_getschedparam(mOSThreadID, &policy, &threadparam); threadparam.sched_priority = realPrio; ret = pthread_setschedparam(mOSThreadID, SCHED_RR, &threadparam); ASSERTION(ret == 0); run(); //call run-method directly //we do not leave method because it is the loop in main thread } (void) ret; }

//avoid "unused variable", //case ASSERTION not enabled

void CThread::run(void) { mRunnablePtr->init(); mRunnablePtr->run(); mRunnablePtr->cleanup(); }

//main method of thread

void CThread::sleep(Int32 mSecs { #ifdef WIN32 Sleep(mSecs); #endif #ifdef __GNUC__ usleep(mSecs*1000); #endif }

//Sleep w/o consuming CPU

//measure in nano seconds

//measure in nano seconds

TID CThread::getThreadID(const char * name) //get the thread ID { TID tid = 0; sMutex.take(); Int32 i; for (i = 0; i < sThreads.getSize(); i++) //run list +compare name { CThread* threadPtr = reinterpret_cast (sThreads[i]); if (0 == strcmp(name, threadPtr->mName)) { tid = threadPtr->mOSThreadID; break; } } sMutex.give(); return tid; } const char* {

CThread::getThreadName(TID tid)

//get the thread name

116

8 Prozesse und POSIX-Threads const char *ptr = NULLPTR; sMutex.take(); Int32 i; //run list+compare ID for (i = 0; i < sThreads.getSize(); i++) { CThread* threadPtr = reinterpret_cast (sThreads[i]); if (tid == threadPtr->mOSThreadID) { ptr = threadPtr->mName; break; } } sMutex.give(); return ptr;

} CThread::EPriority CThread::getCurrentThreadPrio(void) { int policy; sched_param param; int max = sched_get_priority_max(SCHED_RR); //calc right prio int min = sched_get_priority_min(SCHED_RR); pthread_getschedparam(pthread_self(), &policy, ¶m); //calculate the priority int prio=(param.sched_priority-min)*(PRIORITY_REALTIME+1)/(max-min); if (prio < PRIORITY_IDLE) { return PRIORITY_IDLE; } else if (prio > PRIORITY_REALTIME) { return PRIORITY_REALTIME; } else { return static_cast<EPriority>(prio); } } const char *CThread::getCurrentThreadName(void) { CThread* currentPtr = reinterpret_cast (pthread_getspecific(sThreadKey)); return currentPtr->mName; } IRunnable * CThread::getRunnablePtr(TID tid) //get ptr to runnable obj { IRunnable *ptr = NULLPTR;

8.2 Threads

117

sMutex.take(); Int32 i; for (i = 0; i < sThreads.getSize(); i++) { CThread* threadPtr = reinterpret_cast (sThreads[i]); if (tid == threadPtr->mOSThreadID) { ptr = threadPtr->mRunnablePtr; break; } } sMutex.give(); return ptr; } IRunnable * CThread::getCurrentRunnablePtr(void) { CThread* currentPtr = reinterpret_cast (pthread_getspecific(sThreadKey)); return currentPtr->mRunnablePtr; } IRunnable* CThread::selectFirst(void) { //important method to traverse list of threads sIndex = 0; if (sThreads.getSize() > 0) { sMutex.take(); return (reinterpret_cast (sThreads[0]))->mRunnablePtr; } return NULLPTR; } IRunnable* CThread::selectNext(void) { //next runnable.global mutex is unlocked sIndex++; if (sThreads.getSize() > sIndex) { return(reinterpret_cast(sThreads[sIndex]))->mRunnablePtr; } else { sMutex.give(); return NULLPTR; } } Listing 8-13. CThread-Implementierung

118

8 Prozesse und POSIX-Threads

Bei genauer Betrachtung f¨ allt auf, dass die Liste aller Threads in einer Variablen des eigenen Typs VoidPtrVector aufbewahrt wird. Sie wird mit einer Startgr¨oße und einem Inkrement vereinbart, so dass die Liste, falls n¨otig, wachsen k¨onnte. Dies widerspricht zwar den selbst aufgestellten Regeln, keine Vektoren zu verwenden, da die Vektorliste jedoch mit zum Start-Up des Systems erzeugt wird, ist das m¨ogliche dynamische Verhalten unkritisch und messbar.

8.3 Designentscheidung In einem Framework wird normalerweise festgelegt, welche SW-Module als Threads, welche als Prozess implementiert werden. Wir legen fest, dass wir von Komponenten als SW-Einheit sprechen, womit wir Sammelfunktionalit¨aten wie den Tuner“ oder die Navigation“ oder die GUI“ meinen. Solche ” ” ” Komponenten bekommen festgeschriebene Schnittstellen und Aufbauregeln, k¨ onnen aber per Konfiguration zur Kompilierzeit als Task oder Thread spezifiziert werden. Dies erm¨ oglicht und erzwingt saubere Implementierung bei gleichzeitiger Flexibilit¨ at f¨ ur unterschiedliche HW oder Betriebssysteme. Es kostet allerdings auch den Verzicht auf einfache Kommunikation zwischen Threads innerhalb von Tasks, da es ja in anderer Konfiguration auch Prozesse sein k¨onnten. In einer ausgefeilten Konfiguration mit Codegenerierung kann allerdings auch die Kommunikation konfiguriert werden, ohne dass die Applikateure davon wissen m¨ ussen. Hat man die Konfigurationsentscheidung u ¨ber Prozess oder Task zu treffen, m¨ ussen auch die Kontext-Wechselzeiten ber¨ ucksichtigt werden. Dabei sind Wechsel zwischen Prozessen um etwa einen Faktor 1,1-1,3 langsamer als der Wechsel zwischen Threads innerhalb eines Prozesses. Ein kleines Programm kann das ausmessen, siehe Web-Seite, die Ergebnisse wurden auf einem QNX-PC ausgemessen. Die Messungen ergeben folgende Werte: SH4, 240 MHz:

testing process latency average latency: 12,88 usecs end testing process latency testing process-thread latency average latency: 9,89 usecs end testing process-thread latency testing thread latency average latency: 9,69 usecs end testing thread latency */ Listing 8-14. Kontextwechsel-Messungen

8.3 Designentscheidung

119

Achtung: Unter Linux k¨ onnen die Zeiten nicht mit diesem Programm ermittelt werden, da hier keine shared Unnamed-Semaphore unterst¨ utzt werden! Erwartungsgem¨ aß sind Prozesswechsel ein wenig teurer als Threadwechsel, da f¨ ur Prozesswechsel mehr Adressbereiche umgemapped werden m¨ ussen. Der Unterschied ist jedoch nicht gravierend.

9 Inter-Prozess-Kommunikationskan¨ ale, IPC

W¨ ahrend sich Threads direkt u ¨ber Funktionsaufrufe oder Variablen unterhalten k¨onnen, braucht es f¨ ur die Kommunikation zwischen Prozessen eine ausgewiesene Inter-Prozess-Kommunikation u ¨ber vorgesehene Kan¨ale, die IPCs (interprocess communication channels). Man spricht von Nachrichten-Kopplung. Wenn die Voraussetzung ist, dass unsere Komponenten wahlweise Prozesse oder Threads sein k¨ onnen, dann muss von einer Kommunikation u ¨ber Prozessgrenzen ausgegangen werden. Das heißt, dass die Adressen der Gegenseite nicht bekannt sind. Im Folgenden werden einige m¨ogliche Prinzipien mit Pseudo-Code beschrieben. Wir untergliedern die IPCs (interprocess communication channels) in: • • • •

Message-Queues, Pipes, Sockets, FIFOs, QNX-Messages, Shared-Memory, Files und Synchronisierungsmechanismen (Semaphore, Mutexe, Signale, Condition Variables, Locks),

die es mit Unterschieden im UNIX System V und im POSIX-Standard gibt. Normalerweise konzentrieren wir uns auf die POSIX-Standards.

9.1 Pipe Eine Pipe (R¨ohre) ist eine Punkt-zu-Punkt-Verbindung zwischen zwei Prozessen, wobei ein Prozess Daten-Streams sendet und der andere empf¨angt. Pipes sind seit den 70er Jahren aus UNIX als Standard Transportkanal auf einem Prozessor bekannt. Sockets sind der entsprechende Kommunikationsmechanismus zwischen Prozessoren im Netz. Die POSIX-Funktion pipe liefert ein Array mit zwei Filedeskriptoren zur¨ uck. Der eine fd[0] ist zum Lesen vorgesehen, der andere fd[1] zum Schreiben.

122

9 Inter-Prozess-Kommunikationskan¨ ale, IPC

int pipe( int fd[2]);

// system returns pair of filedes // return 0 = success

In der Implementierung muss man abfragen, ob die Pipe-Anforderung funktioniert hat. Auf der Seite des sendenden Prozesses wird pipes[0] nicht verwendet und kann deshalb geschlossen werden. Auf der Empf¨angerseite entsprechend pipes[1].

int fd[2]; if (pipe(fd) != EOK) { /* eigene Fehlerbehandlung */ ;} close(fd[0]); .....

// eine Pipe erzeugen

// Lese-Pipe schließen

Listing 9-1. Pipe erzeugen, Implementierung der Sendeseite

Die Zugriffe finden u ¨ber die Standard-Dateifunktionen read und write statt.

//read ssize_t read ( int fd, void * buf, size_t count); // system returns -1 if failed, sets errno // fd = filedescriptor // buf from which to copy // count number of elements //write ssize_t write ( int fd, const void * buf, size_t count); // system returns -1 if failed, sets errno // fd = filedescriptor // buf from which to copy // count number of elements //close void close( int fd);

Listing 9-2. Pipe schreiben, lesen, schließen, Prototypen

Auch hier muss in der Implementierung an eine Fehlerbehandlung gedacht werden. Man kann sich eine Datei im Betriebssystem vorstellen, die begrenzte Kapazit¨at (PIPE SIZE) hat. Ein Kommunikationspartner kann in diese Datei schreiben, er adressiert die Pipe u ¨ber einen Filedeskriptor, als w¨are sie eine

9.1 Pipe

Abbildung 9.1. Pipe-Erzeugung, fork und Schließen der Pipe-Enden

123

124

9 Inter-Prozess-Kommunikationskan¨ ale, IPC

Datei. Der andere Partner liest am Leseausgang ebenfalls u ¨ber den Filedeskriptor. Es k¨onnen keine Daten mitten aus der Pipe gelesen werden, da nur die Enden zug¨anglich sind. Seek-Operationen als wahlfreie Zugriffe sind also nicht m¨ oglich. Wir k¨onnen uns Pipes wie Fließb¨ ander vorstellen, die auf der einen Seite kontinuierlich beladen werden k¨ onnen und auf der anderen Seite entladen.

Abbildung 9.2. Kommunikation mit Pipes

Zur Vermeidung von Deadlocks muss der lesende Prozess so lange warten, bis der schreibende Prozess alle Daten geschrieben hat. Danach kann der lesende Prozess die Daten abholen. Ein schreibender Prozess muss dann ggf. auf das Ende des Lesens warten. Um die Performance zu erh¨ ohen, stellen viele Betriebssysteme Pipes mit Buffern zur Verf¨ ugung, so dass gr¨ oßere Datenmengen in Portionen u ¨bermittelt werden k¨onnen. Es gibt in limits.h zwei Konstanten PIPE SIZE und PIPE BUF, mit denen die Pipe-Gr¨ oße und die Blockgr¨oße f¨ ur atomares Schreiben eines Elementes festgelegt werden. Die Schreib- und Lese-Operationen k¨ onnen blocking oder non-blocking gew¨ahlt werden. Blocking bedeutet, dass der wartende Prozess blockiert und keine Rechenleistung verbraucht. Das Schreiben blockiert den Prozess/Thread, wenn die Pipe voll ist (im blocking mode). Das Lesen blockiert den Prozess/Thread solange die Pipe leer ist (blocking mode). Er wird vom Scheduler geweckt, sobald die Wartebedingung erf¨ ullt ist. Nachteile der Pipes: Pipes unterst¨ utzen keine strukturierten Daten, man kann also nicht mitgeben, welchen Datentyp man versendet. Sie sind f¨ ur große Datenmengen weniger geeignet. Weiterhin kann nur in der Reihenfolge gelesen werden, in der auch in die Pipe geschrieben wurde. Man beachte: Kommunikationen zwischen unabh¨angigen Prozessen, die nichts miteinander zu tun haben (unrelated), k¨onnen unnamed Pipes nicht nutzen, da nur der ¨ offnende Prozess die Pipes kennt.

9.3 Socket, local

125

Unbenannte Pipes setzen demnach eine gemeinsame Erzeugung f¨ ur beide Prozesse voraus, sie m¨ ussen verwandt sein, in unserem Fall durch das Forken der Prozesse. Sollen unabh¨ angige Executables u ¨ber Pipes kommunizieren, k¨onnen nur named Pipes verwendet werden. Der Zugang zu den Pipes wird vom Betriebssystem angeboten. Die benannten Pipes sind in der Regel allerdings recht langsam. In unserem oben stehenden Bild wird deutlich, dass jedes Datum durch eine Pipe zweimal durch das User-Kernel Interface transportiert wird und daher zwei Kontextwechsel ben¨ otigt werden. Soll ein Task oder Thread mehrere Pipes u ¨berwachen, kann die selectOperation eingesetzt werden. Diese weckt den blockierten Thread z.B. dann, wenn eine zu lesende Pipe Daten hat. Durch Einzelabfrage muss dann herausgefunden werden, welche der Pipes die Ursache des Weckens war, siehe auch [Gray], [Stev].

9.2 FIFO, Named-Pipe Werden f¨ ur Pipes als File-Deskriptoren gemeinsame Namen verwendet, so k¨ onnen auch nicht verwandte Prozesse miteinander kommunizieren. FIFOs und Named-Pipes sind synonym. Sie werden im Directory eingetragen, werden aber im Kernel gespeichert, nicht im Filesystem. Erzeugt werden k¨onnen sie mit den Operationen mknod oder mkfifo. Sequenziell gelesen und geschrieben werden sie mit Standard Stream-Kommandos (fgets, fcout, write, read ...). Da wir Named-Pipes nicht verwenden werden, sei hier auf g¨angige Literatur, z.B. [Stev] und [Gray] verwiesen.

9.3 Socket, local Die Erzeugung eines Paars Unix-Sockets zur lokalen Kommunikation zwischen Prozessen ist ¨ahnlich den Pipes, bei denen auch nach der Erzeugung und dem Forken jeweils ein Kanal geschlossen wird. Auch hier befindet sich der ¨ eigentliche Ubertragungskanal im Kernel und Nutzdaten werden hinein- oder herauskopiert. Typinformationen gehen durch die Serialisierung verloren, wenn sie nicht explizit und zus¨atzlich in die Daten eingebaut werden. ¨ Ubliche Socket-Protokolle wie UDP oder TCP/IP setzen einige zus¨atzli¨ che Header-, Adress- und Sicherungsinformationen zu der Ubertragung hinzu. Eigentlich sind Sockets f¨ ur die Verbindung zwischen verschiedenen Prozessoren gedacht. F¨ ur die Kommunikation auf einem Prozessor sind sie zu teuer bez¨ uglich der Performance.

126

9 Inter-Prozess-Kommunikationskan¨ ale, IPC

int socketpair ( int d, int type, int protocol, int sv[2] ); //int d specifies the domain, z.B. AF_UNIX //type = socket type, normalerweise stream //prot = 0 = system sets it to UDP or TCP/IP //sv[2] the array for filedescriptors //return 0=OK, -1= NOK Listing 9-3. Erzeugen eines Socket-Paares, Prototyp

Das Schreiben und Lesen ist identisch zu den Operationen bei Pipes. Auch hier kann blockierend oder nicht blockierend gearbeitet werden; es k¨onnen ebenfalls wieder per select mehrere Sockets blockierend u ¨berwacht werden. Eine kleine sehr ’C’-lastige Applikation, die zwischen einem Sender und einem Empf¨anger Events (Anzahl = DATA SIZE) u ¨bertr¨agt, ist unten angegeben. Es wird die select-Funktion verwendet.

Int32 Int32 Int32 Int32

sockets[2]; i; numOfBytes; result;

fd_set fdc; if (socketpair(AF_UNIX, SOCK_STREAM, 0, sockets) < 0) { /* own error handling */ } Int32 pid = fork(); //2 Prozesse if (pid == -1) { /* own error handling */ } else if (pid != 0) { close(sockets[0]); //bin Sender UByte data[SIZE]; memset(data, ’W’, SIZE); for (i = 0; i < NUM_TESTS; i++) { FD_ZERO(&fdc); FD_SET(sockets[1], &fdc); select(sockets[1]+1, NULL, &fdc, NULL, NULL); if (write(sockets[1], data, SIZE) == -1) { /* own error handling */ } } } else {

9.4 Socket-Verbindung zwischen Prozessoren close(sockets[1]); UByte data[SIZE];

127

//bin Empf¨ anger

for (i = 0; i < NUM_TESTS; i++) { numOfBytes = SIZE; do { FD_ZERO(&fdc); FD_SET(sockets[0], &fdc); select(sockets[0]+1, &fdc, NULL, NULL, NULL); do { result = read(sockets[0], data, SIZE); if (result == 0) { /* own error handling */ } while (result < 0 && EINTR == errno ); numOfBytes -= result; } while (numOfBytes > 0); } close(sockets[0]); sleep(5); exit(0);

}

} sOwnCout << "mother wait\n" << endl; wait(&state); close(sockets[1]); Listing 9-4. Socket-Applikation, mit select-Implementierung

Der Aufruf der read- beziehungsweise write-Funktion muss in einer Schleife erfolgen. Der Grund hierf¨ ur liegt in der Tatsache, dass beide Funktionen in ihrer Ausf¨ uhrung durch Signale oder Interrupts unterbrochen werden k¨onnen. In beiden F¨ allen werden keine Daten gelesen oder u ¨bertragen. Sofern dies zutrifft, wird ein neuer Versuch gestartet, bis dieser schließlich erfolgreich ist.

9.4 Socket-Verbindung zwischen Prozessoren Betrachten wir nun eine Socket-Verbindung zwischen einem Client- und einem Server-System. Eine solche Kommunikation kann zu Debug-Zwecken sehr n¨ utzlich sein. Es gibt zwei Typen von Socket-Kommunikationen. Die eine baut einmal eine Verbindung durch das Server-Programm auf und bindet einen Namen an den Socket. Dies nennt man den verbindungsorientierten (connection-oriented) Typ, (type SOCK STREAM).

128

9 Inter-Prozess-Kommunikationskan¨ ale, IPC

Die andere Version ist verbindungslos (connection-less). Hier erzeugen beide, Server- und Client-Programm, einen Socket und binden einen Namen daran. Beide Seiten k¨ onnen an den Gegenpart unter der Gegenadresse senden oder von ihm empfangen. Wir w¨ahlen den verbindungsorientierten Typ. Wir definieren eine CSockStream-Klasse als Wrapper f¨ ur eine SocketVerbindung, die Lese-, Schreib- und Close-Funktionen zur Verf¨ ugung stellt. Im Anhang ist eine Version angegeben, die sich f¨ ur Linux, QNX und Windows u asst. Hier beschr¨ anken wir uns auf die QNX-Version. ¨bersetzen l¨

class CSockStream { friend class CSockConnector; friend class CSockAcceptor; public: CSockStream(); ~CSockStream(); //read size bytes from stream into buffer //return number of bytes actually read. int recv( void *buffer, Int32 size ); //send size bytes from the buffer into stream. //return number of bytes actually send. int send( const void *buffer, Int32 size ); //Close this stream for reading and writing void close(); private: int mSocket; }; Listing 9-5. Prototyp f¨ ur Socket-Wrapper CSockStream.h

Die Implementierung:

CSockStream::CSockStream() : mSocket( 0 ) { signal( SIGPIPE, SIG_IGN ); //need to ignore this signal } CSockStream::~CSockStream() { } int CSockStream::recv( void *buffer, Int32 size ) { return read( mSocket, buffer, size ); //read. }

9.4 Socket-Verbindung zwischen Prozessoren

129

int CSockStream::send( const void *buffer, Int32 size ) { return write( mSocket, buffer, size ); } void CSockStream::close() { ::close( mSocket ); mSocket = 0; } Listing 9-6. Implementierung des Socket-Wrapper CSockStream.cpp

Schauen wir die Klassen CSockConnector und -Acceptor an. CSockConnector ist eine Client-Wrapper-Klasse zur Erzeugung/Herstellung einer Verbindung.

class CSockConnector { public: CSockConnector(); ~CSockConnector(); //Connect Params: stream: the stream data sent or received // address: of the server to connect to // block: whether the call should block bool connect( CSockStream& stream, CInetAddr& address, bool block = true ); }; Listing 9-7. Header-Datei des Connector-Wrappers CSockConnector.h

Nun die Implementierung des Clients. Der Client generiert einen Socket und fragt per connect-Aufruf beim Server an, die Verbindung zu akzeptieren bzw. zu etablieren. Daf¨ ur ist in mInetAddr die Internet-Adresse des Servers abgelegt, siehe unten.

CSockConnector::CSockConnector() {} CSockConnector::~CSockConnector() {} bool CSockConnector::connect(CSockStream& stream, CInetAddr& address, bool block ) { int sockfd; if ( ( sockfd = socket( AF_INET, SOCK_STREAM, 0 ) ) < 0 ) { //create socket fails

130

9 Inter-Prozess-Kommunikationskan¨ ale, IPC return false; } if ( ::connect( sockfd, (sockaddr*) &address.mInetAddr, sizeof( address.mInetAddr ) ) < 0 ) { return false; } stream.mSocket = sockfd; return true;

} Listing 9-8. Implementierung des Connector-Wrappers CSockConnector.cpp

Die Socket-Acceptor-Klasse ist eine Wrapper-Klasse f¨ ur den passiven Socket, den Server.

class CSockAcceptor { public: CSockAcceptor(); ~CSockAcceptor(); //Initializes CInetAddr listen passively bool open( CInetAddr& address ); //Initialize CSockStream with a new client connection bool accept( CSockStream& stream, Int8 timeout = 0 ); private: int mListenfd; }; Listing 9-9. Header-Datei des Acceptor-Wrappers CSockAcceptor.h

Die Implementierung zeigt im Folgenden die Zuweisung der Socket-Nummer an den Descriptor mListenfd. Mit ihm wird ein Name oder ein Adresse/PortPaar an den Socket gebunden. In der CInetAddr-Klasse wird die Struktur sockaddr in als mInetAddr instantiiert und gef¨ ullt. Sie ist in definiert. In ihr stehen nacheinander:

sa_family_t u_int16_t struct in_addr ...

sin_family ;//Address family : AF_INET sin_port ; //16 bit port in network byte order sin_addr; //internet address structure

9.4 Socket-Verbindung zwischen Prozessoren

131

// in der Struktur steht die Adresse: struct in_addr { u_int32_t };

s_addr ;

//32 bit address in network byte order

Listing 9-10. Internet-Adress-Struktur sockaddr in in

Hier wird die vollst¨ andige Internet-Adresse angegeben. In /etc/services k¨ onnen die 16 Bit ports nachgeschlagen werden, mit /sbin/ifconfig -a kann die festgelegte Internet-Adresse ausgelesen werden. Nach dem bind-Aufruf zur Adressfestlegung wird mit einer listen-Funktion eine Queue f¨ ur eingehende Connection-Requests erzeugt. Die Gr¨oße der Queue wird typischerweise auf 5 gesetzt [Gray]. Danach ist der Server mit einem blockierenden Aufruf der accept-Methode bereit, eine Verbindungsanfrage des Clients zu akzeptieren.

CSockAcceptor::CSockAcceptor() {} CSockAcceptor::~CSockAcceptor() { } bool CSockAcceptor::open( CInetAddr& address ) { if ((mListenfd = socket( AF_INET, SOCK_STREAM, 0)) < 0) { return false; } bind( mListenfd, (struct sockaddr *) &address.mInetAddr, sizeof( address.mInetAddr ) ); listen( mListenfd, 5 ); return true; }

//create

bool CSockAcceptor::accept( CSockStream& stream, //Stream to read and write Int8 timeout ) //0=blocking, other = wait in secs { if ( timeout > 0 ) { fd_set rfds; struct timeval tv; int retval; FD_ZERO( &rfds ); FD_SET( (unsigned int)mListenfd, &rfds ); tv.tv_sec = timeout;

132

9 Inter-Prozess-Kommunikationskan¨ ale, IPC tv.tv_usec = 0; retval = select( mListenfd + 1, &rfds, NULL, NULL, &tv ); if ( !retval ) { return false; //Timeout with no connection request. } } //here either we have no timeout (blocking mode) or we have //pending connection request so we accept the new connection. int connfd = ::accept( mListenfd, (sockaddr*) NULL, NULL ); if ( connfd == -1 ) { return false; } stream.mSocket = connfd; return true;

} Listing 9-11. Implementierung des Acceptor-Wrappers CSockAcceptor.cpp

Wurde eine Client-Verbindungsanfrage akzeptiert, wird der entsprechende Deskriptor gespeichert. Zum Setzen der IP-Socket-Adresse bzw. F¨ ullen der o.g. Struktur gibt es ebenfalls eine kleine Wrapper-Klasse.

class CInetAddr { friend class CSockConnector; friend class CSockAcceptor; public: CInetAddr(); ~CInetAddr(); //Set address represented by this object //port to be used //address to be used, ret true on success //Set port only. Address be set to IP_ANY for server bool set(UInt16 port, const char *address ); bool set( UInt16 port ); private: sockaddr_in mInetAddr; }; //Die Implementierung ... CInetAddr::CInetAddr() { } CInetAddr::~CInetAddr() { }

9.4 Socket-Verbindung zwischen Prozessoren bool CInetAddr::set( UInt16 port, const char *address ) { memset( &mInetAddr, sizeof( mInetAddr ), 0 ); mInetAddr.sin_family = AF_INET; //set struct mInetAddr.sin_port = htons( port ); if ( inet_aton( address, &mInetAddr.sin_addr ) <= 0 ) { return false; } return true; } bool CInetAddr::set( UInt16 port ) { memset( &mInetAddr, sizeof( mInetAddr ), 0 ); mInetAddr.sin_family = AF_INET; mInetAddr.sin_port = htons( port ); mInetAddr.sin_addr.s_addr = htonl( INADDR_ANY ); return true; } Listing 9-12. Wrapper zum Setzen der Socket-Adresse

In den oben beschriebenen Klassen benutzen wir folgende Headerfiles:

#include #include #include #include

"CSockStream.h" "CSockConnector.h" "CSockAcceptor.h" "CInetAddr.h"

#include #include #include #include #include

<signal.h> <string.h>

#include <sys/socket.h> #include <sys/types.h> #include <sys/select.h> #include #include <arpa/inet.h> Listing 9-13. Verwendete #includes

133

134

9 Inter-Prozess-Kommunikationskan¨ ale, IPC

9.5 Message-Queues Message-Queues sind im Gegensatz zu Pipes und Sockets mehr strukturiert und k¨onnen mit einem User-Type msg type versehen werden. Anhand dieses Typs kann der Empf¨ anger z.B. Nachrichten verschiedener Sender demultiplexen. Jeder Teilnehmer kann in die Kernel-Queue schreiben oder aus ihr lesen. Anhand des msg types kann entschieden werden, von wem an wen eine Nachricht ist. Z.B. k¨onnen die eigenen Process-Ids als Typ angegeben werden. 9.5.1 System V Message-Queues Die Nachrichten in der Queue sind prinzipiell in der folgenden Art intern verkettet: struct msg { msg * msg_next; long msg_type; ushort msg_ts; short msg_spot; };

//ptr to the next Message in the Queue //msg user type //Message text size //adr. of text msg

Der Queue werden die Nachrichten mit einer Struktur einer eigenen Message u ¨bergeben. typedef struct { long mtype; any_type first; any_type second; ... } msg_t;

//user type //hier folgt beliebige eigene Struktur //

System V Message-Queues verwenden die unten aufgelisteten Funktionen, siehe [Stev]: Funktion msgget() msgctl() msgsnd() msgrcv()

Beschreibung Erzeugen einer Queue Kontrollieren einer Queue Senden in eine Queue Empfangen aus einer Queue

9.5.2 POSIX Message-Queues Message-Queues werden vom Kernel zur Verf¨ ugung gestellt. Sie lassen sich wie Buffer oder Pipelines ansehen. Durch ihre Speichertiefe entkoppeln sie den Sender- und den Empf¨ anger-Task. Man kann eine Message-Queue gut

9.5 Message-Queues

135

mit einem Zustandsautomaten oder einem Zustandsdiagramm beschreiben, siehe [Li]. POSIX Message-Queues verwenden die unten aufgelisteten Funktionen: Die wichtigen C-Funktionen lassen sich in einer Klasse mit entsprechenden Funktion mq open() mq close() mq unlink() mq send() mq receive() mq notify() mq setattr() mq getattr()

Beschreibung ¨ Offnet eine Message-Queue Schließt eine Message-Queue L¨ oscht eine Message Queue. Legt eine Message in die Message-Queue Empf¨ angt eine Message aus der Message-Queue Sendet eine Notifikation an den rufenden Prozess, dass eine Nachricht in der Queue vorhanden ist Set Message-Queue attributes Get Message-Queue attributes Abbildung 9.3. Message-Queue Funktionen

Einschr¨ankungen kapseln. Zun¨ achst die Header-Datei:

class CMessageQ { public: CMessageQ( const char *nameOfQueue, Int32 openFlags, mode_t createMode, UInt16 maxMessages, UInt16 maxMessageSize ); ~CMessageQ(); // return 0 if success, -1 if fails Int32 send(const char *msg, size_t msgLength, UInt32 prio ); // -1 if fails, else size of msg - prio of the message is stored Int32 receive(const char *msg, size_t msgLength, UInt32& prio ); private: const char* mqd_t

mName; mDescriptor;

}; //Die Implementierung ist z.B.: ... CMessageQ::CMessageQ( const char *nameOfQueue, Int32 openFlags, mode_t mode, UInt16 maxMessages,

136

9 Inter-Prozess-Kommunikationskan¨ ale, IPC UInt16 maxMessageSize ) : mName(nameOfQueue)

{ struct mq_attr qAttr; qAttr.mq_maxmsg = maxMessages; qAttr.mq_msgsize = maxMessageSize; qAttr.mq_flags = 0; mDescriptor = mq_open( mName, openFlags, mode, &qAttr ); ASSERTION(mDescriptor != 1); } CMessageQ::~CMessageQ() { int closeStat = mq_close( mDescriptor ); int unlinkStat = mq_unlink( mName ); ASSERTION( closeStat >= 0 && unlinkStat >= 0 ); (void) (closeState); // avoid warning (void) (unlinkStat); } //ret 0 for success, ret -1, no message enqueued Int32 CMessageQ:: send(const char *msg, size_t msgLength, UInt32 prio) { return mq_send( mDescriptor, msg, msgLength, prio ); } //ret size of message if success, -1 if fails Int32 CMessageQ:: receive(const char *msg, size_t msgLength, UInt32 &prio) { return mq_receive( mDescriptor, msg, msgLength, &prio); } Listing 9-14. Klasse CMessageQ

Mit einem Message-Queue-Konzept werden demnach Nachrichten per Referenz oder Zeiger in die Message-Queue kopiert, transportiert und am anderen Ende wieder herauskopiert. Die Queue selbst befindet sich in der Kontrolle des Kernels. Bei großen Nachrichten kann das Umkopieren zu Buche schlagen. Auf Message-Queues kann kein select gegeben werden. ¨ Die Kapselungen f¨ ur das Offnen, Schließen der Message-Queue sowie f¨ ur den Versand und den Empfang von Nachrichten pr¨ ufen beim jeweiligen Aufruf, ob dieser durch ein Signal oder einen Interrupt unterbrochen wurde. Sofern dies der Fall ist, wird der Aufruf erneut gestartet.

9.7 Shared-Memory

137

9.6 QNX-Message QNX-Messages haben mit den POSIX oder System V Messages nichts zu tun. Die Letztgenannten werden durch Kernel-Queues transportiert und sind dem Wesen nach asynchron. QNX-Messages werden nicht gequeued“ und sind dem Wesen nach syn” chron. Das heißt, dass ein Sender nach dem Senden einer Nachricht blockiert und erst wieder weiterlaufen kann, wenn der Empf¨anger seine receiveMethode ausgef¨ uhrt und geantwortet hat. Laut QNX-Beschreibung werden Nachrichten direkt vom Sender- zum Empf¨ anger-Prozess kopiert, ohne Zwischenkopie im Kernel. Das Argument f¨ ur die fehlenden Queues lautet, dass diese, falls ben¨otigt, ohne Nachteile in einem abgespalteten Thread angelegt werden k¨onnen. Umgekehrt w¨ urde der feste Einbau den Verlust an Allgemeing¨ ultigkeit bedeuten. Die QNX-Funktionen sind in der Abbildung 9.4 zu finden. Function MsgSend() MsgReceive() MsgReceivePulse() MsgReply() MsgError() MsgRead() MsgWrite() MsgInfo() MsgSendPulse() MsgDeliverEvent() MsgKeyData()

Description Send a Message and block until reply Wait for a Message Wait for a tiny, nonblocking Message (pulse) Reply to a Message Reply only with error status. No Message Byte transferred Read additional data from a received Message Write additional data to a reply Message Obtain info on a received Message Send a tiny, nonblocking Message (pulse) Deliver an event to a client Key a Message to allow security checks

Abbildung 9.4. QNX-Message-Funktionen

9.7 Shared-Memory Auch bei getrennten Prozessen mit privaten Speicherbereichen kann gemeinsamer Speicher, Shared-Memory, vereinbart werden. Zu beachten ist dabei, • • •

dass in jedem Prozess einzeln dieser Speicher vereinbart werden muss, dass in jedem Prozess der Speicher unter anderen Adressen liegen kann, man also ggf. Zeiger umrechnen muss (außer beim forken), dass beim Zugriff auf den Speicher auf Zugriffskollisionen mit anderen Prozessen, die diesen Speicher teilen, geachtet werden muss, siehe unten,

138

9 Inter-Prozess-Kommunikationskan¨ ale, IPC

• dass der Bereich ggf. gegen swappen (Auslagern des Speichers auf Festplatte) gelockt werden muss und • dass dieser Speicher nicht Teil eines der vorgestellten Segmente ist, demnach selbst verwaltet werden muss.

Abbildung 9.5. Bildliche Darstellung eines Shared-Memory Bereichs

Um Shared-Memory in einen Prozess einzubinden, werden in POSIX zwei oder drei Schritte ben¨ otigt: 1. Erzeugen bzw. Holen des Shared-Memory-Objekts:

int shm_open(const char* name, int oflag, mode_t mode) //name: Name des benannten Shared-Memory. //oflag: entweder O_RDONLY oder O_RDWR //zusammen mit O_CREAT, O_EXCL oder O_TRUNC. //Mit O_CREAT | O_EXCL (exkl. Erzeugung) wird das Objekt erzeugt, //wenn es noch nicht existiert. Ein Fehler EEXISTS wird zur¨ uck//gegeben, wenn das Objekt schon angelegt wurde. //Die mode-Konstanten (definiert in <sys/stat.h> sind: //S_IRUSR user read //S_IWUSR user write //S_IRGRP group read //S_IWGRP group write //S_IROTH other read //S_IWOTH other write //R¨ uckgabe Filedescriptor Listing 9-15. Erzeugen Shared-Memory

9.7 Shared-Memory

139

2. Nach dem ersten Open muss die Gr¨ oße des Shared-Objekts bestimmt werden: int ftruncate(int fd, off_t length)

3. Anschließend wird das Objekt in den Adressraum des Prozesses durch den Aufruf eingeblendet:

void * mmap(void* adr, size_t length, int prot, int flags, int fd, off_t offset) //adr: Startadresse im Prozess,wo das Objekt eingeblendet wird //Normalerweise ist dieser Parameter NULL. //length: L¨ ange (Anzahl der Bytes, gestartet bei offset, //die eingeblendet werden sollen). //prot: Protection oft: PROT_READ, PROT_WRITE oder //PROT_READ | PROT_WRITE, //flags MAP_SHARED | MAP_PRIVATE | MAP_FIXED, we use MAP_SHARED //fd: Filedescriptor des Shared-Memory //offset: ist normalerweise 0. //return Adresse des gemappten Shared-Memory Listing 9-16. Einblenden des Shared-Memory in den Speicherbereich

Die Verwendung des Filedeskriptors zeigt bereits, dass Shared-Memory wie ein Datenfile behandelt wird. Je nach Aufruf und Implementierung im OS wird ein gleichnamiges File tats¨ achlich auch auf Festplatte oder im Swap-Space angelegt. Das R¨ uckschreiben des Speicherbereichs auf die Festplatte erfolgt allerdings nicht bei jedem Schreiben, sondern z.B. bei Aufruf von msync unter Linux.

int msync(void *start, size_t length, int flags);

Nach der Verwendung wird das Objekt mit munmap getrennt, mit shm unlink wird der Name des Objekts gel¨ oscht. Das Objekt wird nur gel¨oscht, wenn keine Referenz darauf mehr existiert. In Linux heißen entsprechende Kommandos:

shmget shmctl

//create Shared-Memory //general controls, e.g. shm_lock //to avoid swapping

140 shmat shmdt mmap

9 Inter-Prozess-Kommunikationskan¨ ale, IPC //ctrl. location //detach //create as virtual file Listing 9-17. Linux Kommandos f¨ ur Shared-Memory

Ein Beispiel unter QNX ist im Folgenden gegeben:

extern int errno; #define FILE_MODE (S_IRUSR| S_IWUSR | S_IRGRP | S_IROTH) int main() //Einfaches Programm z. Anlegen eines Shm-Objekts { //Versuch, ein Shared-Memory-Objekt zu erzeugen int fd=shm_open("TestSharedMem",O_RDWR | O_CREAT | O_EXCL,FILE_MODE); bool success = true; if (fd == -1) { if (errno != EEXIST) { sOwnCout<< "can not open " << endl; success = false; } else { fd = shm_open("TestSharedMem", O_RDWR, FILE_MODE); if (fd == -1) { sOwnCout<< "check permission " << endl; success = false; } else { sOwnCout<< "open an existing Shared-Memory" << endl; } } } else { sOwnCout<< "create a new Shared-Memory " << endl; } if (true == success) { ftruncate(fd, 1000); } return 0; } Listing 9-18. QNX Shared-Memory anlegen

9.7 Shared-Memory

141

Mit dem folgenden Testprogramm greifen wir auf das Shared-Memory zu:

define FILE_MODE (S_IRUSR| S_IWUSR | S_IRGRP | S_IROTH) //Ein Objekt dieser Klasse wird in Shared-Memory geschrieben class Test { private: char mName[9]; //Beispieldaten int a; char c; public: Test(): a(1000), c(’d’) { strcpy(mName, "DasIstAB"); } void f() //Ausgabemethode { sOwnCout<< "sizeof Testobjekt" << sizeof(Test) << endl; sOwnCout<< mName << endl; sOwnCout<< c << endl; sOwnCout<< a << endl; } }; struct S { char a, b, c; }; int main() { char *ptr; int fd = shm_open("TestSharedMem", O_RDWR, FILE_MODE ); if (fd == -1) { sOwnCout<< "Error on opening " << endl; exit(1); } //mappen in den eigenen Adressraum ptr = (char *) mmap(NULL, 1000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); Test * t = new(ptr) Test; //Erzeugt ein Objekt (im Shared-Memory) t->f(); //Ausgabemethode des Objekts //Erzeugt Struktur (im Shared-Memory) //Aufpassen! Im realen Projekt Alignmnt //Eigenschaft beachten!!X86 kein Problem

142

9 Inter-Prozess-Kommunikationskan¨ ale, IPC S *s = s->a = s->b = s->c = return

new(ptr + sizeof(Test)) S; ’1’; //Ver¨ andert die Struktur ’2’; ’3’; 0;

} Listing 9-19. Schreiben ins QNX Shared-Memory

Hier wird das Shared-Memory ge¨ offnet und in den Adressraum des Prozesses eingeblendet. Anschließend werden zwei Objekte direkt im Shared-Memory mit Placement-new erzeugt und initialisiert (mit Konstruktoren und auch direkten Zuweisungen). Das entsprechende Pendant zum Lesen:

#define FILE_MODE (S_IRUSR| S_IWUSR | S_IRGRP | S_IROTH) class Test { private: char mName[9]; int i; char c; public: Test() { } void f() { sOwnCout<< mName << endl; sOwnCout<< c << endl; sOwnCout<< i << endl; } }; struct S { char a, b, c; }; int main() { char *ptr; int fd = shm_open("TestSharedMem", O_RDWR, FILE_MODE); if (fd == -1) { sOwnCout<< "Error on opening " << endl; exit(1); } ptr = (char *) mmap(NULL, 1000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

9.7 Shared-Memory

143

Test *t = reinterpret_cast (ptr); t->f(); S* s = reinterpret_cast<S*>(ptr + sizeof(Test)); sOwnCout<< s->a << " " << s->b << " " << s->c << endl; return 0; } Listing 9-20. Lesen aus dem Shared-Memory

Interessant ist die Typisierung des Speichers durch reinterpret cast. An diesem Beispiel sehen wir, dass wir strukturierte Daten u ¨ber Prozessgrenzen hinweg u onnen. ¨bertragen k¨ Interessant ist auch die Frage, wann man sich um Zugriffskollisionen k¨ ummern muss. Beim Prozesswechsel von einem zu einem anderen Prozess wird vom OS der Kontext gesichert. Das betrifft zun¨ achst einmal den Prozessorstatus mit allen Registern. Auch alle Segment-Pointer werden gesichert und umgeschaltet. Nicht gesichert werden Arbeitsdaten. Wenn also z.B. ein Prozess mehrere Datenw¨orter eines zusammenh¨ angenden Datums in den gemeinsamen Speicher schreiben soll und dabei von einem anderen Prozess unterbrochen wird, der dieses Datum weiterverarbeiten soll, so findet dieser zum Teil alte und zum Teil neue Datenteilworte vor. Es kann also zu statistischen Fehlern kommen, die sehr schwer zu finden sind. Dies kann schon bei den oben angegebenen Implementierungsbeispielen passieren. Verallgemeinert gesprochen muss man gemeinsam genutzte Ressourcen vor konkurrierenden Zugriffen sch¨ utzen. ¨ Uber Mechanismen des Betriebssystems kann der Speicherbereich, in denen die gemeinsamen Daten oder Ressourcen liegen, so gesch¨ utzt werden, dass erst der Speicher vom gerade zugreifenden Prozess freigegeben werden muss, bevor ein anderer Prozess denselben Bereich nutzen darf. Diese Synchronisierungsmechanismen werden in einem sp¨ ateren Kapitel besprochen. Unkritisch k¨onnte es sein, wenn es sich nur um ein Datenwort handelt, der Zugriff auf das Wort innerhalb eines Befehls passiert und abgeschlossen wird und daher nicht von einem Prozesswechsel unterbrochen werden kann. Allerdings gilt das Kriterium Unteilbarkeit des Befehls“ f¨ ur den kompi” lierten Befehl; man m¨ usste pr¨ ufen, wie ein C-Befehl in den entsprechenden Maschinenbefehl u ¨bersetzt wird. Da das auch noch vom Compiler und vom Zielsystem abh¨angig sein kann, sollte man in diese Untiefen nicht hinabsteigen. QNX z.B. bietet auch einige atomic-Funktionen an. Die Schwierigkeit in der Verwendung von Shared-Memory ist die Kl¨arung der Frage, welche Daten zu welchem Prozess geh¨oren und wie sie gekapselt werden. Weiterhin hebt das Shared-Memory Konzept zumindest teilweise den Spei¨ durch andere Prozesse (Danglingcherschutz gegen unbefugtes Uberschreiben Pointer) auf.

144

9 Inter-Prozess-Kommunikationskan¨ ale, IPC

Was zumindest m¨ oglich ist, ist dass der Prozess, dem die Daten geh¨oren, den Speicherbereich nach Bedarf gegen Schreiben sch¨ utzt. Dies wird im n¨achsten Unterkapitel er¨ ortert. Schließlich gibt es einige Beispiele in der Literatur, die empfehlen, den Shared-Memory-Bereich volatile zu definieren, z.B. [Mad]. Der Compiler k¨ onnte andernfalls z.B. Polling-Warteschleifen, die darauf warten, dass eine Variable im Shared-Memory von einem anderen Prozess freigegeben wird, herausoptimieren. Verwendet man saubere“ Signale oder Semaphore des OS zur Synchro” nisation statt eigener Polling-Schleifen, sollte man die volatile-Definition nicht brauchen.

¨ 9.8 Shared-Memory gegen Uberschreiben schu ¨ tzen Durch die Einrichtung von Shared-Memory gibt es einen Speicherbereich, der von mehreren Prozessen zugegriffen werden kann. Dies hebt den Prozessschutz der Daten auf. In unserem sp¨ ater folgenden Framework verwenden wir den gemeinsamen Speicher f¨ ur Queues, die Queue-Verwaltung (Schreib-, Lese-Zeiger und einige Semaphore). Falls es sich um ein dynamisch konfigurierbares Framework handeln sollte, m¨ ussen auch Kontextinformationen f¨ ur alle zug¨anglich im SharedMemory aufbewahrt werden. Es gibt in POSIX eine Funktion mprotect, mit der der Speicher seitenweise auf read-only gesetzt werden kann. Diese Page-Gr¨oße betr¨agt unter QNX f¨ ur den SH4 4 kByte, also eine akzeptable Gr¨ oße. Im Folgenden ist eine Wrapper-Klasse zu finden, die Daten im SharedMemory seitenweise vor unberechtigten Zugriffen sch¨ utzen kann.

class CMemoryProtector { public: enum ProtectionMode { WRITE_ONLY READ_ONLY EXEC NONE READ_WRITE READ_EXEC WRITE_EXEC READ_WRITE_EXEC }; CMemoryProtector();

//define all possible protection modes = = = = = = = =

PROT_WRITE, PROT_READ, PROT_EXEC, PROT_NONE, WRITE_ONLY | READ_ONLY | WRITE_ONLY | WRITE_ONLY |

READ_ONLY, EXEC, EXEC, READ_ONLY | EXEC

¨ 9.8 Shared-Memory gegen Uberschreiben sch¨ utzen

145

~CMemoryProtector() {} void init(void* startaddress, size_t size ); //changes the protection setting for its memory area, // ret 0 on success, otherwise -1 Int32 protect(ProtectionMode protmode); private: void* mStartAddress; size_t mSize; //to avoid missuse CMemoryProtector( const CMemoryProtector & ); const CMemoryProtector & operator=( const CMemoryProtector & ); }; Listing 9-21. CMemoryProtector.h

Nachdem ein CMemoryProtector-Objekt erzeugt wurde, kann mit init und protect ein beliebiger Speicherbereich kontrolliert werden. Im Aufruf von init wird zugesichert, ob die u ¨bergebene Speicheradresse ein Vielfaches der Page-Gr¨oße ist. Trifft dies zu, so wird der jeweilige Speicherbereich gem¨aß dem u utzt. ¨bergebenen Zugriffsmodus gesch¨ Es folgt die Implementierung der Klasse CMemoryProtector:

#include #ifndef PAGESIZE #define PAGESIZE 4096 #endif

/* for PAGESIZE */

CMemoryProtector::CMemoryProtector() : mStartAddress(0), mSize(0){} void CMemoryProtector::init(void* startaddress, size_t size) { ASSERTION(startaddress) % PAGESIZE == 0 ); mStartAddress = startaddress; mSize = size; } Int32 CMemoryProtector::protect(ProtectionMode protmode ) { return mprotect( mStartAddress, mSize, protmode ); }

Listing 9-22. CMemoryProtector.cpp

146

9 Inter-Prozess-Kommunikationskan¨ ale, IPC

In der folgenden Klasse wird ein CMemoryProtector-Objekt verwendet, um die Zugriffe auf den Speicher zu kontrollieren.

class CProtectedSharedMemory { public: CProtectedSharedMemory(const char* name, size_t size) ; // size of shared memory ~CProtectedSharedMemory(); char* getStartAddress() const { return mStartAddr; } const char* getSharedMemoryName() const { return mName; } size_t getSize() const { return mSize; } // write a msg with length bytes to shared mem at offset // return true if OK bool write(const char* msg, size_t length, size_t offset); // read into the buffer bool read(char* buffer, size_t length, size_t offset); private: const char* char* size_t CMemoryProtector };

mName; mStartAddr; mSize; mProtector;

#define FILE_MODE (S_IRWXU | S_IRWXG | S_IRWXO) CProtectedSharedMemory:: CProtectedSharedMemory(const char* name, size_t size) : mName(name), mStartAddr(0), mSize(size), mProtector() { int ret; // open the shared memory int fd = shm_open(name, O_RDWR | O_CREAT , FILE_MODE); ASSERTION (-1 != fd ); if( errno != EEXIST ) //truncate only on creation { ret = ftruncate(fd, size); ASSERTION(ret >= 0); }

¨ 9.8 Shared-Memory gegen Uberschreiben sch¨ utzen // Mapped into the own address space mStartAddr = (char *)mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); ASSERTION(0 != mStartAddr); mProtector.init(mStartAddr, mSize); // disable writing ret = mProtector.protect(CMemoryProtector::READ_ONLY); ASSERTION(0 == ret); close(fd); } CProtectedSharedMemory::~CProtectedSharedMemory() { int ret = munmap(mStartAddr, mSize); ASSERTION(ret == 0); ret = shm_unlink(mName); ASSERTION(ret == 0); } bool CProtectedSharedMemory:: write(const char* msg, size_t length, size_t offset) { if (offset + length > mSize) { return false; } else { // enable writing Int32 ret = mProtector.protect(CMemoryProtector::READ_WRITE); ASSERTION(0 == ret); memcpy( mStartAddr + offset, msg, length); // disable writing ret = mProtector.protect(CMemoryProtector::READ_ONLY); ASSERTION(0 == ret); return true; } } bool CProtectedSharedMemory:: read(char* buffer, size_t length, size_t offset) { if(offset + length > mSize) { return false; } else

147

148

9 Inter-Prozess-Kommunikationskan¨ ale, IPC { memcpy(buffer, mStartAddr + offset, length); return true; }

} Listing 9-23. Beispiel-Klasse CProtectedSharedMemory

Nachdem ein Shared-Memory-Bereich erzeugt und eingeblendet wurde, wird er mithilfe des Protektors gegen Schreiben gesch¨ utzt. Nur bei der definierten write-Methode wird das Zugriffsrecht kurzzeitig auf schreibend gesetzt. Der Bereich ist dennoch nicht hundertprozentig gegen unberechtigte Zugriffe gesch¨ utzt, weil dazwischen der Prozess unterbrochen werden kann. Dennoch bietet dieser Mechanismus eine große Hilfe. Ein vagabundierender Zeiger kann damit abgefangen werden, wie das folgende Beispiel zeigt:

void defaultSignalCatcher( Int32 sig ) { if( sig == SIGSEGV ) { sOwnCout << "CMemoryProtector received signal SIGSSEGV" << endl; exit(-1); } } const char* TEXT = "this is a test"; int main(void) { signal(SIGSEGV, defaultSignalCatcher); CProtectedSharedMemory shm("Test", 4096); sOwnCout << "write" << endl; shm.write(TEXT, strlen(TEXT) + 1, 0); char buf[1000]; sOwnCout << "read" << endl; shm.read(buf, strlen(TEXT) + 1, 0); sOwnCout << buf << endl; char* addr = shm.getStartAddress(); *addr = ’a’; return 0; } Listing 9-24. Demonstration des Shared-Memory-Schutzes

9.9 Zeitverhalten

149

9.9 Zeitverhalten Erste Messungen haben folgende Werte ergeben:

Interprozesskommunikation (auf Athlon XP 1300+ QNX x86): ----------------------------------------------------------------------throughput [B/s]: shm 1e+09 named pipe 3.80952*10^07 unnamed pipe 3.84615*10^07 msgQ 3.22581*10^07 unix-socket 2.61438*10^07 unnamed-unix-socket 2.85714*10^07 qnx_msg 5.33333*10^07 mprotect (switch from write to read-only): ----------------------------------------------------------------------mprotect needed 17.982 usecs Kontextwechselzeiten: ----------------------------------------------------------------------testing process average latency: 2.4975 usecs testing process-thread average latency: 2.2977 usecs testing thread average latency: 2.198 usecs Auf Embedded System mit Hitachi SH4 240 MHz: ----------------------------------------------------------------------¨ Ubertragungsdauer [s] Durchsatz [B/s] Shared-Memory 2 2*10^8 QNX-Message 43 9,3*10^6 Named Pipe 53 7,55*10^6 Unnamed Pipe 58 6,9*10^6 Unix Domain Socket 152 2,63*10^6 POSIX Message-Queue 154 2,6*10^6 Unnamed Unix Domain Socket 170 2,35*10^6 Internet Domain Socket 192 2,3*10^6

Abbildung 9.6. Zeitmessungen der unterschiedlichen IPC-Methoden, [Klein]

Das Programm dazu ist auf unserer Web-Seite zu finden, auch dort wurde wieder eine OO-Kapselung der C-Routinen vorgenommen.

150

9 Inter-Prozess-Kommunikationskan¨ ale, IPC

9.10 Designentscheidung und prinzipielle Implementierung Funktionsaufrufe und Callbacks sind f¨ ur die Kommunikation zwischen Prozessen nicht nutzbar. Pipes, FIFOs und Sockets k¨ onnen die Daten nur unstrukturiert als Stream u ¨bertragen. Es gibt keine Paketierung und die Typinformation wird bei der Serialisierung verloren. Sockets ben¨ otigen einen großen Overhead an Zusatzinformationen und Sicherungen. Message-Passing ist nicht f¨ ur große Datenmengen vorgesehen. Der wesentliche Nachteil von Message-Queues gegen¨ uber Pipes ist die fehlende select-M¨ oglichkeit. QNX-Messages gibt es nicht in allen Betriebssystemen und sie sind nur synchron. Die Kommunikation ist schnell, Teilnehmer k¨onnen sich gegenseitig leicht blockieren. Weitere sehr klassische M¨ oglichkeiten, mit denen man Prozesse in ihrer gegenseitigen Synchronisierung beeinflussen kann, sind unter den Stichworten intdisable (Interrupt-disable), scheduledisable, locks und files zu finden. Interrupts oder den Scheduler zeitweise zu sperren, verbietet sich bei Echtzeitanforderungen oder ist nur beschr¨ ankt einsetzbar und in großen Teams nicht beherrschbar. Locks und Files haben an Bedeutung verloren und werden hier nicht besprochen. Die schnellste und flexibelste L¨ osung zur Nachrichtenkopplung von Prozessen ist das Shared-Memory. Wird es auch noch im Zusammenspiel mit fork f¨ ur die Prozesse erzeugt, kennen alle Prozesse die gleichen Zeiger auf den Speicher und auf angelegte Semaphore. Shared-Memory ist eine sehr einfache M¨ oglichkeit, die auch von allen vorgegebenen OS unterst¨ utzt wird. Bei Shared-Memory werden weniger Daten umkopiert als bei anderen Prinzipien, was zumindest bei gr¨oßeren Datenmengen einen Performance-Vorteil bringt. Die Entscheidung f¨ allt daher f¨ ur Shared-Memory, in das Event-Queues gelegt werden. Große Datenstrukturen werden in Datencontainern im SharedMemory ausgetauscht. Beide Themen werden in den folgenden Kapiteln weiter verdeutlicht. Wichtig ist, dass in Multiprozess-Umgebungen die Kontexte und Adressen beim fork-Aufruf geerbt werden, d.h., die Adressen der Kontext-Header und Queues sind in allen Prozessen gleich.

10 Gemeinsame Nutzung von Code

10.1 DLLs Statisches Linken bedeutet, dass zur Kompilierzeit alle erforderlichen Libraries dazu gelinkt werden. Daraus wird ein Executable erzeugt. Nachteilig ist, dass so in einem Executable vielfache Kopien einer Library angelegt werden k¨onnen. DLLs sind Libraries, die vom OS mit einem System-Loader zur Lade- oder zur Laufzeit geladen werden. Man nennt dies im ersten Fall loadtime linking, im zweiten runtime linking. Wegen des hohen Overheads beim Aufruf ist runtime linking nicht sehr verbreitet. In den meisten F¨ allen k¨ onnen Applikationen DLLs gemeinsam benutzen und brauchen keine eigenen Kopien. Dazu m¨ ussen die Libraries zustandslos sein, sie d¨ urfen keine eigenen Daten haben, die zur Verletzung der Threadsafety f¨ uhren w¨ urden. Alle notwendigen Daten und Variablen m¨ ussen zur aufrufenden Applikation geh¨ oren.

10.2 Shared-Code Gemeinsam benutzbarer Code kann durch Shared-Libraries erzeugt werden. Das Prinzip ist einfach: Der gemeinsam benutzte Code verwendet ein gemeinsames Code-Segment, die rufenden Prozesse nutzen weiterhin ihren eigenen Kontext, also Stack, Daten- und Heap-Segment. Die gemeinsame Nutzung des Code-Segments wird durch das OS durch Einmappen mithilfe der MMU bewerkstelligt. Allerdings wird das Datensegment des rufenden Prozesses beim Laden der Library durch eine Kopie des Datensegments der Library erg¨anzt, schließlich arbeiten auch die Programme aus der Library mit Daten, die im Datensegment gehalten werden m¨ ussen.

152

10 Gemeinsame Nutzung von Code

Die Gr¨oße des per MMU eingemappten Segments ist schon zur Link-Zeit auf Grund der Header-Dateien oder Symboltabellen bekannt. Zur Nutzung von Shared-Code ist also kein Kontextwechsel oder Synchronisation von Ressourcen erforderlich.

10.3 Designentscheidung und prinzipielle Implementierung Wir verwenden fork als Prinzip. Wir hatten bereits erl¨autert, dass man mit fork auf einfache und effiziente Weise Code-Sharing f¨ ur alle Prozesse betreibt, ohne daf¨ ur DLLs oder Shared Libraries zu brauchen. In Kombination mit den vor dem fork vereinbarten Shared-Memory-Bereichen kennen alle Prozesse die Shared-Memory-Bereiche, die Queues und die darin implementierten Semaphoren. Da das gesamte Framework als ein Projekt u ¨bersetzt wird, sind auch alle Klassen und Klassenmethoden bekannt.

11 Synchronisierungsmechanismen fu ¨ r Prozesse und Threads

Auch die nachfolgenden Synchronisierungsmechanismen geh¨oren zu den IPCMethoden, sind sie doch gleichzeitig selbst auch kleine Speicher, u ¨ber die Prozesse miteinander kommunizieren k¨ onnen. Meistens werden sie dazu verwendet, den abwechselnden gemeinsamen Datenzugriff zwischen Prozessen und/oder Threads zu regeln oder auch nur den zeitlichen Ablauf zwischen Prozessen zu koordinieren. Alle Synchronisierungsmechanismen gehen von einer kooperativen Implementierung aus; wenn der Designer die Spielregeln“ nicht einh¨alt, kann er in ” gesch¨ utzte Bereiche einbrechen.

11.1 Semaphore Manchmal ist es notwendig, dass mehrere Prozesse oder Threads auf gemeinsame Ressourcen zugreifen. Damit die Zugriffe von verschiedenen Teilnehmern nicht durcheinander gehen, m¨ ussen sie synchronisiert werden. Es w¨are zum Beispiel unlesbar, wenn ein Drucker gleichzeitig und durcheinander von zwei parallelen Prozessen verwendet w¨ urde. Eine kritische Ressource kann auch ein Datenbereich, Queues, SharedMemory, ein SW-Modul, ein Treiber oder ein paar Codezeilen mit globalen Datenzugriffen sein, die nicht parallel von mehreren Prozessen aufgerufen werden d¨ urfen. Der Teil des Codes, der wegen der Datenzugriffe gegen verschachtelten Zugriff gesch¨ utzt werden muss, wird kritischer Abschnitt (critical section) genannt. Genauer gesagt k¨ onnen kritische Programmstellen nicht Codezeilen sein, sondern nur die darin enthaltenen Zugriffe auf globale Variablen sind kritisch. Diese Zugriffe k¨ onnen bei konkurrierenden Threads durcheinander gemischt werden, sie k¨ onnen aus verschiedenen Thread-Kontexten heraus mehrfach aufgerufen werden und dann Daten zerst¨ uckeln. Wenn das passiert, ist dieser SW-Teil nicht threadsafe.

154

11 Synchronisierungsmechanismen f¨ ur Prozesse und Threads

Umgekehrt formuliert ist ein SW-Modul dann threadsafe, wenn kritische Bereiche so gesch¨ utzt sind, dass Threads sie nur hintereinander und synchronisiert passieren k¨ onnen. Ein Modul ist reentrant, wenn es parallel von mehreren Threads aus verwendet bzw. aufgerufen werden kann. Es gibt in diesem Modul demnach keine kritischen Abschnitte mit globalen oder statischen Objekten oder globalen Ressourcen. Dieses Problem ist bei nicht verwandten Prozessen nicht gegeben, da sie keine Gemeinsamkeiten haben und keinen Code mit fremden Daten in ihrem eigenen Prozesskontext aufrufen k¨ onnen. Sie k¨onnen lediglich u ¨ber die vorher angesprochenen IPCs mit anderen Prozessen interagieren. Das Thema threadsafe f¨ ur kritische Abschnitte ist also zun¨achst nur ein Problem bei Threads, nicht bei Prozessen. Etwas anderes ist das bei Zugriffen auf gemeinsame Ressourcen oder Daten im Shared-Memory, hier haben Prozesse das Problem auch. Fr¨ uhe Win-Implementierungen z.B. f¨ ur die Synchronisierung u ¨ber Dateien oder f¨ ur den Zugriff auf Drucker, waren nicht korrekt und haben das Problem jedem Nutzer veranschaulicht. Wenn wir uns vorstellen, dass zwei Tasks auf eine gemeinsame Ressource zugreifen wollen, dann muss der zweite Task blockiert werden, wenn der erste gerade aktuell die Ressource benutzt. Die Codezeilen, die diesen Zugriff implementieren, w¨ urde man in klassischer Sicht ebenfalls kritische Abschnitte nennen, auch wenn hier eigentlich nur direkt die Daten gesch¨ utzt werden m¨ ussen. Letztlich ist diese Diskussion aber nur die unterschiedliche Interpretation der gleichen Implementierung. Um Ressourcen beliebiger Art zu sch¨ utzen, k¨onnen Semaphore eingesetzt werden. Ein Semaphor (griechisch semat = Signal, Zeichen und phor = tragen, bezeichnet Signalmast mit verstellbaren Armen, Schiffahrt; Semaphoro = ital. Ampel) ist eine Primitive f¨ ur die Synchronisation einer Ressource zwischen Prozessen oder Threads eines Prozesses. Ein Semaphor kann sogar eine HW-Variable sein, mit der verschiedene Prozessoren ihre Zugriffe auf gemeinsame Hardware synchronisieren. Normalerweise ist ein Semaphor im Kern eine nichtnegative IntegerVariable, die vom Betriebssysstem verwaltet wird und speichert, ob die Ressource zugegriffen werden darf oder bereits von einem anderen Task benutzt wird. Die Variable kann bin¨ ar gebraucht werden (binary semaphore) oder als Z¨ahler (counting semaphore), wenn mehr als eine Ressource vorhanden ist. Sie kann einen Namen haben (named semaphore) oder nicht (memory mapped semaphore). Es gibt in der klassischen Implementierung von Dijkstra eine P-Operation (passer = blockieren, um den Weg zu passieren; oder probere = probieren) und eine V-Funktion (verlaat = freigeben oder verhogen = inkrementieren), die beide auf den Semaphor wirken. Der Semaphor selbst heißt s.

11.1 Semaphore

155

Vor dem gew¨ unschten Zugriff auf die Ressource wird mit der P-Funktion die Variable angefragt und falls m¨ oglich blockiert. Die Abfrage und die Blockierung sind so gestaltet, dass kein anderer dazwischen rutschen“ kann; es handelt sich um eine unteilbare Funktion, die ” Operation ist atomar (atomic). Ist der Semaphor also frei (>0), wird er blockiert (=0) und die gew¨ unschte Ressource genutzt. Ist der Semaphor nicht frei (==0), wird gewartet und der wartende Task wird blockiert (= “schlafen gelegt“), wenn es das Betriebssystem kann, oder es wird in einer Polling-Schleife gewartet. Mit der V-Funktion wird der Semaphor freigegeben. Eine Pseudodarstellung ist im Folgenden gegeben:

int s=1; ... P(s): P: if (s == 0) goto P else s = s-1; ... V(s):

s = s+1

// auf frei initialisieren

// // // // //

warten bis frei, dann take das. Hier ist eine Polling Schleife!! blockieren die gew¨ unschte Ressource nutzen freigeben give

Listing 11-1. Semaphor und die Zugriffsfunktionen V(s) und P(s)

Abbildung 11.1. Zustandsdiagramm der m¨ oglichen Semaphore-Zust¨ ande

Man kann sich einen Semaphor wie eine rote Ampel vorstellen, die eine gemeinsame Kreuzung, die aus mehreren Richtungen befahrbar w¨are, sch¨ utzt. Der Erste, der an die Kreuzung heranf¨ ahrt, bekommt den Semaphor und darf ihn auf lock oder take (= rot) stellen. Dann f¨ ahrt er durch die Kreuzung. Erst wenn er nach Verlassen der Kreuzung wieder den Semaphor freigibt (unlock

156

11 Synchronisierungsmechanismen f¨ ur Prozesse und Threads

oder give), bildlich auf gr¨ un stellt, k¨ onnen andere Fahrzeuge versuchen, den Semaphor f¨ ur sich zu bekommen. Einen Semaphor darf eigentlich jeder wieder freigeben, also auch andere Prozesse oder Threads, das Ampelbeispiel hinkt hier etwas. Besser ist das Bild eines amerikanischen Briefkastens, bei dem der Brieftr¨ager nach Hineinlegen der Briefe den roten Hebel nach oben stellt. Der Kunde, der die ganze Zeit auf dieses Signal gewartet hat, holt sich daraufhin seine Briefe aus dem Kasten und stellt den Hebel wieder herunter, gibt den Briefkasten also wieder frei. Ein Semaphor hat deshalb auch Signalwirkung. Typische Anwendung ist zum Beispiel die Rollenverteilung Produzent (z.B. Interrupthandler) und Konsument (Treiber). Der Konsument wartet auf einen Semaphor, der vom Produzenten bekannt ist. Wenn etwas verf¨ ugbar ist, wird der Semaphor freigegeben. Mutexe sind exklusive Semaphore, d.h., nur der Prozess oder Thread darf den Semaphor freigeben, der ihn auch blockiert hat. Hier stimmt das Ampelbeispiel sehr gut. Semaphore und Mutexe sind demnach Variablen, die, da sie von verschiedenen Tasks abgefragt, blockiert oder freigegeben werden, nur vom Betriebssystem verwaltet werden k¨ onnen. Auch f¨ uhrt das Betriebssystem eine Warteliste von blockierten Prozessen oder Threads, die nach der Freigabe der Semaphore vom Scheduler priorit¨atengerecht bedient werden. Zur Synchronisierung m¨ ussen die Semaphore allen Beteiligten bekannt sein. Es gibt daf¨ ur verschiedene M¨ oglichkeiten: • Den Semaphor vom OS anzufordern, im Betriebssystemspeicher aufzubewahren und durch OS-Zugriffsfunktionen f¨ ur jeden Prozess zugreifbar zu machen (Unix System V semaphore). Allerdings m¨ ussen diese unbenannten Semaphore mit IDs kenntlich gemacht werden, die dem einzelnen Prozess beim Anfordern der Semaphor-Variablen u ¨bergeben werden. Anhand dieser ID kann dann ein Prozess die Variable mit den verf¨ ugbaren OSFunktionen ver¨ andern. Zwischen den Prozessen muss diese ID auf anderem Weg bekannt gemacht werden, z.B. u ¨ber einen Shared-Memory-Bereich. • Den Semaphor selbst in einem Shared-Memory zu vereinbaren (POSIX memory based Semaphore). Auch hier wird mit einer ID oder einem Zeiger auf der dahinterliegenden Semaphore-Struktur gearbeitet. • F¨ ur Threads ist der Semaphor ohnehin von allen Beteiligten zugreifbar. • Den Semaphor vom Betriebssystem als File mit Namen vereinbaren zu lassen und einen Zeiger darauf zu bekommen (POSIX named semaphore). Man kann sich einen Semaphor wie einen Zeiger oder eine Referenz auf einen Tabelleneintrag oder eine Struktur im privaten Kernelspeicher vorstellen, in der hinterlegt ist, wer welche Zugriffsrechte hat, welche ID gilt sowie den Lock-Zustand. Die Datenstruktur befindet sich also auf Kernel-Level, nur der Zeiger darauf oder die ID ist im User-Level.

11.2 Unbenannter Semaphor

157

Abbildung 11.2. Semaphore zwischen zwei Prozessen

Sehr viel detaillierter k¨ onnen Semaphore in [Gray] oder in [Stev] nachgelesen werden. POSIX spezifiziert, wie oben erl¨autert, zwei Typen von Semaphoren: • benannte Semaphore (nicht unter Cygwin) und • speicherbasierte Semaphore (memory-based semaphore). Attribute eines Semaphors sind pshared, die Angabe, ob der Semaphor zwischen Prozessen verwendet wird, und der Wert value, mit dem er initialisiert wird, siehe unten.

11.2 Unbenannter Semaphor Die Erzeugung und Verwendung von unbenannten speicherbasierten Semaphoren sind unter POSIX mit folgenden C-Aufrufen zu bewerkstelligen:

int sem_init(sem_t * semPtr, int shared, unsigned int value); // semPtr Zeiger auf ein Semaphor // shared != 0 Semaphor kann von // mehreren Prozessen verwendet werden. // value Startz¨ ahler des Semaphors int sem_wait(sem_t * semPtr); // Der Z¨ ahler wird versucht zu erniedrigen. Falls

158

11 Synchronisierungsmechanismen f¨ ur Prozesse und Threads

// Wert <= 0, wird rufender Thread blockiert. int sem_trywait(sem_t * semPtr); // Versuch, Semaphor zu holen. Es wird // 0 zur¨ uckgegeben, falls alles OK ist int sem_timedwait(sem_t * semPtr, const struct timespec *abs_timeout) // Warten mit Timeout. Nur POSIX-draft, // wird aber von QNX unterst¨ utzt int sem_post(sem_t * semPtr); // Inkrement. des Semaphors, Freigabe int sem_destroy(sem_t * semPtr); // Sem.l¨ oschen Listing 11-2. C-Funktionen f¨ ur unbenannte Semaphore

Ein einfaches Beispiel, wie ein Semaphor erzeugt wird, zeigt folgendes Listing: sem_t mySem; int pshared = TRUE; // shared unsigned int value = 1; // Startwert if (sem_init(&mysem, pshared, value)) { /* eigene Fehlerbehandlung */} ......

Ein weiteres Beispiel zeigt, wie ein benannter Semaphor gelockt wird. Es wird der Systemaufruf sem trywait verwendet, ist der Semaphor verf¨ ugbar, wird er gelockt, ist er es nicht, kommt der Aufruf mit -1 zur¨ uck. Die andere Variante ist sem wait, hier wird der rufende Prozess blockiert, solange der Semaphor besetzt ist. if (0 == sem_trywait(sem)) { // sem_trywait() succeeded!\n" ... } else if (errno == EAGAIN) { // semaphore is already locked ... } else { // eigene Fehlerbehandlung ... }

In speziellen Situationen k¨ onnen Semaphore f¨ alschlicherweise mit einem Wert ungleich Null zur¨ uckkommen und Freigabe signalisieren. Dies kann beim Start und bei Unterbrechungen durch Signale passieren. Daher muss diese Bedingung abgefragt werden: In der globalen Fehlervariablen errno ist dann der Fehlercode EINTR hinterlegt.

11.2 Unbenannter Semaphor

159

while (sem_wait(&sem) && EINTR == errno) { // do nothing ; } doCriticalRegion();

Wird der benannte Semaphor nicht mehr gebraucht oder soll der Prozess geschlossen werden, kann man den Semaphor wie folgt schließen: int sts; sts = sem_destroy(&sem); ...

/* Removing unnamed semaphor */

Ein Beispiel f¨ ur ein Produzent-Konsument-Szenario mit zwei Semaphoren folgt im unten stehenden Programmst¨ uck. Normalerweise werden immer zwei Semaphore ben¨otigt. Hier wird z.B. mit einem Semaphor sCanGetSemaphore gepr¨ uft, ob der Speicher zugreifbar ist, und mit einem zweiten sCanWriteSemaphor, ob geschrieben werden darf, d.h., der letzte Wert wurde bereits vom Konsumenten ausgelesen. Die beiden Akteure bauen damit u ¨ber Kreuz einen Handshake auf.

sem_t sCanWriteSemaphore; sem_t sCanGetSemaphore; int sCounter = 0;

// globale Variablen

void producerFunc(void) { for (int i = 0; i < 100; i++) { sem_wait(&sCanWriteSemaphore); sCounter++;

// Producer

// take or wait // jetzt kann ich // schreiben

// mit Testausgabe sieht man Verzahnung sOwnCout<< "Producer "’ << sCounter << endl; // client Semaphore freigeben sem_post(&sCanGetSemaphore); } sCounter++; // damit kann der Consumer terminieren (Schleife verlassen // man beachte die letzte Ausgabe ! // sonst verklemmt consumer ggf. auf der 100 } void consumerFunc(void) { while (sCounter <= 100) {

// 100 mal abholen

160

11 Synchronisierungsmechanismen f¨ ur Prozesse und Threads sem_wait(&sCanGetSemaphore); // take or wait // jetzt counter lesen/ausgeben sOwnCout<< "Counter "’ << sCounter << endl; // schreib Sem. freigeben sem_post(&sCanWriteSemaphore); }

} // Namen f¨ ur Typ Funktionszeiger typedef void * (* threadProc)(void *); int main() { pthread_attr_t attr; pthread_attr_init(&attr); size_t size = 1000; pthread_attr_setstacksize(&attr, size); // init Schreibschutz nicht aktiv sem_init(&sCanWriteSemaphore, 0, 1); // init Zugriffsschutz aktiv sem_init(&sCanGetSemaphore, 0, 0);

// Init mit Defaultwerten // f¨ ur Stack-Ggr¨ oße

pthread_t threadID1; pthread_t threadID2; pthread_create(&threadID1, &attr, (threadProc) producerFunc, NULL); pthread_create(&threadID2, &attr, (threadProc) consumerFunc, NULL); pthread_join(threadID1, NULL); pthread_join(threadID2, NULL); return 0; } Listing 11-3. Synchronisierter Produzenten-/Konsumenten-Zugriff zweier Threads

Zu beachten ist, dass nicht in allen Linux-Versionen ein unbenannter Semaphor mit shared-Eigenschaften f¨ ur Prozesse angeboten wird. Dies wird unter anderem der Grund f¨ ur eine eigene Simulation des Semaphors mit Bedingungsvariablen sein.

11.3 Benannter Semaphor Man kann mit sem open, sem close und sem unlink einen benannten Semaphor u ¨ber das OS zugreifen. Benannte Semaphore sind aber relativ langsam im Vergleich zu anderen Synchronisationsmechanismen.

11.4 Mutex, rekursiver Mutex

161

sem_t * sem_open( const char * sem_name, int oflags,... ); ... int sem_close(const char *sem_name); // closing named semaphore int sem_unlink(const char* sem_name); // unlinking it .. Listing 11-4. Erzeugen und Schließen eines benannten Semaphors

11.4 Mutex, rekursiver Mutex Ein Mutex (mutual exclusion = wechselseitiger Ausschluss“) wird meistens ” verwendet, um einen kritischen Abschnitt zu sch¨ utzen. Der Abschnitt wird von dem Prozess gesch¨ utzt, der ihn gerade betritt bzw. bereits betreten hat. Dementsprechend ist es sinnvoll, dass ein Mutex auch nur durch den Prozess/Thread freigegeben werden kann, der den Mutex vorher genommen hat. Es handelt sich also um einen exklusiven Semaphor mit den Zust¨anden locked (>=1) und unlocked (=0). Im Gegensatz zum Semaphor geh¨ ort“ der Mutex dem Task, der ihn ” kreiert hat. Dies hat zum einen zur Folge, dass Mutex-Locks schneller als Semaphoren-Locks sind, zum anderen k¨ onnen sie nur zwischen Prozessen synchronisieren, wenn sie die Lokalisierung im Shared-Memory erlauben. Außerhalb des Shared-Memory kann ein fremder Prozess die Mutex-Variable nicht adressieren. Mutex-Variablen k¨ onnen rekursiv verwendet werden, das heißt, ein Thread kann eine Mutex-Variable mehrfach sperren. Sie muss dann genauso oft wieder freigegeben werden. Dies ist sinnvoll, wenn innerhalb eines Threads in einer Methode durch die Aufrufe weiterer Funktionen in unterschiedlicher Reihenfolge die gesch¨ utzte Ressource mehrfach belegt werden kann, [Schmi]. Ohne diese Rekursionsf¨ ahigkeit k¨ onnte es zur dauerhaften Blockade kommen (Deadlock), wenn der Thread innerhalb der gelockten Passage erneut versucht, den Mutex zu locken. Der Thread w¨ urde sich dabei selbst blockieren. Ein Mutex wird u ¨ber die OS-Anweisung int pthread_mutex_init (pthread_mutex_t *mutex, const pthread_attr_t *attr); int pthread_mutex_destroy (pthread_mutex_t * mutex);

¨ erzeugt bzw. wieder zerst¨ ort. Uber die unten stehenden Funktionen int pthread_mutex_lock(

pthread_mutex_t *mutex); //blockiert falls // mutex gelockt int pthread_mutex_unlock( pthread_mutex_t *mutex); //freigeben int pthread_mutex_trylock(pthread_mutex_t *mutex); //nicht blockieren

162

11 Synchronisierungsmechanismen f¨ ur Prozesse und Threads

Abbildung 11.3. Zustandsdiagramm der m¨ oglichen Mutex-Zust¨ ande

l¨asst sich ein Mutex probehalber oder blockierend belegen bzw. wieder freigeben. Die Funktion pthread mutex trylock gibt, falls der Mutex blockiert ist, sofort einen Wert zur¨ uck und f¨ uhrt somit nicht zu einer Blockade des aufrufenden Prozesses. Alle Funktionen geben 0 zur¨ uck, wenn der Aufruf in Ordnung ist, sonst einen positiven Fehlercode. Der Aufruf pthread mutex lock kann einen Task blockieren.

Int32 retVal; pthread_mutexattr_t attribut; //Mutexattr pthread_mutex_t mMutex; //Mutex //init the attribut with default values retVal = pthread_mutexattr_init(&attribut); ASSERTION(0 == retVal); //to avoid self-blocking we use recursive mutex. Remember: //unlock as often as you locked! pthread_mutexattr_settype(&attribut, PTHREAD_MUTEX_RECURSIVE); //init mutex with defined structure retVal = pthread_mutex_init(&mMutex,&attribut); ASSERTION(0 == retVal); if (!isFull) //initially owned ? pthread_mutex_lock(&mMutex); pthread_mutexattr_destroy(&attribut); //destroy the attribute ... Listing 11-5. Erzeugung einer Mutex-Variablen

11.4 Mutex, rekursiver Mutex

163

Im Folgenden Programmst¨ uck werden eine Mutex-Variable erzeugt und die Default-Attribute ausgelesen. In den Testausgaben finden sich Erkl¨arungen dazu:

int main() { int retVal; int val; pthread_mutexattr_t attr; pthread_mutexattr_init(&attr); retVal=pthread_mutexattr_getprotocol(&attr,&val);

//protocol

if (val == PTHREAD_PRIO_INHERIT) { sOwnCout<<"Protocol prio inherit" << endl; } else if (val == PTHREAD_PRIO_PROTECT) { sOwnCout<<"Protocol prio protect" << endl; } else { sOwnCout<< "protocol prio none " << endl; } //shared zwischen Prozessen retVal=pthread_mutexattr_getpshared(&attr,&val); if (val == PTHREAD_PROCESS_SHARED) { sOwnCout<< "shared between processes " << endl; } else { sOwnCout<<"shared only in the same process" << endl; } retVal = pthread_mutexattr_gettype(&attr, &val); //Typ if (val == PTHREAD_MUTEX_RECURSIVE) { sOwnCout<< "recursiv " << endl; } else { sOwnCout<< "not recursiv " << endl; } return 0; } Listing 11-6. Lesen der Thread-Attribute

Man beachte das Attribut pshared, das bei Verwendung zwischen Prozessen verwendet werden muss. Ein weiteres Beispiel zeigt das Zusammenspiel zweier Threads mit einem globalen Z¨ahler. Zun¨achst in Pseudo-Code: Zugriff: Mutex_blockieren(); Z¨ ahler++; Mutex_freigeben();

164

11 Synchronisierungsmechanismen f¨ ur Prozesse und Threads

Main: Thread_1 mit Startfunktion Zugriff erzeugen; Thread_2 mit Startfunktion Zugriff erzeugen; Thread_1 und Thread_2 starten;

Nun die Implementierung:

volatile int sCounter = 0; //globale Variable pthread_mutex_t sMutex = PTHREAD_MUTEX_INITIALIZER; //Startfunktion des Threads. Der Thread erh¨ oht //die globale Variable sCounter zehn Millionen Mal. void threadFunc(void) { for (int i = 0; i < 10000000; i++) { pthread_mutex_lock(&sMutex); sCounter++; pthread_mutex_unlock(&sMutex); } } typedef void * (*threadProc)(void *); //zur Vereinfachung einen Namen //f¨ ur den Typ der Funktionszeiger int main() { pthread_t threadID1; pthread_t threadID2; clock_t start, end; start = clock(); pthread_create(&threadID1, NULL, //Defaultparameter (threadProc) threadFunc, NULL); pthread_create(&threadID2, NULL, //Defaultparameter (threadProc) threadFunc, NULL); pthread_join(threadID1, NULL); //warten bis Thread1 beendet pthread_join(threadID2, NULL); end = clock();

//warten bis Thread2 beendet

sOwnCout<< "Ergebnis " << sCounter << endl; sOwnCout<< "Ticks elapsed " << (end -start) << endl; return 0; } Listing 11-7. Implementierung eines Mutex-Schutzes f¨ ur eine Zugriffsfunktion

11.4 Mutex, rekursiver Mutex

165

Die ganzen doch recht low-Level gehaltenen C-Routinen f¨ ur das MutexHandling sollten f¨ ur den Anwender gekapselt werden. Zun¨achst die Prototypen:

class CMutex { public: // Create mutex semaphore //isFull: initial state of Mutex. false means empty //isProcessShared: true, mutex can be accessed by several processes CMutex(bool isFull = true, bool isProcessShared = false); ~CMutex(); //If mutex is locked by other task, our task will be queued //waitForEver: if true task will wait until mutex is free //return true if lock was successfully done bool take(bool waitForEver = true); //lock the mutex void give(void);

//free the mutex

private: CMutex(const CMutex& rhs); //to avoid misuse CMutex& operator=(const CMutex& rhs); pthread_mutex_t mMutex; // mutex }; // end of class CMutex inline void CMutex::give(void) { pthread_mutex_unlock(&mMutex); }

//unlock the mutex

//Nun die Implementierung: ... // class CMutex - Implementation file CMutex::CMutex(bool isFull, bool isProcessShared) { Int32 retVal; pthread_mutexattr_t attribut; // init the pthread_mutexattr_t with default values retVal = pthread_mutexattr_init(&attribut); ASSERTION(0 == retVal); // to avoid self-blocking we use a recursive mutex. // Remember : unlock as often as you locked! pthread_mutexattr_settype(&attribut, PTHREAD_MUTEX_RECURSIVE);

166

11 Synchronisierungsmechanismen f¨ ur Prozesse und Threads retVal =

pthread_mutexattr_setpshared(&attribut, isProcessShared ? //set sharing property PTHREAD_PROCESS_SHARED : PTHREAD_PROCESS_PRIVATE); //commented because retVal is not 0 with cygwin / visual c++ //ASSERTION(0 == retVal); // initialize the mutex with defined attr. structure retVal = pthread_mutex_init(&mMutex,&attribut); ASSERTION(0 == retVal); if (!isFull) pthread_mutex_lock(&mMutex); pthread_mutexattr_destroy(&attribut);

//initially owned ? //destroy the attribute

} CMutex::~CMutex() { pthread_mutex_destroy(&mMutex); }

//destructor

bool CMutex::take(bool waitForEver) //lock the mutex. { // try to lock, if locked already, get queued bool haveSem = (0 == pthread_mutex_trylock(&mMutex)); if ((false == haveSem) && (true == waitForEver)) { // caller will wait until the mutex is free haveSem = (0 == pthread_mutex_lock(&mMutex)); } return haveSem; //true if the lock was successfully done } Listing 11-8. Klasse CMutex

Bei der Erzeugung eines CMutex-Objekts muss in den Attributen mit pshared angegeben werden, ob der Mutex zwischen Prozessen geteilt wird oder nicht. Ferner kann der Typ des Mutex im Konstruktor festgelegt werden. Dieser Parameter legt das Verhalten des CMutex-Objekts im Fall von mehrfachen lock-Aufrufen fest. Mutexe unterst¨ utzen unter QNX Priorit¨ aten-Vererbung und PriorityCeiling. Mithilfe der beiden Methoden setPrioriryInheritanceProtocol und setPriorityCeiling kann dies entsprechend eingestellt werden. Wir kommen darauf noch zu sprechen.

11.5 Mutex-Guard

167

11.5 Mutex-Guard Es ist sinnvoll, eine Guard-Klasse f¨ ur Mutexe zu entwerfen, die daf¨ ur sorgt, dass ein am Anfang gelockter Mutex beim Verlassen eines lokalen Bereichs automatisch freigegeben wird. Der Einsatz solcher Objekte ist besonders hilfreich, wenn die Methode oder Funktion mehrere Ausg¨ange (return) hat. Diese Guard-Klasse nutzt die automatische Zerst¨ orung eines lokalen Objekts aus, um den u ¨berwachten Mutex freizugeben.

//helpe class to autorelease the mutex class CMutexGuard { public: //mutex mutex to guard CMutexGuard(CMutex& mutex) : mMutexPtr(&mutex), mIsOwner(false) { take(); } ~CMutexGuard() { give(); } void take(void) { if (mMutexPtr->take()) { mIsOwner = true; } } void give(void) { if (true == mIsOwner) { mMutexPtr->give(); } } private: //to avoid misuse CMutexGuard(const CMutexGuard&); const CMutexGuard& operator=(const CMutexGuard&); //mutex to guard

168

11 Synchronisierungsmechanismen f¨ ur Prozesse und Threads CMutex* mMutexPtr; //to remember whether the lock is successful bool mIsOwner;

}; Listing 11-9. Guard-Klasse

11.6 Signale Signale sind asynchron zu dem laufenden Prozess und stellen eine Art Interrupt durch Software dar. Signale werden bei fehlerhaften Instruktionen vom Betriebssystem generiert, wie z.B. bei der Division durch Null oder durch eine gew¨ unschte Notifizierung eines Tasks durch einen anderen, dass er terminiert hat. Signale k¨onnen auch durch bestimmte Tastatur-Keys ausgel¨ost werden, z.B. durch ctrl-C oder durch den System-Timer. Beim Auftreten eines Signals wird eine Handler- oder Service-Routine angesprungen. Wie bei HW-Interrupts k¨ onnen Signale bedient werden (serviced), ignoriert werden (ausmaskiert), k¨onnen noch anstehen (pending) oder k¨onnen blockiert werden (disable). Es gibt eine große Anzahl von Signalen, die bereits im System vorgegeben sind. Lediglich zwei Signale SIGUSR1 und SIGUSR2 k¨onnen von Applikationen frei definiert werden. In einigen Implementierungen gibt es keine Priorit¨atenvergabe f¨ ur Signale. Signale k¨onnen keine zus¨ atzlichen Daten oder Informationen beif¨ ugen. Wenn blockierte Signale nicht schnell genug bedient werden und bereits neue Signale eintreffen, gehen diese verloren. Da wir Signale im Teil 2 nicht verwenden werden, sei zur Vertiefung auf [Tan] verwiesen.

11.7 Bedingungsvariablen (Condition Variables) Stellen wir uns vor, dass wir eine zweifache Abfrage brauchen. Ein Z¨ahler wird von einem Produzenten-Prozess regelm¨ aßig hochgez¨ahlt. Ein zweiter Prozess (Konsument) pr¨ uft die Daten regelm¨ aßig. Mit einem Semaphor oder einem Mutex sch¨ utzen wir den Z¨ ahler vor unkoordinierten Zugriffen. Bisher ist die Synchronisierung mit einem Semaphor m¨oglich. Nun aber verlangen wir, dass nur, wenn der Z¨ ahler einen bestimmten Wert hat, der zweite Prozess seinen Programmfluss fortsetzen soll. Der normale Weg w¨ are, durch Prozess 2 zun¨achst zu pr¨ ufen, ob er auf den Z¨ahler zugreifen kann, falls nicht, wird er blockieren. Ist der Semaphor

11.7 Bedingungsvariablen (Condition Variables)

169

frei, wird Prozess 2 ihn nehmen, um dann im kritischen Bereich zu pr¨ ufen, ob der Wert des Z¨ahlers erreicht ist. Ist er das nicht, wird der Zugriffs-Semaphor wieder freigegeben und der Prozess 2 muss in regelm¨aßigen Abst¨anden erneut fragen. Das Verfahren wird demnach zu einem ungewollten Polling, das viel Rechenleistung verbrauchen kann. Alternativ k¨onnte man zuerst auf den Z¨ ahlerstand pr¨ ufen, ihn also durch irgendeine Implementierung selbst zum Semaphor machen. Falls der gew¨ unschte Stand erreicht ist, m¨ usste Prozess 2 anschließend auf den Zugriffs-Semaphor locken. Geht das gerade nicht, beginnt ein anderer Polling-Zyklus. Auch ein sem trylock ist nichts anderes als Polling, wenn man ihn regelm¨aßig wiederholen muss. Versucht man, innerhalb des kritischen Bereichs zu warten, kann man Verklemmungen verursachen. Diese k¨ onnten Deadlocks mit passivem Warten oder Livelocks mit aktivem Warten sein. Einen ¨ahnlichen Fall hatten wir bei Queues: Wir d¨ urfen nur dann in die Queue schreiben, wenn sie zugreifbar und nicht voll ist. Der eine Semaphor pr¨ uft canAccess, der andere canWrite. Einer von beiden kann die Queue locken, der andere muss gepr¨ uft werden. Trifft die Bedingung nicht zu, wird der erste Semaphor wieder freigegeben und das Ganze beginnt in einer PollingSchleife von neuem. Gesucht ist eine M¨ oglichkeit zu warten, ohne dass Synchronisationsobjekt f¨ ur andere zu blockieren. Eine gute L¨osung kann mit einer Bedingungsvariablen (condition variable) erreicht werden, mit der die Belegung kritischer Abschnitte an Bedingungen gekn¨ upft wird. Eine Bedingungsvariable ist immer mit einem Mutex verbunden. Der Ablauf ist wie folgt: 1. Prozess/Thread 2 sperrt einen Mutex und schaut sich einen gemeinsamen Datenbereich an. 2. Der Datenbereich ist nicht so, wie erwartet (z.B. keine neuen Daten vorhanden, es ist nicht der richtige Z¨ ahlerstand etc.). 3. Prozess 2 wartet blockierend auf die Bedingungsvariable und gibt gleichzeitig den Mutex frei. 4. Prozess 1 nimmt sich den Mutex. 5. Prozess 1 schreibt Daten, setzt die Bedingungsvariable und gibt den Mutex an den Kernel frei. 6. Prozess 2 wird durch die Bedingungsvariable aufgeweckt und u ¨bernimmt den Mutex. 7. Prozess 2 kann nun die Daten bearbeiten. 8. Prozess 2 gibt den Mutex frei. Es gibt hier zwei unteilbare Vorg¨ ange: Zun¨achst blockiert Prozess 2 auf die Bedingungsvariable und gibt gleichzeitig unteilbar den Mutex frei. Man nennt dies eine atomic unlock-and-wait operation“. ”

170

11 Synchronisierungsmechanismen f¨ ur Prozesse und Threads

Sp¨ater setzt Prozess 1 die Bedingungsvariable. Prozess 2 wird geweckt und u bernimmt unteilbar den Mutex. Man nennt dies eine atomic resume-and¨ ” lock operation“. Eine Bedingungsvariable kann durch die folgende Anweisung erzeugt und initialisiert werden: pthread_cond_t myCondition = PTHREAD_COND_INITIALIZER;

Wie bei Mutex wird ggf. ein Attribut-Objekt verwendet, um eine Bedingungsvariable zu initialisieren: • Ein Objekt vom Typ pthread condattr t wird definiert. • Das Objekt wird mit int pthread condattr init(pthread condattr t * attrPtr) initialisiert. • Attribut pshared wird durch die Funktion int pthread_condattr_setpshared(pthread_condattr_t *attrPtr, int typ)} gesetzt, wobei typ entweder PTHREAD PROCESS SHARED oder PTHREAD PROCESS PRIVATE ist. • Letzlich mit int pthread_cond_init(pthread_cond_t *condPtr, pthread_condattr_t * attrPtr) wird die Bedingungsvariable initialisiert. Eine Bedingungsvariable unterst¨ utzt vier Operationen: // Lock die Bedingungsvariable, Freigabe Mutex und Warten wait (pthread_cond_wait); // Lock die Bedingungsvariable, Freigabe und Warten mit timeout wait (pthread_cond_timedwait); // Unlock Bedingungsvariable. Nur ein Thread, der blockiert wurde, // wird notifiziert signal (pthread_cond_signal); // Unlock Bedingungsvariable. Alle Threads, die blockiert wurden, // werden notifiziert broadcast (pthread_cond_broadcast);

In der Anwendung muss man zusammen mit einer Bedingungsvariablen einen Mutex und ein Pr¨ adikat (Bedingung) angeben. Die Warte-Funktionen sind wie folgt definiert:

11.7 Bedingungsvariablen (Condition Variables)

171

int pthread_cond_wait(pthread_cond_t * condPtr, pthread_mutex_t *mutexPtr); int pthread_cond_timedwait(pthread_cond_t * condPtr, pthread_mutex_t *mutexPtr, const struct timespec *abstime);

und werden verwendet, um auf eine bestimmte Bedingung zu warten. Dabei gilt f¨ ur die Zeitangabe: typedef struct timespec { time_t tv_sec; long tv_nsec; } timespec_t

/* seconds */ /* nanoseconds */

Um wartende Tasks zu wecken, benutzt man die Funktionen int pthread_cond_signal(pthread_cond_t * condPtr) int pthread_cond_broadcast(pthread_cond_t * condPtr)

Ein typisches Beispiel einer Bedingungsvariablen-Anwendung sieht wie folgt aus:

pthread_mutex_lock( &myMutex ); ... //critical section while (!condition) { pthread_cond_wait( &condVar, &myMutex ); } ... //critical section cntd. pthread_mutex_unlock( &myMutex ); //Freigabe Listing 11-10. Typische Bedingungsvariablen-Anwendung

Man sieht, dass der Ablauf im kritischen Abschnitt mit pthread cond wait blockiert wird. Die Bedingungsvariable wird gelockt und gleichzeitig der Mutex wieder freigegeben. Damit wartet dieser Task zwar auf das Eintreten der Bedingung, die Daten des kritischen Bereichs und der Mutex sind aber f¨ ur andere Tasks in dieser Zeit nutzbar. Einer dieser Tasks kann dann z.B. den Mutex f¨ ur sich nehmen, die Bedingung erf¨ ullen und den wartenden Task mit pthread cond signal wecken. Zusammen mit dem Signal gibt er den Mutex so frei, dass ein auf die Bedingungsvariable wartender Task mit der h¨ochsten Priorit¨at den Mutex bekommt. Die while-Schleife ist aus zwei Gr¨ unden erforderlich: Erstens erlaubt POSIX falsche Wakeups im Hochstart und bei Interrupts durch Signale (siehe Semaphore). Zweitens soll u uft werden, ob die Be¨berpr¨ dingung wirklich erf¨ ullt ist. Die Implementierung im zweiten Prozess, der die Bedingung/das Pr¨adikat erf¨ ullen soll, k¨onnte wie folgt aussehen:

172

11 Synchronisierungsmechanismen f¨ ur Prozesse und Threads

pthread_mutex_lock( &myMutex ); ... pthread_cond_signal(&condVar); pthread_mutex_unlock(&myMutex);

//Mutex nehmen //Bedingung erf¨ ullen //signal condVar erf¨ ullt //Mutex freigeb

Listing 11-11. Code-Beispiel f¨ ur die Freigabe einer Bedingungsvariablen

Ein weiteres Anwendungsbeispiel f¨ ur Bedingungsvariable w¨are das Folgende: Unter Verwendung von Mutex und Bedingungsvariablen kann man Semaphore simulieren. Dies kann aus Performance-Gr¨ unden sinnvoll sein, da Mutex-Variablen performanter sind als Semaphore oder weil es in manchen Betriebssystemen die sem trylock-Funktion mit Timeout nicht gibt. Prinzipiell wird zun¨ achst in der take-Methode eine Mutex-Variable, die die eigentliche selbst gemachte“ lokale Semaphor-Variable mCounter sch¨ utzt, ” gelockt, damit kein anderer Zugriff dazwischen kommt. Dann wird die eigene Semaphor-Variable mCounter gepr¨ uft, ob sie blockiert oder frei signalisiert. Ist der Semaphor frei, wird er geblockt. Ist er nicht frei, wird durch einen unteilbaren Zugriff gleichzeitig der Mutex-Schutz freigegeben und der eigene Task mit einer Bedingungsvariablen blockiert. Der selbst gemachte Semaphor ist also wieder frei f¨ ur Pr¨ ufungen oder f¨ ur die Freigabe durch andere Tasks. Gleichzeitig wartet dieser Task auf seine Freigabe. Diese kann durch Timeout erfolgen oder durch besagte Freigabe eines give-Aufrufes eines anderen Tasks. Wir verwenden gleich einen objektorientierten Ansatz, die Methoden take und give sind in der Prototypdatei gut zu erkennen:

//semaphor must be simulated bcs. Linux missing shared //and windows missing sem_timedwait attribut #include class CBinarySemaphore { public: //false = empty, full default state CBinarySemaphore(bool isFull = true, bool isProcessShared = true); ~CBinarySemaphore(); //waitForEver=true task waits until sem is free bool take(bool waitForEver = true); //timeOut is time in millisecs until task returns //if -1 the task will wait until sem is free forever //return true if the lock is successfully done bool takeWithTimeOut(int timeOut);

11.7 Bedingungsvariablen (Condition Variables) //unlock the semaphor void give(void); private: pthread_mutex_t mMutex; pthread_cond_t mCondition; int mCounter; };

173

//mutex //condvar to implement take with timeout //counter(0/1)-Int32 used for efficiency

Listing 11-12. CBinarySemaphore.h

Die objektorientierte Implementierung ist etwas schwerer zu lesen, die Aufrufe f¨ ur den Applikateur sind jedoch sehr leicht zu verwenden.

CBinarySemaphore::CBinarySemaphore(bool isFull, bool isProcessShared) : mCounter(1) { Int32 retVal; //init the pthread_mutexattr_t with default values pthread_mutexattr_t mutexAttribut; retVal = pthread_mutexattr_init(&mutexAttribut); ASSERTION(0 == retVal); //for safety we set the values explicitely! needed // for pthread_cond_wait retVal = pthread_mutexattr_settype(&mutexAttribut, PTHREAD_MUTEX_ERRORCHECK); ASSERTION(0 == retVal); //set the sharing property retVal = pthread_mutexattr_setpshared(&mutexAttribut isProcessShared ? PTHREAD_PROCESS_SHARED : PTHREAD_PROCESS_PRIVATE); //out commented because retVal is 0 with cygwin //ASSERTION(0 == retVal); //initialize the mutex with defined structure retVal = pthread_mutex_init(&mMutex,&mutexAttribut); ASSERTION(0 == retVal); //destroy the mutex attribut retVal = pthread_mutexattr_destroy(&mutexAttribut); ASSERTION(0 == retVal); //Attribut for condition variable pthread_condattr_t conditionAttribut; retVal = pthread_condattr_init(&conditionAttribut); ASSERTION(0 == retVal); //set the pshared-attribut of the condition variable retVal = pthread_condattr_setpshared(&conditionAttribut,

174

}

11 Synchronisierungsmechanismen f¨ ur Prozesse und Threads isProcessShared ? PTHREAD_PROCESS_SHARED :PTHREAD_PROCESS_PRIVATE); //the following assertion is out commented to avoid problem //with cygwin (pthread_condattr_setpshared is not supported) //ASSERTION(0 == retVal); //init the condition variable. Second parameter is always //ignored in Linux pthread_cond_init(&mCondition, &conditionAttribut); //destroy the attribut pthread_condattr_destroy(&conditionAttribut); //reset the counter if needed if (false == isFull) { mCounter = 0; } //end of constructor

CBinarySemaphore::~CBinarySemaphore() { //destroy the mutex pthread_mutex_destroy(&mMutex); //destroy the condvar Int32 retVal = pthread_cond_destroy(&mCondition); //if a thread still holds the condvar we can not delete it ASSERTION(EBUSY != retVal); (void) retVal; //avoid "unused variable", }

//end of destructor

bool CBinarySemaphore::take(bool waitForEver) //lock semaphore { //If sem is locked by other task //task will be queued bool result = true; pthread_mutex_lock(&mMutex); //free? if (mCounter == 1) { mCounter = 0; } else if (false == waitForEver) { result = false; } else { //idiom when working with condition variable while (0 == mCounter)

11.7 Bedingungsvariablen (Condition Variables)

175

{ //calling pthread_cond_wait will release mMutex! The calling //thread is blocked until the signal is true pthread_cond_wait(&mCondition, &mMutex); } //reset the counter to signal that we have taken it mCounter = 0;

}

} pthread_mutex_unlock(&mMutex); return result; //end of take

bool CBinarySemaphore::takeWithTimeOut(Int32 timeOut) { ASSERTION(-1 <= timeOut); //delegate the case -1 if (-1 == timeOut) { return take(true); } else if (0 == timeOut) { return take(false); } bool result = true; pthread_mutex_lock(&mMutex); if (mCounter == 1) { mCounter = 0; } else { //counter is not free struct timeval now; struct timespec timeExpire; //get the current time gettimeofday(&now, NULL); //calculate the timeout: seconds timeExpire.tv_sec = now.tv_sec + (timeOut/1000); //and nano second timeExpire.tv_nsec=(now.tv_usec+(timeOut %1000)*1000)*1000; Int32 retcode = 0; while ( (0 == mCounter) && (ETIMEDOUT != retcode) ) { retcode = pthread_cond_timedwait(&mCondition, &mMutex, &timeExpire); } //check whether the condition is OK or timeout

176

}

11 Synchronisierungsmechanismen f¨ ur Prozesse und Threads result = (ETIMEDOUT != retcode); //if mCounter is 1 in the time interval given //we must set it to zero again if (true == result) { mCounter = 0; } } pthread_mutex_unlock(&mMutex); return result; //end of takeWithTimeOut

void CBinarySemaphore::give(void) { pthread_mutex_lock(&mMutex); mCounter = 1; //we use signal instead of broadcast because of efficiency pthread_mutex_unlock(&mMutex); pthread_cond_signal(&mCondition); } //end of give Listing 11-13. Objektorientierte Implementierung CBinarySemaphore.cpp

In der Literatur [Stev] und in diversen Internet-Foren wird die Frage der Reihenfolge der letzten beiden Zeilen diskutiert. Sie scheint noch nicht abgeschlossen zu sein. Wird erst der Mutex freigegeben, so k¨ onnte im kritischen Fall ein anderer statt des wartenden Prozesses den Mutex nehmen, da die Bedingungsvariable noch nicht frei ist. Diese Frage ist implementierungsabh¨angig, da das OS eine Warteliste f¨ ur den Mutex f¨ uhrt und normalerweise den BedingungsvariablenKandidaten zuerst f¨ uhrt. Das Scheduling-Verhalten w¨are also ggf. nicht vorhersagbar. Wird zun¨achst pthread cond signal freigegeben und erst anschließend pthread mutex unlock, k¨ onnte es im schlimmsten Fall dazu f¨ uhren, dass ein Prozess das Signal verliert (er l¨ auft los und wird dann sofort gestoppt, weil der Mutex nicht frei ist). Auch hier wieder der Hinweis auf die Implementierungsabh¨angigkeit im OS. F¨ ur unsere Anwendung, in der wir den simulierten Semaphor nur zum Signalisieren verwenden, kommt das Problem mehrerer Mutex-Wartenden nicht vor, so dass die Reihenfolge nicht relevant ist. Diese etwas kompliziert anmutende oben stehende L¨osung hat mehrere gute Gr¨ unde: • •

Linux bietet keinen unbenannten Shared-Semaphor an. Cygwin bietet kein Warten auf Semaphore mit Timeout (sem timedwait) an. • Vermeidung von Polling.

11.9 Deadlock, Livelock und Priorit¨ atsinversion

177

11.8 Zeitverhalten Das Zeitverhalten f¨ ur die einzelnen Synchronisationsmethoden wurde mit dem Programm Testall und und der Klasse CSyncBenchmark getestet, siehe unser Link. Es f¨ uhrt jeden Vorgang (warten, freigeben) 10000 mal durch und misst die ben¨otigte Zeit. Auf dem Target (SH4, 240 MHz) liefert es unten stehende Ergebnisse. SH4 240 MHz Synchronisationsmechanismus [ us ] Benannte Semaphore 92 Unbenannte Semaphore 5,7 Mutex 0,4 Celeron Notebook QNX SyncMethode Zeit f¨ ur 1M Vorg¨ ange POSIX Mutex 1,3626 s CMutex 1,6113 s Condition-Variable 2,7096 s POSIX Semaphore 4,8256 s

Zeit proVorgang 0,00136 ms 0,00161 ms 0,00271 ms 0,00483 ms

Verh¨ altnis 1,00-fach 1,18-fach 1,99-fach 3,54-fach

Abbildung 11.4. Zeitverhalten der Synchronisationsmethoden

11.9 Deadlock, Livelock und Priorit¨ atsinversion Man kann durch wechselseitige Synchronisation mit Semaphoren ungewollte Verklemmungen erzeugen. Deadlock: Ein sehr praxisrelevantes Problem ist die Blockade zweier Prozesse, die aufeinander warten und sich gegenseitig blockieren. Das typische Beispiel daf¨ ur sind zwei nebenl¨aufige Prozesse, die miteinander u ussen. ¨ber Queues kommunizieren m¨ Man kann Queues so implementieren, dass Schreib- und Lesez¨ahler sich nicht in die Quere kommen k¨ onnen, also niemals die gleiche Speicherstelle adressieren. Kritisch k¨onnen dennoch der Leer- und der Voll-Fall werden. Schlecht implementiert kann es passieren, dass beispielsweise Prozess A gerade einen Event in die Queue seines Gegen¨ ubers schreiben will und blockiert, weil dessen Queue voll ist. Er kann aber seine eigene Queue auch nicht leeren, da er ja gerade beim Schreiben blockiert. Das klassische Beispiel ist das bekannte Philosophenproblem von Dijkstra. Es gibt dazu viele verschiedene Versionen mit St¨abchen, Gabeln, Spagetti und anderen Speisen. Das Prinzip wird wie folgt beschrieben:

178

11 Synchronisierungsmechanismen f¨ ur Prozesse und Threads

Abbildung 11.5. Deadlock-Beispiel

Es sitzen f¨ unf Philosophen an einem (runden) Tisch, auf dem f¨ unf Teller randvoll gef¨ ullt mit Spagetti gedeckt sind, zwischen denen sich f¨ unf einzelne Gabeln befinden. Philosophen k¨ onnen aber nur mit zwei Gabeln Spagetti essen. Daraus folgt, dass nie alle Philosophen gleichzeitig essen k¨ onnen. Zum Essen braucht jeder Philosoph die Gabeln zu seiner linken und rechten Seite, hat er diese genommen, k¨onnen seine beiden Tischnachbarn nicht essen. Den gr¨oßten Teil des Tages besch¨aftigen sich Philosophen damit, zu denken. Nach unterschiedlicher Zeit bekommen sie Hunger, nehmen die Gabeln und beginnen, zu essen. Kommt es jedoch zuf¨ allig einmal vor, dass alle Philosophen gleich lange nachgedacht haben und alle gleichzeitig ihre linke Gabeln aufnehmen wollen, dann kann keiner essen, weil ihm seine rechte Gabel fehlt. Dies ist der Zustand Deadlock“. Die Philosophen verhungern in dieser ” Situation, weil keiner von ihnen auf die Idee kommt, seine linke Gabel wieder hinzulegen. Die H¨ alfte seines ben¨ otigten Werkzeuges hat er ja schon. Die Bedingungen f¨ ur das Auftreten einer Verklemmung sind wie folgt: 1. Exklusivit¨at: Nur ein Task kann eine Ressource benutzen. 2. Es gibt einen Task, der Ressourcen blockiert und gleichzeitig selbst auf weitere Ressourcen wartet (hold and wait). 3. Eine Ressource kann nur freiwillig vom Task freigegeben werden (non preemptive), es gibt keine Zeitscheibe, nach der der blockierende Prozess abgel¨ost wird und keinen Prozess h¨ oherer Priorit¨at, der diesen verdr¨angen kann und die Blockade l¨ ost. 4. Es gibt eine zirkulare Verkettung von Prozessen, die auf blockierte Ressourcen eines anderen Prozesses warten. Es ist hinreichend, nur eine der Bedingungen aufzubrechen, um die Verklemmung zu l¨osen.

11.9 Deadlock, Livelock und Priorit¨ atsinversion

179

Livelock Zwei Prozesse k¨ onnen sich derart verklemmen, dass beide noch aktiv laufen, also keiner auf einem Semaphor oder Mutex blockiert und dennoch nicht mehr fortschreiten. Dies kann passieren, wenn jeder Prozess in einer Schleife auf einen Variablenwert wartet, den der andere Prozess einstellen k¨onnte, wenn er nicht selbst in einer Schleife auf einen Variablenwert des ersten Prozesses warten w¨ urde. Begrenzte Priorit¨ atsinversion Verallgemeinert tritt Priorit¨ aten-Inversion auf, wenn ein hochpriorer Task A auf die Freigabe einer gemeinsamen Ressource oder eines kritischen Abschnitts durch einen niedrigprioren Task B warten muss. Es gibt zwei Arten der Priorit¨ats-Inversion, die begrenzte und die unbegrenzte. Die begrenzte Inversion kann bereits zwischen zwei Prozessen passieren, wenn ein niedrigpriorer Task B einen kritischen Bereich locked und noch vor der Freigabe von einem hochprioren Task A abgel¨ost wird. Dieser versucht dann, den kritischen Bereich zu locken und zu betreten, wird aber blockiert. Nun wird wieder der niedrigpriore Task B gescheduled und kann schließlich nach seiner Verarbeitungszeit den kritischen Bereich freigeben. Die Worst-Case-Zeit entspricht der zeitlichen L¨ange des kritischen Bereichs des niedrigprioren Tasks B. Begrenzte Inversion ist nicht zu kritisch, solange die kritischen Bereiche der niedrigprioren Tasks kurz gehalten werden k¨onnen.

Abbildung 11.6. Begrenzte Inversion

Unbegrenzte Priorit¨ atsinversion Nehmen wir nun an, dass ein hochpriorer Prozess A z.B. vor einem Mutex wartet und auf einen niedrigprioren Prozess C warten muss, weil dieser den Mutex h¨alt.

180

11 Synchronisierungsmechanismen f¨ ur Prozesse und Threads

Dieser Prozess C wird aber nicht gescheduled, da er ja niedrige Priorit¨at hat und gerade ein Prozess B mittlerer Priorit¨at aktiviert ist. Damit w¨ urde ein niedrigpriorer Prozess B oder C einen hochprioren blockieren, was den festgelegten Priorit¨ aten widerspr¨ache. Die Worst-Case-Zeit ist die Summe des kritischen Bereichs des niederprioren Tasks C und der Durchlaufzeit des Tasks B mittlerer Priorit¨at. Diese k¨onnte sehr lang sein, da die Programmierer davon ausgingen, dass Task B ja nur mittlere Priorit¨ at hat und deshalb von Task A mit hoher Priorit¨at unterbrechbar ist. Wartet ein Prozess auf eine IPC-Nachricht oder auf die Freigabe

Abbildung 11.7. Priorit¨ atsinversion

einer Mutex-Variablen, die von einem anderen Prozess blockiert ist, so erbt dieser die Priorit¨ at des Wartenden. Damit kann Priorit¨ atsinversion vermieden werden. Die beiden Mechanismen, mit denen die dauernde Blockierung vermieden werden k¨onnen, heißen Priority-Inheritance und Priority-Ceiling. Im ersten Fall erbt der Prozess, der den Mutex besitzt, die Priorit¨at des Prozesses, der gerade auf den Mutex warten muss. Nach Freigabe des Mutex“ ” wird die Priorit¨at zur¨ uckgesetzt. Im zweiten Fall wird der Prozess, der den Mutex in Besitz nimmt, auf die h¨ ochste vorkommende Priorit¨ at der Tasks gehoben, die auf den Mutex warten k¨ onnten. Wird der Mutex wieder freigegeben, setzt der Task seine Priorit¨at wieder auf den Originalwert zur¨ uck. Achtung: Semaphore und Bedingungsvariablen sind global und geh¨oren“ ” keinem bestimmten Prozess, daher kann es hier keine Vererbung der Priorit¨ at geben.

11.9 Deadlock, Livelock und Priorit¨ atsinversion

181

Sie sind also anf¨ allig f¨ ur Priorit¨ ats-Inversion und der Designer muss auf dieses m¨ogliche Problem achten. Die beste Idee, Blockierungen durch Synchronisation zu vermeiden, ist, keine Synchronisationen zu verwenden, sondern atomare Befehle. QNX bietet daf¨ ur atomare Befehle an, die auch von Interrupts nicht unterbrochen werden k¨onnen. Allerdings bieten nicht alle Betriebssysteme solche Konzepte, weshalb ansonsten atomare Befehle nur in der low-Level Treiberprogrammierung auf Assembler-Ebene m¨ oglich sind. Eine zweite einfache Strategie zur Vermeidung der Inversionen ist, Prozesse auf gleiche Priorit¨ at zu setzen und damit das regul¨are Round-Robin Scheduling zu nutzen. Weiterhin ist es sinnvoll, Mutex-Variablen zu bevorzugen und immer zum Schutz von Ressourcen und kritischem Code zu verwenden und das Attribut Priority-Inheritance zu aktivieren. Es gibt aber auch eine Art der Priorit¨ atsinversion, die in der Literatur weniger Beachtung findet. So kann bei einer Produzenten-KonsumentenKonstellation eine Blockade durch Inversion auftreten, ohne dass u ¨berhaupt eine Synchronisierung oder ein kritischer Bereich im Spiel ist. Nehmen wir an, der Konsument habe niedrigere Priorit¨ at als der Produzent und der Empfangspuffer sei voll. Er ist zwar f¨ ur den Produzenten zugreifbar und nicht blockiert, dennoch kann nicht eingeschrieben werden, da der Konsument noch keinen Platz im Puffer freiger¨ aumt hat. Es handelt sich hier also um eine Inversion auf h¨oherem abstraktem Level, der auch durch automatische Priorit¨ atsvererbung von Mutexen nicht l¨osbar ist. Diese Inversion kann ebenfalls begrenzt oder unbegrenzt auftreten. Wir werden in dem Kapitel u ogliche Abhilfen er¨ortern. ¨ber Queues m¨ Semaphore sind nur f¨ ur die Synchronisation zwischen Prozessen durch Signalisation sinnvoll. Wenn also z.B. ein Treiber nach erfolgtem Empfang sein Datenpaket in die Queue des Empf¨ angers gelegt hat und diesen zur Weiterverarbeitung wecken soll, so wird dies mit einem Semaphor realisiert. Derartige Treiberprogramme m¨ ussen sehr effizient und schnell implementiert werden und bekommen hohe Priorit¨at, so dass sie nicht durch lang dauernde, weniger wichtige Prozesse blockiert werden k¨ onnen. Prozesse, die mehr als ein paar Millisekunden lang Rechenleistung brauchen, werden grunds¨ atzlich auf niedrige Priorit¨at gesetzt. Ein u ¨berwachender Prozess, der dennoch auftretende Blockierungen detektieren k¨onnen soll, muss so implementiert werden, dass er selbst niemals blockiert. Zugriffe auf Mutexe, Semaphore oder Handles d¨ urfen in einem solchen Admin-Prozess nur nicht-blockierend implementiert werden. Dies kann im Teil II an dem Admin-Task studiert werden.

182

11 Synchronisierungsmechanismen f¨ ur Prozesse und Threads

11.10 Zusammenfassung Semaphore, Mutexe, Signale und Bedingungsvariablen sind f¨ ur verschiedene Anwendungsf¨alle gedacht. Alle dienen zur Synchronisation verschiedener Anwendungen, entweder in ihrem Ablauf oder in ihrem Zugriff auf gemeinsame Ressourcen. Mutex-Variablen k¨ onnen nur von dem Thread freigegeben werden, dem sie geh¨oren, der sie also vorher gesperrt hat. Nicht in allen Betriebssystemen lassen sich Mutex-Variablen auch zwischen Prozessen verwenden. Mutexe besitzen Vorrichtungen zur Vermeidung von Priorit¨ats-Inversion. Ein Mutex ist entweder gelockt oder frei, ¨ ahnlich des bin¨aren Semaphors. Bedingungsvariablen und Mutexe waren urspr¨ unglich f¨ ur die Synchronisation von Threads vorgesehen. Mutex-Variablen mit aktivierter Priorit¨ atsvererbung sind f¨ ur den Schutz kritischer Bereiche oder gemeinsamer Ressourcen die beste Wahl. Semaphore sind nicht sicher gegen Priorit¨ ats-Inversion, da Semaphore keinem Prozess/Thread geh¨ oren. Semaphore sind f¨ ur die Synchronisation mehrerer Prozesse die beste Wahl. Da Semaphore von beliebigen Prozessen wieder freigegeben werden k¨onnen, eignen sie sich gut f¨ ur Signal- und Interrupt-Handler. Ist ein Datenbereich durch einen Prozess gesch¨ utzt worden, so bleiben einem anderen Prozess vier prinzipielle M¨ oglichkeiten, sich zu synchronisieren: 1. Er blockiert und steht (lock) mit Mutex oder Semaphor. 2. Er wartet (wait) mit einer Bedingungsvariablen. 3. Er fragt regelm¨ aßig nicht blockierend, ob er nun zugreifen kann (Polling) mit Mutex oder Semaphor (trywait). 4. Er tut andere Dinge und wird durch ein Signal auf die Freigabe aufmerksam.

12 Kommunikation per Events

Normalerweise werden Events oder Messages im Umfeld von Zustandsautomaten (FSM = finite state machine) verwendet. Die Automaten nehmen Zust¨ande ein, die sich durch Ereignisse (empfangene Events) ver¨andern. Das klassische Beispiel jeder Grundausbildung ist die Ampelsteuerung mit ihren verschiedenen Ampelphasen als Zust¨ anden oder der Geb¨audeaufzug mit Stockwerken als Zust¨ anden. Events eignen sich gut zum Versenden zwischen verschiedenen Prozessoren oder Prozessen, da hier Callbacks bzw. Funktionsaufrufe u ¨ber Prozessgrenzen hinweg nicht funktionieren. In unserer Embedded-Automotive-Welt sind die groben Zust¨ande eines Zustandsautomaten die Bedien-Zust¨ ande des Ger¨ats, z.B. befindet es sich im Radio-Mode, im Navigations-Mode oder im Telefon-Zustand. Events werden durch Tastenbedienungen erzeugt oder durch Meldungen der angeschlossenen Ger¨ ate. Externe Events sind in diesem Umfeld immer asynchron, da Tastendr¨ ucke und KFZ-Nachrichten nicht synchronisiert auf den Takt und Ablauf im Ger¨ at sind. Allerdings gibt es auch generierte Events, z.B. innerhalb einer Headunit, die synchron ausgebildet sein k¨ onnen, so dass auf die Abarbeitung gewartet werden muss. Typische Windows-Applikationen nehmen neue Maus-Clicks erst an, wenn vorhergehende Aktionen beendet sind. ¨ Events werden u verwendet, sie ¨blicherweise zur asynchronen Ubertragung k¨ onnen aber per Cookie, per Quittungs-Events oder u ¨ber Einschr¨ankungen der ¨ ¨ Tiefe des Ubermittlungskanals auch zur synchronen Ubertragung verwendet werden. Events haben Namen, ggf. Empfangs- und Sende-IDs, Typinformationen, Parameter, m¨oglicherweise Guards, oft eine Liste mit dazugeh¨origen Aktionen und Cookies. Der Sender von Events meldet ein Ereignis, die Abarbeitung und passende Reaktion auf das Ereignis bleiben dem Empf¨ anger u ¨berlassen. Dies unterschei¨ ¨ det die Ubertragung von Events von der Ubertragung von Kommandos. ¨ Die Ubertragungsstrecke beginnt beim Sender, der ein Event zu einem Empf¨anger verschickt.

184

12 Kommunikation per Events

Normalerweise befindet sich auf der Empf¨angerseite eine Warteschlange (Queue), in die das Event eingetragen werden muss, da nicht garantiert werden kann, dass der Empf¨ anger die Nachricht sofort bearbeiten kann. Baldm¨oglichst holt sich ein Verteiler (Dispatcher) im Empf¨anger das a¨lteste Event aus der Warteschlange, gem¨ aß dem FIFO-Prinzip. Anschließend bestimmt er, welche Einheit oder welches Modul im Empf¨anger die Nachricht bekommt und verschickt sie dorthin, oder er ruft die passende Funktion auf. Die Art, wie die Einheit bestimmt wird, die das Event bekommt, kann verschieden sein. Sie kann sich aus dem Namen oder Typ des Events ergeben, aus einer mitgegebenen logischen Adresse im Event, sie kann aber auch in einer Registry niedergelegt sein. Dort wird f¨ ur alle m¨oglichen Ereignisse eingetragen, an wen sie weitergemeldet werden sollen. Events k¨onnen andere Events ausl¨ osen. So kann ein Men¨ uwechsel von Radio auf CD mehrere Events ausl¨ osen, mit denen die Radio-Musik leise geregelt wird, die Umschaltung angestoßen und die CD-Musik wieder laut geregelt wird. Physikalische Events wie das Tastensignal < + > k¨onnen durch den Kontext eines aktiven Bedienmen¨ us CD-Mode erst ihre logische Bedeutung eines bekommen. Es gibt einige Hauptarten von Events.

12.1 Wichtige Event-Typen 12.1.1 Signal-Events Signal-Events sind die normalen“ asynchronen Events, die z.B. zwischen ” Komponenten versendet werden. Der Sender der Events generiert Events und f¨ ullt sie mit der Nutzinformation, verschickt diese und k¨ ummert sich nicht um weitere Abl¨aufe. ¨ Ein Dispatcher verteilt nach der Ubertragung die Events an den oder die passenden Empf¨ anger, diese verarbeiten die Events und reagieren mit Zustandswechseln und ggf. mit Aktionen. Eventuell antworten sie ihrerseits auch mit Events an den urspr¨ unglichen ¨ Sender. Dieser hat w¨ ahrend dieser ganzen Ubertragungsund Verarbeitungszeit die Gelegenheit, sich um andere Aufgaben zu k¨ ummern. Erst beim Eintreffen einer Antwort bearbeitet er wieder die urspr¨ ungliche Aufgabe. Dieses Verhalten ist auf der einen Seite komfortabel und schnell, auf der anderen Seite muss auch mit nicht angeforderten oder sp¨aten Events zu jeder Zeit gerechnet werden. Dies k¨ onnen Events sein, die andere Komponenten im System von sich aus an unsere Komponenten schicken, oder z.B. asynchrone Tastatur- oder Timer-Events. Die Kopplung zwischen Komponenten oder Systemen per asynchroner ¨ Event-Ubertragung ist sehr lose“ und im Sinne echter Realzeit-Anforderung ” nicht deterministisch.

12.1 Wichtige Event-Typen

185

Durch die Event-Laufzeiten im System kann es auch zu Antwort-Events kommen, die nicht mehr zum inzwischen ver¨anderten Zustand des Senders passen. 12.1.2 Events mit Cookies Events mit Cookies k¨ onnen das oben beschriebene Problem l¨osen. Dem gesendeten Event wird eine Kennung mitgegeben, die der Empf¨anger bei seiner Antwort ebenfalls zur¨ ucksendet. Damit kann der urspr¨ ungliche Sender einordnen, zu welchem seiner Ereignisse die erhaltene Antwort geh¨ort. Asynchrone Events werden immer u ¨ber Warteschlangen (Queues) u ¨bertragen, normalerweise sind diese auf der Seite des Empf¨angers implementiert. Dort werden empfangene Events solange aufgesammelt (FIFO), bis der Empf¨anger sie abarbeiten kann. Ein wichtiges Prinzip im Bereich der Zustandsautomaten ist das so genannte RTC, run till completion. Es wird erst das n¨ achste Event aus der Queue akzeptiert und bearbeitet, wenn alle Aktionen zu dem jetzigen Event abgeschlossen sind (completion). 12.1.3 Call-Events Call-Events sind synchron versendete Events. Der Sender bleibt nach dem Senden des Events solange blockiert, bis die Abarbeitung des Events erfolgt ist. Abarbeitung kann bedeuten, dass der Empf¨anger das Event konsumiert oder aus der Queue geholt haben muss, es kann aber auch heißen, dass eine Antwort des Empf¨ angers seinerseits zwingend ist und erst abgewartet werden muss. Realisiert werden kann dieses Verhalten durch Beobachten der Queue“ ” mit einem blockierenden Semaphor, der vom Empf¨anger freigegeben wird oder durch Abwarten der quittierenden Antwort. 12.1.4 Timer-Events In einer Bedienoberfl¨ ache beispielsweise f¨ ur die Klangeinstellung soll nach Ablauf von 8 Sekunden automatisch wieder in ein Hauptmen¨ u zur¨ uckgesprungen werden. Eine andere Aufgabe ist es, nach Absendung eines Kommandos an einen CD-Changer auf die Antwort zu warten und ggf. ein Timeout zu erzeugen. Daf¨ ur gibt es Timer, die nach Ablauf der programmierten Zeit TimerEvents erzeugen und verschicken. Es gibt in Frameworks oft die L¨ osung, einen zentralen Timer, der von einem Hardware-Timer gespeist wird, als Server f¨ ur so genannte Soft-Timer in den einzelnen Komponenten zu benutzen. Dieser Zentraltimer schickt

186

12 Kommunikation per Events

regelm¨aßig Time-Tick-Events an die Soft-Timer der einzelnen Komponenten. Die Soft-Timer-Clients u ¨berwachen dann lokal die Zeitfunktionen und schicken ihrerseits der eigenen Komponente Timer-Events nach Ablauf der gew¨ unschten Zeit. Es gibt bei diesen Ans¨ atzen mehrere Probleme: Events, die durch Queues geschickt werden, sind zeitlich nicht mehr deterministisch und werden ungenau. Oft werden nach Men¨ uwechseln die Timer-Events nicht mehr gebraucht. Bei kleinen Systemen setzt man dann einfach lokal den HW-Timer zur¨ uck (kill), bei Systemen mit Timer-Events, die durch Queues verschickt werden, k¨onnen Events abgelaufener Soft-Timer noch durch die Queues laufen, sie sind sozusagen noch unterwegs. Daf¨ ur muss man Cookies einf¨ uhren und den Events mitgeben. Nach Empfang kann man dann anhand der Cookies entscheiden, ob dieses Event noch aktuell ist, ignoriert oder weggeworfen werden kann. Alternativ kann man solche Events direkt aus der Queue nehmen, was aber einigen Aufwand in SW bedeutet und die Gefahr birgt, dass man nicht an alle m¨oglichen Probleme und Ausnahmen denkt. Erfahrungsgem¨aß werden solche L¨ osungen 2-3 Mal u ¨berarbeitet. Man kann beobachten, dass Timer-Events hohe Queue-Lasten erzeugen, 10-20% aller Events sind Timer-Events. Eine bessere L¨ osung, die dieses Problem vermeidet, wird sp¨ater im vorgestellten Framework gezeigt. Dort wird ein Hintergrund-Timer verwendet. 12.1.5 Change-Events (Notifikation - Das Hollywood-Prinzip) Schließlich gibt es noch eine Reihe anderer Events wie Notifikations-Events ¨ oder Change-Events, die die Anderung eines Zustands oder eines Attributs senden. Dies entspricht dem Observer/Listener-Pattern, das auch Publisher/Subscriber-Pattern genannt wird oder sehr anschaulich dem so genannten Hollywood-Prinzip: Der Agent sagt zu einem Schauspieler: Don’t call me, I call you.“ ” Rufe mich nicht an, ich rufe Dich zur¨ uck, sobald sich etwas Wichtiges ” ver¨andert hat.“ ¨ Es wird also praktischerweise nicht regelm¨ aßig auf Anderungen abgefragt (gepollt), sondern es wird einmal in eine Registrierung (Registry) eingetragen, ¨ an welchen Anderungen von Zust¨ anden oder Attributen man interessiert ist, ¨ und nur, wenn sich solche Anderungen ereignen, sendet die Registry einen Change-Event an den registrierten Listener.

12.2 Realisierungen von Events 12.2.1 Einfache Events Events k¨onnen auf vielerlei Arten realisiert werden. Einfache Events werden mit einem Enum-Typ implementiert und an einer zentralen Stelle, die jedem

12.2 Realisierungen von Events

187

Nutzer zug¨anglich ist, wird die Bedeutung jeder Event-Nummer festgehalten. Wie in der Literatur werden hier die Begriffe Event und Message synonym verwendet.

enum MessageType { TUNER_SCAN, TUNER_SETFREQUENCY, AMP_SETVOL, AMP_SETMUTE, ... }; ... queue.add(TUNER_SCAN) ;

//Enum-Wert wird in die Queue eingetragen

Listing 12-1. Enum f¨ ur einfache Events

Der einfache Dispatcher scannt nacheinander die m¨oglichen Events und ruft bei einem Treffer die passende Routine auf. Jede Komponente hat einen eigenen Dispatcher, dem die lokalen Adressen der Bearbeitungsroutinen bekannt sind. Der einfache Dispatcher hat den folgenden Aufbau:

MessageType event; queue.get(event) ; switch (event) { case TUNER_SCAN: mTuner.scan(); break; case TUNER_SETFREQUENCY: mTuner.setFrequency(); break; ... default: break; } Listing 12-2. Dispatcher f¨ ur Enum-Events

12.2.2 C-Strukturen Eine weitere einfache Version ist die C-Struktur, in der Eintr¨age u ¨ber ihre Elementnamen angesprochen werden k¨ onnen:

188

12 Kommunikation per Events

struct MyMessage { UInt8 mType; UInt8 mData[63]; };

Listing 12-3. Event als C-Struktur

Man kann auch mehrere Interpretationen eines Events u ¨bereinander blenden:

struct MostMessage { UInt8 mType; // Device, Model, internal, external, UInt8 mSource; union OwnUnion { UInt8 mRawMessage[62]; // raw most message struct MyMessage { UInt16 mDevice; UInt8 mFBlock; UInt8 mInstance; UInt16 mFkID:12; UInt16 mOPType:4; UInt16 mLength; UInt8 mData[54]; }; }; }; // 64 Bytes total

Listing 12-4. Event als C-Struktur mit Union

Ein Treiber kann die Daten als Datenstrom in mRawMessage ablegen, die Interpretation in weiterverarbeitenden Komponenten nutzt dann MyMessage und dekodiert die Nachricht mit den Strukturelementen. Achtung: Es muss sehr genau auf m¨ ogliche Alignment-Probleme geachtet ¨ werden. Die Uberlagerung kann schnell zu Fehlern bei Big-Endian/LittleEndian f¨ uhren (fehlende Plattformunabh¨ angigkeit) oder zu Fehlern durch Alignment-Strategien des Compilers, falls Elemente nicht auf DoppelwortGrenzen ausgerichtet sind. In oben stehendem Beispiel k¨onnte das passieren, wenn der Compiler die Variablen auf Doppelwortgrenzen ausrichtet und dazwischen Leerstellen einf¨ ugt. Die mRawMessage w¨are aber nicht ausgerichtet und die erwartete Strukturierung w¨ are zerst¨ ort. Statt unions kann man auch

12.2 Realisierungen von Events

189

reinterpret cast verwenden. Beide Konstrukte verhalten sich gleich und k¨ onnen die gleichen Probleme mit Endian, Alignment und Zero-Padding haben. Es gibt Design-Regeln, die union und reinterpret cast verbieten. 12.2.3 Funktionszeiger Jedem Event kann auch ein Zeiger auf die Abarbeitungsroutine im Empf¨anger mitgegeben werden.

typedef void (*EventFuncPtr)(Int32); struct MyMessage { EventFuncPtr mFuncPtr; // Adresse der gew¨ unschten Fkt. Int32 mParam; }; //Der Aufruf k¨ onnte wie folgt aussehen: ... MyMessage msg; queue.get(msg); // get the event (*(msg.mFuncPtr))(msg.mParam); // and trigger it Listing 12-5. Event als C-Struktur mit Funktionszeiger und Parameter

In der Struktur kann auch gleich eine Funktion zur Abwicklung des Events definiert werden:

typedef void (*EventFuncPtr)(Int32); struct MyMessage { EventFuncPtr mFuncPtr; // Adresse der gew¨ unschten Fkt. Int32 mParam; void dispatch(); }; //Der Aufruf erfolgt ¨ uber das Event selbst: ... void MyMessage::dispatch() { (*mFuncPtr)(mParam); } Listing 12-6. Implementierung der dispatch-Methode der Struktur

190

12 Kommunikation per Events

Alle diese Varianten mit Funktionszeigern k¨onnen in Multithread- und in durch fork erzeugten Multiprozess-Umgebungen genutzt werden, da der Pointer in den gemeinsamen Code-Bereich zeigt. Die aufgerufene Funktion muss allerdings threadsafe implementiert sein. In einer Nachricht kann man auch zus¨ atzliche Parameter wie Empf¨angerund Sender-ID, Zeitstempel usw. mitgeben. Handelt es sich nicht nur um den Zeiger auf eine Funktion, sondern auf ein Handler-Objekt, so ist Vorsicht geboten. Zwar sind die virtuellen Funktionen des Handlers im Code-Segment u ¨ber den Zeiger erreichbar, falls das System durch fork erzeugt wurde. Dies allerdings nur, falls das Objekt auch schon initialisiert wurde. Daten des Objekts sind in Multiprozess-Umgebung nur referenzierbar, falls das Objekt im Shared-Memory angelegt wurde. Hier ist es dann auch sinnvoller, die Verarbeitungsmethode als Methode des Objekts zu implementieren. Dies folgt weiter unten. Wenn das Event selbst seine Ausf¨ uhrungsroutine mitbringt bzw. darauf zeigt, dann muss jemand zu irgendeiner Zeit diese Zeigerinformation beim Generieren des Events f¨ ullen. Damit m¨ usste der Sender alles u ¨ber den Empf¨anger wissen. Das erscheint zun¨ achst nicht besonders sinnvoll. Sp¨ater werden wir Registries besprechen, in denen sich Komponenten (Publisher/Subscriber) f¨ ur Events registrieren k¨ onnen. Bei dieser Registrierung k¨onnen sie ihre Funktionsadresse oder einen Handler eintragen, die im Fall des Events aufgerufen werden sollen. Diese zahlreichen komplexen Einschr¨ ankungen f¨ uhren dazu, dass man besser keine Zeiger in Events verschickt oder sie nur innerhalb einer ThreadUmgebung erlaubt. 12.2.4 Event-Klassen und Objekte Wie angek¨ undigt k¨ onnen wir f¨ ur Events auch Klassen verwenden. In unten stehendem Beispiel werden gleich zwei Objekte in einer Union u ¨berlagert, so dass sich ein empfangenes Event als Most-Event oder Normal-Event interpretieren l¨asst:

class CMessage { class MostContent { public: UInt8 mType; UInt8 mSource; UInt16 mLength; UInt8 mMostMessage[60]; };

// // // //

type of the message (int/ext) source type (device/model) length of the message. The message

12.2 Realisierungen von Events

class NormalContent { public: UInt8 mType; UInt8 mReserved [3]; UInt32 mOpcode; UInt32 mParam[14]; }; union OwnUnion { MostContent NormalContent }; ...

191

// force 32 bit alignment // operation code (e.g. FuncID)

mMostContent; mNormalContent;

Listing 12-7. Event als Klasse CMessage

Es ist dann sinnvoll, auch die Zugriffsmethoden in der Klasse zu implementieren. Die private Vereinbarung der Daten verhindert den direkten und unkontrollierten Zugriff auf die Daten. Nur u ¨ber die public Zugriffsmethoden k¨ onnen die Daten zugegriffen werden. In diesen Zugriffsmethoden werden auch die Synchronisationsmechanismen versteckt, so dass sich der Anwendungsprogrammierer darum nicht mehr k¨ ummern muss. Was er allerdings wissen muss, ist, dass sein Zugriff auch blockiert werden kann und warten muss. Im unten angegebenen Beispiel dient eine einfache Klasse zur Implementierung von Ereignissen und zum Versenden zwischen Komponenten. Eine Sender-ID, eine Empf¨ anger-ID und ein Op-Code (der eigentliche Event) sind Teil der Nachricht. Außerdem ist z.B. ein Parameter vorgesehen. Diese Nachricht w¨ urde 16 Bytes beanspruchen.

class CMessage { public: CMessage(); void setSenderID(Int32 senderID); void setReceiverID(Int32 receiverID); void setOpcode(Int32 opcode); void setParam1(Int32 param); ... Int32 getSenderID(void) const; Int32 getReceiverID(void) const;

// SET-METHODS

// GET-METHODS

192

12 Kommunikation per Events

Int32 Int32 ... private: Int32 Int32 Int32 Int32 };

getOpcode(void) const; getParam1(void) const;

mSenderID; mReceiverID; mOpcode; mParam1;

// // // //

ID of the source. ID of the receiver operation code (for example FuncID) opt. Parameter

Listing 12-8. Event-Klasse mit eigenen Methoden und Attributen

12.2.5 Zeiger auf Event-Objekte verschicken Events k¨onnen Objekte oder Zeiger auf Objekte sein, mit eigenem Typ und eigenen Aufrufmethoden. Das Versenden als Zeiger auf Objekte spart aufw¨andiges Umkopieren der Objekte. Eine Typpr¨ ufung der Zeiger ist m¨ oglich. In einer Komponente beispielsweise werden dann Event-Objekte aus einem Pool entnommen, initialisiert, gef¨ ullt und die Zeiger auf die Objekte in die Queue einer anderen Komponente versendet. Von dort liest ein Dispatcher Events nach dem FIFO-Prinzip aus und stellt sie den Applikationen zu. Die Applikationen sollen die Events nicht an das System zur¨ uckgeben, wenn sie sie konsumiert haben. Die Gr¨ unde sind z.B. vergessene oder mehrfache R¨ uckgaben. Ferner ist es m¨ oglich, dass der Dispatcher das Event an mehrere Objekte verteilt. Diese Aufgabe sollte daher der Dispatcher u ¨bernehmen.

Abbildung 12.1. Die Nutzung eines Pools zur Event-Erzeugung

12.2 Realisierungen von Events

193

CMessage * eventPtr = FW_NEW_DEFAULT(CMessage, eventPool); ..... // Event mit Daten f¨ ullen queue.addMessage(eventPtr); // abschicken // im Dispatcher des Receivers: CMessage * eventPtr = NULLPTR; eventPtr = mQueue.getMessage(false); // Zeiger auf Event holen ..... // weiterverarbeiten FW_DELETE(eventPtr, eventPool); // Event wieder freigeben Listing 12-9. Verwendung von Event-Pool

Bezogen auf Laufzeiten ist die vorgestellte L¨osung gut, statt ganze Events in Queues zu kopieren, muss lediglich der Zeiger kopiert werden. Das Thema Queue wird im folgenden Kapitel n¨ aher besprochen, wir beschr¨anken uns hier auf die Vorstellung einer Warteschlange. Bezogen auf die Organisation unseres Speichers ist eine solche L¨osung ohne geeignete Speicherverwaltung eher von Nachteil: Wenn f¨ ur jedes Event, das gerade im System unterwegs ist, ein Speicherblock allokiert wird, bedeutet das die dynamische Allokation der EventBl¨ ocke. Der oben vorgestellte Event-Object-Pool wird erforderlich. Wie wir in dem oben angegebenen Beispiel sehen, wird ja auch ein Event aus dem Event-Pool allokiert. Zus¨atzlich m¨ ussen Zeiger auf die Bl¨ ocke verwaltet werden. Es gibt also zwei Stellen, die dynamisch auf die Anforderungen im System reagieren m¨ ussen, die Queue selbst und der Objekt-Pool. Diese L¨osung ist gut, wenn man es mit Event-Objekten verschiedener Gr¨oße zu tun hat. Dann haben die Queues selbst eine einheitliche Elementgr¨ oße, n¨amlich die des Zeigers. Eine weitere Komplikation bei Events unterschiedlicher Gr¨oße ist die erforderliche Speicherallokation. Objekte werden generiert und Objekte werden gel¨oscht. Um Speicherfragmentierung zu vermeiden, m¨ ussen eigene Objektpools implementiert werden, aus denen Speicher f¨ ur verschiedene Events geholt wird und an die am Schluss der Speicher auch wieder zur¨ uckgegeben wird. Hat man nur eine Event-Gr¨ oße, kann man die Objekte im Pool direkt als Queue verketten und nicht noch deren Zeiger mehrfach umkopieren. Formal gesehen gibt es dann keine leeren Queue-Elemente, sondern nur gef¨ ullte, die in der Queue-Kette eingegliedert sind, oder leere Elemente, die nicht in der Queue, sondern in der freelist des Objekt-Pools verwaltet werden. Es k¨onnen f¨ ur die verschiedenen Event-Objekte auch eigene Event-Klassen aus einer abstrakten Basisklasse abgeleitet werden, besipielsweise f¨ ur TunerEvents, CD-Events usw.

194

12 Kommunikation per Events

So kann aufgrund des Objekttyps die dazu geh¨orige Methode zur Laufzeit ermittelt und aufgerufen werden (Polymorphismus). Die Queue selbst hat dann den Typ der Basisklasse, die Event-Zeiger werden dann w¨ahrend des Transports up- und down-gecastet.

class CEvent // Basisklasse f¨ ur Ereignisse { public: void *getConsumerPtr() { return mConsumerPtr; } void *getSourcePtr() { return mSourcePtr; } // Methode zum Senden des Ereignisses virtual void sendEvent() = 0; // mit Empf¨ anger als Param void sendEvent(void *consumerPtr) { mConsumerPtr = consumerPtr; sendEvent(); } //mit Sender und Empf¨ anger void sendEvent(void *sourcePtr, void *consumerPtr) { mSourcePtr = sourcePtr; sendEvent(consumerPtr); } protected: // Konstruktor mit Zeiger auf Sender, Zeiger auf Konsumenten CEvent(void* sourcePtr = NULLPTR, void *consumerPtr = NULLPTR) : mSourcePtr(sourcePtr), mConsumerPtr(consumerPtr) { } virtual ~CEvent() { } virtual void activate() = 0; // zum Aktivieren des Ereignisses // Methode ruft dann richtige Methode des Empf¨ angers virtual void freeEvent() = 0; // Freigabe des Ereignisses. // Abgeleitete Klassen m¨ ussen // Methode entspr. implementieren // (z.B.¨ uber Objektpool) friend class CDispatcher; // erlaubt CDispatcher, // das Ereignis freizugeben

12.2 Realisierungen von Events void* mSourcePtr; void* mConsumerPtr; }; // end of CEvent

195

// Der Sender // Empf¨ anger

Listing 12-10. Event-Basisklasse

Zu bemerken ist, dass die Events selbst sp¨ ater u ¨ber die virtuelle Methode freeEvent freigegeben werden. Sie m¨ ussen ihren eigenen Pool kennen. ¨ Uber Prozessgrenzen hinweg funktioniert das Versenden von Zeigern auf Objekte allerdings wieder nur, wenn die Prozesse durch fork entstanden sind, weil nur dann alle Objekte derselben Klasse dieselbe virtuelle Tabelle haben. Außerdem k¨onnen Zeiger auf Objekte nur verwendet werden, wenn alle beteiligten Komponenten auf einem gemeinsamen Speicher arbeiten k¨onnen, in der Regel ist dies nur bei Multithread-Systemen oder bei MultiprozessSystemen mit Shared-Memory m¨ oglich. ¨ Da wir von der Ubertragung zwischen Komponenten verschiedener Prozesse ausgehen wollen, sollten in unserem System die Objekte selbst verschickt werden. Anmerkung: Mit dem vorgestellten Shared-Memory kann man auch Zeiger u ¨ber Prozessgrenzen hinweg verschicken, wenn man die Objekte, auf die die Zeiger zeigen, im gemeinsamen Shared-Memory allokiert und die Prozesse durch fork erzeugt hat. Dann sind wir aber bei obiger L¨osung, dass der Pool im Shared-Memory angelegt werden kann und die Elemente in der Queue direkt im Pool verkettet werden k¨ onnen. 12.2.6 Events am Beispiel von MOST MOST-Messages f¨ ur Kommandos oder f¨ ur Daten gem¨aß der Spezifikation [MOST] sind ebenfalls einfache Events:

struct MOSTEvent { UInt16 mDeviceID; UInt8 mFBlockID; UInt8 mInstance; UInt16 mFkID:12; UInt16 mOPType:4; UInt8 mLength; UInt8 mData[12]; } ;

// Bitfeld // bis hierhin sind es 7 Bytes // hier sind die Nutzdaten

Listing 12-11. Beispiele f¨ ur MOST-Events gem¨ aß MOST-Spezifikation

196

12 Kommunikation per Events

Auf die einzelnen Bedeutungen gehen wir sp¨ater ein. Ersichtlich sind sol¨ che Events nach serialisierter Ubertragung typfrei, d.h., zwischen Sender und ¨ Empf¨anger muss ein gemeinsames Format, das nicht Teil der Ubertragung ist, vereinbart sein. Dies ist z.B. das oben angegebene Format, das beide, der Sender und der Empf¨ anger aus einer Headerdatei kennen.

12.3 Designentscheidung und prinzipielle Implementierung Eine Untersuchung der MOST-Protokolle zeigt, dass die meisten Events Kontroll-Events mit nur wenigen Daten sind. Lediglich Daten wie die grafische Karte f¨ ur die Navigation, Telefon- oder Adressb¨ ucher oder gr¨ oßere Datenmengen f¨ ur die Spracherkennung erfordern große und flexible Objekte, f¨ ur die Events mit mehreren kByte n¨otig w¨aren. Es gibt MOST-Events gem¨ aß MOST-Katalog mit einer Nutzlast von 12 Bytes [MOST]. Diese werden f¨ ur die Kommunikation mit externen Komponenten u ¨ber den MOST-Ring genutzt. Nachrichten mit einer gr¨oßeren Menge Daten werden u ¨ber mehrere MOST-Events segmentiert. Von den MOST-Events werden f¨ ur unser Framework die internen MOSTEvents mit einer festen Gr¨ oße von 64 Bytes abgeleitet, bei denen in der Regel die Daten Teil des Events sind. Messungen haben gezeigt, dass das Umkopieren solcher Datenmengen nur wenig Zeit im Vergleich zum Synchronisieren der Zugriffe ben¨ otigt; es ist vernachl¨ assigbar. Mit dem Format von 64 Bytes k¨onnen alle Standard-Nachrichten von MOST abgebildet werden. Reicht die Event-Gr¨ oße f¨ ur große Daten wie Navigationsdaten oder Adressbucheintr¨age nicht, so werden die Daten abgetrennt und unter Zuhilfenahme eines Speicher-Pools transportiert. Dies hat den Vorteil, dass alle beteiligten Komponenten mit festen Gr¨ oßen arbeiten k¨ onnen. Es werden keine Zeiger, sondern die Event-Objekte selbst verschickt, da wir die Konfiguration, ob Thread oder Prozess, jederzeit in der Konfiguration ¨andern wollen. Dadurch m¨ ussen wir auch keine Event-Objekte dynamisch erzeugen, um mit Zeigern darauf zu zeigen. Events k¨onnten sogar direkt in der Queue erzeugt und gef¨ ullt werden und m¨ ussten nicht umkopiert werden. Lediglich die Anfangs- und Ende-Zeiger m¨ ussen entsprechend verwaltet werden. Nachteilig k¨onnte hier sein, dass f¨ ur die Zeit, w¨ahrend der das Event zusammengebaut“ wird, die Queue auch f¨ ur ” andere blockiert wird. Das gleiche gilt f¨ ur das Auswerten im Empf¨anger. Die Versendung usnerer Events hat gegen¨ uber der Versendung von EventZeigern einen sehr wichtigen Vorteil: Die Debugf¨ahigkeit. Werden die Events aus dem System ausgekoppelt und z.B. u ¨ber eine Socket-Verbindung an einen Debug-Rechner geschickt, k¨ onnen dort die Daten mitgelesen und verstanden werden. Dies w¨ are bei Versendung von Zeigern auf Event-Objekte nicht m¨ oglich.

13 Event-Verarbeitung

13.1 Queues Wie schon einige Male erw¨ ahnt, sind Queues Warteschlangen. Die Warteschlange an englischen Bushaltestellen ist ein anschauliches Beispiel f¨ ur deren Funktionsweise. Kommen neue Fahrg¨ aste zur Bushaltestelle, so m¨ ussen sie sich hinten an der Warteschlange anstellen (please queue up!). Diejenigen, die ganz vorne stehen, haben bereits am l¨ angsten gewartet und d¨ urfen zuerst in den Bus einsteigen und mitfahren. Die anderen Fahrg¨aste in der Schlange d¨ urfen dann nach vorne nachr¨ ucken. Es handelt sich also um das FIFO-Prinzip, first in first out“. Es ist eine ” Queue mit tail-write-Eigenschaft, neue Elemente werden hinten angef¨ ugt. Demgegen¨ uber gibt es auch Queues, die in besonderen F¨allen nach dem Prinzip head-write beschrieben werden“. Priore neue Elemente werden vorne ” eingeschrieben und zuerst wieder ausgelesen, nach dem LIFO-Prinzip last in ” first out“ 1 . An einer Bushaltestelle k¨ ame es mit diesem Prinzip zu Komplikationen. Dieses u ¨bliche Bild zeigt eine zu einfache Vorstellung, da sicher nach

Abbildung 13.1. Symbolische Queue

dem Auslesen eines Elements die folgenden Elemente nachr¨ ucken, wie es bei der erw¨ahnten Bushaltestelle der Fall w¨ are. 1

Einen Speicher, der nur nach dem LIFO-Prinzip beschrieben wird, nennt man in der Informatik Stack.

198

13 Event-Verarbeitung

Tats¨achlich kann eine Queue mit einem Array implementiert werden, das als Ringpuffer adressiert wird. Alternativ kann eine verkettete Liste verwendet werden. Dies w¨are sinnvoll, wenn die Queue keine feste Gr¨oße hat, sondern wachsen kann. Eine Bespiel mit einem Array ist unten gegeben:

class CCommQueue { public: CCommQueue(Int32 queuesize); ~CCommQueue(); bool add(const CMessage& msg); bool getMessage(CMessage& msg); Int32 getNumOfMessages(void); Int32 getNumOfByteNeeded(void);

// // // // //

add Message into the queue get a Message from the queue get the number of Messages get number of Bytes occupied by the queue

private: Int32 mSize; // size of the queue Int32 mCurrentSize; // current size Int32 mHeadIndex; // first possible element for reading Int32 mTailIndex; // position to insert CMessage mQueue[1] // dirty trick to force the subsequent memory // belong to the queue. This technique is needed // for placing the queue into a Shared-Memory }; Listing 13-1. Queue-Klassendefinition, Prototyp

Man beachte den Trick in der letzten Zeile, wir definieren im Moment die Queue mit der L¨ ange eins und implementieren die richtige L¨ange erst bei der Definition des Shared-Memory und der entsprechenden Komponentenkontexte. Dies ist n¨otig, da wir aus einer Klasse Queues unterschiedlicher Gr¨oße instantiieren wollen und daf¨ ur die queuesize als Parameter mitgeben. Die Gr¨oße eines Arrays muss aber schon zur Kompilierzeit feststehen und kann nicht variabel angegeben werden. Da es in C++ aber keine Index¨ uberpr¨ ufung ¨ zur Laufzeit gibt, erlauben wir in diesem speziellen Fall das Uberschreiben u oße queuesize. ¨ber die Arraygrenze bis zur Gr¨ Unser Queue-Objekt hat eine festgelegte Tiefe, es w¨achst also nicht bei Belegung. Es ist f¨ ur die Einbettung in ein Shared-Memory vorgesehen. Deshalb muss das Queue-Objekt mit Placement-new in den vorgesehenen Speicher plaziert werden. Um die erforderliche L¨ ange zu ermitteln, gibt es eine Methode getNumBytesNeeded. In der Klasse ist das Queue-Array nur mit einem

13.1 Queues

199

Element angegeben, im Shared-Memory wird aber der erforderliche Platz f¨ ur die angegebene Zahl von Message-Objekten bereitgestellt. Die Queues werden normalerweise nicht gel¨ oscht. 13.1.1 Externe Queue Events, die von fremden Komponenten oder Modulen an die eigene Komponente geschickt werden, nennen wir externe oder normale Events. Im Gegensatz dazu kann sich eine Komponente auch selbst Events schicken, die wir interne Events nennen. Events aus der Systemadministration wie z.B. On/Off, Diagnose-Events oder andere Events h¨ ochster Priorit¨ at nennen wir System-Events. F¨ ur den Empfang externer Events ben¨ otigen wir eine Warteschlange, die Queue. Zeitlich richtig m¨ ussen die ¨ altesten Events zuerst aus der Queue geholt werden, sie funktioniert hier demnach nach dem FIFO-Prinzip und puffert Events zwischen, bis der Event-Handler im Empf¨anger sie aus der Queue nimmt und abarbeiten kann. Es folgt eine Implementierung einer externen Queue nach FIFO-Prinzip. Da in der Regel auf eine externe Queue mehrere konkurrierende Tasks zugreifen, muss die Queue entsprechend gesch¨ utzt werden. Die Adressierung des

Abbildung 13.2. Reale Queue

Schreib- und des Lesezeigers wird modulo der Queue-Gr¨oße weitergeschaltet, um einen Ringpuffer zu implementieren. Im Moment wird zur Vereinfachung auch noch nicht n¨aher ausgef¨ uhrt, wie das Lesen aus der Queue gestartet wird, man k¨ onnte pollen oder auf ein Signal (¨ uber einen Semaphor) warten.

CCommQueue::CCommQueue(Int32 queuesize, CBinarySemaphore& sem) : mSignalSem(sem), mSize(queuesize),

200

13 Event-Verarbeitung mCurrentSize(0), mHeadIndex(0), mTailIndex(0) mAccessMutex(true, true), mCanWriteSem(true, true)

//writing into an empty queue is OK

{ ASSERT(queueSize > 0); //now init queue correctly Int8* ptr = reinterpret_cast (&mQueue[0]); new(ptr) CMessage[queuesize]; } CCommQueue::~CCommQueue(){} bool CCommQueue::add(const CMessage& msg, bool waitForever) // return true if event is delivered { if (false == mCanWriteSem.take(waitForever)) //try get write access { return false; //doesn’t work and caller doesn’t want to wait } if (false == mAccessMutex.take(waitForever)) { //try block Q (no reader allowed) mCanWriteSem.give(); //someone has the access right return false; } mQueue[mTailIndex] = msg; //at this point we have whole control mTailIndex--; if (mTailIndex < 0) //Ringbuffer!! { mTailIndex = mSize - 1; } mCurrentSize++; if (1 == mCurrentSize) // wake up the waiter if needed { mSignalSem.give(); // signal waiting threads } if (mCurrentSize < mSize) { mCanWriteSem.give(); //give write access if Q not full } mAccessMutex.give(); //Give the access right back return true; } bool CCommQueue::getMessage(CMessage& msg) //get a Message from Q { mAccessMutex.take(); //try to access queue if (mCurrentSize == 0) //just in case {

13.1 Queues

201

mAccessMutex.give(); return false; } //at this point caller has whole control of queue msg = mQueue[mHeadIndex]; //get message mCurrentSize--; mHeadIndex--; if (mHeadIndex < 0) //Ringpuffer { mHeadIndex = mSize - 1; } if ((mSize -1) == mCurrentSize) //check if queue was full before { //we allow write access again mCanWriteSem.give(); } mAccessMutex.give(); //dont forget give access right back return true; } Int32 CCommQueue::getNumOfMessages(void) { Int32 size; mAccessMutex.take(true); size = mCurrentSize; mAccessMutex.give(); return size; //ret number of events in queue } Int32 CCommQueue::getNumOfByteNeeded(void) //get size of queue { return MAKE_ALIGNMENT_SIZE(sizeof(CCommQueue) + sizeof(CMessage)*(mSize-1)); }//end of CCommQueue.cpp

Listing 13-2. Eine Queue-Implementierung

Wir arbeiten mit einem Mutex und zwei Semaphoren: 1. Mit dem Semaphor mSignalSem wird ein wartender Task ggf. geweckt, so dass er neu eingetragene Events aus der Queue lesen kann. Dieser Semaphor wird auch dazu verwendet, um Queue-select“ zu implementieren. ” 2. Der Semaphor mCanWriteSem signalisiert, wenn die Queue voll ist und ¨ verhindert damit den Uberlauf. 3. Der Mutex mAccessMutex sch¨ utzt die Queue vor konkurrierenden Zugriffen. Wir werden diese Implementierung im Teil II f¨ ur die Erl¨auterung der Komponenten im Zusammenspiel mit dem Dispatcher noch genauer betrachten. Die L¨osung mit Semaphoren hat folgende Vorteile:

202

13 Event-Verarbeitung

• Schreiben an beide Enden der Queue ist m¨oglich. • Ein Semaphor ist das gemeinsame Signal, um einen wartenden Task (Dispatcher) zu wecken. Dadurch kann der Dispatcher auch auf mehrere Queues warten. Dagegen hat sie folgende Nachteile: • Wenn die Queue voll ist, hat selbst der High-Prio-Produzent keine M¨oglichkeit, die Priorit¨ at des lesenden Tasks zu erh¨ohen. • Ein schreibender Task kann den anderen schreibenden Task blockieren. W¨ahrend der add-Methode wird der Task von einem Prozess mittlerer Priorit¨at unterbrochen. Ein schreibender hochpriorer Task kommt nicht an die Queue, weil der Zugriffssemaphor belegt ist, d.h., die Gefahr der Priorit¨atsinversion ist sehr konkret. • Ein lesender Task kann einen schreibenden blockieren, obwohl sie auf verschiedene Stellen der Queue zugreifen. • Die aktuelle Queuel¨ ange ist ggf. nicht genau. Es werden auch Varianten gelehrt, in denen zwei Counting-Semaphore f¨ ur die Adressierung eines Pufferspeichers verwendet werden. Die Schreibroutine erh¨oht der Leseroutine den Z¨ ahlerstand (counting semaphor) der zu lesenden Elemente, die Leseroutine erh¨ oht den Z¨ ahler (counting semaphor) der noch m¨oglichen Schreibelemente. Der jeweils eigene Z¨ahler wird beim Belegen des Semaphors (wait/take) dekrementiert. Zum Start mit einem leeren Speicher muss demnach der Schreibz¨ ahler mit der Puffergr¨oße, der Lesez¨ahler mit 0 gesetzt werden. Diese Variante lebt davon, dass niemals beide Z¨ahler auf dieselbe Adresse zeigen k¨onnen, da es sonst zu Zugriffskonflikten k¨ame. Deshalb muss die Implementierung genau gepr¨ uft werden, ob es nicht doch beim ersten Element im Puffer zu Konflikten oder Deadlock-Situationen kommen kann, z.B. bei der Verwendung von verketteten Listen statt Arrays als Queue. Auch der odd ” plus one“-Error, bei dem der Z¨ ahler von 1..n z¨ahlt, das Array aber von 0..n-1 vereinbart ist, kommt hier h¨ aufig vor.

.... // shmPtr zeigt auf den Shared-Memory-Bereich char * shmPtr = ... // semaphore mit placement-new erzeugen sem_t *semReadPtr = new(shmPtr)sem_t; sem_t *semWritePtr = new(semReadPtr + sizeof(semReadPtr))sem_t; int *Qread = new(semWritePtr + sizeof(semWritePtr)) int; int *Qwrite = new(Qread + sizeof(Qread)) int; int pshared = 1; if(sem_init(semReadPtr, pshared, 0) == -1) {

13.1 Queues sOwnCout << "Init semRead failure!"; return -1; } // Anfangswert QSize if(sem_init(semWritePtr, pshared, QSize) == -1) { sOwnCout << "Init semWrite failure!"); return -1; } int pid = fork(); if(pid != 0) //producer { for(int loop = 0; loop < 100; loop++) { sem_wait(semWritePtr); Event* eventPtr = (Event*)EventPool->allocate(sizeof(Event)); if (eventPtr ==NULL) { sOwnCout << "allocate error"; return -1; } sprintf(eventPtr->mMsg,"Hallo %d",loop); (Q[*Qwrite])= eventPtr; sOwnCout << "Producer: " << Q[*Qwrite]->mMsg; *Qwrite=((*Qwrite)+1)%QSize; sem_post(semReadPtr); ... sleep(zufall); //Zufallstests } } else //consumer { sem_wait(semReadPtr); sOwnCout << "Consumer received: << Q[*Qread]->mMsg; EventPool->deallocate(Q[*Qread]); *Qread=((*Qread)+1)%QSize; sem_post(semWritePtr); ... sleep(zufall); } } Listing 13-3. Produzent-Konsument mit Counting-Semaphor

203

204

13 Event-Verarbeitung

Die Queue-Version mit zwei Counting-Semaphoren hat folgende Vorteile: • Die Implementierung ist sehr einfach. • Der lesende Task kann den schreibenden nicht blockieren, solange sie an getrennten Stellen (mHeadIndex und mTailIndex sind verschiedene Variablen) arbeiten. Die Nachteile sind: • Schreiben an beide Enden ist nicht m¨ oglich, wie wir es f¨ ur interne Queues brauchen. • Wenn die Queue voll ist, hat selbst der hochpriore Produzent keine M¨oglichkeit mehr, die Priorit¨ at des lesenden Tasks zu erh¨ohen, da beide mit verschiedenen Semaphoren arbeiten. Deshalb ist die Gefahr der Priorit¨atsinversion sehr konkret. • Es darf nur einen Produzenten geben. Wollen mehrere Tasks in die Queue schreiben, so muss die Queue auch entsprechend gesch¨ utzt werden. • Will man die Queue-L¨ ange berechnen, kann es zu Zugriffskonflikten und Fehlberechnungen kommen. 13.1.2 Interne Queue Um das Prinzip RTC (run till completion) zu wahren, kann es erforderlich sein, dass sich ein Modul oder ein Zustandsautomat beim Abarbeiten eines Events selbst interne Events schickt. Diese m¨ ussen zuerst zu Ende prozessiert werden, bevor das n¨ achste (externe) Event angegangen werden darf, sie m¨ ussen sich also vor die anderen anstehenden Events vordr¨angeln. Es ist daher n¨otig, die internen Events vor den n¨ achsten externen zu bearbeiten, dabei muss außerdem der j¨ ungste Event zuerst bearbeitet werden. Es wird also eine Queue nach LIFO- oder head-write“-Prinzip f¨ ur interne Events ben¨otigt. Die ” folgende Teilimplementierung gibt das wieder. Anmerkung: Falls es eine Vektor-Klasse oder -Template gibt, kann man auch einen Stack als LIFO-Queue implementieren. Der Einfachheit halber verwenden wir hier fast dieselbe Implementierung wie f¨ ur die FIFO-Queues.

//return true if event is delivered bool CCommQueue::addInt(const CMessage& msg) { if (mCurrentSize == mSize) return false; mHeadIndex++; if (mHeadIndex == mSize)

//Ringpuffer

13.1 Queues

205

mHeadIndex = 0; mQueue[mHeadIndex] = msg; mCurrentSize++; return true; } bool CCommQueue::getIntMessage(CMessage& msg) //get Message from queue { if (mCurrentSize == 0) return false; msg = mQueue[mHeadIndex]; mCurrentSize--; mHeadIndex--; if (mHeadIndex < 0) mHeadIndex = mSize - 1; return true;

//Ringpuffer

} Listing 13-4. Teilimplementierung einer internen Queue

13.1.3 System-Queue System-Queues unterscheiden sich im Aufbau nicht von externen Queues und arbeiten nach dem FIFO-Prinzip. Lediglich in der Reihenfolge, in der der Dispatcher die Queues bedient, kommt die System-Queue gleich nach der internen an die Reihe. 13.1.4 Queue mit verbesserter Inversions-Eigenschaft In diesem Abschnitt wird ein Variante vorgestellt, die sich bez¨ uglich Priorit¨atsInversion besser verh¨ alt. Erreicht wird dies durch Nutzung von Mutexen statt Semaphoren.

class CCommQueue { public: CCommQueue(Int32 queueSize, CBinarySemaphore& sem,

CMutex& mutex); ~CCommQueue();

//ctor //to signal that an event arrives //in an empty Q so that dispatcher //can be waken up) // hold by reader task, used // for priority inheritance //dtor

206

13 Event-Verarbeitung // add a message into the queue bool add(const CMessage& msg, bool waitForever = true ); Int32 getNumOfMessages(void); bool getMessage(CMessage& msg);

//get number of messages in Q //get message from queue. //caller cannot be blocked Int32 getNumOfBytesNeeded(void); //get number of bytes occupied Q Int32 getSizeNeeded(Int32 numOfMsg) //calc.memory needed to create Q { //with number of messages needed return sizeof(CCommQueue) + sizeof(CMessage)*(numOfMsg - 1); } private: CCommQueue (const CCommQueue& rhs); //to avoid wrong usage const CCommQueue& operator=(const CCommQueue& rhs); CBinarySemaphore& mSignalSem; //to signal CBinarySemaphore mWriterSignal; //used to signal the producer if //it has lower priority than reader CMutex& mPrioInheritanceMutex; //used for priority inheritance CMutex mCounterMutex; //used to protect access //of current length of queue CMutex mWriteMutex; //used to synchronize the producers CMutex& mSyncMutex; //used for the synchronisation //the reader and the writers const Int32 Int32 Int32 const bool

Int32 mSize; //size of the queue mCounter; //current length of the queue mHeadIndex; //first possible element for reading mTailIndex; //position to insert CThread::EPriority mPrioOfReader; mHiPrioWriterWait;

CMessage mQueue[1];

//dirty trick to force subsequent mem //belong to queue.Technique is needed //for placing Q into shared memory

}; // end of CCommQueue Listing 13-5. Die Queue-Klasse CCommQueue.h, Prototyp

Wir nutzen mehrere Mutexe zur Synchronisation und Priorit¨atsbeeinflussung. Ein schreibender Task kann durch Zugriff auf mPrioInheritanceMutex seine Priorit¨at an den lesenden Task vererben. Der mCounterMutex sch¨ utzt den F¨ ullstandsz¨ahler vor Zugriffskollisionen. Der mWriteMutex ist erforderlich, falls es mehr als einen Produzenten gibt und diese synchronisiert werden m¨ ussen. Der mSyncMutex nutzt die Priorit¨ atsvererbung des Mutex aus. Wir fragen ab, ob der oder die Produzenten h¨ohere Priorit¨at als der Konsument haben. Ist dies nicht der Fall, wird in der Implementierung ohne weitere Maßnahmen weitergemacht.

13.1 Queues

207

Statt wie bei einer u osung auf einem Semaphor zu blockieren, ¨blichen L¨ wird hier im Fall einer vollen Queue auf dem mPriorityInheritanceMutex blockiert. Dies hebt den Konsument-Task in seiner Priorit¨at. Folgende Priorit¨ atsvererbungen kann es geben: • Schreibende Tasks k¨ onnen aufgrund der mWriteMutex Priorit¨at von einem anderen erben. Die Schreibmethode ist allerdings kurz, so dass dies keine schlechte L¨osung ist. St¨ ort dies, kann das Attribut auch auf nicht erbend gesetzt werden. • Der lesende Task erbt die Priorit¨ at desjenigen Tasks, der als Erster versucht hat, in die volle Queue zu schreiben. Alle anderen schreibwilligen Produzenten-Tasks blockieren auf dem mWriteMutex. Wir nehmen hier an, dass alle Produzenten-Tasks gleiche Priorit¨at haben. W¨are dies nicht ¨ der Fall, m¨ ussste man sich mit der Ubertragbarkeit von Priorit¨aten befassen: A wartet auf B, B aber schon auf C => C bekommt die Priorit¨at von A. ¨ Folgende Uberlegungen liegen der Implementierung zu Grunde: • • • •

• • • •

Es gibt in unserem Konzept nur einen Konsumenten. Es gibt mehrere Produzenten. Die Produzenten d¨ urfen nur nacheinander in die Queue schreiben. Zu sch¨ utzende Daten sind die aktuelle Queuel¨ange und der TailIndex (das Array der Nachrichten wird dabei automatisch gesch¨ utzt). Der Headindex wird automatisch durch die Queuel¨ ange gesch¨ utzt (wir haben nur einen Konsumenten). Produzenten und Konsument d¨ urfen parallel und unsynchronisiert arbeiten, solange die Queue nicht leer oder voll ist. Der Konsument kann mit einer niedrigen Priorit¨at arbeiten. Wenn die Queue voll ist, muss der Konsument die h¨ohere Priorit¨at des wartenden Produzenten-Threads annehmen (Priorit¨atsvererbung). Bei den Produzenten gilt auch die Priorit¨ atsvererbung. Damit k¨ onnen kritische Threads ihre Nachrichten zeitnah liefern.

Unten stehendes Bild zeigt in Pseudo-Befehlen die Synchronisation zwischen Produzenten und Konsument: Nun die Implementierung:

CCommQueue::CCommQueue(Int32 queueSize, //capacity of the queue CBinarySemaphore& sem, //signal that event arrived //in empty Q so dispatcher can be waken up CMutex& priomutex, //mutex used to inherit the priority CMutex& syncMutex, //synchronize writer/reader when Q is full CThread::EPriority prioOfReader) //base priority of the reader : mSignalSem(sem),

208

13 Event-Verarbeitung

Abbildung 13.3. Handshake zwischen Produzenten und Konsument

mPrioInheritanceMutex(priomutex), mSyncMutex(syncMutex), mSize(queueSize), mCounter(0), mHeadIndex(0), mTailIndex(0), mPrioOfReader(prioOfReader), mHiPrioWriterWait(false), mCounterMutex(true, true), mWriteMutex(true, true), mWriterSignal(false,true)

//free,shared across processes

{ ASSERTION(queueSize > 0); Int8* ptr = reinterpret_cast (&mQueue[0]); new(ptr) CMessage[queueSize]; //now init the queue correctly } CCommQueue::~CCommQueue(){}

//the queue is destroyed.

13.1 Queues

209

bool CCommQueue::add( //add message into queue const CMessage& msg, //reference to a message bool waitForever ) //true when the sender can wait { if (false == mWriteMutex.take(waitForever)) { return false; //a writer is active,producer } //does not want to wait mCounterMutex.take(true); //here prod.can write if Q not full if (mCounter == mSize) //check the counter { mCounterMutex.give(); //Q full,possible:reader in getMessage if (false == waitForever) //bcs. prod. not want wait,leave method { mWriteMutex.give(); return false; } do { //try to force priority inheritance if and only if reader has a //base prio lower than prio of writer, it is possible that //the reader at the moment has a high prio due to inheritance //of prio of other thread. It is a wrong design if reader //can have this high prio for a long time if (CThread::getCurrentThreadPrio() > mPrioOfReader) { //reaching this point the writer want to wait for reader //set the flag. This flag is not protected against reading. //It is possible the reader checks flag just at this moment //and finds it false the reader will check again in next //read message (bcs. queue not empty) mHiPrioWriterWait = true; //try to take PrioM such that reader can inherit priority mPrioInheritanceMutex.take(true); //reaching this point if and only if reader finds //mWriterFlag is true and in turn call //mPrioInheritanceMutex.give() //prio of reader is lower than prio of writer. //give the mutex back mPrioInheritanceMutex.give(); //try to take another mutex that reader has to force //make the next step getting the mPrioInheritanceMutex mSyncMutex.take(true); //reader has normal prio now. Reader will continue working //if a high prio task will write into a full queue //(the high prio task must take the mPrioInheritanceMutex //first that is owned by the reader mSyncMutex.give(); mHiPrioWriterWait = false;

210

13 Event-Verarbeitung } else { mWriterSignal.take(); } } while (mCounter == mSize); } else { mCounterMutex.give(); } mQueue[mTailIndex] = msg; mTailIndex++; if (mTailIndex == mSize) { mTailIndex = 0; } mCounterMutex.take(true); mCounter++; mCounterMutex.give(); mWriteMutex.give(); mSignalSem.give(); return true;

//proceed as normal

//Q not full - release counter mutex //now we can write message into Q //wrap,using simple assigment inst. of //mTailIndex=(mTailIndex + 1)%mSize

//update the counter

//release the write mutex //Trigger the semaphore

} bool CCommQueue::getMessage( //get message. Caller cannot block CMessage& msg) //ret true if a message exists { bool retVal = false; //check whether we can read something, if not leave method, but //dont forget to give back inherited prio (possible if Qsize is 1) //Possible: in meanwhile a producer has written a message into //queue. In implementation of dispatcher the dispatcher will //take the trigger semaphore later and retry again if (0 != mCounter) { retVal = true; //now we have to read-if reader is suspended at this point it //will be woken up when a high prio trys to write into full Q msg = mQueue[mHeadIndex]; mHeadIndex++; if (mHeadIndex == mSize) //wrap if needed { mHeadIndex = 0; } mCounterMutex.take(true); //now update counter mCounter--; //-only a short step mCounterMutex.give(); }

13.2 Dispatcher if (true == mHiPrioWriterWait) { mPrioInheritanceMutex.give();

211

//free mutex, reader gets own //prio. if inher. prio before

mPrioInheritanceMutex.take(true); mSyncMutex.give(); mSyncMutex.take(true); } mWriterSignal.give(); return retVal; } Int32 CCommQueue::getNumOfMessages(void) { return mCounter; }

//get number of events in Q //approximate

Int32 CCommQueue::getNumOfBytesNeeded(void) //get size of queue { return MAKE_ALIGNMENT_SIZE(sizeof(CCommQueue) + sizeof(CMessage)*(mSize-1)); } Listing 13-6. Basisklasse CCommQueue.cpp, Implementierung

13.2 Dispatcher Eigentlich gibt es in einem System mehrere Dispatcher. Man kann sich den Dispatcher wie einen Paketverteiler vorstellen. Mit einem kleinen Lastwagen kommt der System-Dispatcher und bringt alle Pakete des Tages f¨ ur diesen Wohnort. Er verteilt diese im Postamt in die F¨acher (lokale Queues) der einzelnen Paketzusteller gem¨aß der Postleitzahl, die auf den Paketen stehen. Diese geben die einzelnen Bezirke (Komponenten, Receiver-ID) an, in denen die lokalen Zusteller die Pakete dann nach Straßenadressen (Function-ID) in die Briefk¨asten verteilen. Der System-Dispatcher muss demnach die Adressen der Queues der lokalen Verteiler kennen, dies ist Task- oder Prozess-¨ ubergreifend. Die lokalen Komponenten-Dispatcher kennen die Briefk¨asten innerhalb ihres Bezirks, das sind die Adressen innerhalb eines Prozesses. 13.2.1 Der System-Dispatcher Der System-Dispatcher muss die Briefk¨ asten aller Komponenten kennen. In diese verteilt er eingegangene Nachrichten. In unserer Implementierung be-

212

13 Event-Verarbeitung

finden sich alle Queues der Komponenten im Shared-Memory. Der SystemDispatcher kann sich von allen Komponenten u ¨ber den jeweiligen Kontext die add-Methoden der jeweiligen Queues holen. Damit kann der Dispatcher alle Queues ansprechen und sie abh¨angig von den im Event-Objekt gespeicherten Informationen f¨ ullen. Tats¨achlich kann der System-Dispatcher sowohl f¨ ur das Verteilen eingegangener Events als auch f¨ ur das Aussenden im System generierter Events verantwortlich sein. Wir beschr¨anken uns im Moment auf kleine Ausschnitte, im Teil II gehen wir genauer auf die Implementierung ein. Der System-Dispatcher empf¨ angt aus drei Quellen Events, die in zwei m¨oglichen Formaten vorliegen k¨ onnen und in der Headunit verteilt werden m¨ ussen. Alle Events werden in einer Queue aufgefangen. 1. Vom externen MOST-Bus werden MOST-Events empfangen und m¨ ussen an eine der internen Komponenten weiterverteilt werden. 2. Von einem Tastaturtreiber werden Daten abgeholt, die an die HMIKomponente weitergeleitet werden m¨ ussen. Dort k¨onnen sie dann im Zusammenhang mit dem aktuellen Men¨ u ausgewertet werden. 3. Von internen Komponenten empf¨ angt er Events, die intern oder nach außen weiterverteilt werden m¨ ussen. Diese Events werden in derselben externen Queue wie oben aufgesammelt: a) Eine interne Komponente sendet Nachrichten u ¨ber den Dispatcher an externe MOST-Devices. b) Eine interne Komponente sendet Nachrichten u ¨ber den Dispatcher an interne MOST-Devices. 13.2.2 Der lokale Dispatcher Jede Komponente besitzt ihren eigenen Dispatcher. Der lokale Dispatcher bedient zuerst seine interne Queue, da hier eventuell noch nicht abgeschlossene Aktionen interne Events hinterlegt haben (RTC). Anschließend wird die System-Queue bedient, da hier die wichtigsten Nachrichten zu erwarten sind. Ist dort z.B. in System shutdown“ hinter” legt, m¨ ussen keine anderen weniger wichtigen Nachrichten aus der externen Queue mehr bearbeitet werden. Schließlich wird die normale externe Queue kontrolliert.

while (false == hasMessage) { //try intern. command RTC hasMessage = mInternalQueue.getMessage(Message); if (false == hasMessage) { //next is System hasMessage = mSystemQueue.getMessage(Message);

13.2 Dispatcher

213

} if (false == hasMessage) { //external Q last hasMessage = mNormalQueue.getMessage(Message); } if (true == hasMessage) { break; //command has been found } else if (false == waitForever) { return; } //at this point the dispatcher must wait for a new Message //because all Queues are empty. //mSem is only free if at least one queue is not empty //or if a cond var signal is received. mSem.take(); } if (true == hasMessage) { handleMessage(Message); }

//handle message

} Listing 13-7. Lokaler Dispatcher

13.2.3 Signalisation im Dispatcher Im oben gezeigten Dispatcher-Beispiel gibt es die Zeile mSem.take. Der Dispatcher wartet also blockierend auf die Verf¨ ugbarkeit von Events der Queues. Er steht an der Stelle mSem.take und wartet wie vor einer roten Ampel. In dieser Zeit ist der Motor aus, je nach Implementierung schl¨aft der Thread oder die ganze Komponente und verbraucht keine Rechenleistung. Durch den Aufruf mSem.give einer anderen Komponente wird der Dispatcher geweckt, wenn in einer der Queues neue Events eingetragen wurden. 13.2.4 Registrierung im Dispatcher Jeweils beim Dispatcher kann hinterlegt sein, wer u ¨berhaupt Pakete empfangen will. Dies gilt f¨ ur ganze Komponenten, aber auch f¨ ur Funktionen innerhalb der einzelnen Komponente. So k¨ onnen sich der System-Dispatcher oder der lokale Dispatcher Arbeit sparen. Zus¨atzlich k¨onnen sich Komponenten sogar bei dem Absender m¨oglicher ¨ Pakete am anderen Ende der Ubertragungskette“ registrieren lassen und hin” terlassen, an welchen Paketen sie interessiert sind. Eventuell kann ja so der

214

13 Event-Verarbeitung

ganze Transport gespart werden. In dem Abschnitt Change-Events und bei der Notifikation wurde das bereits angesprochen. Wir nehmen f¨ ur die Dispatcher an, dass sich pro Event-Typ nur ein Listener registrieren muss. Die Liste wird im Dispatcher selbst gef¨ uhrt. In die Liste wird direkt der Message-Handler eingetragen.

void CDispatcher::addListener(CMessage::MessageType theMsgType, IMessageHandler* theListenerPtr) { mListeners[theMsgType] = theListenerPtr; } void CDispatcher::removeListener(CMessage::MessageType theMsgType) { mListeners[theMsgType] = &sNullHandler; } Listing 13-8. Registrierung und Deregistrierung in CDispatcher

13.3 Synchrone Events In bestimmten Layern der SW-Architektur kommt es ganz besonders darauf an, dass die zeitliche Reihenfolge erhalten bleibt und keine unklaren ra¨ ” ces“ zwischen Nachrichten entstehen. Hier bietet sich die synchrone Ubertra¨ gung an, die einfacher zu u lassen ¨berschauen ist. Auch Event-Ubertragungen sich auf synchron trimmen, es wird gewartet, bis das Event abgeholt oder ein Antwort-Event angekommen ist. Eine einfache L¨osung kann auch sein, die Queue nur f¨ ur ein Event tief zu implementieren. Dann muss aber sehr sorgf¨altig auf die Vermeidung gegenseitiger Blockierung geachtet werden (Philosophenproblem). Auch darf es daf¨ ur nur einen Sender/Produzenten geben.

14 Zustandsautomaten

14.1 Motivation In der eingebetteten Welt sind viele typischen Applikationen zustandsbasiert. Gef¨ahrlich wird es, wenn Entwickler diese Tatsachen nicht wahrnehmen und ein Netz aus if-else F¨ allen implementieren, in denen Zustandsvariablen versteckt und die Zustands¨ uberg¨ ange implizit sind. Oft f¨ uhrt das dazu, dass Zust¨ande, die vorkommen k¨ onnen, nicht ganz erfasst bzw. ausprogrammiert werden. Jedes Objekt hat Eigenschaften und Verhalten. Der Aufruf einer Methode entspricht dem Senden einer Nachricht an das Objekt. Objektmethoden k¨ onnen in zwei Kategorien klassifiziert werden. Zustandslose Objekte Der Aufrufende bekommt immer dasselbe Ergebnis auf seinen Aufruf. Die Ausgabe ist nur eine Funktion oder Transformation der Eingabedaten.

Abbildung 14.1. Zustandsloses Objekt

Die Zeit oder die Vergangenheit spielen hierbei keine Rolle, auch wenn die Methoden komplexe kombinatorische Entscheidungen beinhalten k¨onnen (eine Menge von switch-case-Anweisungen, die auf die Parameter aufbauen). Zustandsmaschinen, FSM (finite state machine) Die Ausgabe h¨ angt nicht nur von den Eingangssignalen, sondern auch von der Historie in Form von Objekt-Eigenschaften (Zust¨anden) ab. Es werden

216

14 Zustandsautomaten

Attribute des Objekts verwendet, um seinen letzten Zustand zu merken, siehe auch [Hor]. Die meisten Objektmethoden folgen dieser Form. Wenn sich

Abbildung 14.2. Zustandsbehaftetes Objekt

Eigenschaften des Objekts ¨ andern, so wird ein Methodenaufruf ein anderes Ergebnis zur¨ uckgeben als vorher. Mit steigender Anzahl der Entscheidungen und Verzweigungen, die von den Zust¨anden des Objekts abh¨ angen, treten viele Probleme auf: • Die Komplexit¨ at kann exponentiell steigen. • if-else- oder switch-Anweisungen, die auf Zust¨anden basieren, werden schnell un¨ uberschaubar, schwer zu warten oder zu erweitern. ¨ • Durch Anderung der ¨ offentlichen Attribute entstehen wegen der schlechten Kapselung Seiteneffekte, die schwer zu verfolgen sind. • Wenn nicht alle Zust¨ ande verstanden werden, sind auch nicht alle Entscheidungswege komplett, es fehlen Defaults und Notausg¨ange. • Die Logik wird falsch implementiert.

14.2 Kommunikation Wie im vorigen Kapitel gezeigt, k¨ onnen wir die Kommunikation zwischen zwei Objekten als synchron oder asynchron klassifizieren. Synchrone Kommunikation Die synchrone Kommunikation entspricht einem Funktionsaufruf (call). Ein R¨ uckgabewert wird abgewartet und steht aber auch gleich nach dem Aufruf zur Verf¨ ugung. Diese Kommunikation ist einfach zu implementieren und zu u ¨berschauen, blockiert jedoch den Aufrufenden w¨ahrend des gesamten Aufrufes.

14.4 Statechart-Elemente

217

Asynchrone Kommunikation Die Zeit, die zwischen Anfrage und Antwort vergehen kann, ist nicht determiniert. Aufrufendes und aufgerufenes Objekt k¨onnen parallel arbeiten. Der Vorteil dieser Kommunikation ist, dass das aufrufende Objekt nicht blockiert wird, da es nur einen Auftrag an einen Dienstanbieter absendet. Dieser tr¨agt dann Kenntnis und Verantwortung f¨ ur das weitere Vorgehen. Der Nachteil dieser Kommunikation ist die entstehende Parallelit¨at und Komplexit¨at. Asynchrone Kommunikation ist in vielen F¨allen unvermeidbar.

14.3 Automaten Systeme, die Gegenstand unserer Betrachtungen sind, sind komplexe Zu” standsautomaten“ mit einer hohen Zahl asynchroner Kommunikationswege. Unsere Systeme sind reaktiv und asynchron, d.h., Events werden von außen oder aus der Hardware heraus ausgel¨ ost, beschreibbar als stochastische Prozesse. Wartezeiten (idle) sind unvermeidbar und Antwortzeiten sind stochastischer Natur. Da nicht alle Anforderungen durch Events sofort bedient werden k¨onnen, werden Puffer oder Queues eingef¨ uhrt. Als Konsequenz daraus sind Antworten verz¨ogert zu erwarten. Auch k¨ onnen aufrufende Objekte durch die begrenzte Kapazit¨at von Queues zeitweise blockiert werden. Im schlimmsten Fall k¨onnen Events verloren gehen oder gest¨ ort eintreffen. Eine geeignete Modellierung eines solchen Systems ist das Konzept von Zustandsautomaten. Es gibt einige Modelle in der Literatur: • • •

Mealy-Automaten Moore-Automaten Harel-Statecharts

Wegen der Komplexit¨ at der Probleme und wegen der M¨achtigkeit von Zustandsdiagrammen ist das Harel-Konzept [Har] u ¨blich, dessen Syntax und Semantik im n¨achsten Abschnitt vorgestellt werden.

14.4 Statechart-Elemente ¨ Einfache Uberg¨ ange Ein Zustandsdiagramm ist ein einfaches Netz aus Zust¨anden und Events. Ein Zustands¨ ubergang kann mit einer Bedingung versehen werden: Dieses Diagramm kann wie folgt verstanden werden: Wenn sich das Objekt im Zustand A befindet, das Event EV XY eintritt und die Bedingung C wahr ist, so wechselt es in den Zustand B.

218

14 Zustandsautomaten

Abbildung 14.3. Bedingter Zustands¨ ubergang

Bedingungen sind in der Regel versteckte Zust¨ande. Sie sind allerdings einfach“, so dass eine explizite Modellierung durch Zust¨ande nur zur Un¨ uber” sichtlichkeit f¨ uhrt. In realen Systemen sind mit dem Zustands¨ ubergang Aktionen verkn¨ upft. Normalerweise ist es nicht m¨ oglich, alle Aktionen in das Diagramm einzutragen, so dass eine entprechende Zustands¨ ubergangstabelle ben¨otigt wird. Man kann zus¨atzlich zwischen Aktionen unterscheiden, die bei Eintritt in einen Zustand erfolgen, und solchen, die bei Verlassen eines Zustands aktiv werden. Current state Event Actions Next state Comment conditions A EV XY and F1, B For example: condition C F2 Actions due to the softkey 1; and F3 the current panel is FM“ ” Abbildung 14.4. Zustands¨ ubergangstabelle

Exit- und Entry-Aktionen F¨ ur jeden Zustand k¨ onnen eine Exit- und eine Entry-Aktion definiert werden. Eine Entry-Aktion wird aufgerufen, wenn das System den Zustand annimmt. Eine Exit-Aktion ist die letzte Aktion in dem Zustandskontext, bevor er verlassen wird. Die Exit-Aktion des alten Zustands wird vor der Aktion beim Zustands¨ ubergang ausgef¨ uhrt. Aktion im Zustandskontext In der Regel werden, wenn ein Zustand verlassen wird, die zugeh¨origen Exit- und Entry-Aktionen ausgef¨ uhrt. Beim Selbst¨ ubergang ist dieses Verhalten manchmal unerw¨ unscht. Eine M¨ oglichkeit ist die Einf¨ uhrung der Aktionen im Zustandskontext. In diesem Fall wird als Reaktion auf das Event EV1 die Methode f3 aufgerufen. Beim Erhalt des Events EV2 wird das Event EV3 ausgel¨ost, das als N¨ achstes vom Automaten bearbeitet wird. Zust¨ ande mit Tiefe (Oberzust¨ ande); Verfeinerung und ClusterBildung ¨ Ein Zustandsautomat kann durch die Menge der Uberg¨ ange sehr schnell un¨ ubersichtlich werden. Eine M¨ oglichkeit ist die Gruppierung der Zust¨ande,

14.4 Statechart-Elemente

219

Abbildung 14.5. Aktionen im Zustandskontext

die dasselbe Verhalten bei bestimmten Events aufweisen (¨ahnlich wie die Basisklasse der objektorientierten Programmierung). Ein Oberzustand kann das gemeinsame Verhalten beschreiben. Ein Zustand in diesem Oberzustand erbt dieses Verhalten. In einem Statechart k¨ onnen Zust¨ande in einer Hierarchie organisiert werden (Zust¨ ande im Zustand).

Abbildung 14.6. Zustandshierarchie

Zust¨ande A und B bilden die Abstraktion des Systems auf einer h¨oheren Ebene. Zustand A enth¨ alt mehrere Zust¨ ande (so genannte Unterzust¨ande). A ist ein Oberzustand (Superstate). Das gemeinsame Verhalten f¨ ur alle Zust¨ ande in A ist, dass der Automat zum Zustand B u ¨bergeht, wenn das Ereignis EV UV vorkommt. Das Event ¨ EV XY deutet nur an, dass aus einem Unterzustand von A ein Ubergang zum Zustand B m¨oglich ist. Ebenso ist ein Wechsel von B in einen Unterzustand von A aufgrund von EV AB erlaubt. Ein m¨ ogliches Bild wird unten gezeigt: Default-Startzustand und Endzustand Harel f¨ uhrte auch Symbole f¨ ur Default-Startzust¨ande und Endzust¨ande ein. Der gef¨ ullte Kreis beschreibt den Ausgangpunkt f¨ ur den Default-Startzustand. Beim Eintreffen des Zustands A wird z.B. der Zustand C angenommen. Entsprechend wird der Endzustand besonders hervorgehoben. In vielen Anwendungen wird das Konzept des Endzustands nicht verwendet. Der Automat existiert solange wie das System. Der gef¨ ullte Kreis hat im Konzept von

220

14 Zustandsautomaten

¨ Abbildung 14.7. Uberg¨ ange in der Zustandshierarchie

Abbildung 14.8. Default-Start- und End-Zust¨ ande

Harel keinen Namen. Wir nennen ihn einfach den Default-Initialzustand. ¨ Der Ubergang vom Default-Initialzustand in einen richtigen Zustand kann durch ein k¨ unstliches Event EV INIT dargestellt werden. Das Event wird als Parameter f¨ ur die Entry-Methode aufgerufen. H¨aufig beh¨alt das System sein Ged¨ achtnis beim Verlassen eines Oberzustands. Wenn beispielsweise ein Telefonanruf kommt, w¨ahrend der Benutzer ein Ziel eingibt, muss der Benutzer nach dem Anruf seine Eingabe fortsetzen k¨onnen). Beim Wiedereintritt muss der zuletzt eingenommene Zustand wiederhergestellt werden. Die Oberzust¨ ande (in dem Bild A und C) haben ein Ged¨achtnis. Das erste Mal, wenn der Zustand A betreten wird, werden der Oberzustand B und in B der Zustand E als Default-Zust¨ande angenommen. Beim Wiedereintritt (durch das Ereignis 1) wird das Default-Verhalten igno-

14.5 Probleme mit Statecharts und Ersatzl¨ osungen

221

Abbildung 14.9. Statechart mit Ged¨ achtnis

riert. Der letzte Zustand in A wird wiederhergestellt, wenn das System z.B. zuletzt in F ist, dann muss der Zustand F wieder aktiviert werden. Tiefe Historie H¨aufig ist die Historie nicht nur f¨ ur eine Ebene, sondern f¨ ur eine Hierarchie gespeichert. Um diese Angabe zu vereinfachen, kann zu der Eingabe H ein Stern hinzugef¨ ugt werden. In diesem Fall hat nicht nur A, sondern auch B und C ein Ged¨achtnis. Parallelismus/AND-Zust¨ ande Harel bietet auch das Konzept von nebenl¨aufigen Automaten. Sie sind ¨ durch gestrichelte Linien getrennt. Ein Ereignis kann mehrere Uberg¨ ange in ¨ verschiedenen Automaten ausl¨ osen. Ferner kann ein Ubergang bedingt durch den Zustand eines anderen Automaten ausgef¨ uhrt werden. Problematisch in diesem Konzept ist die Reihenfolge der Ausf¨ uhrung. Ferner ist das Konzept nur brauchbar und u ¨berschaubar, wenn die Abh¨angigkeiten der Automaten trivial sind.

14.5 Probleme mit Statecharts und Ersatzl¨ osungen Mit den Statechart-Elementen kann man das Verhalten vieler Systeme in u ¨bersichtlicher Form beschreiben. Das Konzept von Harel stammte von 1968. Die Grundz¨ uge werden fast unver¨ andert in UML u ¨bernommen. Das Konzept hat aber einige Probleme:

222

14 Zustandsautomaten

Abbildung 14.10. Statechart mit tiefer Historie

Abbildung 14.11. Statechart mit Parallelismus

• Der Parallelismus ist schwer zu verwenden. Stattdessen kann man eine Priorit¨at einf¨ uhren, um die Reihenfolge der Abarbeitung zu erzwingen. ¨ Ein Event, das mehrere Uberg¨ ange in verschiedenen Automaten ausl¨ost, kann durch eine Kette von Events simuliert werden. Nachdem der erste Automat das Event konsumiert, wird das n¨ achste Event ausgel¨ost, das von einem folgenden Automaten bearbeitet wird. Die Kette wird fortgesetzt, bis der Letzte das Event bekommt. • W¨ahrend die Zust¨ ande durch die Hierarchie eine Struktur bzw. ein Ab¨ straktionslevel aufweisen, haben die Uberg¨ ange immer noch den Charakter von Spagetti-Spr¨ ungen“. Die Spr¨ unge k¨onnen von einem beliebigen ” Level in einen beliebigen Level stattfinden. Als Konsequenz muss das gesamte Statechart global gehalten werden. Ein Unterzustand, als Objekt

14.6 Implementierung dynamischen Verhaltens

223

modelliert, muss in der Regel andere Objekte und ggf. auch ihren internen Aufbau kennen, um die Spr¨ unge realisieren zu k¨onnen. ¨ Eine Ersatzl¨osung ist die Einschr¨ ankung, dass nur Uberg¨ ange in demselben Level stattfinden. Ein Unterzustand, falls notwendig, kann ein Ereignis ausl¨osen, das den Oberzustand veranlasst, den Wechsel auszuf¨ uhren. Beispielweise statt einen Sprung von einem Unterzustand C in den Zustand B durch das Ereignis EV 1 zu erlauben, kann aufgrund von EV 1 ein Ereignis ¨ EV1 1 generiert werden, das letzlich den Ubergang von A in B zwingt.

Abbildung 14.12. Zustands¨ uberg¨ ange in Hierarchie

¨ Umgekehrt kann ein Sprung von B nach C durch einen Ubergang von B nach A mit einer anschließenden M¨ oglichkeit f¨ ur den Eintritt in C simuliert werden. Um dies zu erm¨ oglichen, wird das Konzept des Eintritts in einen Oberzustand erweitert (siehe die Implementierung unten).

14.6 Implementierung dynamischen Verhaltens In diesem Abschnitt werden einige Implementierungen von Zustandsdiagrammen vorgestellt. Wir benutzen ein einfaches Statechart als Beispiel (siehe Bild). Es ist leicht, einen einfachen Automaten ohne Hierarchie zu kodieren. Man hat nur einen aktuellen Zustand. Er wird dann in einer Variablen gehalten, die bei einem Zustandswechsel aktualisiert wird. Zust¨ande eines Statecharts zu implementieren, ist weniger einfach, da es eine Anzahl unterschiedlicher Detaillierungsebenen hat, von denen Teile auch parallel ablaufen k¨ onnten. Der Parallelismus wird, wie oben erkl¨art, bewusst ausgenommen. Das Statechart enth¨ alt zwei Zust¨ande. Der eine ist ein Oberzustand A, der zwei Unterzust¨ ande C und D verbirgt. Der Automat startet im Zustand D (im Oberzustand A). Zur Demonstration werden vier Events genutzt. In unserem Beispiel ben¨ otigen wir zwei Variablen, um den aktuellen Zustand darzustellen.

224

14 Zustandsautomaten

Abbildung 14.13. Beispiel eines Statecharts

In der obersten Hierarchie-Ebene kann sich der Automat im Zustand A oder B befinden. Im Zustand A kann sich der Automat in der n¨achsttieferen Ebene im Zustand C oder D befinden. Im Allgemeinen wird eine Zustandsvariable f¨ ur einen Ober-Zustand ben¨ otigt. Eine m¨ogliche Implementierung eines allgemeinen Statecharts besteht aus folgenden Schritten: • • •

Definition der Events, Implementierung der Aktionen, Implementierung des Statecharts.

14.6.1 Definition der Events In unserem Beispiel ben¨ otigen wir vier Events. Der Automat befindet sich in dem so genannten Default-Initialzustand. F¨ ur die Aktionen, die bei einem Objekt im Konstruktor ausgef¨ uhrt w¨ urden, muss hier selbst gesorgt werden. Deshalb f¨ uhren wir ein zus¨ atzliches Init-Event EV INIT ein, mit dem wir unseren Zustandsautomaten initialisieren. Beim Starten wird der erste Zustand angenommen und die zugeh¨ orige Entry-Aktion ausgef¨ uhrt. Um das Verhalten zu vereinheitlichen, wird das Event EV INIT als Erstes (meist im Rumpf des Konstruktors des Automaten) in die Queue geschrieben. enum Event // events of the demo { EV_INIT, EV_1, EV_2, EV_3, EV_4 };

14.6 Implementierung dynamischen Verhaltens

225

14.6.2 Implementierung der Aktionen Zur Implementierung des dynamischen Verhaltens muss ein geeigneter Satz Objekt-Methoden gew¨ ahlt werden. Zun¨ achst m¨ ussen wir die Aktionen, die im Statechart angegeben werden, implementieren. Da die Methoden w¨ahrend der ¨ Entwicklung weniger oft Anderungen unterliegen als die Diagramme selbst, bietet sich die Trennung der Methoden von der Implementierung des Zustandsautomaten an. Ferner f¨ uhrt die Trennung dazu, dass die Aktionen vom Zustandsautomaten unabh¨ angig bleiben. In unserem Beispiel f¨ uhren wir die Klasse CFSMAction ein, die alle ben¨ otigten Aktionen unterst¨ utzt.

class CFSMAction { public: void entryA(void); void entryB(void); void entryC(void); void entryD(void); void exitA(void); void exitB(void); void exitC(void); void exitD(void); void f1(void); void f2(void); void f3(void); void f4(void); };

// actions called by the example FSM

// entry actions

// exit actions

// actions called during a transition

Listing 14-1. Methoden zum Beispielautomaten

Man beachte: • Alle Methoden k¨ onnen privat deklariert werden, da sie mit Zustands¨ uberg¨angen innerhalb bestimmter Objekte assoziiert sind und andere Objekte sie nicht direkt aufrufen d¨ urfen. Nur die befreundeten Klassen (friend class) d¨ urfen die Aktionen ausf¨ uhren. • Objekte, die die Methoden aufrufen, erhalten eine Referenz auf ein Objekt, das alle notwendigen Aktionen anbietet. • Methoden sollten sinnvoll benannt werden, um ihre Aufgabe zu verdeutlichen. In unserem Beispiel haben wir sie (relativ schlecht) nur demonstrativ benannt, um ihre Rollen hervorzuheben. • Objekte, die Aktionen ausf¨ uhren, d¨ urfen keine Kenntnis u ¨ber den aktuellen Zustand des Automaten haben. • Falls es eine switch-case-Anweisung innerhalb der Methoden gibt, sollte man sich fragen, ob diese Teil des Statecharts ist. Oft wird durch solche Anweisungen ein Teil des Kontrollflusses unzul¨assig aus dem Statechart in die

226

14 Zustandsautomaten

Methode verlagert. Eine Ausnahme ist die Bedingungsvariable. Klassen, die Aktionen implementieren, k¨ onnen Bedingungsvariablen beinhalten. Bedingungsvariablen sind erweiterte Zustandsvariablen. Sie sind von Natur aus einfach und sind z.B. der Z¨ ahlerstand, die Anzahl der Wiederholungen usw. Es ist schwierig zu entscheiden, ob die Aktionen die Bedingungsvariablen ver¨andern d¨ urfen oder nicht. In der Regel h¨angt diese Entscheidung von der Anwendung und von den Bedeutungen der Variablen ab. Manchmal m¨ ussen die Objekte Events ausl¨ osen, um indirekt die Bedingungen zu ver¨andern. Erweiterte Zustandsvariablen m¨ ussen daher mit großer Sorgfalt gew¨ahlt werden. Ferner m¨ ussen sie gut dokumentiert sein.

14.7 Implementierung der Statecharts Es gibt einige M¨oglichkeiten, Statecharts zu implementieren. Jede Technik hat Vor- und Nachteile. An dieser Stelle werden die folgenden Varianten beschrieben: • Aufz¨ahlungsmethode f¨ ur Zust¨ ande und Unterzust¨ande, • Zustandsmuster (State-Pattern), • verbesserte Aufz¨ ahlungsmethode, • Implementierung nach Samek [Sam]. 14.7.1 Implementierung durch Aufz¨ ahlung f¨ ur Zust¨ ande und Unterzust¨ ande Diese Vorgehensweise beinhaltet folgende Aktivit¨aten, siehe auch [Lee]: • Einf¨ uhrung geeigneter Aufz¨ ahlungstypen f¨ ur Zust¨ande und Unterzust¨ande, • Einf¨ uhrung geeigneter Zustandsvariablen als Member der Klasse, • Realisierung der Hilfsmethoden f¨ ur Entry- und Exit-Aktionen, • Implementierung der Event-Handler (Methoden) f¨ ur die entsprechenden Events. Einf¨ uhrung der Aufz¨ ahlungstypen Wir definieren f¨ ur jede Hierarchie-Ebene einen geeigneten Aufz¨ahlungstyp. In unserem Beispiel haben wir enum State { DEFAULT_INITIAL = -1, STATE_A, STATE_B }; // substate in super state A enum ASubState { DEFAULT_INITIAL_SUBSTATE = -1, SUBSTATE_C, SUBSTATE_D};

14.7 Implementierung der Statecharts

227

Man beachte, dass zus¨ atzliche Zust¨ ande DEFAULT INITIAL und DEFAULT INITIAL SUBSTATE eingef¨ uhrt wurden. Wir ben¨otigen sie f¨ ur den Konstruktor, der zu Beginn alle Zustandsvariablen korrekt initialisieren muss. Zustandsvariablen Anschließend definieren wir f¨ ur jede Zustandsvariable eine Member-Variable. In diesem Beispiel haben wir zwei Oberzust¨ande, den Automat selbst und den Oberzustand A. Es werden daher zwei Variablen, mState und mSubState, ben¨otigt. Man beachte, dass die Variable mSubState keine Bedeutung hat, wenn sich mState nicht im Zustand STATE A befindet. Wenn der Automat Historie hat, muss man einen weiteren Satz von Zustandsvariablen haben, um den letzten Zustand zu merken. State mState; ASubState mSubState;

// for state and substates

Einf¨ uhrung von Hilfsmethoden f¨ ur Entry- und Exit-Aktionen Entsprechend der UML-Semantik werden Exit-Aktionen im Kontext der aktuellen Zust¨ande ausgef¨ uhrt und Entry-Aktionen im Kontext der Zielzust¨ande. Daf¨ ur werden zus¨ atzliche Hilfsmethoden ben¨otigt. Alle Entry-Aktionen (bzw. Exit-Aktionen) einer Ebene werden in einer Methode implementiert. Alternativ k¨onnten wir f¨ ur jeden Zustand eine Entry- und Exit-Methode realisieren, was aber die Gesamtkomplexit¨ at erheblich erh¨ohen w¨ urde. Es ist ausreichend, dass f¨ ur jeden Hierarchie-Level eine Methode f¨ ur Entry- und eine f¨ ur Exit-Aktionen implementiert wird (d.h., f¨ ur jeden Oberzustand m¨ ussen die beiden Methoden definiert werden). Im Vergleich zu g¨ angigen Implementierungen in der Literatur (z.B. [Hor] oder [Lee]) besitzt unsere Entry-Methode das Event als Parameter. Mit diesem Parameter k¨ onnen die Behandlungen f¨ ur Historie (Ged¨achtnis), f¨ ur tiefe Historie, f¨ ur Initialisierung usw. einheitlich gestaltet werden. Die Methode kann aufgrund des Events entscheiden, ob ein Eintritt aufgrund einer Initialisierung stattfindet. Der Fall einer Wiederherstellung des Ged¨achtnisses kann ebenfalls dadurch abgedeckt werden. In unserem Beispiel spielt der Parameter noch keine Rolle. Man beachte, dass Eintritt bzw. Austritt des Zustands D implizit den Eintritt und Austritt des Oberzustands A beinhaltet. Beginnen wir mit der Exit-Aktion auf der obersten Ebene. Der Automat kann entweder in A oder B sein (im normalen Betrieb). Beim Verlassen des Zustands B wird nur eine Exit-Aktion aufgerufen. Das Verlassen des Oberzustands A f¨ uhrt dazu, dass Unterzust¨ ande verlassen wurden. Daher muss die entsprechende Exit-Hilfsmethode aufgerufen werden. Anschließend wird die Exit-Aktion von A ausgef¨ uhrt. Bei Statecharts mit Historie k¨ onnen die letzten Zust¨ande auch gespeichert werden.

228

14 Zustandsautomaten

// helper method for exit actions - super state level void CFSM1::onExit(void) { switch (mState) { case STATE_A: onAExit(); // first exit-actions of the substates mActionHandler.exitA(); break; case STATE_B: mActionHandler.exitB(); break; default: break; } } // helper method for exit actions - super state A oid CFSM1::onAExit(void) { switch (mSubState) { case SUBSTATE_C: mActionHandler.exitC(); break; case SUBSTATE_D: mActionHandler.exitD(); break; default: break; } } Listing 14-2. Exit-Methoden von CFSM1

Die Exit-Aktion des Oberzustands A ist einfach, weil er nur einfache Zust¨ande hat. Das Gegenst¨ uck der Exit-Hilfsmethode ist die Entry-Hilfsmethode. Hier muss man die Reihenfolge umkehren. Beispielsweise wird zuerst die entsprechende Entry-Aktion f¨ ur Oberzustand A ausgef¨ uhrt, bevor die Hilfsmethode f¨ ur den Eintritt in Oberzustand A aufgerufen wird. Der Parameter e wird hier nicht verwendet. Man kann ihn aber benutzen, um eine eventuelle Historie wieder herzustellen.

vvoid CFSM1::onEntry(Event e ) { switch (mState) {

14.7 Implementierung der Statecharts

229

case STATE_A: mActionHandler.entryA(); // go in to the deep onAEntry(e); break; case STATE_B: mActionHandler.entryB(); break; default: break; } } void CFSM1::onAEntry(Event /* e */) { // note that the parameter e is not used. switch (mSubState) { case SUBSTATE_C: mActionHandler.entryC(); break; case SUBSTATE_D: mActionHandler.entryD(); break; default: break; } }

Listing 14-3. Die on Entry-Methoden

Bei der Implementierung sollte man folgende Punkte beachten: •

Switch-Statements sind if-else-Konstrukten vorzuziehen, da if-elseKonstrukte schwerer zu lesen sind und leichter Verschachtelungsprobleme ausl¨osen k¨onnen. • Es muss immer ein Default-Zweig vorgesehen werden, um CompilerWarnungen zu vermeiden und um die M¨ oglichkeit f¨ ur Fehlerbehandlungen vorzusehen. • Die case-F¨alle sollten durch breaks voneinander getrennt bleiben. Die Mitverwendung aufeinander folgender F¨ alle spart zwar Codespeicher, ist aber fehlertr¨achtig. Event-Handler Wir f¨ uhren nun Methoden f¨ ur jedes Event ein, auf das ein Objekt reagieren muss. In unserem Beispiel ben¨ otigen die Methoden keinen Parameter. In der Praxis k¨onnen wir aber einen bis zwei Parameter einf¨ uhren. Nat¨ urlich k¨onnte

230

14 Zustandsautomaten

man auch mehrere Parameter einf¨ uhren, die Komplexit¨at der Implementierung bzw.Modellierung steigt aber mit der Zahl der u ¨bergebenen Argumente. Als R¨ uckgabewert f¨ uhren wir einen bool-Wert ein, der aus mehreren Gr¨ unden hilfreich sein wird: • Es kann damit leicht das Muster Verantwortungskette“ (chain of respon” sibility) implementiert werden. Externe Events k¨onnen durch eine Kette von FSMs gesendet werden, bis eine das Ereignis konsumiert. • Man kann damit Zusatzinformationen f¨ ur Debugger einf¨ uhren (wird das Event konsumiert oder nicht). In unserem Beispiel sind es unter anderem folgende Methoden: Mit EV INIT wird der Automat initialsiert. Der Oberzustand A wird eingenommen. Gleichzeitig wird dann der Automat A aktiviert.

bool CFSM1::onEVInit(void) { if (DEFAULT_INITIAL == mState) { // set default state mState = STATE_A; mSubState = SUBSTATE_D; onEntry(EV_INIT); return true; } return false; }

bool CFSM1::onEV1(void) { if ( (STATE_A == mState) && (SUBSTATE_D == mSubState) ) { // exit action (in the context of current state) onAExit(); mActionHandler.f1(); // action of the transition mSubState = SUBSTATE_C; // transition // entry action (in the context of the new state) onAEntry(EV_1); return true; } return false; } Listing 14-4. Beispiel von Event-Handler-Methoden

Die Behandlungen f¨ ur andere Events sind entsprechend zu implementieren. Wie eingef¨ uhrt, geben die Methoden true f¨ ur den Fall zur¨ uck, dass das Ereignis konsumiert wurde.

14.7 Implementierung der Statecharts

231

Alternativ zu Event-Handlern kann man Zustands-Handler implementieren. Ein Zustands-Handler ist eine Methode f¨ ur den einzelnen Zustand. Er bekommt alle Ereignisse und kann sich entscheiden, was zu erledigen ist. Ein Zustands-Handler ist nur dann sinnvoll, wenn die Menge der Events klein ist. Konsequenzen Die beschriebene Implementierung von Zustandsmaschinen hat einige Vorteile: • • •

Sie ist einfach. Es werden nur enumerierte Zust¨ ande und Trigger ben¨otigt. Der Speicherbedarf (Footprint) ist klein. Es werden nur einfache Variablen f¨ ur die Zust¨ande verwendet. Nachteile sind:

• • • •

Keine Wiederverwendung von Code, alle Elemente werden manuell programmiert. Flache Implementierung ohne Hierarchien. ¨ Manuelle Implementierung aller Entry-/Exit-Aktionen sind bei Anderungen der Topologie schwer zu verstehen und zu warten. Die Aktionen eines Zustands sind u ¨ber verschiedene Stellen der Klasse verteilt.

Die vorgestellte Technik ist nur f¨ ur kleine Statecharts zu empfehlen. Tools zur Code-Erzeugung wie Rhapsody sind verf¨ ugbar, mit denen diese Vorgehensweise effizienten Code erzeugen kann. Bei dieser Vorgehenweise ist das Statechart aber global. Alle Zust¨ ande m¨ ussen sich gegenseitig kennen. 14.7.2 Zustandsmuster (State-Pattern) Eine popul¨are Implementierung von Statecharts ist in [Gan] beschrieben. Jeder Zustand ist in einem Objekt einer eigenen Klasse gekapselt. Damit reagiert jeder Zustand auf denselben Satz von Events, aber mit verschiedenen Aktionen. Bevor wir das Statechart in dieser Weise implementieren, ¨andern wir es uberg¨ ange nur in gleicher Ebene gibt. Damit ¨aquivalent so ab, dass es Zustands¨ vermeiden wir Spagetti-Spr¨ unge in der Zustandshierarchie. Das urspr¨ ungliche Statechart wird dann in das folgende, ¨ aquivalente transformiert. Folgende Schritte sind typisch f¨ ur die Implementierung dieses Musters: • Einf¨ uhrung einer Basis-Klasse f¨ ur alle Zust¨ande. • Einf¨ uhrung einer virtuellen Methode f¨ ur jedes Event in der Basisklasse. (Eine Alternative ist eine virtuelle Methode f¨ ur jedes Event, die alle Events dekodiert und entsprechende Funktionen aufruft.) F¨ ur das k¨ unstlich eingef¨ uhrte Event EV INIT soll keine Methode eingef¨ uhrt werden. Das Event wird als Parameter an die Entry-Methode u ¨bergeben und damit abgedeckt.

232

14 Zustandsautomaten

Abbildung 14.14. Abge¨ andertes Statechart

• Einf¨ uhrung virtueller Exit- und Entry-Methode f¨ ur jeden Zustand/Unterzustand. • Implementierung der abgeleiteten Klassen f¨ ur jeden Zustand/Unterzustand. Die beiden Default-Initialzust¨ ande m¨ ussen nicht explizit implementiert werden. • Einf¨ uhrung einer Liste von Unterzust¨ anden in jedem Oberzustand. • Implementierung einer Verteilungsmethode in der FSM, die die Events dekodiert und die entsprechenden Methoden des aktuellen Zustands aufruft. Zu bemerken ist, dass RTC (run til completion) - d.h., ein Event muss bis zum Ende behandelt werden - einzuhalten ist. Das Zustandsmuster kann wie in dem folgenden Klassendiagramm dargestellt werden. In der Regel ist die Basisklasse eine abstrakte Klasse. Ein zusammengesetzter Zustand wird nach dem Kompositum-Muster gebaut. Er ist ein Oberzustand, der mehrere Unterzust¨ ande hat (die wiederum auch Oberzust¨ande sein k¨onnen). In unserem Beispiel ben¨ otigen wir sieben Zust¨ande: Default-Initialzustand, Oberzustand A, Zustand B, Default-Initial-Unterzustand in A, Zustand C, Zustand D und einen f¨ ur den Zustandsautomaten selbst. Die Basisklasse mit ihrer Schnittstelle ist so gew¨ ahlt, dass der Verteiler (Dispatcher) die passende virtuelle Methode aufrufen kann, ohne das aktuelle Objekt zu kennen. Einf¨ uhrung der Basisklasse Es wird deshalb f¨ ur jedes Event und f¨ ur jede Entry- und Exit-Aktion eine virtuelle Methode eingef¨ uhrt.

14.7 Implementierung der Statecharts

233

Abbildung 14.15. Klassendiagramm des Zustandsmusters

class CBasicState { public: CBasicState(CFSMAction& actionHandler); virtual void onEntry(Event e) { } virtual void onExit(void){ } virtual bool onEV1(void) { return false; virtual bool onEV2(void) { return false; virtual bool onEV3(void) { return false; virtual bool onEV4(void) { return false; virtual bool onEV21(void){ return false;

} } } } }

protected: CFSMAction& mActionHandler; // used to simulate the internal queue static Event sInternalQueue; static int sQueueLength; }; Listing 14-5. Basisklasse CBasisState

Um RTC zu realisieren, werden die vom Automaten selbst generierten Events in eine interne Queue geschrieben. Um nur das Konzept zu illustrieren, wird hier eine Queue der L¨ ange eins eingef¨ uhrt. Man beachte, dass alle Methoden virtuell sind. F¨ ur Events, deren Implementierungen in allen Unterklassen unabdingbar sind, sollen die entsprechenden Methoden als rein virtuell deklariert werden.

234

14 Zustandsautomaten

Deklaration und Implementierung der Unterklassen F¨ ur jeden Zustand wird eine Klasse aus CBasicState abgeleitet. Beispielsweise implementieren wir den Zustand B: class CStateB: public CBasicState { public: CStateB(CFSMAction& actionHandler); virtual void onEntry(Event e); virtual void onExit(void); };

Im Konstruktor wird eine Referenz auf Aktionsobjekt gespeichert. Die Methoden onEntry- und onExit delegieren die Aktivit¨aten an das Aktionsobjekt. CStateB::CStateB(CFSMAction& actionHandler) : CBasicState(actionHandler) {} void CStateB::onEntry(Event e) { mActionHandler.entryB(); } void CStateB::onExit(void) { mActionHandler.exitB(); }

Der Zustand A ist etwas komplizierter, da er ein Oberzustand ist. class CStateA: public CBasicState { public: CStateA(CFSMAction& actionHandler); virtual void onEntry(Event e); virtual void onExit(void); virtual bool onEV1(void); virtual bool onEV2(void); private: CBasicState mDefaultInitialState; CStateC mStateC; CStateD mStateD; CBasicState *mCurrentPtr; };

14.7 Implementierung der Statecharts

235

Wie im vorherigen Abschnitt muss auch hier ein Oberzustand einen Zeiger auf den aktuellen Unterzustand halten. Die meisten Aktivit¨aten werden dann zum aktuellen Zustand delegiert. Der Automat startet in dem Zustand mDefaultInitialState. CStateA::CStateA(CFSMAction& actionHandler) : CBasicState(actionHandler), mDefaultInitialState(actionHandler) mStateC(actionHandler), mStateD(actionHandler), mCurrentPtr(mDefaultInitialState) { }

Der Oberzustand A kann nur u ¨ber EV INIT oder EV 4 betreten werden.

void CStateA::onEntry(Event e) { if (mCurrentPtr != & mDefaultInitialState) return; switch (e) { case EV_INIT: mCurrentPtr = &mStateD; break; case EV_4: mCurrentPtr = &mStateD; break; default: return; } mActionHandler.entryA(); mCurrentPtr->onEntry(e); }

// for safety

Listing 14-6. Der inEntry Oberzustand A

Beim Verlassen des Oberzustands A wird zun¨ achst die onExit-Methode des aktuellen Zustands aufgerufen. Die exit-Aktion von A wird ausgef¨ uhrt. Der aktuelle Zustand wird dann auf mDefaultInitialState umgelenkt. void CStateA::onExit(void) { mCurrentPtr->onExit(); mActionHandler.exitA(); mCurrentPtr = &mDefaultInitialState }

Das Event EV1 wird nur von dem Zustand D akzeptiert.

236

14 Zustandsautomaten

bool CStateA::onEV1(void) { if (mCurrentPtr == &mStateD) { mCurrentPtr->onExit(); mActionHandler.f1(); mCurrentPtr = &mStateC; mCurrentPtr->onEntry(EV_INIT); return true; } return false; } bool CStateA::onEV2(void) { return (mCurrentPtr->onEV2()); } Listing 14-7. Klasse f¨ ur SuperState A, Implementierung

Man beachte die Bedeutung des Events als Parameter in der Implementierung der onEntry-Methode. Aufgrund des Parameters wird hier die Behandlung f¨ ur die Initialiserung mit abgedeckt. Unsere Zustandsmaschine ist ebenfalls ein Oberzustand. Die Implementierungsvorgehensweise aller Oberzust¨ ande ist fast gleich.

class CFSM3 : public CBasicState { public: CFSM3(CFSMAction& actionHandler); bool dispatch (Event evt); virtual void onEntry(void); virtual bool onEV1(void); virtual bool onEV2(void); virtual bool onEV21(void); virtual bool onEV3(void); virtual bool onEV4(void); private: CBasicState mInitialState; CStateA mStateA; CStateB mStateB; CBasicState *mCurrentPtr; }; Listing 14-8. Zustandsmaschine CFSM3, Header

14.7 Implementierung der Statecharts

237

In dieser Klasse gibt es zwei interessante Methoden, den Konstruktor und den Verteiler. Im Konstruktor wird der Zustandsautomat mit onEntry(EV INIT) gestartet. Der Automat geht daraufhin in den Oberzustand A und f¨ uhrt die entsprechenden Initialsierungen durch.

CFSM3::CFSM3(CFSMAction& actionHandler) : CBasicState(actionHandler), mStateA(actionHandler), mStateB(actionHandler), mCurrentPtr(&mInitialState) { // init the machine onEntry(EV_INIT); } Listing 14-9. Konstruktor von CFSM3

Beim Erhalten des Events EV1 wird die entsprechende Methode aufgerufen. Da der Automat auf diesem Level das Event nicht behandelt, wird es nur an den aktuellen Zustand weitergereicht.

bool CFSM3::onEV1(void) { return mCurrentPtr->onEV1(); } Listing 14-10. Reaktion von CFSM3 auf EV 1

Die Verteiler-Methode f¨ uhrt in der Regel eine Dekodierung der Ereignisse aus und ruft die entsprechende Methode auf. Ferner muss der Verteiler den RTCMechanismus garantieren.

bool CFSM3::dispatch(Event evt) { // decoding the event and trigger the corresponding methods bool ret = false; switch (evt) { case EV_1: ret = onEV1(); break; case EV_2: ret = onEV2();

238

14 Zustandsautomaten break; case EV_21: ret = onEV21(); break; case EV_3: ret = onEV3(); break; case EV_4: ret = onEV4(); break; default: break; } // necessary for handling the event from substate if (ret) { // run to completion while (sQueueLength != 0) { // get event from the internal queue evt = sInternalQueue; sQueueLength = 0; dispatch(evt); } } return ret;

} Listing 14-11. Zustandsmaschine CFSM3, Ereignisverteilung

Der RTC-Mechanismus stellt sicher, dass die interne Queue zuerst geleert wird, bevor das n¨ achste externe Event bearbeitet wird. Die Bedeutung des Events als Parameter in der onEntry-Methode kann anhand der folgenden Methode studiert werden:

bool CFSM3::onEV4(void) { if (mCurrentPtr == &mStateB) { // leave the state B mCurrentPtr->onExit(); mActionHandler.f4(); // enter the state A mCurrentPtr = &mStateA; // with param EV_4 the correct substate can be taken

14.7 Implementierung der Statecharts

239

mCurrentPtr->onEntry(EV_4); return true; } return false; } Listing 14-12. Wirkung von Event als Parameter

Anmerkung: In unserer Implementierung werden Zustands¨ uberg¨ange im Oberzustand ausgef¨ uhrt. In der Implementierung von [Gan] muss jeder Zustand den Folgezustand kennen, was zu einer starken Abh¨angigkeit zwischen den Objekten f¨ uhrt. In unserer Implementierung sind die Unterzust¨ande unabh¨angig. Nur ein Oberzustand muss seine Unterzust¨ande kennen (ContainerContainment-Prinzip). Dies verbessert die m¨ ogliche Wiederverwendung der Zust¨ande in anderem Kontext. Vorteile Die Implementierung einer Zustandsmaschine entsprechend dem Zustandsmuster hat einige Vorteile: • Das zustandsspezifische Verhalten ist in separaten Klassen implementiert. Der Code f¨ ur jeden Zustand wird in seiner eigenen Klasse implementiert. Dies erlaubt, neue Zust¨ ande ohne unerw¨ unschte Nebeneffekte einzuf¨ uhren. • Die Zustands¨ uberg¨ ange sind effizient implementiert. • Die Event-Verteilung ist effizient und schnell. Jedes Event wird direkt vom aktuellen Zustands-Objekt bearbeitet, so dass keine langen switch-caseKonstrukte erforderlich sind. • Die Signatur jedes Event-Handlers kann frei definiert werden. Verschiedene Events k¨onnen unterschiedliche Signaturen haben. Es ist einfach, Parameter f¨ ur spezielle Events einzuf¨ uhren. Nachteile • Das Hinzuf¨ ugen eines neuen Zustands erfordert eine neue abgeleitete Klasse, da sie die existierenden Methoden u ¨berschreiben muss (Anzahl der Klassen w¨achst). F¨ ur Automaten mit vielen Zust¨anden ist das Muster aufgrund der auftretenden Klassen un¨ ubersichtlich und unbrauchbar. • Das Hinzuf¨ ugen eines neuen Events erfordert einen neuen Event-Handler in der Basis-Klasse und eine Rekompilierung aller abgeleiteten Klassen. • F¨ ur jeden Zustand muss ein Objekt erzeugt werden, was die Initialisierungszeit beeintr¨ achtigen kann. Bemerkung Viele Implementierungen in der Literatur sind relativ problematisch. Sie ben¨otigen globale Zust¨ ande (Klassenvariablen f¨ ur alle Zust¨ande in der Basisklasse).

240

14 Zustandsautomaten

14.7.3 Verbesserte Aufz¨ ahlungsmethode Der schwerwiegende Nachteil des Zustandsmusters ist, dass Zustandsmuster Objekte durchgehend als Zust¨ ande verwenden. Jeder Zustand besitzt das Wissen, wie die Events zu behandeln sind. Das ist jedoch nur sinnvoll und angemessen, wenn jeder Zustand denselben Satz von Events erwartet. In der Praxis ben¨otigt aber jeder Zustand nur einen kleinen Teil der Events, so dass viele der virtuellen Methoden nicht implementiert werden. Ferner ist es nicht immer notwendig, f¨ ur jeden Zustand ein Objekt bzw. eine Klasse zu entwickeln. Die oben erkl¨ arte Aufz¨ ahlungsmethode ist ein anderes Extrem. Alle Events und alle Zust¨ande werden in einer Klasse behandelt. Kombinieren wir die Idee von Aufz¨ahlungsmethode und Zustandsmuster, so erhalten wir eine weitere Implementierungsm¨ oglichkeit: • • • •

Einf¨ uhrung geeigneter Aufz¨ ahlungstypen f¨ ur Zust¨ande und Unterzust¨ande. Einf¨ uhrung geeigneter Zustandsvariablen als Member der Klasse. Jeder Oberzustand wird durch eine Klasse beschrieben. F¨ ur jeden Zustand wird eine Methode der Klasse eingef¨ uhrt.

Wie in der Implementierung des Zustandsmusters ben¨otigen wir Klassenvariablen f¨ ur die Simulation einer internen Queue. Im Vergleich zu den vorherigen Implementierungen f¨ uhren wir zus¨ atzlich ein Event EV EXIT ein, das dem aktuellen Oberzustand beim Verlassen u ¨bergeben wird. Anschließend sichert die FSM falls erforderlich die Historie und ruft direkt die Exit-Methode auf, falls der aktuelle Zustand ein reiner Unterzustand ist. Falls der aktuelle Zustand eine FSM ist, so ruft sie die Exit-Methode des aktuellen Zustands auf. Sodann wird die objekteigene Exit-Aktion aufgerufen. Beginnen wir mit der Deklaration der Klassen:

class SuperStateA { public: CSuperStateA(CFSMAction& actionHandler); void entry(Event e); void exit(); bool dispatch(Event e); private: bool onInitialState(Event e); bool onC(Event e); bool onD(Event e); CFSMAction& mActionHandler; enum State { DEFAULT_INITIAL, STATE_C, STATE_D }; State mState; }; class CFSM4

14.7 Implementierung der Statecharts

241

{ public: CFSM4(CFSMAction& actionHandler); void entry(Event e); void exit(); bool dispatch(Event e); private: bool onInitialState(Event e); bool onA(Event e); bool onB(Event e); CFSMAction& mActionHandler; enum State { DEFAULT_INITIAL, STATE_A, STATE_B }; State mState; CSuperStateA mSuperStateA; // to simulate the internal queue static Event sInternalQueue; static int sQueueLength; }; Listing 14-13. Verbesserte Aufz¨ ahlungsmethoden, Klassendeklaration

Im Konstruktor der nachfolgenden Klasse CSuperStateA wird der AktionsHandler gemerkt. Der Startzustand des Automaten ist der Default-Initialzustand. CSuperStateA::CSuperStateA(CFSMAction& actionHandler) : mActionHandler(actionHandler), mState(DEFAULT_INITIAL) {}

Das Event bei entry wird weitergeleitet an den betreffenden Zustand. Ein Austritt wird durch das Versenden des Events EV EXIT realisiert. void CSuperStateA::entry(Event e) { dispatch(e); } void CSuperStateA::exit() { dispatch(EV_EXIT); }

Die Verteilungsmethode ist eine einfache Fallunterscheidung in Abh¨angigkeit vom aktuellen Zustand:

bool CSuperStateA::dispatch(Event e) { switch (mState) {

242

14 Zustandsautomaten case INITIAL_STATE: return onInitialState(e); case STATE_C: return onC(e); default: return onD(e); }

} Listing 14-14. Dispatch-Methode von CSuperStateA

Es sind zwei Events, die den Eintritt in A erm¨oglichen. Sie werden durch die folgende Methode abgedeckt: bool CSuperStateA::onInitialState(Event e) { if (EV_INIT == e || EV_4 == e) { mActionHandler.entryA(); // entry action mState = STATE_D; // next state mActionHandler.entryD(); // entry action of the substate return true; } return false; }

Nach dem Eintritt befindet sich der Automat entweder in Zustand C oder D. Die entsprechenden Methoden sind in onC und in onD implementiert. Das Verlassen der FSM wird durch das Event EV EXIT behandelt, das in allen Methoden der Klasse implementiert werden muss. Der Folgezustand in FSM nach EV EXIT ist der Default-Initialzustand: bool CSuperStateA::onC(Event e) { if (EV_EXIT == e) { mActionHandler.exitC(); mActionHandler.exitA(); mState = DEFAULT_INITIAL; return true; } else if (EV_2 == e) { // on queue the EV_21 event CFSM4::sInternalQueue = EV_21; CFSM4::sQueueLength = 1; return true; } return false; }

14.7 Implementierung der Statecharts

243

bool CSuperStateA::onD(Event e) { if (EV_1 == e) { mActionHandler.exitD(); mActionHandler.f1(); mState = STATE_C; mActionHandler.entryC(); return true; } else if (EV_EXIT == e) { mActionHandler.exitD(); mActionHandler.exitA(); mState = DEFAULT_INITIAL; return true; } return false; }

Auf der obersten Ebene verh¨ alt sich die FSM wie ein Oberzustand. Die entsprechende Implementierung ist: CFSM4::CFSM4(CFSMAction& actionHandler) : mActionHandler(actionHandler), mState(DEFAULT_INITIAL) {}

Abbildung 14.16. Die FSM im Oberzustand

Die Implementierung f¨ ur entry- und exit-Methode ist wie die Implementierung der Klasse CSuperStateA:

244

14 Zustandsautomaten

void CFSM4::entry(Event e) { dispatch(e); } void CFSM4::exit() { dispatch(EV_EXIT); }

Die Verteilung der Ereignisse ist spezifisch und h¨angt von dem aktuellen Zustand ab.

bool CFSM4::dispatch(Event e) { bool ret; switch (mState) { case INITIAL_STATE: ret = onInitialState(e); break; case STATE_A: ret = onA(e); break; default: ret = onB(e); break; } // implement the RTC-mechanism while (sQueueLength != 0) { Event internalEvent = sInternalQueue; sQueueLength = 0; //(this->*mState)(internalEvent); dispatch(internalEvent); } return ret; } bool CFSM4::onInitialState(Event e) { if (EV_INIT == e) { mState = STATE_A; mSuperStateA.entry(EV_INIT); return true; } return false; } bool CFSM4::onA(Event e) { // A is a super state. I.e. it must be first invoked if (true == mSuperState.dispatch(e) {

14.7 Implementierung der Statecharts

245

return true; } // if the event is not consumed the machine must try to consume it bool ret = false; switch (e) { case EV_21: mSuperStateA.exit(); mActionHandler.f2(); mState = STATE_B; mActionHandler.entryB(); ret = true; break; case EV_3: SuperStateA.exit(); mActionHandler.f3(); mState = STATE_B; mActionHandler.entryB(); ret = true; break; default: break; } return ret; } bool CFSM4::onB(Event e) { if (EV_4 == e) { mActionHandler.exitB(); mActionHandler.f4(); mState = STATE_A;; mSuperStateA.entry(e); return true; } return false; } Listing 14-15. Verbesserte Aufz¨ ahlungsmethode, Implementierung

Mit dieser Implementierung erreichen wir folgende Vorteile: • Die Unterzust¨ ande sind unabh¨ angig von Oberzust¨anden (Container- und Contained-Prinzip). • Oberzust¨ande sind Objekte (wie im Zustandsmuster). • Einfache Unterzust¨ ande sind Methoden. • Es werden keine virtuellen Methoden ben¨ otigt. • Volle Kontrolle der Entry- und Exit-Aktionen. • Efiziente Zustands¨ uberg¨ ange.

246

14 Zustandsautomaten

• Effiziente Event-Verteilung. • Die Zustandsklasse kann wieder verwendet werden. • Hinzuf¨ ugen eines neuen Zustands (kein Oberzustand) ben¨otigt nur die Erg¨anzung einer neuen konkreten Methode. • Hinzuf¨ ugen eines neuen Events erfordert nur die Erg¨anzung bei den beteiligten Klassen. • Kleiner Speicherbedarf (Footprint). • Historie kann einfach implementiert werden (wurde hier nicht gezeigt). Nachteile: • Wie im Zustandsmuster m¨ ussen die Objekte f¨ ur Oberzust¨ande zum Start des Programms konstruiert werden. Allerdings ist die Zahl dieser Zust¨ande normalerweise klein. • Aufz¨ahlungstyp f¨ ur Events erforderlich. • Die Verteilungsmethode jeder Klasse ben¨ otigt switch-case-Anweisungen, siehe auch die folgende Implementierung.

14.8 Implementierung nach Samek Um die Verteilungsmethode effizient und einheitlich zu gestalten, kann man die Idee von Samek [Sam] verwenden: • F¨ ur jeden Zustand wird eine Funktion (mit derselben Signatur) implementiert. • Jeder Zustand wird durch einen unterscheidbaren Wert dargestellt. Anstatt eines Wertes kann man die Funktion selbst abspeichern. Der aktuelle Zustand wird in einem Funktionszeiger gespeichert, so dass die Verteilung sehr schnell geht. • Der Zustandswechsel erfolgt durch Ver¨ anderung des Funktionszeigers. Die folgende Implementierung weicht von der von Samek dargestellten ab. Samek beschrieb in seinem Buch, wie man Statecharts in C und C++ [Sam] mit einem Funktionszeiger implementieren kann. Allerdings haben seine Vorschl¨age einige Nachteile: ¨ • Die genutzte Semantik unterscheidet sich von UML. Die Ubergangsaktionen werden vor der Exit-Aktion ausgef¨ uhrt. Dadurch kann Samek seine Implementierung vereinfachen. • Seine Implementierung ist nur f¨ ur kleine Statecharts nutzbar. Alle Zust¨ande und Unterzust¨ ande m¨ ussen in demselben Chart implementiert werden. Der aktuelle Zustand wird in einer globalen Variablen gespeichert. Jedes Event wird vom Blatt zur Baumwurzel verteilt. ¨ • Es werden statische Strukturen f¨ ur die Uberg¨ ange ben¨otigt. Statische ¨ Uberg¨ange werden beim ersten Mal konstruiert.

14.8 Implementierung nach Samek

247

• Die dynamischen Zustandswechsel (wegen der Historie) sind ineffizient. Der Pfad muss jedes Mal neu konstruiert werden. ¨ • Auch beim Ubergang auf sich selbst werden die Exit- und Entry-Aktionen ausgel¨ost. • C-lastige Implementierung. Wichtig ist aber, dass außer dem Destruktors keine virtuellen Methoden gebraucht werden. Die Kombination aus der Implementierung im letzten Abschnitt und Sameks Ideen kann zu einer effizienten Implementierung f¨ uhren (Klasse CFSM5). Die Klassenstruktur sieht wie folgt aus:

Abbildung 14.17. Klassendiagramm von CFSM5

• Jeder Zustand, der nicht ein Oberzustand ist, wird in einer Methode der Klasse implementiert. Ein Oberzustand wird in einer abgeleiteten Klasse von CSFM implementiert. • Jede FSM muss einen Anfangszustand haben (spezielle Methode zum Eintritt in den Zustand). Diese Methode ist hilfreich f¨ ur die Wiederherstellung des letzten Zustands (History). • Beim Eintritt in einen Oberzustand wird ein Event an diesen Zustand gesendet. Diese Vorgehensweise wird auch daf¨ ur verwendet, die Initialisierung oder die Wiederherstellung der Historie einheitlich zu realisieren. • Nur Oberzust¨ ande implementieren Reaktionen auf EV EXIT. Das Objekt weiß, ob es erforderlich ist, die Historie zu speichern. Außerdem wird normalerweise der aktuelle Zustand in einen Anfangszustand zur¨ uckgesetzt. Folgende Punkte m¨ ussen bei der Implementierung beachtet werden: • Einf¨ uhrung einer Basisklasse f¨ ur alle Oberzust¨ande. • Implementierung der Oberzust¨ ande als abgeleitete Klassen. • Implementierung entsprechender Methoden f¨ ur jeden Zustand.

248

14 Zustandsautomaten

• F¨ ur jeden Oberzustand, der als Unterzustand einer FSM fungiert, muss eine Methode und eine FSM implementiert werden. • Die Zustandsmaschine der h¨ ochsten Hierarchie-Ebene muss die dispatchMethode implementieren, um RTC sicherzustellen. Interessant an der Klasse CFSM ist die Typdefinition:

typedef bool (CFSM::*State)(Event e); Listing 14-16. Definition eines Funktionszeigers auf eine CFSM-Methode

Der Typ State ist ein Funktionszeiger auf eine Methode der Klasse CFSM. Jede abgeleitete Klasse von CFSM kann neue Methoden einf¨ uhren, die in einer Variablen vom Typ State abgespeichert werden kann, vorausgesetzt, sie hat dieselbe Methodensignatur. Ein wichtiger Punkt ist, dass der Defaultzustand als Methode der Klasse implementiert werden muss. Um die Arbeit mit Zust¨anden zu vereinfachen (statt immer wieder mit Funktionszeiger zu arbeiten) definieren wir ein Makro wie folgt:

#define STATE(x) ((static_cast(x))) Listing 14-17. Makro f¨ ur den Funktionszeiger

Mit diesem Makro k¨ onnen wir den Zust¨ anden geeignete Namen geben (siehe auch STATE C und STATE D im unten stehenden Beispiel – man vergleiche auch die Implementierung im letzten Abschnitt).

class CFSM { public: // define a state as a method pointer typedef bool (CFSM::*State)(Event e); // actionHandler object that performs actions // initial initial state. Note that a default initial CFSM(CFSMAction& actionHandler, State initial); // state must be modelled and implemented as a // method of the class void entry(Event e);

// called on entering the super state // param e event causes the entering

14.8 Implementierung nach Samek

249

void exit(void); // method called on exiting the super state bool dispatch(Event e); // central method for consuming events // received return true if event is consumed protected: // for holding the object supporting the actions CFSMAction& mActionHandler; // for holding the current state State mState; // to simulate the internal queue static Event sInternalQueue; static int sQueueLength; }; ... //Die Implementierung: ... Event CFSM::sInternalQueue; int CFSM::sQueueLength = 0; CFSM::CFSM(CFSMAction& actionHandler, State initial) : mActionHandler(actionHandler), mState(initial) { } void CFSM::entry(Event e) { dispatch(e); } void CFSM::exit(void) { dispatch(EV_EXIT); } bool CFSM::dispatch(Event e) { return (this->*mState)(e); } Listing 14-18. Basisklasse CFSM

Die dispatch-Methode aktiviert nur die aktuelle Methode. Oberzustand als abgeleitete Klasse F¨ ur den Zustand A erben wir von der Klasse CFSM und f¨ ugen einige Methoden hinzu:

class CFSMA: public CFSM

250

14 Zustandsautomaten

{ public: CFSMA(CFSMAction& actionHandler); private: bool onInitial(Event e); // methods for every states bool onC(Event e); bool onD(Event e); #define INITIAL_SUBSTATE STATE(&CFSMA::onInitial) #define STATE_C STATE(&CFSMA::onC) #define STATE_D STATE(&CFSMA::onD) }; Listing 14-19. SuperState als abgeleitete Klasse

In der Klasse CFSMA ist die Aufgabe des Makros STATE zu erkennen. Weiterhin nutzen wir drei Zust¨ ande als drei Methoden der Klasse. Eine Methode wird f¨ ur den Defaultzustand ben¨ otigt. Die Implementierungen f¨ ur die Methoden der Klasse CFSMA sind ¨ ahnlich denen im letzten Abschnitt. Als Beispiel vergleiche man die onC-Methode: bool CFSMA::onC(Event e) { if (EV_EXIT == e) { mActionHandler.exitC(); mState = INITIAL_SUBSTATE; mActionHandler.exitA(); return true; } else if (EV_2 == e) { // on queue the EV_21 event CFSM::sInternalQueue = EV_21; CFSM::sQueueLength = 1; return true; } return false; }

Auf oberster Ebene sehen wir die ganze FSM. Sie verh¨alt sich wie ein Oberzustand:

class CFSM5 : public CFSM { public: CFSM5(CFSMAction& actionHandler);

14.8 Implementierung nach Samek

251

bool dispatch(Event e); // method for consuming events received private: bool onInitial(Event e); // method of the different states bool onA(Event e); bool onB(Event e); CFSMA mSuperStateA; // FSM for super state A #define InitialState STATE(&CFSM5::onInitial) #define STATE_A STATE(&CFSM5::onA) #define STATE_B STATE(&CFSM5::onB) }; Listing 14-20. FSM CFSM5 mit Funktionen als Zust¨ anden

Die Implementierung der Methoden ist identisch mit der Implementierung von CFSM4 bis auf bool CFSM5::dispatch(Event e) { bool ret = CFSM::dispatch(e); // implement the RTC-mechanism while (sQueueLength != 0) { Event internalEvent = sInternalQueue; sQueueLength = 0; //(this->*mState)(internalEvent); CFSM::dispatch(internalEvent); } return ret; }

Vorteile: Im Vergleich zur letzten Implementierung erhalten wir weitere Vorteile: • Die Verteilung der Events ben¨ otigt keine switch-case-Anweisung. • Alle beteiligten Klassen f¨ ur die Oberzust¨ande brauchen die dispatchMethode nicht zu implementieren.

15 Externer Kommunikationskanal: MOST-Bus

Generell gibt es viele geeignete Bussysteme f¨ ur den Datenaustausch. Im Moment scheint der MOST-Bus (media oriented system transport) f¨ ur das Kraftfahrzeug am besten zu passen und zum europ¨ aischen Standard zu werden. Es gibt ihn als optischen und als elektrischen Standard. Was ihn auszeichnet, ist die Aufteilung in synchrone, asynchrone und Kontroll-Daten und eine breite Standardisierung verschiedener Komponenten. Als optischer Bus ist er frei von Masseschleifen, ein Thema, das bei den hohen Str¨omen im Auto einerseits und den empfindlichen Audiokomponenten andererseits sonst schnell zum Problem werden kann. Ein weiterer Grund, hier nur den MOST-Bus zu besprechen, ist, dass es zu anderen Systemen wie Firewire, USB, TCP/IP u ¨ber Ethernet und diverse serielle Systeme ausreichend Literatur gibt. MOST ist eine Netzwerk-Technologie, die auf die Verbindung von Infotainment-Systemen zugeschnitten ist. Die meisten der im KFZ vorkommenden physikalischen Infotainment-Komponenten sind in Katalogen bereits definiert. Der MOST-Bus ist f¨ ur die automobile Umgebung mit erh¨ohten Temperaturund Robustheitsanforderungen geeignet. Zun¨achst war er nicht f¨ ur sicherheitskritische Systeme vorgesehen, durch ¨ die Ubertragung von Parkwarner-Signalen, Daten an Tempomaten und Kurvenwarnungen verschwimmen die Grenzen aber. Wer schon einmal sein Radio im Auto auf voller Lautst¨ arke h¨ oren musste, weil es nicht mehr leise zu regeln war, kann sich vorstellen, dass selbst ein Radio sicherheitsrelevant sein kann. Der MOST-Bus ist ein optischer Bus, es wird rotes Licht versendet, der Lichtleiter ist aus Plastik. Die Datenrate des MOST-Systems liegt zurzeit bei brutto 22.5 Mbits/s. Der MOST-Bus arbeitet nach dem Master/Slave-Prinzip, es gibt eine zentrale Timing-Verwaltung durch den Timing Master. Der Systemtakt betr¨ agt normalerweise 44.1kHz, damit CD-Musikdaten ohne weitere Datenraten-Wandlung u ¨bertragen werden k¨onnen. In jedem MOST-Ger¨ at befindet sich eine elektrisch-optische Wandlereinheit, die FOT-unit (fiber optical transceiver) und ein Netzwerkchip.

254

15 Externer Kommunikationskanal: MOST-Bus

Der MOST-Bus wird meistens als Ring-Topologie ausgef¨ uhrt. Ein Beispiel ist unten dargestellt. Auch wenn mittlerweile sehr viele Funktionalit¨aten in der Headunit geb¨ undelt werden k¨ onnen, gibt es noch einige separate Einheiten im Netzwerk.

Abbildung 15.1. MOST-Ring mit Komponenten

Der MOST-Bus ist wie erw¨ ahnt in drei verschiedene Kan¨ale aufgeteilt. Die Grenze zwischen synchronem und asynchronem Kanal ist dabei vom so genannten Timing Master programmierbar. Die MOST-Definitionen entsprechen dem ISO/OSI-Layer-Standard. Sie umfassen von der untersten Schicht der physikalischen Hardware-Architektur u ¨ber die Kommunikationsprotokolle bis hin zum Applikationsframework alle Schichten.

15.1 Der synchrone Kanal Der synchrone Kanal erlaubt mit kleinen HW- und Prozessorstrukturen be¨ von Audio-Datenstr¨ omen u reits die Ubertragung ¨ber den synchronen Kanal. In jedem MOST-Frame sind feste Zeitschlitze f¨ ur diesen Kanal allokiert. Sie sind mit dem Master-Clock synchronisiert. In jedem Knoten werden in einer so genannten Routing-Engine die Quellen und Senken angelegt und verbunden. F¨ ur die Administration gibt es einen so genannten ConnectionMaster, der als Funktionsblock“ u ¨ber den Kontrollkanal ansprechbar ist. ” Alle synchronen Daten sind in jedem Knoten im Ring verf¨ ugbar. Ein synchroner Channel wird reserviert, indem allocate- und connect-Kommandos an Quelle, Master und Senke gesendet werden.

15.4 Ger¨ ate/Devices im Framework

255

15.2 Der asynchrone Kanal ¨ Der asynchrone Kanal erlaubt die Ubertragung von Datenpaketen a¨hnlich ¨ Ethernet mit hoher Datenrate aber ohne Anforderungen an Echtzeit. Uber den asynchronen Kanal k¨ onnen 48 Bytes Pakete u bertragen werden oder mit ¨ zus¨atzlicher Hardware 1014 Bytes pro segementiertem Paket. Die m¨ogliche Datenrate betr¨agt einige Mbyte/sec. Vorzugsweise ist der Kanal f¨ ur Burst-artige Datenpakete geeignet. Ein ¨ typischer Fall w¨ are die Ubertragung einer grafischen Navigationskarte oder eines Adressbuchs aus einer SIM-Card.

15.3 Der Kontrollkanal Mit dem Kontrollkanal werden Steuerkommandos und kleine Pakete u ¨bertragen. In einem Hilfsservice werden weiterhin administrative Daten, Fernbedienung anderer Knoten und Routing-Informationen u ¨bertragen. Im Kontrollkanal werden Daten gezielt zu bestimmten Knoten u ¨bertragen, die Daten werden CRC-gepr¨ uft. Weiterhin gibt es Acknowledge-Mechanismen und Retries. Die Bandbreite f¨ ur den Kontrollkanal ist fest eingestellt und liegt bei etwa 10 kBit/sec. Das entspricht etwa 2600 m¨oglichen Nachrichten pro Sekunde. Allerdings kann ein Empf¨ anger bei der heutigen Konfiguration nur eine Datenrate von ca. 830 Nachrichten verarbeiten, so dass, wenn mehrere Nachrichten verschiedener Sender hintereinander alle an denselben Empf¨anger gerichtet sind, Nachrichten verloren gehen k¨ onnen. Uns interessiert vor allem, wie Daten u ¨bertragen werden, und das API, das im so genannten Function-Catalog [MOST] niedergelegt ist.

15.4 Ger¨ ate/Devices im Framework Physikalische Ger¨ ate sind Ger¨ ate wie Tuner, Laufwerk oder Telefon. Sie sind normalerweise u ¨ber eine Vernetzung an der Headunit angeschlossen, durch die heutige Hochintegration gibt es aber auch Devices, die in demselben Geh¨ause wie die eigentliche Headunit verbaut sind. Eine MOST-Einheit im Ring enth¨ alt oft mehr als ein Device. So sind oft Tuner, CD und Amplifier kombiniert. Oder eine Navigations-Hardware ist mit in die Headunit integriert. Die physikalischen Ger¨ ate lassen sich wie folgt unterteilen: • Interne Non-MOST-devices, z.B. DVD-Mediaplayer, HDD. Dies sind Devices, die nicht u ¨ber das MOST-Protokoll angesprochen werden, sondern u ur lassen wir POSIX-APIs zu, normaler¨ber andere, direkte APIs. Daf¨ weise File-Zugriffe mit Descriptor, open, read, write und close;

256

15 Externer Kommunikationskanal: MOST-Bus

• interne MOST-Devices, z.B. im Projekt die Navigation oder auch ein Laufwerk, wenn seine Atapi-Befehle und Stati in interne MOST-Protokolle umgesetzt werden, die identisch mit denen externer MOST-Devices sind; • externe MOST-Devices, beispielsweise Navi-Box oder Tuner, die im Netzwerk verteilt sind. Um in allen F¨ allen immer die gleiche Systematik zu verfolgen, werden die Devices einzeln u ¨ber MOST-Protokolle angesprochen, unabh¨angig davon, ob intern oder extern im Ring angeordnet. Sie werden dabei als Funktionsblock angesprochen; das API f¨ ur ein Ger¨ at/Device ist also der Function-Block (FB). ¨ Plakativ kann man davon sprechen, dass die Ubertragung optical, electrical oder softical stattfindet, die Kommunikation u ¨ber die MOST-APIs, die die Ger¨ateeigenschaften abstrahieren, bleibt immer gleich. Auch Fremdkomponenten k¨ onnen oft durch MOST-FBs gekapselt werden. Jeder FBlock enth¨ alt Einzelkommandos, z.B. f¨ ur CD: Play, Stop, . . . oder Eigenschaften (Properties) wie: Temp, Speed, Track,. . . Jede Einheit enth¨ alt den FB NetBlock, in dem die Parameter f¨ ur die Kommunikation abgelegt sind. Die Netservices verbinden den Chip mit den FBlocks und stellen das Fehlerhandling sicher.

Abbildung 15.2. Mehrere Function-Blocks in einem Ger¨ at

Alle intelligenten“ MOST-Devices sind von den Klassen MOST-Device ” und NetBlock abgeleitet und enthalten deren gesamte Funktionalit¨atwie z.B. die Eigenschaften NodeAddr, LogicalAddr und den NetBlock mit FBlockIDs und DeviceInf. Sie m¨ ussen alle Methoden und Eigenschaften von NetBlock

15.4 Ger¨ ate/Devices im Framework

257

und MOST-Device unterst¨ utzen. Zus¨ atzlich kommen meist noch eigene Methoden und Eigenschaften hinzu. F¨ ur einige Modelle gibt es generische Versionen, die diese Vorgehensweise besonders unterst¨ utzen, z.B. einen generischen Player. 15.4.1 Logische Ger¨ ate, Modelle Interne oder externe physikalische Ger¨ ate werden in der Headunit durch entsprechende Modelle bedient. Diese Modelle nennt man auch Logical-Devices (logische Ger¨ate) oder kurz LogDev. Beispielsweise muss in der Headunit ein im Netzwerk vorhandenes Ger¨ at zur Ansteuerung dargestellt werden. Es gibt grunds¨ atzlich verschiedene Strategien zur Ansteuerung von verteilten Systemen: • RPC (Remote Procedure Call): Funktioniert bei MOST nicht, weil der Abbruch von zu lang andauernden Methoden erw¨ unscht ist. • CORBA/COM/DCOM: Zu fett“ f¨ ur Embedded Systeme, auch zu fett f¨ ur viele PC-Applikationen. ” • Proxy-Pattern: Jede entfernte Komponente bietet einen entsprechenden Stellvertreter (Proxy) an. Der Client verwendet die Methoden des Proxies, ohne sich um die Details der Kommunikation zu k¨ ummern. Zum Empfangen von Daten/Nachrichten wird das Zuh¨ orer-Muster angewandt. Die letzte Variante ist die von MOST pr¨ aferierte. Die Headunit als Client kommuniziert also mit einem logischen Device (Proxy) in der Headunit so, als w¨are es das physikalische Ger¨ at (Server). Dieses Modell wiederum organisiert selbst die Kommunikation zum physikalischen Device. Versenden der Client-Nachrichten auf der Client-Seite unschte Spur einer geh¨orten CD. Dazu ruft die ¨andert die HMI z.B. die gew¨ HMI eine Methode des Proxies auf, dies kann als Call in einem MultithreadSystem oder z.B. als Event in einem Multitask-System realisiert werden. Der Proxy wandelt die Anfrage in eine MOST-Nachricht und sendet sie an das MOST-Subsystem (MOST-Treiber). Auf der Server-Seite verteilt das MOST-System die Nachricht an das richtige Device (mehrere Ger¨ate k¨onnen im selben Knoten liegen). Das Ger¨at dekodiert die MOSTNachricht und startet die entsprechende Funktion. Empfangen der Server-Nachrichten auf der Server-Seite setzt das Ger¨ at neue Daten (Properties), z.B. weil die aktuelle Spur zu Ende ist. Anschließend wird u uft, ob sich jemand f¨ ur diese Daten interes¨berpr¨

258

15 Externer Kommunikationskanal: MOST-Bus

siert. Falls ja, wird eine MOST-Nachricht generiert und an das MOST-System (NetServices) gesendet. Auf der Client-Seite werden die MOST-Nachrichten dekodiert und damit die Ist-Daten“ des ” Proxy aktualisiert. Es wird u uft, ob sich jemand f¨ ur diese Daten interessiert. Ist dies ¨berpr¨ der Fall, so wird ein Ereignis generiert und an den Empf¨anger innerhalb der Headunit gesendet, z.B. an die HMI. Der Empf¨anger kann dann die f¨ ur ihn interessanten Daten abholen. Proxies sind von MOST vorgeschlagen und k¨onnen automatisch generiert werden. Proxies k¨ onnen: • MOST Messages generieren und nach außen“ senden, ” • eingehende MOST Messages auswerten, • interne Events an Listener erzeugen, die sich notifiziert hatten und die Daten bereithalten, • Ist-Daten und Soll-Daten verwalten, • Zuh¨orer verwalten, die sich f¨ ur die Daten¨ anderung interessieren (Registrierung und Abmeldung), • MOST-Methoden generieren und auswerten, • Besonderheiten der Ger¨ ate kapseln und Funktionalit¨aten erweitern (z.B. kann das Ger¨ at nur einen Befehl bearbeiten), • Proxies haben Datencontainer f¨ ur Ist-Daten (in) und Soll-Daten (out). 15.4.2 Methoden F¨ ur jeden Funktionsblock gibt es einen Katalog von Funktionen [MOST], dabei sind die Grundfunktionen zwingend, einige andere optional. Die Funktionen steuern direkt mit Kommandos wie Scan, Mute und Connect oder sie ver¨andern Eigenschaften (Properties) wie Volume, DeckStatus oder Frequency u ¨ber set- und get-Methoden. Funktionen (methods) werden gestartet und liefern nach einiger Zeit asynchron Ergebnisse: start, start result,. . . , error, processing, . . . Ein AM/FM-Tuner hat z.B. folgende Methoden: StorePreset, RecallPreset, StoreAutoPreset, RecallAutoPreset, Allocate, Deallocate. Ein Audio-Amplifier: Connect, DisConnect uvm. 15.4.3 Properties Ver¨andern sich Eigenschaften im Device, so melden sie von selbst und asynchron die Ver¨anderung an die FBl¨ ocke, die sich f¨ ur die Benachrichtigung angemeldet haben. Man spricht von Registrierung und Notifizierung. Ein Beispiel

15.4 Ger¨ ate/Devices im Framework

259

sind RDS-Meldungen (Verkehrsmeldungen). Jedes Device, das diese Nachrichten braucht (Navigation, Amplifier, Bordcomputer), meldet sich bei dem entsprechenden FB an, um zuk¨ unftig diese Meldungen zu bekommen. Notifikationen sind eine gute Alternative zu zyklischem Pollen. Der AM/FM-Tuner hat z.B. folgende Properties: FktID, Notification, TunerStatus, Frequency, Preset, AutoPreset, SourceInfo. Der Audio-Amplifier hat folgende Properties: FktID, Notification, Volume, Bass, Treble, Balance, Fader, Mute, SinkInfo. Der NetBlock eines Ger¨ ats, in dem Tuner und Amplifier kombiniert sind, enth¨alt folgende Properties: FBlockIDs, DeviceInfo, Power, NodeAdress, NodePositionAdress, GroupAdress, SourceHandles. 15.4.4 MOST-Adressierung Auf Applikations-Level werden Funktionen wie folgt adressiert: • • • •

• •

DeviceID phys. Device, z.B. CDC; FBlockID, z.B. Audiodiscplayer; Im NetBlock in der Property FBlockID eines Devices stehen alle FBlocks mit den InstIDs; InstID bei gleichen FBlocks: Unterscheidung der Instanzen, z.B. mehrere CD-Laufwerke, Lautsprecher,. . . ; FktID aufgerufene Funktion oder Property. Es gibt: coordination, mandatory, extension, unique, Proprietary-Sys-Specific, Proprietary-SupplierSpecific z.B.: 000: gibt alle FktIDs des FBlocks zur¨ uck, 001: notification list; OpType siehe Tabelle; Length(Data).

Ein MOST-Event ist demnach logisch wie folgt aufgebaut:

DevID.FuncBlockID.InstID.FuncID.OperType.Length(Data).Data Listing 15-1. MOST-Event, Struktur

260

15 Externer Kommunikationskanal: MOST-Bus

MOST-Message Beispiel: DeviceID FunctionBlockID InstanceID FunctionID OpType Data HMI -> CDP AudioDiskPlayer 1 Deckstatus Get 100 -> 101 0x31 1 200 1 0 Abbildung 15.3. MOST-Funktionsaufruf, Beispiel

Ein Beispiel eines NetBlock-Aufrufs w¨ are: NetBlock.0.FBlockIDs.Set(FBlockID,OldInstID,NewInstID) Listing 15-2. Beispiel eines NetBlock-Aufrufs

DeviceID (16 bit) Funktionale Adresse FBlockID.InstID den FBlock enthaltendes Device (log. Knotenadr.=DeviceID) AudioAmp.1 0x0105 AudioAmp.2 0x0103 AM/FM Tuner.0 0x0107 AudiDiskPlayer.1 0x0107 Abbildung 15.4. Beispiel einer DeviceID-Tabelle

Die DeviceID ist die Knotenadresse im Ring und wird aus den im Folgenden erkl¨arten FBlockIDs und InstIDs gebildet und in einer zentralen Registrierung (Registry) abgelegt. Die Ger¨ ate k¨ onnen sich lokale Kopien davon ziehen und in den NetServices halten. FunctionBlockID (8 bit) Abbildung 15.5 zeigt die Vorbelegung von FBlockIDs f¨ ur Ger¨ate. Es gibt reservierte FBlockIDs f¨ ur besondere Zwecke: System Specific FBlockIDs 0xC0 ... 0xC7 und 0xC9 ... 0xEF Supplier Specific FBlockIDs 0xF0 ... 0xFE //hier k¨onnen eigene FunctionBlocks definiert werden. InstanceID (8 bit) Die InstID gibt an, welches Ger¨ at gemeint ist, wenn es mehr als eins davon im Ring gibt. Beispielsweise kann es mehrere Laufwerke gleichen Fblocks geben. Die Adressen 0x00 und 0xFF haben hierbei eine besondere Bedeutung: 0x00 = Don’t care - Nachricht wird an irgendein“ Device in der Gruppe ” weitergeleitet.

15.4 Ger¨ ate/Devices im Framework Art FBlockID Bezeichnung Verwaltung 0x0x NetServices 0x01 NetBlock 0x02 NetWorkMaster 0x03 ConnectionMaster 0x04 PowerMaster 0x05 Vehicle 0x06 Diagnose Art FBlockID Bezeichnung Bedienung 0x1x 0x10 MMI 0x11 Sprachbedienung Art FBlockID Bezeichnung Audio 0x2x 0x20 AudioMaster 0x21 AudioDSP 0x22 AudioAmplifier Art FBlockID Bezeichnung Laufwerke 0x3x 0x30 AudioTapeRecorder 0x31 AudioDiskPlayer 0x32 ROMDiskPlayer 0x33 MultiMediaPlayer 0x34 VersatileDiskPlayer

261

Erkl¨ arung kennzeichnet Telegramme

Erkl¨ arung

Erkl¨ arung

Erkl¨ arung

Abbildung 15.5. Beispiel einiger FblockID-Tabellen

0XFF = Broadcast FunctionID (12 bit) FunctionIDs sind wie folgt definiert: Coordination (0x000..0x1FF) // Administrative Funktionen Mandatory (0x200..0x3FF) // Zwingende Fkt-nen f¨ ur Applikation Extentions (0x400..0x9FF) // optionale Erweiterungen Unique (0xA00..0xBFF) // Funktionen, die anderen Gruppen“ ” // nicht zugeordnet werden k¨onnen Proprietary/ // Funktionen die z.B. vom System Specific (0xC00..0xEFF) // Fahrzeughersteller definiert wurden. Proprietary/ // Funktionen, die von Supplier Specific (0xF00..0xFFE) // OEM vorgegeben wurden Die Verwendung der FktIDs l¨ asst sich in der Tabelle 15.6 f¨ ur das Beispiel eines Multimedia-Changers zeigen. Die Property SourceInfo enth¨ alt n¨ ahere Informationen u ¨ber die Art der synchronen Quelldaten. Durch die Funktion Allocate wird die Quelle veranlasst, synchrone Kan¨ale zu belegen.

262

15 Externer Kommunikationskanal: MOST-Bus

FktID 0x000 0x001 0x002 0x200

Bedeutung FktIDs Notification NotificationCheck DeckStatus

0x201 0x202 0x203 0x204 0x100 0x101 0x102

Track Time DiskInfo DiskMode SourceInfo Allocate DeAllocate

Kommentar Abfrage der im FBlock enthaltenen Funktionen verwaltet die Notification Matrix des Funktionsblocks ¨ Uberpr¨ uft Distribution List Deck Status abgefragen und setzten, z.B. 0x00 play, 0x01 stop, 0x02 pause, 0x03 unload, 0x04 load, 0x05 forward, 0x06 rewind Spurnummer lesen, setzen Ausgabe der gespielten Zeit Ausgabe verschiedener Informationen u ¨ber die Disk Umschaltung zwischen ROM und Audio Mode Art der synchronen Quell-Daten und Verwendung allokiert synchrone Kan¨ ale zur Audio-Ausgabe deallokiert synchrone Kan¨ ale

Abbildung 15.6. Verwendung der FktIDs am Beispiel eines Multimedia-Changers

Optypes (4 bit) Die Optypes geben die Art der Operation an. OPType Kommandos 0 1 2 3 4 5 6 7 OPType Reports A B C D E F

f¨ ur Properties f¨ ur Methoden set get setget increment decrement getInterface setAck getAck f¨ ur Properties

f¨ ur Methoden

status statusAck interface error

processing result resultAck interface error

start StartResult

getInterface startAck

Abbildung 15.7. OPTypes f¨ ur Methoden und Eigenschaften

15.4 Ger¨ ate/Devices im Framework

263

Length (16 bit) Gibt die L¨ ange des Datenblocks an. Z. B. Length = 0x0000 Datenfeld mit der L¨ ange 0 Byte Length = 0x0001 Datenfeld mit der L¨ ange 1 Byte Length = 0xFFFF Datenfeld mit der L¨ ange 65535 Bytes Data Die Daten, die u ¨bertragen werden sollen. Im Prinzip k¨onnen Daten bis 65535 Bytes u bertragen werden. Pro MOST-Event ist die Grenze jedoch bei ¨ 17 Bytes, so dass die h¨ oheren MOST-Protokollschichten die Nachricht segmentieren und desegmentieren m¨ ussen. Es ist also sinnvoll, auf Applikationsebene auf Nachrichten kleiner oder gleich 17 Bytes zu achten. Unten sind die m¨ oglichen Datentypen aufgelistet. Boolean Enum unsigned Byte signed Byte unsigned Word signed Word unsigned Long signed Long String

Stream

1 Bit des Bytes genutzt 1 Byte 1 Byte 1 Byte 2 Bytes 2 Bytes 4 Bytes 4 Bytes (identifier, content, terminator) variable length, MSB first, High Byte first, String starts with identifier 0x00 = unicode 16 bit, 0x01 = ISO 8 bit, 0x02 = UTF8, others = ASCII Terminator NULL character any data

Abbildung 15.8. Datentypen in MOST, aus [MOST]

Registry In gr¨oßeren Netzwerken wird eine zentrale Registry im RAM oder FLASH des Network Master w¨ ahrend der Initialisierung erzeugt. Die Registry zeigt f¨ ur jeden Knoten die enthaltenen Funktionsbl¨ocke und einige Device-Informationen, zus¨ atzlich Seriennummer, Hardware- und Softwarestand. Der Aufbau der zentralen Registry erfolgt zweistufig. Im ersten Schritt fragt der NetworkMaster (NM) alle Knoten nach ihrer DeviceInfo. In dieser Funktion sind Informationen abgelegt, die das Device eindeutig kennzeichnen, wie z.B. Seriennummer, HW-Stand und SW-Stand.

264

15 Externer Kommunikationskanal: MOST-Bus

NetworkMaster -> Device: NetBlock.0.DeviceInfo.Get Device -> NetworkMaster: NetBlock.0.DeviceInfo.Status (Seriennummer, HW-Stand, SW-Stand) Listing 15-3. Aufbau der zentralen Registry

Ist das Abfrageergebnis mit dem bisherigen Eintrag identisch, so u ¨bernimmt er die Zeile inklusive FBlockID und InstID.

Abbildung 15.9. Zentrale Registry

Notifikation Notifikation ist ein guter Ersatz f¨ ur Polling, wenn ein Device u ¨ber eine Eigenschaft eines anderen Ger¨ ats Kenntnis haben muss. Wir hatten dieses Prinzip unter dem Titel Hollywood-Prinzip bereits vorgestellt. Ein Beispiel einer Notifikation ist im Folgenden gezeigt:

15.4 Ger¨ ate/Devices im Framework

265

Controller->Slave: FblockID.InstID.Notification.Set (Control,DeviceID, FktIDq, FktID2...)

Control 0x0 0x1 0x2 0x3 rest

Name SetAll SetFunction ClearAll ClearFunction

Kommentar Entry for all functions Entry for following functions (max 4) DeviceID deleted for all functions DeviceID deleted for specified function (max 4) reserved

Abbildung 15.10. Beispiel einer Notifikation

15.4.5 Adressierungsbeispiele Einige Beispiele f¨ ur die Adressierung gem¨ aß MOST sind im folgenden gezeigt:

Anwahl einer neuen Spur: MMI-> CDC: CD.0.Track.Set(11) R¨ uckmeldung CDC->MMI: CD.0.Track.Status(11) Klimaanlage, neue Temperatur setzen: MMI->Aircon: Heating.Temp.Set(30) Klimaanlage, Status abfragen: MMI->Aircon: Heating.Temp.Get Antwort: Aircon->MMI:

Heating.Temp.Status(30)

Listing 15-4. Beispiele f¨ ur die Adressierung gem¨ aß MOST

266

15 Externer Kommunikationskanal: MOST-Bus

Nehmen wir an, dass von der Headunit (MMI) ein Steuerkommando an den CD-Wechsler geschickt werden soll. In der Headunit-Komponente, die den Changer bedient, wird das Kommando erzeugt. Alles Weitere siehe Kommentarzeilen.

CD.0.Track.Set(10) FFFF.CD.0.Track.Set(10)

// // // CDC.CD.0.Track.Set(10) // MMI.CDC.CD.0.Track.Set(10) // // MMI.CD.0.Track.Set(10) // // // MMI.CD.0.Track.Status(10) // // CDC.MMI.CD.0.Track.Status(10)// CDC.CD.0.Track.Status(10) // //

erstellt und an die eigenen Netservices gegeben. Diese machen daraus: Die Nachricht wird gesendet als im Empf¨ anger muss die Empfangsadresse nicht verfolgt werden Der Changer wird das Kommando verarbeiten und mit seinem Status antworten. Antwort des Changers: Dies geht an die eigenen Netservices und wird gesendet als: der Controller der MMI bekommt und kann dies z.B. an die Anzeige weitergeben.

Listing 15-5. MOST-Sequenz

15.4.6 MOST-Events, prinzipielle Dekodierung des Headers Im Kapitel Adressierungsbeispiele hatten wir die allgemeine Definition einer MOST-Message gesehen. Es gibt einige prinzipielle M¨ oglichkeiten, diese im Empf¨anger zu dekodieren oder im Sender zu encodieren. Die einfachste M¨ oglichkeit ist die Zerlegung mit einer Union, die wir in eine Klasse mit entsprechenden Methoden einbetten. In ein Array mRawByte[64] werden die Daten ohne Interpretation eingeschrieben. Dann betrachten wir die Header-Informationen. .... void void void void UInt16 UInt8 UInt8 UInt8*

setDeviceID (UInt16 deviceID); setFBlockID (UInt8 FBlockID); setInstanceID (UInt8 instanceID); setData(UInt8 data[], UInt8 length); getDeviceID(void) const; getFBlockID(void) const; getLength(void) const getData(void) ;

union MostMessage

15.4 Ger¨ ate/Devices im Framework

267

{ UInt8 mRawByte[64]; //whole raw Message, 64 Bytes so // we can use it for // internal events struct { UInt16 mDeviceID; UInt8 mFBlockID; UInt8 mInstance; UInt16 mFkID:12; UInt16 mOPType:4; UInt8 mLength; // to this point 7 Bytes UInt8 mData[1]; // actually more depends on message }; }; private: MostMessage mMessage; }; inline CMessage::CMessage() { memset(this, 0, sizeof(CMessage)); } inline void CMessage:: setDeviceID (UInt16 deviceID) { mMessage.mDeviceID = deviceID; } inline void CMessage:: setData (UInt8 data[], UInt8 length) { mMessage.mLength = length; for (Int32 i=0; i < length; i++) { mMessage.mData[i] = data[i]; } } ... inline UInt8 CMessage::getDeviceID (void) const { return mMessage.mDeviceID; } ...

Eine große Gefahr dabei ist, dass man von der Byteorder abh¨angt. MOST nutzt Big-Endian, wenn das eigene System mit HW und Compiler von LittleEndian ausgeht, gibt es ernsthafte Probleme. Eine zweite Gefahr sind unterschiedliche Alignment-Strategien verschiedener Compiler. Mit der oben stehenden Union nehmen wir implizit an, dass der Compiler die einzelnen Va-

268

15 Externer Kommunikationskanal: MOST-Bus

riablen in der Struktur direkt hintereinander in den Speicher legt und nicht durch 0-zapping an Wortgrenzen ausrichtet. Eine andere M¨ oglichkeit, die gerne verwendet wird, ist die Adressierung eines Arrays u ber Enum-Konstanten. Diese Dekodierung wird allerdings un¨ handlich wegen der verschiedenen Wortbreiten der Header-Informationen. Die high- und low-Bytes m¨ ussen der gew¨ unschten Byte-Order entsprechend zusammengef¨ ugt werden. Hinzu kommt, dass man auf Bitfelder (OpType und FkID) zugreifen muss. Int8 MostMessage[64]; // in diesem Buffer steht die Message enum {DeviceID_h, DeviceID_l, FblockID, Instance, FkID_h, FkID_l, OPType_h, OPType_l, Length_h, Length_l}; ..... inline Int32 CMessage::getInstance (void) const // ein Beispiel { return MostMessage[Instance]; } ...

Auch die Dekodierung zu Fuß“ per Byte-Pointer ist eine einfache Metho” de. Bessere Konzepte werden wir im Teil II in unserem Framework kennen lernen. Int8 MostMessage[64]; .... inline Int32 CMessage::getInstance (void) const { Int * ptr = MostMessage; return (Int32) ptr[3]; } ..

Auch hier m¨ ussen Worte entsprechend mit Makros zusammengesetzt werden. 15.4.7 MOST-Events, prinzipielle Dekodierung der Daten Die Dekodierung der Daten wird etwas komplexer. Das Problem ist, dass verschiedene Nachrichten ganz verschiedene Strukturen haben. Nehmen wir als Beispiel den Audioverst¨ arker. Er hat 44 FunctionIDs. Volume (0x400) Treble (0x400) Mute (0x113) Notification (0x001) .....

Set erwartet einen Unsigned Byte Wert zwischen 1..255, Step 1 Set erwartet einen Signed Byte Wert, Step 1 SetGet erwartet SinkNr als Unsigned Byte, Status als Boolean Status erwartet FktID als Unsigned Word, DeviceIDList als Stream

15.4 Ger¨ ate/Devices im Framework

269

Wenn wir demnach im System einige 10 FBs haben und jeder FunctionBlock wiederum einige 10 FunctionIDs, dann k¨ onnen wir nicht f¨ ur jede Kombination eine eigene Funktion, die die Abfolge der Teilnachrichten kennt, implementieren. Wir haben aber gesehen, dass MOST 10 verschiedene Datentypen kennt. Es reicht also aus, 10 Funktionen zu schreiben, die in geeigneter Reihenfolge entsprechend der FblockID und der FunctionID aufgerufen werden. Diese Reihenfolge wird am besten tabelliert und nicht im Code versteckt. Nimmt man die Dekodierung komponentenweise vor, so dass z.B. der Tuner auch nur Tuner-Messages bearbeiten muss, so kann man Teiltabellen in jeder Komponente erzeugen, in denen abh¨ angig von der FunctionID die aufzurufenden Funktionen stehen. Diesen Funktionen muss man noch mitgeben, wo im Buffer die zu bearbeitenden Daten stehen, einen Zeiger auf eine Spezifikationstabelle, in der die zu pr¨ ufenden Limits der Daten stehen und wohin die zerlegten Daten geschrieben werden sollen. F¨ ur den tabellenabh¨angigen Aufruf der Funktionen bieten sich Funktionszeiger an. Wie man mit solchen Ans¨ atzen einen statischen Parser-Baum aufgebauen kann, der alle spezifizierten Kombinationen von MOST-Datentypen einer Nachricht dekodieren kann, wird im Teil II in einem eigenen Kapitel gezeigt. 15.4.8 MOST-Konstanten Zur Enkodierung und Dekodierung von MOST-Nachrichten ist es sinnvoll, die verschiedenen FbIDs und OpCodes lesbar zu definieren. Hierf¨ ur fassen wir die verschiedenen Konstanten in einem Namensraum MOST zusammen.

namespace MOST { enum MOSTUnit { NONE, MILLISEC, YEAR, MONTH, HOUR, MINUTE, SECOND }; // elementar types used in MOST communication enum ElementarTypeEnum { BOOLEAN, ENUM, INT8, INT16, INT32, UINT8, UINT16, UINT32, STRING, STREAM }; enum StringType { UNICODE, ASCII, UTF8 }; enum ModelTypeEnum {

// Properties

270

15 Externer Kommunikationskanal: MOST-Bus SINGLE_PROP, RECORD_PROP, ARRAY_PROP, ARRAY_RECORD_PROP

}; // max properties in MOST msg enum {MAX_PROPERTIES_IN_A_FUNC = 5}; enum OpTypeEnum // Different MOST-Op types defined in spec { OP_SET = 0x00, OP_START = 0x00, OP_GET = 0x01, OP_ABORT = 0x01, OP_SETGET = 0x02, OP_STARTRES = 0x02, OP_INC = 0x03, OP_DEC = 0x04, OP_GETIF = 0x05, OP_STARTRESACK = 0x06, OP_ABORTACK = 0x07, OP_STARTACK = 0x08, OP_ERRACK = 0x09, OP_PROCACK = 0x0A, OP_PROC = 0x0B, OP_STAT = 0x0C, OP_RES = 0x0C, OP_RESACK = 0x0D, OP_IF = 0x0E, OP_ERR = 0x0F, //start of MMI internal OpTypes OP_INTERN_DATA = 0x10, //used with LongArray OP_INTERN_ERROR= 0x11, //used with LongArray OP_UNDEFINED = 0xFF }; enum OpInTypeMask { OP_STATUS_MASK = 0x1000, OP_ERROR_MASK = 0x8000, }; enum OpOutTypeMask { OP_SET_MASK = 0x0001, OP_GET_MASK = 0x0002, OP_SETGET_MASK = 0x0004, OP_INCREMENT_MASK = 0x0008, OP_DECREMENT_MASk = 0x0010, OP_GETINTERFACE_MASK = 0x0020 }; enum ERROR_ENUM { PROC_OK = 0x00,

15.4 Ger¨ ate/Devices im Framework ERR_FBLKID_NOT_AVAILABLE ERR_INSTID_NOT_AVAILABLE ERR_FUNCID_NOT_AVAILABLE ERR_OPTYPE_NOT_AVAILABLE ERR_INVALID_LENGTH ERR_PARAMETER_WRONG ERR_PARAMETER_NOT_AVAILABLE ERR_PARAMETER_MISSING ERR_TOO_MANY_PARAMETERS ...

= = = = = = = = =

271

0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09,

}; enum FBLOCK_ID_ENUM // Function Block ID’s {//0x00 to 0xBF reserved for FBlockID’s defined by MOST Consortium NET_BLOCK = 0x01, NETWORK_MASTER = 0x02, CONNECTION_MASTER = 0x03, POWER_MASTER = 0x04, VEHICLE = 0x05, ... AM_FM_TUNER = 0x40, TMC_TUNER = 0x41, TV_TUNER = 0x42, TELEPHONE = 0x50, PHONE_BOOK = 0x51, NAVIGATION_SYSTEM = 0x52, TMC_DECODER = 0x53, BLUETOOTH = 0x54, ... ALL = 0xFF }; }; Listing 15-6. Die Sammlung vieler Most-Konstanten, MOSTConst.h

15.4.9 MOST-Probleme Es sind ein paar Probleme der MOST-Definitionen zu Tage getreten. 1. Die Protokolle definieren nur Befehle und Properties, allerdings nicht den Kontext, in dem sie zul¨ assig sind. Das Beispiel Telefon hat sehr deutlich gezeigt, dass Befehle an sich nur ein kleiner Teil der Komplexit¨at sind, auch die Sequenz-Diagramme m¨ ussen vereinbart oder besser noch standardisiert werden. Der zul¨ assige Befehlssatz eines Telefons h¨angt z.B. stark von einer g¨ ultigen SIM-Card ab. 2. Die MOST-Spezifikation h¨ alt den Unterschied zwischen Methoden und Aktionen, Eigenschaften und Properties und Optionen nicht konsistent ein. Beispielsweise werden die Aktionen Stop“, Play“, Pause“, Scan“ ” ” ” ”

272

15 Externer Kommunikationskanal: MOST-Bus

etc. eines CD-Spielers u ¨ber MOST-Properties gesteuert. Aufrufe, die Aktionen nach sich ziehen und aus Benutzersicht Zeit brauchen, sollten eigentlich als Methoden aufgerufen werden. So wird die Methode Suchlauf“ ” eines Tuners richtigerweise u ¨ber eine MOST-Methode getriggert. Das Setzen von Eigenschaften ben¨ otigt demgegen¨ uber keine Zeit. Die Abfrage und die Festlegung von Arbeitsdaten oder Optionen sollten demnach als Eigenschaften/Properties spezifiziert werden. Dauerhafte Eigenschaften/Daten, die auch u ¨ber Aus/Ein bestehen bleiben, nennen wir Optionen. Mit ihnen muss anders umgegangen werden als mit Eigenschaften oder Methoden. Eine Aktion geht irgendwann zu Ende. Eine Option bleibt solange bestehen, bis der Benutzer sie ¨ andert. 3. Meldet ein physikalisches Ger¨ at seinen Status auf dem Bus, so kann der Nachricht nicht angesehen werden, ob sie angefordert wurde oder aufgrund einer Notifikation gesendet wurde. Dies erh¨oht die Komplexit¨at im Controller eines logischen Ger¨ ats erheblich. Selbst mit genauer Buchf¨ uhrung ist nicht immer entscheidbar, ob die empfangene Nachricht eine Antwort auf eine Anfrage ist und damit die offene Aktion abgeschlossen werden kann oder ob es eine unmotivierte“ Meldung aufgrund einer Notifikation ” war und die angefragte Antwort noch zu erwarten ist. 4. Innerhalb der physikalischen Spezifikation ist es m¨oglich, dass mehrere Ger¨ate gleichzeitig Nachrichten u ¨ber den Kontrollkanal z.B. so an die Headunit schicken, dass die Headunit nicht alle Daten verarbeiten kann. Im schlechtesten (unrealistischen) Fall k¨ onnte es passieren, dass nur jede dritte Nachricht bei der Headunit ankommt. Dies erwarten SW-Ingenieure eigentlich von einem robusten optischen Bus nicht. Die Acknowledgeund Retry-Mechanismen, die nachtr¨ aglich bis in die h¨oheren Applikationsschichten implementiert wurden, erh¨ ohen die Komplexit¨at, versch¨arfen ¨ die Uberlast und waren in der Vergangenheit nicht immer fehlerfrei. 5. Es gab in der letzten Ger¨ ate-Generation einige unerwartete Probleme mit so genannten Unlocks“, das sind Situationen, bei denen die physikalische ” Bussynchronisierung verloren geht. Ursachen daf¨ ur k¨onnen in der Ger¨ateSoftware, in HW-Problemen oder auch im Hochstart-Verhalten der Ger¨ate liegen. Man unterscheidet zwischen kurzen Noncritical-Unlocks und l¨angeren Critical-Unlocks. Die erforderlichen Reaktionen der angeschlossenen Ger¨ate waren nicht einheitlich implementiert und auch die Interpretation, wann ein Unlock kritisch war, war nicht einheitlich. Dadurch, dass diese Probleme nicht erwartet wurden, fanden sich in den SW-Architekturen daf¨ ur auch keine Standard-Vorgehensweisen, so dass z.B. ein typischer Applikationsfehler das Re-Init mit erneutem Allokieren von Speicher war, obwohl die alten Objekte noch existierten. Oft wurde die Fehlerbehandlung bis in die Applikationsschichten der Komponenten gezogen, obwohl es sich eigentlich um Low-Level Probleme handelt. Die Neu-Registrierung aller Komponenten nach einem kritischen Unlock kann zu einer neuerli¨ chen Uberlast-Situation f¨ uhren.

Teil II

Das Framework

16 Das Framework

Das Framework wird in erster Linie f¨ ur die Headunit ausgelegt, nat¨ urlich k¨ onnen große Teile auch f¨ ur angeschlossene Ger¨ate verwendet werden. Nach der Diskussion im Teil I, welche Bausteine f¨ ur ein Framework m¨oglich sind, betrachten wir im Folgenden hoffentlich interessante Ausschnitte einer tats¨achlichen Realisierung eines solchen Frameworks. Es ist weitgehend von speziellen OS-Funktionen unabh¨ angig, so dass es unter QNX, Win32 und Linux lauff¨ahig ist. Darauf wird in einem sp¨ ateren Kapitel n¨aher eingegangen. Weiterhin hat es gut Eigenschaften wie kurze Startzeit, geringen Speicherbedarf (footprint) und gute Kapselung von Expertenwissen.

17 OS-Grundmechanismen

Das Betriebssystem stellt viele Grundmechanismen zur Verf¨ ugung, von denen wir aber nur einige nutzen und so kapseln, dass ein Austausch des Betriebssystems leicht m¨ oglich bleibt. Dies ist eine wichtige Anforderung, da erfahrungsgem¨aß oft schon nach einer Generation der Prozessor aus einer anderen Familie gew¨ahlt wird und damit gelegentlich auch ein neues Betriebssystem n¨otig wird. Um die Portabilit¨ at sicherzustellen, beschr¨anken wir uns auf Mechanismen, die unter Linux, QNX, Cygwin und Win32 (mit Anpassungen in Libraries) lauff¨ahig sind. Wir verwenden POSIX-konforme Mechanismen oder kapseln Mechanismen entsprechend. Zun¨achst sind die vorgestellten Synchronisationsmechanismen zu nennen. Es sind Mutexe und Condition-Variablen. Bin¨are Semaphore generieren wir uns selbst aus Mutex und Condition-Variable. Die Gr¨ unde daf¨ ur wurden in dem entsprechenden Kapitel bereits genannt. Signale, Semaphore, Messages, Pipes und QNX-Messages werden nicht verwendet. Zum Debuggen gibt es einen IP-Socket-Anschluss an den Main-Dispatcher und ggf. an die Komponenten, der hier nicht weiter er¨ortert wird. Der Anwendungsprogrammierer bekommt gekapselte Binary-Semaphore zur Verf¨ ugung gestellt, mit high-level Objekt-Methoden zum Zugreifen. Eigene Systemcalls zur Erzeugung von OS-Mechanismen sind im Framework verboten. Wir verwenden Prozesse und generieren diese mit fork in der main des Start-Prozesses. Es werden f¨ ur bestimmte Zwecke ebenfalls Threads verwendet. Auch daf¨ ur gibt es Kapselungen, die high-level Objekt-Methoden zur Verf¨ ugung stellen (CThread). Eigene C-Level Aufrufe von Thread- oder Prozess-Erzeugungen sind verboten. Als Kommunikationsmechanismen nutzen wir Memory-Mapped-SharedMemory, in dem wir eigene, OS-unabh¨ angige Queues implementieren. Die

278

17 OS-Grundmechanismen

Erzeugung des Shared-Memories erfolgt im Framework und bleibt dem Anwendungsprogrammierer verborgen. Auch hier bekommt er Objekt-Methoden f¨ ur den Zugriff auf Queues im Shared-Memory inklusive der Synchronisation, ohne dass er sich um die Mechanismen k¨ ummern muss oder darf. Wir verwenden nur 16 verschiedene Priorit¨aten, die wir auf eine eigene Skala abbilden, da sie in unterschiedlichen Betriebssystemen unterschiedliche Bedeutung haben. Die u ur Festplatte, Flash und Schnittstellen finden ¨blichen File-Systeme f¨ Anwendung. Ebenso normale“ blockierende File-Zugriffsmethoden. ” Soweit im Teil I noch nicht geschehen, werden wir in diesem Teil schrittweise die Kapselungen, die das Framework bietet, besprechen.

18 Komponentenarchitektur

Unter einer Software-Komponente verstehen wir ein St¨ uck Software, das eine spezifische Funktionalit¨ at zusammen mit einer Anzahl von so genannten Komponentenschnittstellen implementiert. Eine Komponente realisiert einen Teilbereich unserer Anwendung mit dem Gedanken eines wieder verwendbaren, bausteinartigen Moduls. Jede Komponente in unserem Framework l¨auft in einem separaten Thread und hat bestimmte Regeln so einzuhalten, dass der Einsatz von Codegeneratoren erm¨ oglicht wird. In diesem Kapitel wird der Rahmen einer Komponente beschrieben und diskutiert. Wir beschr¨anken unsere Betrachtungen auf interne Komponenten. Mit einer einfachen Erweiterung kann man auch remote-Komponenten z.B. u ¨ber Socket ansprechen. ¨ Aufgrund der Uberlegungen im Teil I treffen wir zun¨achst folgende Entscheidungen: 1. Events werden als Kommunikationsmittel zwischen Komponenten eingesetzt. Ob die Kommunikation synchron oder asynchron ist, h¨angt von der konkreten Anwendung ab. In der Regel ist eine Anfrage synchron. Die Benachrichtigung, wenn bestimmte Ereignisse eintreffen, ist naturgem¨aß asynchron, da zeitlich nicht voraussagbar. 2. F¨ ur Events werden Objekte fester Gr¨ oße verwendet. Wir konzentrieren uns auf die Kontrollnachrichten. Kleine Datenmenge k¨onnen damit transportiert werden. Gr¨ oßere Datenmengen werden u ¨ber einen gemeinsamen Speicherbereich abgewickelt. 3. Zur schnellen Kommunikation zwischen Komponenten wird Shared-Memory verwendet, unabh¨ angig davon, ob sie im selben Prozess oder in verschiedenen Prozessen liegen. 4. Zur Synchronisation werden nur Mutexe und Condition-Variablen verwendet, die wir allerdings in Objekten kapseln, so dass der Anwendungsprogrammierer sie normalerweise nicht direkt anspricht. Unser Ziel ist es, ein Komponentenframework zu entwerfen, wobei jede einzelne Komponente als Thread oder Main-Thread eines eigenen Prozesses konfiguriert werden darf. In als Main-Thread gestartete Komponenten k¨onnen damit

280

18 Komponentenarchitektur

schon bestehende Komponenten, beispielsweise von third-party-Herstellern, einfach integriert werden. Die Skalierbarkeit und Robustheit werden dadurch erh¨oht. In der Praxis muss man zun¨ achst entscheiden, wie die Anwendungen in nebenl¨aufige Objekte aufgeteilt werden. Dies muss so geschehen, dass einerseits nicht zu viele davon entstehen, da sonst die Kontext-Umschaltzeiten zu stark zu Buche schlagen w¨ urden. Die Komponenten m¨ ussen prinzipiell den Anwendungskontext in den Vordergrund bringen und einen aus Anwendersicht darstellbaren Bereich abdecken. Ferner sollen sie m¨oglichst gekapselt und unabh¨angig sein, so dass die Entwicklung und Fehlersuche erleichtert werden. Zu wenige nebenl¨ aufige Objekte andererseits w¨ urden dazu f¨ uhren, dass die Querbeziehungen zu komplex werden. Man kann sich das gut als eine Art dreidimensionalen Sternenraum vorstellen, in dem jede Komponente ein Stern ist und jede Kommunikation zwischen den Sternen Verbindungslinien in einem Netz. Es gibt daf¨ ur SW-Analyse-Tools, die solche bildlichen Darstellungen im Nachhinein erzeugen k¨ onnen. Im Folgenden sprechen wir von Komponenten oder von Tasks, wobei Komponenten Tasks mit zus¨ atzlichen Vorrichtungen wie Queues, Timer und Watchdog sind. Entsprechend unserer Definition im Teil I k¨onnen Tasks als Threads oder Prozesse (genauer: Main-Threads von Prozessen) konfiguriert werden, ebenso die Komponenten. Die Abstraktion der Aufgaben in einzelne Tasks muss so gew¨ahlt werden, dass es nicht zu einem Spinnennetz kommt aber auch nicht zu einem Sternenhaufen. Einige Tasks sind leicht zu identifizieren: 1. Ein- und Ausgangssignale werden schon in einer Treiberschicht in einheitliche logische Signale (Events) verwandelt. Jeder Treiber f¨ ur eine physikalische Einheit ist ein eigener Task (Bedieneinheit, Grafikdisplay, Laufwerk, Festplatte, ...). 2. Wir folgen der Abstraktion der MOST-Spezifikation und definieren in der Regel f¨ ur jeden Function-Block (MOST-Ger¨at) in der Headunit eine Komponente, in der das Modell abl¨ auft. 3. Wir definieren eine HMI-Komponente, in der die Bedienabl¨aufe aller Devices implementiert sind, da sie stark miteinander verwoben und nicht gut trennbar sind. Im MVC-Sprachgebrauch sind das die Controller. 4. Auch die Implementierung der virtuellen GUI mit abstrahierten Bedienelementen und Ausgaben (GUI-Objekte) findet sich in der HMIKomponente. Im MVC-Gebrauch ist dies der View. 5. Die eigentliche Grafikerzeugung wird dem Treiber oder einem separaten Task zugerechnet. 6. Weiterhin wird es einige zus¨ atzliche Tasks wie Admin oder Komponenten wie Audio-Controller usw. geben. 7. Eine weitere Komponente ist der System-Dispatcher, der die Events nach innen und außen verteilt Eine m¨ogliche Partition zeigt die Abbildung 18.1.

18.1 Event-Handler und Event-Formate

281

Abbildung 18.1. Tasks der Headunit

Um externe Events zu bearbeiten, verf¨ ugt jede Komponente mindestens u ¨ber eine Queue und einen Dispatcher. Bevor wir auf die Architektur unserer Komponenten n¨aher eingehen, betrachten wir das Format unserer Events und die Schnittstelle der Nachrichten-Handler.

18.1 Event-Handler und Event-Formate Es ist m¨oglich, mit Event-Hierarchien zu arbeiten und zu jedem Event-Typ eine separate Handler-Schnittstelle zu vereinbaren. Beim Empfangen einer Nachricht fordert der Dispatcher dann das Objekt auf, die passende Methode aufzurufen. Diese L¨ osung f¨ uhrt dazu, dass man eine Menge von Schnittstellen und Implementierungen bekommt (also sehr objekt-orientiert). In unserem Framework haben wir uns daf¨ ur entschieden, nur Nachrichten fester Gr¨oße

282

18 Komponentenarchitektur

zu verwenden. Dazu wird nur eine Klasse entwickelt und alle Event-Handler m¨ ussen nur eine bestimmte Schnittstelle implementieren:

class CMessage; // forward declaration class IMessageHandler { public: virtual void handleMessage(const CMessage& msg) = 0; }; Listing 18-1. Schnittstelle IMessageHandler

Ein Event-Objekt der Klasse CMessage hat eine feste Gr¨oße von 64 Bytes. Die ersten drei Informationen mit einer Gesamtgr¨oße von 12 Bytes sind in einer Struktur Header beschrieben: class Header { public: Int32 mSenderID; //die Kennung des Senders Int32 mReceiverID; //Kennung des Empf¨ angers IMessageHandler* mMessageHandlerPtr; //Nachrichten-Handler };

Zur Erl¨auterung: Die Komponenten haben zus¨atzlich zur FBlockID eine eigene ID. Dies ist n¨ otig, da manche Komponenten nur intern verwendet werden und keinen Bezug zu MOST-Function-Bl¨ocken haben, Beispiele sind die Admin-Komponente oder eine Non-MOST-Komponente Mediaplayer. F¨ ur die interne Kommunikation k¨ onnen daher als Sender- oder Empf¨anger-ID diese eigenen IDs verwendet werden. Ein Event-Objekt wird auch als Buffer f¨ ur den Datentransport verwendet. Es gibt in unserer Anwendung nur wenige unterschiedliche Event-Typen. Diese Unterscheidung ist in der Membervariablen mType des Objekts beschrieben. Eine weitere Verfeinerung ist prinzipiell m¨ oglich. • DONT CARE ist im Moment ein Typ, der vom Dispatcher ignoriert werden soll. • Der ADMIN TYPE wird vom Admin-Task an System-Queues verschickt. • Der TICK SERVICE TYPE wird vom Timer-Server verwendet, um Komponenten u ¨ber einen neuen Timer-Stand zu informieren. • REQUEST TYPE wird verwendet, um eine Anfrage an eine Komponente zu senden. ¨ • Mit UPDATE TYPE werden Anderungen der Daten angezeigt.

18.1 Event-Handler und Event-Formate

283

• MOST APPMSG TYPE wird f¨ ur Nachrichten aus dem externen MOST-Ring verwendet und deutet an, dass die gesamten Daten der MOST-Nachricht im Event untergebracht sind. • MOST POOL REF TYPE zeigt an, dass die MOST-Nachricht mehr als 48 Bytes beinhaltet. Diese wird u ¨ber einen MOST-Pool verschickt, da sie nicht in das Format von CMessage hineinpasst. • Der INFOMSG TYPE wird zum Broadcasten an alle verwendet. • Alle Tastatur-Nachrichten sind vom Typ KEY EVENT TYPE. • Die beiden Nachrichten LOCK und UNLOCK TYPE werden vom MOSTTreiber generiert und melden, mit UNLOCK TYPE, wenn der Bus gest¨ort ist und Ger¨ate ihre Taktsynchronisierung verloren haben. Die Komponenten sollten deshalb ihre Aktivit¨ aten mit den Ger¨aten einstellen. Nach Wiederherstellung des Lock-Zustands muss die zentrale Registry neu aufgebaut werden. Erst danach ist eine Kommunikation mit den Ger¨aten im Ring m¨oglich. Im Fall MOST APPMSG TYPE und MOST POOL REF TYPE haben die restlichen 52 Bytes die Bedeutung: class MostContent { public: Int8 mType; Int8 mSource; Int16 mLength; Int8 mMostMessage [MESSAGE_SIZE - sizeof(Header) - 4]; };

Die Bedeutung von mType wurde oben erkl¨ art. mSource beinhaltet unter anderem die Unterscheidung zwischen externen und internen Ger¨aten. Mit mLength wird die tats¨achliche L¨ ange der Nachricht angegeben. Das Abholen der MOST-Daten im Falle des Typs MOST POOL REF TYPE ist eine Aufgabe des Handlers. In der Regel wird eine bestimmte Funktion mit einem Buffer hinreichender Kapazit¨ at als Parameter aufgerufen, in den die MOST-Daten geschrieben werden. F¨ ur normale Anwendungen beinhalten die 52 Bytes die folgende Bedeutung: class NormalContent { public: Int8 mType; Int8 mReserved [3]; // wegen padding Int32 mOpcode; Int32 mParam[(MESSAGE_SIZE - sizeof(Header) - 8)/sizeof(Int32)]; };

284

18 Komponentenarchitektur

Wie wir unten sehen werden, kann mit mOpcode der eigentliche Befehl zu einem Typ ermittelt werden. Jeder Befehl kann bis zu 11 Parameter vom Typ Int32 haben. In der Praxis sollte man aber nur maximal drei Parameter erlauben. Zusammenfassend werden alle Events in unserem Framework durch eine Klasse beschrieben:

class CMessage { public: enum MessageType { DONT_CARE_TYPE, ADMIN_TYPE, TICK_SERVICE_TYPE, ... KEY_EVENT_TYPE, };

// set for default // for admin messages // for tick event // for key event

enum SourceType { EXTERNAL_TYPE = 0, DEVICE_TYPE = 2, MODEL_TYPE = 3 }; class Header { ...// see above }; class NormalContent { ... // see above }; class MostContent { ... // see above }; CMessage(); CMessage(MessageType theMsgType); // SETTER-METHODS void setSenderID(Int32 senderID); void setReceiverID(Int32 receiverID); void setOpcode(Int32 opcode);

18.2 Implementierung von Schnittstellen, Proxy und Handler

285

void setParam(UInt32 index, Int32 value); void setMessageHandlerPtr(IMessageHandler* handlerPtr); void setSource(SourceType type); // GETTER-METHODS Int32 getSenderID(void) const; Int32 getReceiverID(void) const; MessageType getMessageType(void) const; Int32 getOpcode(void) const; Int32 getParam(UInt32 index) const; UInt32 getParamCount(void) const; IMessageHandler* getMessageHandlerPtr(void) const; Int8 * getMostContentPtr(void) const; UInt32 getMostContentSize(void) const; UInt32 getMostMessageSize(void) const; SourceType getSource(void) const; private: Header

mHeader;

// and one of the following contents (depending on message type) union { MostContent mMostContent; NormalContent mNormalContent; }; }; Listing 18-2. Ausschnitt aus CMessage.h

18.2 Implementierung von Schnittstellen, Proxy und Handler Wie oben erw¨ahnt, bietet jede Komponente eine Anzahl von Schnittstellen. F¨ ur Objekte, die die Dienste der Komponente ben¨otigen, ist es von Bedeutung, die Kommunikation zu verbergen. Da wir keine großen Datenmenge transportieren, reicht die Kapazit¨ at der Events f¨ ur unsere Befehle vollkommen aus. Beginnen wir damit, Befehle als interne Events an eine andere Komponente zu senden. Die Befehle werden in die Nachricht geschrieben und an die betreffende Komponente gesendet, in dem sie in die zugeh¨orige externe Queue geschrieben werden. Beim Auslesen wird der abgespeicherte Code interpretiert und die entsprechende Methode ausgef¨ uhrt. Die Klassen dazu lassen sich relativ einfach generieren (siehe Kapitel 23). Will die Komponente A z.B. die folgenden Methoden anbieten:

286

18 Komponentenarchitektur

void doIt(); void connect(UInt32 channels);

so k¨onnen wir in folgenden Schritten entwicklen: 1. Definieren der passenden Konstanten f¨ ur die Methoden (jede Methode muss durch einen Code dargesteltt werden). namespace Demo { ... enum { DO_IT, CONNECT }; ... }

2. Implementierung einer Proxy-Klasse, die dieselben Methoden anbietet. Aufgabe dieser Klasse ist die Dekodierung der Nachricht und das Versenden in die Queue der richtigen Komponente. Ein wichtiger Punkt ist, dass wir hier keine Interfaces verwenden. Das bedeutet, die Verwendung wird statisch zur Kompilierzeit festgelegt. Alternativ zur direkten Versendung an die Komponente ist die Versendung der Nachricht an den MainDispatcher m¨ oglich, der sie dann anhand der Kennung des Empf¨angers (Receiver-ID) an diesen weiterleitet. void CProxy::doIt() { CMessage msg(CMessage::REQUEST_TYPE); setSenderID(mID); setReceiverID(mServiceID); msg.setOpcode(Demo::DO_IT); // mQueuePtr ist die Queue der betreffenden Komponenten mQueuePtr->add(msg); } void CProxy::connect(UInt32 channels) { CMessage msg(CMessage::REQUEST_TYPE); setSenderID(mID); setReceiverID(mServiceID); msg.setOpcode(Demo::CONNECT); msg.setParam(0, channels); // mQueuePtr ist die Queue der betreffenden Komponenten mQueuePtr->add(msg); }

3. Auf der Empf¨ angerseite wird eine Handler-Klasse implementiert. Die Handler-Klasse kennt den Dienstanbieter und ist bei dem Dispatcher re-

18.3 Komponentenarchitektur

287

gistriert (siehe unten), so dass er die Nachricht bekommt. Seine handleMessage-Methode sieht dann etwa so aus: void CHandler::handleMessage(const CMessage& msg) { if (msg.getOpcode() == Demo::DO_IT) mServiceProvider.doIt(); else { UInt32 param0 = static_cast(msg.getParam(0)); mServiceProvider.connect(param0); } }

Anders als in der Literatur wird hierbei keine Vererbung ben¨otigt bzw. verwendet. Falls eine gr¨ oßere Nachricht transportiert wird, muss sie erst in einen Shared-Memory-Bereich geschrieben werden. Der Handler kann sie dann in seinen eigenen Buffer einlesen und an den Empf¨anger/Dienstanbieter weiter¨ geben. Dadurch wird die Komplexit¨ at der Ubertragung stark verborgen. Mit dem oben beschriebenen Mechanismus kann man auch synchrone Nachrichten zwischen Komponenten realisieren. Der Proxy wartet, nachdem er die Nachricht an die Komponente gesendet hat, auf ein Signal, das vom Handler zur¨ uckgeschickt wird. An diesem Beispiel kann man sehen, dass das Konzept der Dienste in den Vordergrund r¨ uckt. Die Kommunikation wird weitgehend generiert. Es ist daher auch m¨oglich, gezielt bestimmte Nachrichten zum Debugging u ¨ber Sockets nach außen zu transportieren. Der Entwickler muss nur den Codegenerator entsprechend konfigurieren.

18.3 Komponentenarchitektur Eine Komponente ist, wie oben erw¨ ahnt, eine Einheit mit definierten Aufgaben. In unserem Framework muss eine Komponenten zus¨atzlich bestimmte Elemente bzw. F¨ ahigkeiten haben: • Drei Queues mit begrenzten Kapazit¨ aten (damit wir sie im SharedMemory platzieren k¨ onnen). 1. Eine FIFO-Queue f¨ ur normale, externe Events im Shared-Memory. Alle Events, die von außerhalb kommen, werden in diese Queue eingetragen. Die Events werden in der Reihenfolge ihres Auftretens abgearbeitet. Es ist verboten, sich selbst ein Event in die Queue zu schreiben, da man sich damit blockieren k¨ onnte. ¨ 2. Eine weitere FIFO-Queue f¨ ur System-Events im Shared-Memory. Uber diese Queue werden die hoch priorisierten Events wie On/Off, Diagnose etc. empfangen.

288

18 Komponentenarchitektur

3. Eine LIFO-Queue f¨ ur interne Kommunikationen, entweder im eigenen Daten-Segment oder im Shared-Memory. Eine LIFO-Queue wird ben¨otigt, um Events an andere Objekte in der eigenen Komponente zu versenden. Bei der Abarbeitung eines externen Events kann es vorkommen, dass weitere interne Events ausgel¨ost werden (¨ahnlich wie weitere Funktionsaufrufe). Um den Mechanismus RTC (Run-Til-Completion) zu garantieren, m¨ ussen diese Events in die LIFO-Queue abgelegt werden. • Ein Dispatcher, der in einer Schleife die Ereignisse aus den Queues abholt und verteilt. Dabei wird die interne Queue zuerst leer ger¨aumt, bevor ein Event aus der System-Queue abgenommen wird. Die normale Queue hat die niedrigste Priorit¨ at. Falls kein Event zu bearbeiten ist, wird der Dispatcher blockiert. Wie wir unten sehen werden, wird der Standard” Dispatcher“ in der Hauptschleife aufgerufen. Dabei werden auch Mechanismen f¨ ur den Watchdog und den Zeitservice realisiert. • Reaktion auf Watchdog-Trigger. Im normalen Betrieb, wenn sich die Komponente nicht aufgeh¨ angt“ hat, muss sie bestimmte definierte Aktivit¨aten ” ausf¨ uhren, um zu signalisieren, dass sie lebt. Wird f¨ ur l¨angere Zeit kein Signal erhalten bzw. versendet, kann das nur bedeuten, dass die Komponente irgendwo h¨ angen geblieben ist. Sie wird dann als tot erkl¨art. • F¨ahigkeit, so genannte Softtimer anzubieten. In unseren Anwendungen brauchen wir h¨ aufig Uhren, die nicht sehr genau sein m¨ ussen. Wichtig ist nur, dass, wenn eine Uhr gestoppt wird, kein Event mehr versehentlich ausgel¨ost werden soll. Ferner wird jede Komponente in einem Thread ihre Aktivit¨aten aufneh¨ men. Sie muss daher, gem¨ aß den Uberlegungen im Teil I, die Schnittstelle IRunnable implementieren. Die Basis unserer Komponenten wird in der Klasse AComponentBase beschrieben: Im Teil I haben wir die Schnittstelle IRunnable schon ausf¨ uhrlich besprochen. Die Aufgaben der beteiligten Klassen werden im Folgenden genauer besprochen. 18.3.1 Komponentenkontext und Daten im Shared-Memory Eine Komponente muss mit der Umgebung kommunizieren und mit anderen Objekten Daten austauschen. Diese unten aufgef¨ uhrten Daten m¨ ussen allen beteiligten Objekten zug¨ anglich sein und werden deshalb im Shared-Memory gehalten. Wir nennen sie Kontext einer Komponente. 1. Zum Empfang externer Daten werden wie erw¨ahnt zwei externe Queues ben¨otigt. 2. Zum Empfang eigener interner Daten wird wie erw¨ahnt eine interne Queue ben¨otigt.

18.3 Komponentenarchitektur

289

Abbildung 18.2. Klassendiagramm zu einer Komponente

3. Ein Semaphor zum Signalisieren. Generell darf eine Komponente keine Zeit konsumieren, wenn kein Event bzw. keine Arbeit vorliegt. Der Dispatcher muss also an einer bestimmten, definierten Stelle blockiert werden. Dies geschieht dadurch, dass er auf ein Signal wartet, das von einer oder mehreren externen Quellen gesendet wird. Daf¨ ur ist ein bin¨arer Semaphor geeignet. Der Semaphor muss allen Beteiligten bekannt sein und darf nur in einer Richtung verwendet werden. 4. Zwei Mutexe, die verwendet werden, um die Priorit¨atsvererbung der Queues zu erm¨ oglichen (siehe Kapitel 13). Diese Mutexe werden in den Queue-Objekten referenziert und k¨ onnen von Objekten verschiedener Prozesse zugegriffen werden. Sie m¨ ussen daher ebenfalls im Shared-Memory liegen. ¨ 5. Die Komponente wird nicht nur aufgrund einer Anderung in den Queues geweckt. Sie wird auch geweckt, wenn der Watchdog-Z¨ahler ver¨andert wurde. Dieses Ereignis wird aus Gr¨ unden der Effizienz nicht als Event f¨ ur eine Queue implementiert, sondern im Hintergrund direkt in der Komponente gesetzt. Wir kommen auf diese Besonderheit noch zur¨ uck. Damit der Dispatcher nicht geweckt wird und dann versehentlich auf eine leere Queue zugreift, wird ein Flag verwendet, mit dem angezeigt wird, wenn die Komponente von außen unterbrochen“ und geweckt wurde. ” 6. Um den Watchdog-Mechanismus zu implementieren, werden zwei Variablen ben¨otigt. Unsere Watchdog-Implementierung funktioniert etwa so: In der Hauptschleife wird ein Z¨ ahler von der Komponente st¨andig gel¨oscht. Ein externes Objekt, das in einem Admin-Task l¨auft, erh¨oht den Z¨ahler in regelm¨aßigen Abst¨ anden. Sobald der Z¨ ahlerstand eine festgelegte Grenze u ¨berschreitet, welche in einer zweiten Variablen abgespeichert ist, wird der Thread als verklemmt erkl¨ art. Der u ¨berwachte Thread darf sie in besonderen Situationen zur Laufzeit variieren.

290

18 Komponentenarchitektur

7. Jede Komponente hat eine Variable als eigene Uhr, die von dem TimeServer erh¨oht wird. Es wird versucht, ein Update-Event in die Queue zu schreiben. Um die Flut der so genannten Tick-Events zu vermeiden, wird ein Flag verwendet, das anzeigt, ob sich schon ein Tick-Event in der Queue befindet und noch nicht konsumiert wurde. ¨ 8. Zur Uberwachung der Komponente kommen außerdem zwei Variablen zum Einsatz. Die eine speichert den aktuellen Zustand, die andere beinhaltet den Sollzustand (requested state). Ferner ist ein Merker hilfreich, mit dem die Komponente erkennen kann, dass ein neuer Sollzustand vorliegt. Zurzeit sind folgende Zust¨ ande implementiert: // describe the state of the component enum ComponentState { NON_EXISTENCE,// only the context is existing the // component does not exist INITIALIZED, // component is created, init. but not running RUNNING, // normal state Running IN_STANDBY, // like running but with little actions READY_FOR_SHUTDOWN, // all important data are saved STOPPED // stopped I.e. the component must be destroyed // and created if it should be running again }; // describe the state requested by the system enum RequestedState { RUN_REQUEST, // default STANDBY_REQUEST, // component must go into standby mode PREPARE_FOR_SHUTDOWN, // request for shutdown preparation STOP_REQUEST // stop the component };

9. Eine Kontext-ID kann abgespeichert werden, um diese Datens¨atze zu unterscheiden. F¨ ur einige Komponenten werden ggf. zus¨ atzlich ein oder mehrere Datencontainer ben¨otigt. Somit haben wir einen festen und einen variablen Teil der Daten. Der feste Teil wird in der folgenden Klasse beschrieben:

class ContextHeader { public: ContextHeader(Int32 limit, Int32 id); // Data section CBinarySemaphore mTriggerSem; // for signal

18.3 Komponentenarchitektur CMutex mPrioInhMutex; // for prio inheritance CMutex mSyncMutex; // indicate that signal comes but not because of new event bool mIsInterrupted; Int32 mCounter; // for watchdog Int32 mLimit; bool mIsTickEventConsumed; // for time service Int32 mTickCounter; // used for setting the component state from outside #ifdef __GNUC__ CComponentContext::RequestedState mRequestedState; #endif #ifdef WIN32 RequestedState mRequestedState; #endif bool mIsRequest; #ifdef __GNUC__ CComponentContext::ComponentState mCurrentState; #endif #ifdef WIN32 ComponentState mCurrentState; #endif Int32 mID; }; Listing 18-3. Der Kontext-Header

Abbildung 18.3. Kontext-Header der Komponenten

291

292

18 Komponentenarchitektur

Der zweite Teil der Daten hat eine zur Kompilierzeit feste Gr¨oße, denn unsere Queues und Datencontainer sind statisch. Sie werden direkt hinter den ersten Teil platziert. Um die Zugriffe auf all diese Daten zu vereinfachen, wird eine Hilfsstruktur ben¨otigt:

class CComponentContext { public: enum ComponentState { ... see above }; enum RequestedState { ... see above }; const char* getContextNamePtr(void) const; CBinarySemaphore& getTriggerSemaphore(void); CMutex& getPriorityInheritanceMutex(void); CMutex& getSyncMutex(void); CCommQueue& CCommQueue& CInternalQueue&

getSystemQueue(void); getNormalQueue(void); getInternalQueue(void);

// this method will be called only by the watchdog-server. It will // increment a counter and unblock the component if necessary void checkAlive(void); // check whether the component has answered the checkAlive bool isAlive(void); // will be called by the component in the main-loop to reset // the watchdog counter void resetCheckCounter(void); // called from the tick server to send a message into the // component if needed void handleTick(void); // get reference to a flag that indicates whether the last tick // message is already consumed. Note that no tick message is sent // into the component as long as this flag is false bool& getTickConsumedFlag(void); // for the current clock const Int32& getTickCounter(void); // get the flag that indicates that the component is interrupted. // It is needed to known whether the dispatcher is waken up due to

18.3 Komponentenarchitektur

293

// the signal or because some messages are received. bool& getInterruptFlag(void); // get the flag that signal that a state change is requested. In the // main-loop this flag will be checked and a system message will be // tried to sent to the component. If successful the flag is reset. bool& getRequestFlag(void); // set the requested state. It will be called by the component // management. void setRequestedState(RequestedState newState); RequestedState getRequestedState(void); void setCurrentState(ComponentState currentState); ComponentState getCurrentState(void) const; Int32 getId(void) const; public: class ContextHeader { // ... see above }; private: // CContext is allowed to create a component context friend class CContext; static CComponentContext createComponentContext(const char* contextNamePtr, Int8* memPtr, Int32 checkLimit, Int32 systemQueueSize, Int32 normalQueueSize, Int32 internalQueueSize, CThread::EPriority prioOfReader, Int32 id, bool shmAlreadyOpened); // the context name const char* mContextNamePtr; ContextHeader* mContextHeaderPtr; // pointers to the queues CCommQueue* mSystemQueuePtr; CCommQueue* mNormalQueuePtr; CInternalQueue* mInternalQueue; }; Listing 18-4. Beschreibung des Komponentenkontexts, CComponentContext.h

294

18 Komponentenarchitektur

Abbildung 18.4. Kontext einer Komponenten

Die Methode createComponentContext wird verwendet, um den Kontext an einer vorgegebenen Stelle zu platzieren. Dabei ist zu beachten, ob das Shared-Memory schon ge¨ offnet und initialisiert wurde (von einem anderen Prozess). Ist dies der Fall, werden nur die entsprechenden Zeiger berechnet und abgespeichert. Wird der Speicherbereich zum ersten Mal initialisiert, so werden durch Placement-new der Kontextheader und die Queues erzeugt. Man beachte den Aufruf getNumOfBytesNeeded, der die tats¨achliche Gr¨oße der Queue zur¨ uckliefert, weil wir nur eine Klasse f¨ ur verschiedene Queue-Gr¨oßen implementieren, ohne dynamische Arrays zu verwenden (siehe auch Kapitel 13). CComponentContext CComponentContext::createComponentContext (const char* contextNamePtr, // name of component Int8 *memPtr, // mem on which context is created Int32 checkLimit, // limit used for watchdog Int32 systemQueueSize, // size of the system queue Int32 normalQueueSize, // size of the normal queue Int32 internalQueueSize, // size of the internal queue CThread::EPriority prioOfReader, Int32 id, bool shmAlreadyOpened) { CComponentContext context; context.mContextNamePtr = contextNamePtr; // create data header if (shmAlreadyOpened) { // The shared memory was already opened and initialized by // another process. So we only set the address but don’t // create a new ContextHeader.

18.3 Komponentenarchitektur

295

context.mContextHeaderPtr = (ContextHeader*) memPtr; // Also no new Queues, only set the addresses. context.mSystemQueuePtr = (CCommQueue*) memPtr; memPtr += context.mSystemQueuePtr->getNumOfBytesNeeded(); context.mNormalQueuePtr = (CCommQueue*) memPtr; memPtr += context.mNormalQueuePtr->getNumOfBytesNeeded(); context.mInternalQueuePtr = (CInternalQueue*) memPtr; } else { context.mContextHeaderPtr = new(memPtr) ContextHeader(checkLimit, id); // create header memPtr += HEADER_SIZE; context.mSystemQueuePtr // and queues = new(memPtr) CCommQueue(systemQueueSize, context.mContextHeaderPtr->mTriggerSem, context.mContextHeaderPtr->mPrioInhMutex, context.mContextHeaderPtr->mSyncMutex, prioOfReader); memPtr += context.mSystemQueuePtr->getNumOfBytesNeeded(); context.mNormalQueuePtr = new(memPtr) CCommQueue(normalQueueSize, context.mContextHeaderPtr->mTriggerSem, context.mContextHeaderPtr->mPrioInhMutex, context.mContextHeaderPtr->mSyncMutex, prioOfReader); memPtr += context.mNormalQueuePtr->getNumOfBytesNeeded(); context.mInternalQueuePtr = new(memPtr) CInternalQueue(internalQueueSize); } return context; } Listing 18-5. Die createComponentContext-Methode der Klasse, Implementierung

Nun sehen wir uns den Codeteil an, in dem die Kontexte erzeugt werden. 18.3.2 Erzeugung der Kontexte Die notwendigen Informationen eines Kontexts wie Name, Gr¨oße der Queues usw. sind in einer Struktur untergebracht: struct CContextDescription { Int32 mId; const char* mComponentName; Int32 mNormalQueueSize; Int32 mSystemQueueSize;

// id of the component // name of the component

296

18 Komponentenarchitektur Int32 mInternalQueueSize; Int32 mWatchdogLimit; CThread::EPriority mPrio; Int32 mSizeNeeded;

// Initial limit for watchdog // Prio of the component // size needed in shared mem.

};

Zusammen mit den Makros otigten Gr¨oße eines Objekts vom 1. HEADER SIZE: Zum Aufrunden der ben¨ Typ ContextHeader. Dabei wird das Alignment ber¨ ucksichtigt; 2. EXT QUEUE SIZE: Unsere Queues haben verschiedene Gr¨oße. Um sie einheitlich in einer Klasse unterzubringen, wurde ein Trick beschrieben und verwendet. Der tats¨ achliche Speicherbedarf einer Queue wird mit Hilfe dieses Makros berechnet; 3. INT QUEUE SIZE: Dasselbe mit der internen Queue; und den (von einem Codegenerator erzeugten) Konstanten wie AUDIODISCPLAYER COMPONENT NAME, AUDIODISCPLAYER COMPONENT ID usw. sowie die ben¨ otigten Gr¨ oßen AUDIODISCPLAYER CONTEXT SIZE, ... , TOTAL SIZE. #define HEADER_SIZE

(MAKE_ALIGNMENT_SIZE(( \ sizeof(CComponentContext::ContextHeader))))

#define EXT_QUEUE_SIZE(numOfMsg) \ (MAKE_ALIGNMENT_SIZE((sizeof(CCommQueue) + sizeof(CMessage)*((numOfMsg) - 1)))) #define INT_QUEUE_SIZE(numOfMsg) \ (MAKE_ALIGNMENT_SIZE((sizeof(CInternalQueue) + sizeof(CMessage)*((numOfMsg) - 1)))) .... static const char* AUDIODISCPLAYER_COMPONENT_NAME = "AudiodiscplayerComponent"; static const char* AUDIOAMPLIFIER_COMPONENT_NAME = "AudioamplifierComponent"; ... enum { AUDIODISCPLAYER_CONTEXT_SIZE = HEADER_SIZE + EXT_QUEUE_SIZE(100) + EXT_QUEUE_SIZE(10) + INT_QUEUE_SIZE(10),

18.3 Komponentenarchitektur

297

AUDIOAMPLIFIER_CONTEXT_SIZE = HEADER_SIZE + EXT_QUEUE_SIZE(100) + EXT_QUEUE_SIZE(10) + INT_QUEUE_SIZE(10), ... TOTAL_SIZE = AUDIODISCPLAYER_CONTEXT_SIZE + AUDIOAMPLIFIER_CONTEXT_SIZE + ... };

werden die konstanten Kontextinformationen definiert:

static const CContextDescription sDescriptionTable[] = { { AUDIODISCPLAYER_COMPONENT_ID, // id of the component AUDIODISCPLAYER_COMPONENT_NAME, // name of the component 100, // NormalQueueSize 10, // SystemQueueSize 10, // InternalQueueSize 10, // Initial limit for watchdog AUDIODISCPLAYER_PRIORITY, // prio of audiodiscplayer AUDIODISCPLAYER_CONTEXT_SIZE // size needed in shared mem }, { AUDIOAMPLIFIER_COMPONENT_ID, AUDIOAMPLIFIER_COMPONENT_NAME, 100, 10, 10, 10, AUDIOAMPLIFIER_PRIORITY, AUDIOAMPLIFIER_CONTEXT_SIZE }, ... }; Listing 18-6. sDescriptionTable f¨ ur die Erzeugung von Kontexten

Zur Erzeugung und Verwaltung der Kontexte wird eine Klasse CContext de¨ finiert und generiert. Uber diese Klasse erhalten die Komponenten sp¨ater den Zugang zu einem bestimmten Kontext. Auch Datencontainer werden hier angelegt.

298

18 Komponentenarchitektur

class CContext { public: .... // other stuff static CComponentContext& static CComponentContext& .... // similar for other static CComponentContext& static CComponentContext&

getAudiodiscplayerContext(void); getAudiodiscplayerdeviceContext(void); components getDebugContext(void); getMostdispatcherContext(void);

// Data container static CAudioDiscPlayerDC * getAudioDiscPlayerDC(); static CAmFmTunerDC * getAmFmTunerDC(); static const CThread::EPriority AUDIODISCPLAYER_PRIORITY; static const CThread::EPriority AUDIODISCPLAYERDEVICE_PRIORITY; .... // similar for other components static const CThread::EPriority DEBUG_PRIORITY; static const CThread::EPriority MOSTDISPATCHER_PRIORITY; static const Int32 AUDIODISCPLAYER_STACK_SIZE; static const Int32 AUDIODISCPLAYERDEVICE_STACK_SIZE; .... // similar for other components static const Int32 DEBUG_STACK_SIZE; static const Int32 MOSTDISPATCHER_STACK_SIZE; private: friend void initComponentContexts(void); friend void signalHandler(int); friend class CAdmin; static void createContexts(bool, Int8*); enum { NUM_OF_COMPONENTS = 12 }; static CComponentContext sContextTable[NUM_OF_COMPONENTS]; static ADataContainerBase * CContext::sDataContainerTable[NUM_OF_COMPONENTS]; }; Listing 18-7. Klasse zur Erzeugung und Verwaltung der Kontexte

Die Methode createContexts wird sp¨ ater aus der main heraus u ¨ber die Methode initComponentContexts aufgerufen. Sie durchl¨auft die Beschreibungstabelle und legt die Kontexte und Datencontainer an:

18.3 Komponentenarchitektur

void CContext::createContexts(bool shmAlreadyOpened, Int8* memPtr) { Int8* ptr = memPtr; // Erzeugt einzelne Kontexte entsprechend der Beschreibung for (Int32 i = 0; i < NUM_OF_COMPONENTS; i++) { sContextTable[i] = CComponentContext::createComponentContext ( sDescriptionTable[i].mComponentName, ptr, sDescriptionTable[i].mWatchdogLimit, sDescriptionTable[i].mSystemQueueSize, sDescriptionTable[i].mNormalQueueSize, sDescriptionTable[i].mInternalQueueSize, sDescriptionTable[i].mPrio, sDescriptionTable[i].mId, shmAlreadyOpened ); ptr += sDescriptionTable[i].mSizeNeeded; // Create DataContainer(s) // Each DC consits of the data object in shared memory // and an object having a reference to shared data, // which provides getVar.. functions switch(i) { case AUDIODISCPLAYER_INDEX: { if (!shmAlreadyOpened) { new(ptr) CAudioDiscPlayerDCShared(0); } CAudioDiscPlayerDCShared & sharedData = *(reinterpret_cast(ptr)); ptr += sizeof(CAudioDiscPlayerDCShared); sDataContainerTable[i] = new CAudioDiscPlayerDC(sharedData); } break; case AMFMTUNER_INDEX: { if (!shmAlreadyOpened) { new(ptr) CAmFmTunerDCShared(0); } CAmFmTunerDCShared & sharedData =

299

300

18 Komponentenarchitektur *(reinterpret_cast(ptr)); ptr += sizeof(CAmFmTunerDCShared); sDataContainerTable[i] = new CAmFmTunerDC(sharedData); } break; default: sDataContainerTable[i] = 0; } }

} Listing 18-8. Code zur Erzeugung von Kontexten und Datencontainer

Bevor wir die anderen Methoden und Mechanismen einer Komponente weiter diskutieren, werfen wir einen Blick auf die main-Funktion und den AdminTask. 18.3.3 Main-/Admin-Task Die main-Funktion hat im Framework vorrangig die Aufgabe, die gesamten Komponenten der Anwendung hochzufahren. Zum Schluss startet sie den Admin-Task. Dieser Task ist ein Main-Thread mit einer relativ hohen Priorit¨ at. W¨ahrend des Betriebs u ¨berwacht der Admin-Task die einzelnen Komponenten und reagiert ggf. auf Fehler, notfalls durch einen Neustart der Anwendung. Daf¨ ur sind Watchdog-Server und andere Funktionen implementiert. Zu seinen Aufgaben geh¨ ort auch der Timer-Service f¨ ur die Komponenten. Er kann auch einzelne Komponenten auffordern, ihren Zustand zu ver¨andern (z.B. als Vorbereitung f¨ ur einen Neustart). Betrachten wir nun die main in einzelnen Abschnitten:

Int32 main(void) { //Signale abfangen //Erzeugung und Initialisierung der Komponentenkontexte //Erzeugung und Starten der Komponenten //Erzeugung und Starten des Admin-Tasks return 0; } Listing 18-9. Pseudocode f¨ ur main

Zun¨achst werden Signale abgefangen. In der Entwicklungsumgebung kann beispielsweise Ctrl-C (SIGINT) Verwendung finden, um eine Anwendung abzuschalten. Unter der Entwicklungsumgebung Momentics soll auch das Signal SIGTERM durch einen geeigneten Handler abgefangen werden. Anschließend wird ein passender Shared-Memory-Bereich erzeugt und in den Adressraum

18.3 Komponentenarchitektur

301

eingeblendet. Komponenten, die durch exec gestartet werden, m¨ ussen nur nach dem Shared-Memory suchen (named) und sich einklinken. Durch den Aufruf CContext::createContexts(false, memPtr);

werden alle Kontexte, Datencontainer und Pools im Shared-Memory erzeugt. Danach werden die einzelnen Komponenten (hier durch fork) erzeugt und gestartet. if ((audiodiscplayerPID = fork()) == 0) // Audiodiscplayer { CAudiodiscplayerComponent audiodiscplayer( CContext::getAudiodiscplayerContext(), 1, 1); CThread audioDiscThread(audiodiscplayer, "AudioDiscPlayer", CContext::AUDIODISCPLAYER_STACK_SIZE, CContext::AUDIODISCPLAYER_PRIORITY, true); audiodiscThread.start(); } sOwnCout<< "Creating process Audiodiscplayerdevice" << endl; if ((audiodiscplayerdevicePID = fork()) == 0) { ... // similar } ... // other components

Am Schluss u ¨bergibt die main die Kontrolle an den Admin-Task, dessen Hauptaktivit¨aten in der endlosen Schleife der Watchdog- und Time-Service sind. Dabei ist zu beachten, dass gilt: • der Admin-Thread hat hohe Priorit¨ at; • der Admin-Task implementiert nur die Methode run der Schnittstelle IRunnable. Er l¨ auft in einer endlosen Schleife, die mit Power-On f¨ ur alle Zeiten l¨auft, bis die Betriebsspannung abgeschaltet wird. In einem vollst¨andigen System w¨ are er ein Teil des Ur-On/Off-Prozesses; • die Zeitaufl¨osung soll passend gew¨ ahlt werden; eine zu kurze Dauer kann zu Performance-Verschlechterung f¨ uhren; • die Behandlung im Falle einer toten“ Komponente ist diskussionsw¨ urdig. ” Die einfachste und effizienteste L¨ osung ist ein Neustart, nachdem der Fehler in den Fehlerspeicher geschrieben wurde. Jeder Versuch, das System zu retten (Neustart der betreffenden Komponente zur Laufzeit, Recovery usw.) f¨ uhrt nur zu einer unn¨ otigen, unbeherrschbaren Komplexit¨at. Da unser System nach 2 Sekunden betriebsbereit ist, ist es sogar besser, es neu zu starten.

302

18 Komponentenarchitektur

Im folgenden Code sieht man die Hauptaktivit¨aten des Admin-Tasks. Das Zusammenspiel mit den Komponenten wird durch die Beschreibungen in den folgenden Abschnitten klarer:

Int32 counter = 0; Int32 i; bool checkAlive; while (true) { // Sleep for a defined resolution CThread::sleep(TIME_RESOLUTION); counter++; checkAlive = (0 == counter%CHECK_ALIVE_CYCLE); for (i = 0; i < CContext::NUM_OF_COMPONENTS; ++i) // Time Service { CContext::sContextTable[i].handleTick(); if (true == checkAlive) { CContext::sContextTable[i].checkAlive(); } } if (counter%WATCHDOG_CYCLE == 0) // Watchdog Service { for (i = 0; i < CContext::NUM_OF_COMPONENTS; ++i) { if (false == CContext::sContextTable[i].isAlive()) { // put your hangup handling here } } } } Listing 18-10. Auszug aus der run-Methode des Admin-Tasks, Watchdog-Loop

18.3.4 Signale, Mechanismen u ¨ ber den Kontext Nun studieren wir die Methoden der Klasse CComponentContext genauer. Durch den Kontext k¨ onnen wir einer Komponente Nachrichten senden. Dar¨ uber hinaus kann der Admin-Task handleTick, checkAlive, isAlive etc. aufrufen. Watchdog Der Admin-Task ruft die Methode checkAlive f¨ ur jede einzelne Komponente auf, die den Z¨ ahler mCounter im Kontext inkrementiert, anschließend das

18.3 Komponentenarchitektur

303

Flag mIsInterrupted aktiviert und schließlich den Trigger-Semaphor im Dispatcher freigibt.

// this method will be called only by the watchdog-server. It will // increment a counter and unblock the component if necessary void CComponentContext::checkAlive(void) { mContextHeaderPtr->mCounter++; // wake up dispatcher if blocked mContextHeaderPtr->mIsInterrupted = true; getTriggerSemaphore().give(); } Listing 18-11. Auszug aus der run-Methode des Admin-Tasks, Watchdog-Trigger

Daraufhin wird die Komponente ggf. geweckt, falls sie blockierend auf das Signal gewartet hat. Auf jeden Fall wird die Kontrolle an die Methode der Basisklasse AComponentBase::run u ¨bertragen (siehe unten), die das Flag ggf. l¨oscht, den Watchdog-Counter der Komponente zur¨ ucksetzt und weitere Verwaltungsaktivit¨aten ausf¨ uhrt, bevor der Dispatcher wieder aufgerufen wird.

... bool& interruptFlag = mContext.getInterruptFlag(); ... while (mContext.getCurrentState() != CComponentContext::STOPPED) { ... clear the interrupt flag if needed // reset the watchdog counter mContext.resetCheckCounter(); ... some activities mDispatcher.dispatch(); } Listing 18-12. Auszug aus der run-Methode einer Komponente

W¨ahrend checkAlive alle CHECK ALIVE CYCL msec aufgerufen wird, wird nur in l¨angeren Abst¨ anden die Methode isAlive aufgerufen, um nachzupr¨ ufen, ob die Komponente darauf reagiert hat. L¨auft der Counter mCounter u uckgegeben. Im Admin-Task muss dann ¨ber das Limit, wird ein false zur¨ mit einer Fehlerbehandlung darauf reagiert werden. Es k¨onnte z.B. die Komponente oder das ganze System in einen Reset gefahren werden. Die Komponente oder der Admin-Task k¨ onnten auch das Limit ver¨andern, wenn bekannt ist, dass die Komponente in eine zeitaufw¨andige Bearbeitung

304

18 Komponentenarchitektur

Abbildung 18.5. Eingebauter Watchdog-Mechanismus

geht und deshalb den Watchdog eine Zeit lang nicht bedienen kann. Solche Situationen gibt es beispielsweise beim Update der SW von CD oder bei speziellen Diagnose-Phasen. Tick-Service Die Uhr jeder Komponente soll nach Ablauf von TIME RESOLUTION msec angepasst werden. Es gibt dazu verschiedene L¨ osungen. Eine L¨osung w¨ are entsprechend dem Watchdog-Z¨ahler. Der Admin-Task erh¨oht die Uhr, setzt ein Flag und triggert den Semaphor. Die Komponente in ihrer Schleife informiert den sp¨ ater beschriebenen Timer-Manager u ¨ber den Tick. Die L¨osung hat aber einige Nachteile: 1. Viele unn¨otige Reaktionen. Es ist m¨ oglich, dass die Komponente keine Benachrichtigung braucht, weil intern kein Softtimer“ l¨auft. Ferner sollte ” der Timer-Manager nicht bei jedem Tick alle Uhren anpassen. Die meisten Softtimer haben eine Weckzeit, die das Vielfache der Aufl¨osung ist. 2. Die Hauptschleife wird dadurch u ¨berfrachtet. Viele Aufgaben werden in der Hauptschleife bearbeitet. 3. Die L¨osung erfordert viele Wake-ups. Viele Komponenten im System sind nicht aktiv und schlafen. Durch den Tick-Event w¨ urden sie bei dieser L¨osung geweckt und unn¨ otige Arbeit verrichten, bevor sie wieder schlafen gehen. Ein Kontextwechsel ist zudem auch teuer. Eine andere L¨osung ist, bei jedem Tick ein Event in die Queue der betreffenden Komponente zu senden. Auch diese L¨ osung ist problematisch:

18.3 Komponentenarchitektur

305

1. Der Admin-Task darf in seinen Aktivit¨ aten nicht aufgehalten werden. Das bedeutet, das jedes Tick-Event sofort gesendet werden muss. Sollte die Queue voll sein, wird es verworfen. Es ist insofern nicht tragisch, weil die Softtimer nicht genau sein m¨ ussen. Problematisch ist der Aufwand f¨ ur die Versendung (genauer der Aufwand f¨ ur den Zugriff auf die Queue). 2. Der Admin-Task kann dadurch die Queue der Komponenten voll bombardieren, w¨ahrend die Komponente eine lange Aktivit¨at ausf¨ uhrt. Um die zweite L¨ osung zu verbessern, wird ein Flag mIsTickEventConsumed eingef¨ uhrt. Der Timer-Manager der Komponente kann durch L¨oschen dieses Flags unn¨otige Events vermeiden. Durch Setzen des Flags signalisiert der Timer-Manager, dass er bereit ist, ein neues Event zu bearbeiten.

Abbildung 18.6. Tickservice

void CComponentContext::handleTick(void) { // increment the tick count mContextHeaderPtr->mTickCounter++; // see whether the tick event should be sent if (true == mContextHeaderPtr->mIsTickEventConsumed) { // a tick event should be sent CMessage msg(CMessage::TICK_SERVICE_TYPE); // Note that the following logic is important

306

18 Komponentenarchitektur // we set the flag before sending because after the add-method // a thread switch can occur such that the // flag can be changed in the meanwhile ! It can cause the // timer manager stop working mContextHeaderPtr->mIsTickEventConsumed = false; if (false == mSystemQueuePtr->add(msg, false)) { // correction only if the message //is not successfully delivered mContextHeaderPtr->mIsTickEventConsumed = true; } }

} Listing 18-13. handleTick

Wichtig dabei ist, dass das Flag vor dem Abschicken des Events gel¨oscht wird. W¨ are es nicht so, k¨ onnte der Timer-Manager unter Umst¨anden keinen Tick mehr bekommen. Es w¨ are theoretisch m¨ oglich, dass ein Kontextwechsel direkt nach der add-Methode stattfindet. Der Timer-Manager der Komponente wird aktiviert, bearbeitet den Tick und setzt dabei das Flag, um die Bereitschaft f¨ ur einen neuen Tick anzuzeigen. Nun setzt der Admin-Task seine Ausf¨ uhrung fort. W¨ urde er das Flag erst jetzt l¨ oschen, w¨ are das Flag danach in einem inkonsistenten Zustand. Komponentenzust¨ ande Der Admin-Task oder die On/Off-Komponente k¨onnen einen Wechsel des Betriebszustands jeder Komponente direkt und am Event-System vorbei erzwingen. Daf¨ ur schreiben sie mit setRequestedState einen neuen Zustand in das Shared-Memory und setzen das Flag getRequestFlag. Anschließend wird die Komponente u ¨ber ein Semaphorsignal geweckt. Anders als bei Tick wird hierbei kein Event in die Queue gesendet, weil: 1. Das Event nicht verloren gehen darf. Es ist eine wichtige Information f¨ ur die Komponente, z.B. kann es die Aufforderung f¨ ur die Vorbereitung zum Runterfahren sein. 2. Der Admin-Task nicht durch den Zugriff auf die Queue angehalten und blockiert werden darf. Deshalb wird die folgende L¨ osung gew¨ ahlt: Die Komponente wird selbst versuchen, ein Event in ihre System-Queue zu schreiben. Es wird keine Direktbehandlung zugelassen, damit die Reihenfolge der System-Events noch garantiert bleibt.

18.3 Komponentenarchitektur

307

Abbildung 18.7. Mechanismus zum Auffordern eines Zustandswechsels

void AComponentBase::run(void) { // flag that indicate state change bool& checkFlag = mContext.getRequestFlag(); ... CMessage msg(CMessage::ADMIN_TYPE); //for sending admin-request while (mContext.getCurrentState() != CComponentContext::STOPPED) { ... if (true = = checkFlag) //check if change request pending { //use req.state for OpCode msg.setOpcode((Int32)(mContext.getRequestedState())); msg.setParam1(reinterpret_cast(this)); // nonblocking into Queue if (true == mContext.getSystemQueue().add(msg, false)) { checkFlag = false; //reset checkflag } } ... } }

308

18 Komponentenarchitektur

Zu beachten ist, dass das Flag nur gel¨ oscht wird, wenn eine Nachricht erfolgreich in die Systemqueue geschrieben wurde. Wenn w¨ahrenddessen ein neuer Zustand gefordert wird, kann der noch nicht gesendete Zustand u ¨berschrieben werden. 18.3.5 Komponenten-Dispatcher Wir haben in dem Kapitel Event-Verarbeitung die Prinzipien eines Dispatchers erl¨autert. Jede Komponente hat ihren eigenen lokalen Dispatcher mit einer eigenen Registry, der die drei Queues bedient. Zun¨achst betrachten wir die Basisklasse, die f¨ ur beide, Komponenten-Dispatcher und System-Dispatcher, Verwendung findet.

class CCommQueue; // forward declarations class CBinarySemaphore; class IMessageHandler; class CDispatcher // dispatcher gets messages from queues { // and deliver them public: CDispatcher( CCommQueue& normalQueue, // for normal commands CCommQueue& systemQueue, // for system commands CCommQueue& internalQueue, // for internal commands CBinarySemaphore& sem, // signal to block the dispatcher const bool& interruptFlag);// indicates wake up due to watchdog ~CDispatcher(); // add interest for certain message type. only one // listener is allowed void addListener(CMessage::MessageType theMsgType, IMessageHandler* theListenerPtr); // remove listening interest for certain channel void removeListener(CMessage::MessageType theMsgType); // get command from queue + dispatch it blocked as // long no event avaiable void dispatch(bool waitForever = true); private: CDispatcher(const CDispatcher& rhs); CDispatcher& operator=(const CDispatcher& rhs); protected: void handleMessage(); CBinarySemaphore& mSem; // used to block the dispatcher CCommQueue& mNormalQueue;

18.3 Komponentenarchitektur CCommQueue& mSystemQueue; CCommQueue& mInternalQueue; // needed to leave the dispatch method const bool& mIsInterruptedFlag; // to hold the current message CMessage mMessage; IMessageHandler* mListeners[CMessage::NUM_OF_TYPES]; }; // Array for storing the listeners ... void CDispatcher::dispatch(bool waitForever) { bool hasMessage = false; if (mInternalQueue.getSize() > 0) { mMessage = mInternalQueue.pop(); hasMessage = true; } // as long as the dispatcher is not interrupted it will // block if no message is available while ((false == hasMessage) && (false == mIsInterruptedFlag)) { // try to get an system command hasMessage = mSystemQueue.getMessage(mMessage); if (false == hasMessage) { hasMessage = mNormalQueue.getMessage(mMessage); } if (true == hasMessage) { // a command has been found break; } else if (false == waitForever) { return; } // at this point the dispatcher must wait for // a new message because both queues are empty. // mSem is only free if at least one queue is not empty // or if a signal is received the context must call // interruptDispatcher before mSem.take(); } if (true == hasMessage) { handleMessage(); }

309

310

18 Komponentenarchitektur

} // handle the message if any listener for it exists void CDispatcher::handleMessage() { // get the listener in the global context IMessageHandler *handlerPtr = mMessage.getMessageHandlerPtr(); if (NULLPTR != handlerPtr) { handlerPtr->handleMessage(mMessage); } else { CMessage::MessageType type = mMessage.getMessageType(); if (type != CMessage::DONT_CARE_TYPE) { handlerPtr = mListeners[type]; handlerPtr->handleMessage(mMessage); } } } Listing 18-14. Auszug aus der Klasse CDispatcher

Mit den Methoden addListener und removeListener k¨onnen Abonnenten innerhalb der eigenen Komponente in eine Liste mListener unter einem Message-Typ ein- oder ausgetragen werden. Es ist demnach nur ein Listener pro Event-Typ zul¨ assig. Als Listener werden Zeiger auf Message-Handler eingetragen, die ihrerseits dann f¨ ur die Weiterverarbeitung sorgen. Da dies innerhalb eines Prozesses geschieht, ist dieser Weg der einfachste. Mit der Methode dispatch erfolgt das eigentliche Verteilen der Nachricht. Sie wird gem¨ aß der Registrierung eines Handlers verteilt, wenn sie von außerhalb kommt. Bei einer internen Kommunikation ist der Handler in der Nachricht eingetragen. Hier sieht man die Bedeutungen des Flags mIsInterruptedFlag und des Semaphors mSem. Mit take wird die Komponente an dieser Stelle angehalten, falls es kein Event mehr zu verarbeiten gibt. Dennoch muss die Komponente ihre Schleife durchlaufen, um Tick-Event bzw. Watchdog zu bedienen (siehe die Implementierung der run-Methode vonAComponentBase unten). 18.3.6 Softtimer und Timer-Manager In unseren Anwendungen werden h¨ aufig viele Uhren ben¨otigt, die nicht sehr genau sein m¨ ussen. Z.B. kann man in ein Sound-Men¨ u wechseln, um Bass oder H¨ohen einzustellen, und es wird nach 8 Sekunden von selbst wieder zur¨ uck

18.3 Komponentenarchitektur

311

in das vorherige Hauptmen¨ u gesprungen. Dabei ist es unwesentlich, ob genau nach 8 Sekunden oder einige Hunderte Millisekunden sp¨ater der Wechsel stattfindet. F¨ ur die Kommunikations¨ uberwachungen werden ebenfalls Uhren eingesetzt. Um ein Timer-Objekt zu erhalten, muss das Objekt in der Komponente nur die Klasse CSoftTimer benutzen.

class CSoftTimer { public: // theListenerPtr pointer to the listener object // theDuration duration of the timer // theCookie given and used by the client to speed up // the handling // isCyclic specified whether it is a one shot timer // or a cyclic timer CSoftTimer(ITimerListener* theListenerPtr, Int32 theDuration, Int32 theCookie, bool isCyclic = true); ~CSoftTimer(); void start(void); void restart(void); void restart(Int32 theNewDuration); void stop(); Int32 getCookie(void) const; bool isActive(void) const; bool isCyclic(void) const; void setCyclic(bool isCyclic); private: // constant reserved for illegal timer number enum { ILLEGAL = -1}; // Note that only timer manager is allowed to modify some data // of the timer object friend class CTimerManager; ITimerListener* mListenerPtr; //the handler for timeout Int32 mDuration; //duration (stored as tick number) Int32 mCookie; //cookie used by the client bool mIsCyclic; //type of timer // used to store the timer number given by a timer manager. Int32 mNr; // used to store the time when the timer is expired Int32 mExpireTick; }; // end of CSoftTimer Listing 18-15. Klasse f¨ ur Softtimer

312

18 Komponentenarchitektur

Der Aufruf eines Softtimers in einer Applikation w¨are wie folgt zu bewerkstelligen: CSoftTimer mTimer(this, 1000, 0, true); mTimer.start();

In diesem Fall muss das Objekt selbst die Schnittstelle ITimerListener implementieren, die nur eine Methode hat: class ITimerListener { public: // callback method to inform that the desire timer is expired // theTimer softtimer object that is expired virtual void processTimeOut(CSoftTimer& theTimer) = 0; }; // end of interface ITimerListener

Im Konstruktor werden auch die Zeitdauer und ein Cookie mitgegeben. Dieses Cookie wird sp¨ater an das Objekt selbst zur¨ uckgegeben. Auf diese Art und Weise hat das Objekt die M¨ oglichkeit, seine Uhren zu unterscheiden und die richtige Reaktion zu starten. Speziell in der Men¨ usteuerung ist zu erwarten, dass einige Timer parallel gebraucht werden. Mit start wird die Uhr gestartet. Nach Ablauf der Zeit wird die Methode processTimeOut vom Framework aus aufgerufen. Das Objekt selbst kann seine Uhr stoppen (stop) oder mit der alten oder einer neuen Zeit neu starten (restart). Es wird auf jeden Fall garantiert, dass das Objekt kein Ereignis bekommt, wenn die Uhr gestoppt wurde. Ein CSoftTimer hat intern verschiedene Daten, die nur f¨ ur den Timer-Manager relevant sind. Alle wichtigen Methoden von Softtimer werden mit Hilfe des so genannten Komponentenservices abgewickelt, den wir sp¨ ater beschreiben werden. Die Softtimer werden von einem Timermanger in der Komponente verwaltet. Der Timer-Manager ist auch der Empf¨ anger von Tick-Events.

class CTimerManager : public IMessageHandler { private: // CComponentBase-type objects can create and destroy // a timer manager friend class AComponentBase; // CComponentServices can start, restart and stop a timer friend class CComponentServices; // startCapacity create timer manager with start capacity // clockCounter current clock of the component // isConsumed flag such that the timer manager

18.3 Komponentenarchitektur

313

// can indicate if last tick is consumed. (see section about // tick-service CTimerManager(Int32 startCapacity, const Int32& clockCounter, bool& isConsumed); virtual ~CTimerManager(); // to start, restart and stop timers void startTimer(CSoftTimer& theTimer); void restartTimer(CSoftTimer& theTimer); void stopTimer(CSoftTimer& theTimer); // called on receiving the tick event virtual void handleMessage(const CMessage& msg); private: const Int32& mClockCounter; // reference to the current clock bool& mIsConsumed; // ref. to flag to enable tick event Int32 mNumOfTimers; // current number of timer VoidPtrVector mTimerList; // list of internal timers CMessage mMessage; // used to send event }; Listing 18-16. Timer-Manager , CTimerManager.h

Betrachten wir zun¨ achst die Timer-Liste vom Typ VoidPtrVector. Sie wird im Konstruktor des Timer-Managers mit einer Startkapazit¨at als Parameter angelegt. Sie kann falls n¨ otig wachsen. Dies widerspricht zwar den selbst aufgestellten Regeln, keine Vektoren zu verwenden, da der Timer-Manager jedoch mit seiner Komponente zum Start-Up des Systems erzeugt wird, ist das m¨ogliche dynamische Verhalten unkritisch und messbar. CTimerManager::CTimerManager(Int32 theStartCapacity, const Int32& theClockCounter, bool& isConsumed) : mClockCounter(theClockCounter), mIsConsumed(isConsumed), mNumOfTimers(0), mTimerList(theStartCapacity,1), mMessage() { // for safety we reset the flag mIsConsumed = false; // fill the vector with NULLPTR for (Int32 i = 0; i < theStartCapacity; i++) { mTimerList.add( NULLPTR); } mMessage.setMessageHandlerPtr(CTimeOutHandler::getInstancePtr()); } // end of constructor

314

18 Komponentenarchitektur

Es wird ein Singleton-Objekt als Hilfsobjekt verwendet, das als Handler eingetragen wird. Das Objekt versteht das Format der Timer-Events und kann die richtige Methode des Listeners (Zuh¨ orers) aufrufen. class CTimeOutHandler : public IMessageHandler { public: static CTimeOutHandler* getInstancePtr() { return &sInstance; } // virtual to avoid warning virtual ~CTimeOutHandler() { } virtual void handleMessage(const CMessage& msg) { ITimerListener* listenerPtr = reinterpret_cast (msg.getParam(0)); CSoftTimer* timerPtr = reinterpret_cast (msg.getParam(1)); listenerPtr->processTimeOut(*timerPtr); } private: static CTimeOutHandler sInstance; }; // end of CTimeOutHandler // declaration of the static variable CTimeOutHandler CTimeOutHandler::sInstance;

Soll ein neuer Timer eingetragen werden, wird ein freier Platz gesucht und die Adresse des Timers eingetragen. Im Timer-Objekt selbst wird dann die Position in der Liste und die Ablaufzeit gespeichert. Handelt es sich um den ersten eingetragenen Timer, registriert sich der Timer-Manager bei der Komponentenverwaltung f¨ ur Tick-Events. Ferner wird ein Flag gesetzt, so dass der Admin-Task Tick-Events senden darf. void CTimerManager::startTimer(CSoftTimer& theTimer) { // if the timer is active it is restarted if ( true == theTimer.isActive()) { restartTimer(theTimer); return; } // else we must find a free slot in the list Int32 pos; Int32 length = mTimerList.getSize(); if (mNumOfTimers == length) { // no more space - add it at the end

18.3 Komponentenarchitektur

315

mTimerList.add(&theTimer); // remember the position pos = length; } else { // search for a free object for (pos = 0; pos < length; pos++) { if (NULLPTR == mTimerList[pos]) { // found, leave the loop break; } } } mNumOfTimers++; // register the tick event if the timer is the first one // we do it by enable the tick again if (1 == mNumOfTimers) { CComponentServices::addListener(CMessage::TICK_SERVICE_TYPE, this); // enable the event - the Admin-task can send a tick-event mIsConsumed = true; } mTimerList[pos] = &theTimer;

}

// store the position into the timer object theTimer.mNr = pos; // store the expire theTimer.mExpireTick = mClockCounter + theTimer.mDuration; // end of startTimer

Mit der abgespeicherten Position in dem Softtimer-Objekt ist es sp¨ater einfach, es neu zu starten. void CTimerManager::restartTimer(CSoftTimer& theTimer) { // check whether the timer is valid, if not we start it if (false == theTimer.isActive()) { startTimer(theTimer); } else { // calculate the new expire tick theTimer.mExpireTick = mClockCounter + theTimer.mDuration; } } // end of restart

316

18 Komponentenarchitektur

Stoppen eines Timers kann auch dazu f¨ uhren, dass sich der Timer-Manager bei der Komponentenverwaltung abmeldet: void CTimerManager::stopTimer(CSoftTimer& theTimer) { if ( (false == theTimer.isActive()) ) { return; } // remove the timer from the list Int32 tmrNr = theTimer.mNr; mTimerList[tmrNr] = NULLPTR; mNumOfTimers--; // and correct the attribut of theTimer theTimer.mNr = CSoftTimer::ILLEGAL;

}

// remove the interest if we do not have any timers running if (0 == mNumOfTimers) { CComponentServices::removeListener(CMessage::TICK_SERVICE_TYPE); // disable the tick - no tick will be sent to the component mIsConsumed = false; } // end of stopTimer

Nachdem der Dispatcher einen Tick-Event aus der externen Queue entnommen hat, u uft er, ob es einen Handler daf¨ ur gibt und ruft ggf. die ¨berpr¨ handleMessage-Methode des Handlers auf. Im Fall des Timer-Managers ist die Implementierung der Methode wie folgt: void CTimerManager::handleMessage(const CMessage& msg) { // signal that the timer manager consumes the tick mIsConsumed = true; // get the current tick Int32 currentTick = mClockCounter; Int32 size = mTimerList.getSize(); // go through the list and inform the objects about the current tick for (Int32 i = 0; i < size; ++i) { if (NULLPTR == mTimerList[i]) { continue; } CSoftTimer* objPtr = reinterpret_cast (mTimerList[i]); // check whether the time is expired. If yes we must do some work if (objPtr->mExpireTick <= currentTick) {

18.3 Komponentenarchitektur

317

// to avoid problem we set the new tick if needed if (false == objPtr->mIsCyclic) { stopTimer(*objPtr); } else { objPtr->mExpireTick = mClockCounter + objPtr->mDuration; } mMessage.setParam(0, reinterpret_cast(objPtr->mListenerPtr)); mMessage.setParam(1, reinterpret_cast(objPtr)); CComponentServices::addIntMessage(mMessage);

}

} } // end of handleMessage

F¨ ur jede abgelaufene Uhr wird ein Event in die interne Queue geschrieben. Die gew¨ahlte Zeit ist ja in den Softtimer-Objekten abgespeichert und wird mit der aktuellen Uhrzeit verglichen. Der Handler des Events ist das Singleton CTimeOutHandler, das in einem sp¨ ateren Schritt vom Dispatcher direkt invokiert wird und daraufhin die processTimeOut-Methode der Objekte aufruft. Mit diesem Konzept ist es demnach f¨ ur die Applikationsprogrammierer nur wichtig, die Klasse CSoftTimer mit einigen Methoden zu kennen.

Abbildung 18.8. Empfang eines Tick-Events, Timer-Manager und -Client

318

18 Komponentenarchitektur

18.3.7 Registrierung Unsere Architektur benutzt ausgiebig das Muster Publisher/Subscriber, das ¨ auch Observer/Listener-Konzept genannt wird. Aufgrund einer Anderung wird ein Event generiert und an den Zuh¨ orer gesendet. Der Zuh¨orer kann dann die notwendigen Schritte ausf¨ uhren. F¨ ur Objekte einer Komponente ist es einfacher, die Registrierung zentral zu organisieren. Auch Objekte außerhalb der Komponente k¨ onnen sich f¨ ur einen bestimmten Informationstyp registrieren. Alle Registrierungen werden in eine zentrale Liste der Kompo¨ nente eingetragen. Andert sich eine Property“ (Datum mit registriertem ” Zuh¨orer), kann das zust¨ andige Objekt einfach u ¨ber den Komponentenservice eine informDataChange-Methode aufrufen, die dann die richtige Nachricht zusammenbauen und an den Zuh¨ orer senden kann. Da die Implementierung nicht schwierig ist, verzichten wir auf eine vollst¨andige Erl¨auterung.

// inform the listeners about the data changed // theInfoType type of data changed // block if true the server must wait until the message is delivered // urgent if true the message will be written into the system queue // else it is written into the normal queue void CObserverRegistry:: informDataChange(Int32 theInfoType, bool block, bool urgent) { CMessage msg(CMessage::UPDATE_TYPE); msg.setOpcode(IUpdateListener::UPDATE_ONE_PARAM); send(theInfoType, msg, block, urgent); } // inform the listeners about the data changed // theInfoType type of data changed // theIndex index of the data (can be any short information // like frequency, track time etc) // block if true the server must wait until the message is delivered // urgent if true the message will be written into the system queue // else it is written into the normal queue void CObserverRegistry::informDataChange(Int32 theInfoType, Int32 theIndex, bool block, bool urgent) { CMessage msg(CMessage::UPDATE_TYPE); msg.setOpcode(IUpdateListener::UPDATE_TWO_PARAM); msg.setParam(1, theIndex); send(theInfoType, msg, block, urgent); } void CObserverRegistry::send(Int32 theInfoType, CMessage& msg,

18.3 Komponentenarchitektur

319

bool block, bool urgent) { Int32 size = mListeners.getSize(); for (Int32 i = 0; i < size; i++) { Registry& r = mListeners[i]; if (r.mInfoType == theInfoType) { msg.setParam(0, r.mCookie); if (false == urgent) { ((r.mContextPtr)->getNormalQueue()).add(msg, block); } else { ((r.mContextPtr)->getSystemQueue()).add(msg, block); } } } } Listing 18-17. Auszug aus CObserverRegistry.cpp

18.3.8 Die Basisklasse AComponentBase und das Zusammenspiel mit der Umgebung Zum Abschluss des Kapitels betrachten wir die Basisklasse AComponentBase sowie die Klasse CComponentService, die das Laufzeitsystem realisieren. Komponentendienste In einer Komponente gibt es normalerweise mehrere Objekte wie Dispatcher, Timer-Manager und Registry, die Dienstleistungen f¨ ur andere zur Verf¨ ugung stellen. Um an diese Objekte heranzukommen, k¨onnte man u ¨ber globale Variablen gehen. Diese L¨ osung funktioniert nur, wenn die Komponente die einzige im Prozess ist. Eine andere L¨ osung ist die Weitergabe einer Referenz auf die Komponente. Die Dienste werden von den Anwendern direkt zugriffen. Diese L¨osung bedeutet einen großen Overhead, da viele Objekte die Dienste ben¨otigen. Eine weitere L¨ osung ist die Verwendung der Thread-spezifischenDaten (TSD). Das Konzept von TSD wurde im Kapitel 8 beschrieben. Sie werden direkt vom OS unterst¨ utzt. Die TSD zu einer Komponente werden in der Klasse CComponentServices gekapselt. Objekte brauchen zum Erhalt der ¨ gew¨ unschten Dienste nur normale Funktionsaufrufe zu verwenden. Uber TSD kann dann das passende Objekt der Komponente bestimmt und aufgerufen werden. Die Schnittstelle von CComponentServices ist:

320

18 Komponentenarchitektur

class class class class class class

IMessageHandler; CTimerManager; CDispatcher; CMessage; CComponentContext; CObserverRegistry;

// forward declarations

class CComponentServices { public: // add and remove listener static void addListener(CMessage::MessageType theMsgType, IMessageHandler* theListenerPtr); static void removeListener(CMessage::MessageType theMsgType); // access to the context in which object running static CComponentContext* getComponentContextPtr(void); static CObserverRegistry* getObserverRegistryPtr(void); private: // CSoftTimer can use the timer manager friend class CSoftTimer; static void startTimer(CSoftTimer& theTimer); static void restartTimer(CSoftTimer& theTimer); static void stopTimer(CSoftTimer& theTimer); // allow class AComponentBase to register thread local data friend class AComponentBase; // different registries static void registry(CTimerManager* theTimerManagerPtr); static void registry(CDispatcher* theDispatcherPtr); static void registry(CComponentContext* theComponentContextPtr); static void registry(CObserverRegistry* theObserverRegistryPtr); static void unregistry(CTimerManager* theTimerManagerPtr); static void unregistry(CDispatcher* theDispatcherPtr); static void unregistry(CComponentContext* theComponentContextPtr); static void unregistry(CObserverRegistry* theObserverRegistryPtr); // method called once to initialize all keys static void initKeys(void); static pthread_key_t sTimerManagerKey; static pthread_key_t sDispatcherKey;

18.3 Komponentenarchitektur

321

static pthread_key_t sContextKey; static pthread_key_t sObserverKey; static pthread_once_t sInit; }; Listing 18-18. Headerfile der Klasse CComponentContext

In der Klasse werden vier Keys verwaltet. Die assozierten Daten sind der Timermanger, der Dispatcher, der Kontext und die Liste der Observer. Um diese Keys nur einmal anzulegen, wird pthread once t verwendet. Die Zugriffe auf die Dienste sind u ¨ber definierte Funktionen zu erledigen. Die Implementierung dazu ist im Folgenden zu finden:

pthread_key_t CComponentServices::sTimerManagerKey; pthread_key_t CComponentServices::sDispatcherKey; pthread_key_t CComponentServices::sContextKey; pthread_key_t CComponentServices::sObserverKey; // used to ensure init- methodis called only once pthread_once_t CComponentServices::sInit = PTHREAD_ONCE_INIT; void CComponentServices::initKeys(void) { pthread_key_create(&CComponentServices::sTimerManagerKey, NULLPTR); pthread_key_create(&CComponentServices::sDispatcherKey, NULLPTR); pthread_key_create(&CComponentServices::sContextKey, NULLPTR); pthread_key_create(&CComponentServices::sObserverKey, NULLPTR); } void CComponentServices::registry(CTimerManager* theTimerManagerPtr) { pthread_once(&sInit, initKeys); pthread_setspecific(sTimerManagerKey, theTimerManagerPtr); } void CComponentServices::registry(CDispatcher* theDispatcherPtr) { pthread_once(&sInit, initKeys); pthread_setspecific(sDispatcherKey, theDispatcherPtr); } void CComponentServices::registry(CComponentContext* theContextPtr) { pthread_once(&sInit, initKeys); pthread_setspecific(sContextKey, theContextPtr); }

322

18 Komponentenarchitektur

void CComponentServices::registry(CObserverRegistry* theListPtr) { pthread_once(&sInit, initKeys); pthread_setspecific(sObserverKey, theListPtr); } void CComponentServices::unregistry(CTimerManager* /*timerManPtr*/) { pthread_setspecific(sTimerManagerKey, NULLPTR); } void CComponentServices::unregistry(CDispatcher* /*dispatcherPtr*/) { pthread_setspecific(sDispatcherKey, NULLPTR); } void CComponentServices::unregistry(CComponentContext* /*contextPtr*/) { pthread_setspecific(sContextKey, NULLPTR); } void CComponentServices::unregistry(CObserverRegistry* /*listPtr*/) { pthread_setspecific(sObserverKey, NULLPTR); } #define DISPATCHER_PTR (reinterpret_cast \ (pthread_getspecific(CComponentServices::sDispatcherKey))) #define TIMER_MANAGER_PTR (reinterpret_cast \ (pthread_getspecific(CComponentServices::sTimerManagerKey))) void CComponentServices::addListener(CMessage::MessageType theMsgType, IMessageHandler* theListenerPtr) { CDispatcher *dispatcherPtr = DISPATCHER_PTR; ASSERTION(NULLPTR != dispatcherPtr && CMessage::DONT_CARE_TYPE != theMsgType); dispatcherPtr->addListener(theMsgType, theListenerPtr); } void CComponentServices::removeListener (CMessage::MessageType theMsgType) { CDispatcher *dispatcherPtr = DISPATCHER_PTR; ASSERTION(NULLPTR != dispatcherPtr && CMessage::DONT_CARE_TYPE != theMsgType); dispatcherPtr->removeListener(theMsgType); }

18.3 Komponentenarchitektur

323

CComponentContext* CComponentServices::getComponentContextPtr(void) { return (reinterpret_cast (pthread_getspecific(CComponentServices::sContextKey))); } CObserverRegistry* CComponentServices::getObserverRegistryPtr(void) { return (reinterpret_cast (pthread_getspecific(CComponentServices::sObserverKey))); } void CComponentServices::startTimer(CSoftTimer& theTimer) { CTimerManager *tmPtr = TIMER_MANAGER_PTR; ASSERTION(NULLPTR != tmPtr); tmPtr->startTimer(theTimer); } void CComponentServices::restartTimer(CSoftTimer& theTimer) { CTimerManager *tmPtr = TIMER_MANAGER_PTR; ASSERTION(NULLPTR != tmPtr); tmPtr->restartTimer(theTimer); } void CComponentServices::stopTimer(CSoftTimer& theTimer) { CTimerManager *tmPtr = TIMER_MANAGER_PTR; ASSERTION(NULLPTR != tmPtr); tmPtr->stopTimer(theTimer); } Listing 18-19. Komponentenservice-Klasse, CComponentServices.cpp

Basisklasse der Komponente AComponentBase Nun betrachten wir die Methoden der Klasse AComponentBase genauer. Diese abstrakte Klasse implementiert nur teilweise die Schnittstelle IRunnable. Folgende Methoden sind konkretisiert: init, run und cleanup. Die init-Methode Die init-Methode wird aufgerufen, nachdem ein Thread f¨ ur die Komponente konstruiert wurde. Sie l¨ auft garantiert in dem Kontext der Komponente und bietet den Einstiegspunkt f¨ ur die Registrierungen an.

324

18 Komponentenarchitektur

void AComponentBase::init(void) { // registry for the timer manager, dispatcher and admin CComponentServices::registry(&mDispatcher); CComponentServices::registry(&mTimerManager); CComponentServices::registry(&mContext); CComponentServices::registry(&mObserverRegistry); CComponentServices::addListener(CMessage::ADMIN_TYPE, CSystemEventHandler::getInstancePtr()); // signal that the component is initialized mContext.setCurrentState(CComponentContext::INITIALIZED); } Listing 18-20. init-Methode, Klasse AComponentBase

Ein Singleton der Klasse CSystemEventHandler wird dabei verwendet, um die Request-Nachrichten in die entsprechende Methode der Komponente umzuwandeln. Dies ist sinnvoll, da die Schnittstelle f¨ ur die System-Events f¨ ur alle Komponenten gleich ist. Im Moment sind m¨ ogliche System-Events die Befehle RUN REQUEST, STANDBY REQUEST, PREPARE FOR SHUTDOWN und STOP REQUEST. StandBy ist der Zustand eines Systems, wenn es ausgeschaltet erscheinen soll, das Fahrzeug aber l¨ auft. Das Display ist zwar dunkel und die Verst¨arker sind gemutet, es ist jedoch ein Schnellstart m¨oglich, und auch die Navigation f¨ uhrt im StandBy ihre Positionsmitf¨ uhrung weiterhin durch. Der Zustand Prepare-for-Shutdown ist z.B. f¨ ur das Telefon n¨otig oder f¨ ur die Navigation, es muss erst noch das Gespr¨ ach beendet und ggf. einige Daten weggespeichert werden, bevor das Ger¨ at ganz ausschalten darf.

CSystemEventHandler: public IMessageHandler { public: static CSystemEventHandler* getInstancePtr() { return &sInstance; } virtual ~CSystemEventHandler() { } virtual void handleMessage(const CMessage& msg) { // first parameter contains the pointer to the component // see the sending mechanism below AComponentBase* componentPtr =

18.3 Komponentenarchitektur

325

reinterpret_cast(msg.getParam(0)); // call the right method depending on the op code switch (msg.getOpcode()) { case CComponentContext::RUN_REQUEST: componentPtr->reRun(); break; case CComponentContext::STANDBY_REQUEST: componentPtr->goToStandby(); break; case CComponentContext::PREPARE_FOR_SHUTDOWN: componentPtr->prepareForShutdown(); break; case CComponentContext::STOP_REQUEST: componentPtr->stop(); break; default: ASSERTION(false); break; } } private: // singleton static CSystemEventHandler sInstance; }; Listing 18-21. Hilfsklasse CSystemEventHandler

Die cleanup-Methode In der cleanup-Methode werden nur die Listeners und die assozierten Objekte gel¨oscht.

void AComponentBase::cleanup(void) { // remove all listeners CComponentServices::removeListener(CMessage::ADMIN_TYPE); CComponentServices::unregistry(&mDispatcher); CComponentServices::unregistry(&mTimerManager); CComponentServices::unregistry(&mContext); CComponentServices::unregistry(&mObserverRegistry); } Listing 18-22. cleanup-Methode, Klasse AComponentBase

Die run-Methode Die run-Methode wurde in den vorgangenen Abschnitten mehrfach angedeutet. Sie ist die Hauptschleife der Komponente. Ihre Aktivit¨aten sind:

326

18 Komponentenarchitektur

1. Den Watchdog zu bedienen, 2. System-Signale zu u ufen und sie ggf. in System-Events umzuwandeln ¨berpr¨ und 3. Events zu verteilen.

void AComponentBase::run(void) { // flag that indicate state change bool& checkFlag = mContext.getRequestFlag(); // flag indicate that an interrupt has occured (due to the watchdog) bool& interruptFlag = mContext.getInterruptFlag(); // signal that the component is now running mContext.setCurrentState(CComponentContext::RUNNING); // message for sending the admin-request CMessage msg(CMessage::ADMIN_TYPE); // as while { // if {

long the state is not STOPPED (mContext.getCurrentState() != CComponentContext::STOPPED) clear the interrupt flag (true == interruptFlag)

interruptFlag = false; } // reset the watchdog counter mContext.resetCheckCounter(); // check whether a state change request is pending if (true == checkFlag) { msg.setOpcode((Int32)(mContext.getRequestedState())); msg.setParam(0, reinterpret_cast(this)); if (true == mContext.getSystemQueue().add(msg, false)) { checkFlag = false; } } mDispatcher.dispatch(); } } Listing 18-23. run-Methode, Klasse AComponentBase

In der Anwendung soll eine konkrete Komponente von der abstrakten Klasse AComponentBase erben und die fehlenden Methoden der Schnittstelle IRunnable implementieren. Objekte, die auf externe Events warten und sie

18.4 Zusammenfassung

327

bearbeiten, werden in der Initialisierungsphase in der u ¨berschriebenen initMethode registriert .

18.4 Zusammenfassung Fassen wir unser Verst¨ andnis von einer Komponente noch einmal zusammen. Unsere Komponente ist eine Einheit mit definierten Aufgaben, vorgefertigtem Kontext mit drei Queues im Shared Memory, einem Watchdog-Z¨ahler, einem Timer-Client und einigen bestimmten vorgeschriebenen Objekten und Methoden. Im vom Komponenten-Dispatcher aufgerufenen Message-Handler wird die eigentliche Applikationslogik implementiert. Es gibt eine Tuner-Komponente, eine Navi-Komponente, eine oder mehrere CD-Komponenten und viele mehr. Diese logDev-Komponenten bilden Modelle zur Bedienung der externen physikalischen Ger¨ate. In einer solchen Komponente findet sich, wenn sie das logische Modell (logDev) einer physikalischen Komponente im Netzwerk darstellt, ein Controller, der das Ger¨ateverhalten abbildet. Weiterhin gibt es einen MOST-Codec, der das MOSTProtokollwissen kapselt. Ein interner Komponenten-Dispatcher fragt die interne, externe und die System-Queue nach neuen Events ab und verteilt sie entsprechend der Registrierung in der Komponente. Umgekehrt sendet er oder der MOST-Codec Events an den System-Dispatcher zur Weiterverteilung. Weitere Komponenten sind die HMI-Komponente, der System-Dispatcher und eine Debug-Komponente. Es gibt aber auch interne physikalische Devices, ein Beispiel daf¨ ur ist das interne CD-Laufwerk. Auch hierf¨ ur k¨ onnen wir den Komponentenrahmen verwenden, auch wenn wir nicht alle Methoden und Queues nutzen werden, die bereitgestellt sind. Es gilt der folgende Komponentenrahmen: • Eine Komponente l¨ auft in der Standard-Konfiguration im main-Thread eines Prozesses, kann aber auch als einfacher Thread konfiguriert werden. • Eine Komponente hat einige Standardmethoden (IRunnable). • Eine Komponente hat einen einheitlichen Kontext (CComponentContext). • Jede Komponente hat einen internen eigenen Event-Dispatcher. • Eine Komponente kommuniziert mit anderen Komponenten u ¨ber Kon” trollnachrichten“, unseren Events (CMessage). • In jeder Komponente laufen im Hintergrund Clients f¨ ur Watchdog, Timer und Diagnose1 . • Jeder Komponente sind 3 Queues zugeordnet: 1

Jede Komponente besitzt einen eigenen Tick-Z¨ ahler (Timercounter), auch wenn in der Regel die Z¨ ahler aller Komponenten den gleichen Stand haben. Auf diese Art sind die Komponenten voneinander unabh¨ angig.

328

18 Komponentenarchitektur

Abbildung 18.9. Beispiel einer Komponente (logisches Tuner-Device)

¨ 1. Uber die interne Queue kann sich die Komponente z.B. zwischen Modell und Proxy selbst Events schicken. ¨ 2. Uber die externe Queue bekommt sie Events von MOST oder von anderen Komponenten. ¨ 3. Uber die System-Queue bekommt sie hoch-priorisierte Events wie off/on, Diagnose etc. • Die Queues sind im Shared-Memory angelegt (CComponentContext). • Ihre Daten bekommt die Komponente in der Regel u ¨ber MOST-Events oder interne Events a hnlichen Formats. ¨ • Damit gibt es im System keine Datenduplikation. • In einer Modell-Komponente sind Controller und MOST-Codec implementiert. Sie existieren immer, auch wenn das Ger¨at momentan nicht verf¨ ugbar ist. • Eine Sonderrolle spielt die HMI-Komponente. Sie bekommt ihre Daten u ¨ber den Ist-Datencontainer der HMI. Eine Komponente (LogDev)

18.4 Zusammenfassung

• • • • •

329

schreibt diese Ist-Daten nach der Dekodierung in den Ist-Datencontainer (MOST) der HMI-Komponente im Shared-Memory. Kommen jedoch von den Komponenten einfache Kommandos, werden sie wie u ¨blich per Event an die HMI gesendet (update, keys, MOST-Kommandos). Soll-Daten, wie neue Spur oder ver¨ anderte Lautst¨arke, gehen von der HMIKomponente u ¨ber den Soll-Datencontainer zu den Ger¨ate-Komponenten. Die main startet das System, legt die Shared-Memory-Bereiche an, forkt die Komponenten und startet sie. Der Admin-Task betreibt die System¨ uberwachung mit einem WatchdogServer und einem System-Tick-Server. Eine Main-Dispatcher-Komponente nimmt alle Events von dem MOSTTreiber, ggf. dem CAN-Treiber und dem Keyboard-Treiber an und versendet sie entsprechend. In umgekehrter Richtung versendet der Main-Dispatcher MOST-Events nach außen.

Fassen wir auch den Komponenten-Kontext zusammen: Die wesentlichen Methoden, die der Kontext f¨ ur jede Komponente zur Verf¨ ugung stellen muss, sind: • • • •

Zugriff auf den Namen der Komponente, Zugriff auf die ID der Komponente, Zugriff auf die Triggervariable, Zugriffe auf die System-Queue, die externe Queue und auf die interne Queue, • Watchdog-Methoden, • Signalisierung eines angeforderten Zustandswechsels und Setzen eines Zustands. Kontext-Header und Queues werden in einem gemeinsamen Speicher abgelegt. Das bedeutet in einer Multithread-Umgebung die Speicherung in normalem Speicher, da er ja von allen Threads zugreifbar ist. In einer MultiprozessUmgebung m¨ ussen die Informationen im Shared-Memory gespeichert werden. Der Code zum Anlegen der Komponentenkontexte wird automatisch generiert. Wichtig in unserem Konzept ist, dass in MultiProzess-Umgebungen die Kontexte und alle Adressen durch fork-Aufruf geerbt werden. Die Adressen der Kontext-Header und Queues sind in allen Prozessen verf¨ ugbar und identisch. Damit muss die Architektur hier nicht zwischen Prozess- und TaskImplementierung unterscheiden.

19 Main-Dispatcher-Komponente

Wir wiederholen kurz die Aufgabe des System-Dispatchers: Der System-Dispatcher empf¨ angt aus drei Quellen Events, die in zwei m¨ oglichen Formaten vorliegen k¨ onnen und in der Headunit verteilt werden m¨ ussen. Alle Events werden in der gemeinsamen externen Queue der Komponente aufgefangen. 1. MOST-Events von außen werden durch einen separaten Thread blockierend aus dem MOST-Treiber gelesen und in die externe Queue des Dispatchers geschrieben. 2. Daten des Tastaturtreibers werden ebenfalls durch einen separaten Thread gelesen und in die Queue des System-Dispatchers gesendet. 3. Events zur internen Kommunikation k¨ onnen auch u ¨ber den Dispatcher laufen. Der Main-Thread der Dispatcher-Komponente liest blockierend diese Queues und schreibt die Events entweder in die Queue einer internen Komponente oder in den MOST-Treiber nach außen. Der Main-Dispatcher ist, wenn alle internen Kommunikationen u ¨ber ihn laufen, mit seiner normalen Queue der einzige Konsument im Framework, der mehrere Produzenten parallel erwarten muss. Seine Queue-Implementierung muss dies ber¨ ucksichtigen. Um nicht zur Engstelle des ganzen Systems zu werden, muss er sehr effizient implementiert werden.

19.1 Dispatcher-Receiver Im Main-Dispatcher gibt es einen abgespaltenen Thread, der MOST-Pakete vom MOST-Treiber abholt. Er ist als separater Thread implementiert, da er blockierend liest. Bekommt er MOST-Nachrichten, so legt er sie in die externe Queue des Dispatchers.

332

19 Main-Dispatcher-Komponente

Abbildung 19.1. Main-Dispatcher-Komponente

Eine regul¨are Architektur w¨ are ein eigener Adapter zwischen MOSTTreiber und Main-Dispatcher, in dem zwei Threads laufen. Der TransmitterThread empf¨angt in einer Eingangs-Queue MOST-Events vom Main-Dispatcher und schreibt sie blockierend in den MOST-Treiber (POSIX-API). Der Receiver-Thread liest blockierend Events aus dem MOST-Treiber und schreibt sie in die Eingangs-Queue des Main-Dispatchers. Er w¨are im Wesentlichen identisch zu der unten stehenden Beschreibung und kann leicht umgesetzt werden. Hat man den Treiber selbst in der Hand, k¨onnte der Adapter mit dem Treiber zur Vereinfachung kombiniert werden. Man kann die Nachrichten auch direkt in die Queues der Komponenten schreiben, dann verliert man jedoch die Zeitrichtigkeit der Events und die M¨ oglichkeit des zentralen Debuggings. Mit dem jetzigen Konzept passieren alle externen Events des Systems die System-Queue des Dispatchers, den man mit einer Socket-Verbindung zu einem externen Rechner gut zum Aufzeichnen und Wiedereinspielen von Events verwenden kann. Der Receiver-Thread wird in der run-Methode des System-Dispatchers gestartet. Man beachte, dass er lokal statisch definiert ist, so dass der notwendige Speicher im Datensegment angelegt wird.

19.1 Dispatcher-Receiver

333

Abbildung 19.2. MOST-Adapter

void CMostdispatcherComponent::run(void) //start Most receiver thread { static CMostdispatcherReceiver receiver (*this, mMostHandle); static CThread threadReceiver(receiver, "MostdispatcherReceiver", 1000, CThread::PRIORITY_NORM); threadReceiver.start(); sOwnCout() << "Component Mostdispatcher has started" << endl; AComponentBase::run(); ... } Listing 19-1. Start des MostDispatcher Receiver-Threads

Der Typ MostHandle ist im (in C implementierten) Treiber selbst als Zeiger auf eine Struktur wie folgt definiert:

334

19 Main-Dispatcher-Komponente

typedef struct { const char *mostDevice; int fd; const char *targetIP; int targetPort; MOSTPool *pool; void *userData; struct MostHandlePD_S *x; } MostHandle_ *MostHandle;

//Handle to the MOST low-level driver. //device name of MOST driver //file descriptor of MOST driver //only for winmost! //only for winmost! //Shared-Memory pool //may be specified by the user //private data for mostutils

Listing 19-2. Zeiger auf Struktur MostHandle

Der Prototyp der Klasse:

//CMostdispatcherReceiver reads Most Pakets from driver //It reads CMessages containing Most messages, //and enqueues them to the MostDispatcher queue class CMostdispatcherReceiver: public IRunnable { public: CMostdispatcherReceiver(CMostdispatcherComponent& aMostdispatcher, MostHandle& aMostHandle); virtual ~CMostdispatcherReceiver() { }; virtual void init(void) { mStop = false; }; virtual void run(void); virtual void stop(void); virtual void cleanup(void) { }; virtual void prepareForShutdown(void) { }; virtual void reRun() { }; virtual void goToStandby() { }; private: CMostdispatcherComponent& mMostdispatcher; bool mStop; MostHandle mMostHandle; }; CMostdispatcherReceiver::CMostdispatcherReceiver ( CMostdispatcherComponent& theComponent, MostHandle& theMostHandle ) :mMostdispatcher(theComponent), mStop(false),

19.1 Dispatcher-Receiver

335

mMostHandle(theMostHandle) { } void CMostdispatcherReceiver::run(void) { while (!mStop) { int ret = 0; //gets filled by most driver CMessage msg(CMessage::DONT_CARE_TYPE); //map to most driver struct MostMsgUnion * msgPtr = (MostMsgUnion *) msg.getMostContentPtr(); ret = MostUMsgReceive( mMostHandle, msgPtr ); if (ret == EOK) { mMostdispatcher.mContext.getNormalQueue().add(msg); } else { sOwnCout() << "Error reading MOST message. " << "Stop receiver thread." << endl; mStop = true; } } } void CMostdispatcherReceiver::stop() { mStop = true; //thread does only stop, if a MOST message // is received after mStop is set to true, because } //MostUMsgReceive() is a blocking function

Listing 19-3. MOST-Empf¨ anger-Klasse CMostdispatcherReceiver

Hier wurde der Nachrichtentyp CMessage und pMostMsgUnion verwendet, um die MOST-Nachricht aus dem Treiber abzuholen. Der MostMsgPtr aus der CMessage-Klasse wird zum pMostMsgUnion umgecastet, damit der Treiber die Message nach seinem Format f¨ ullen kann. Mit der Dispatcher-Methode forwardMessageInternal wird die Nachricht anschließend an die normale Queue des Dispatchers weitergegeben. Diese Methode wird hier nicht n¨ aher erl¨ autert.

336

19 Main-Dispatcher-Komponente

19.2 Dispatcher-Main-Thread Studieren wir nun die Implementierung der Dispatcher-Komponente. In der ersten Phase (init-Methode) wird versucht, die Verbindung mit dem MOSTTreiber herzustellen. Danach registriert die Komponente sich selbst als Handler f¨ ur verschiedene Events.

void CMostdispatcherComponent::init(void) { AComponentBase::init(); mMostHandle = MostNewHandle(); //Open most driver //Set device name for direct access to MOST driver mMostHandle->mostPrefix = mostPrefix; if ( MOSTERR_OK != MostConnect( mMostHandle ) ) { //todo: error handling sOwnCout() << "Error connecting Most driver." << endl; } //could not be set in ctor, because ComponentBase is not ready mMyId = (CComponentServices::getComponentContextPtr())->getId(); CComponentServices::addListener(CMessage::MOST_APPMSG_TYPE, this); CComponentServices::addListener(CMessage::MOST_INFOMSG_TYPE, this); CComponentServices::addListener(CMessage::MOST_POOL_REF_TYPE, this); CComponentServices::addListener(CMessage::MOST_REGWRITE_TYPE, this); CComponentServices::addListener(CMessage::MOST_LOCK_TYPE, this); CComponentServices::addListener(CMessage::MOST_UNLOCK_TYPE, this); } Listing 19-4. init-Methode von Dispatcher-Main-Thread

In der run-Methode wird zun¨ achst, wie wir oben gesehen haben, der ReceiverThread gestartet. Das weitere Verhalten ist in der Basisklasse definiert (siehe Kapitel 18). D.h., die Komponente kann sich auf die Implementierung der Reaktionen konzentrieren. Alle ankommenden Nachrichten werden direkt vom Dispatcher an die Komponente weitergegeben:

void CMostdispatcherComponent::handleMessage(const CMessage& theMsg) { //map to most driver struct MostMsgUnion * msgPtr = (MostMsgUnion *) theMsg.getMostContentPtr(); UInt32 msgType = mostmsg_getType(msgPtr); //get message type switch ( msgType )

19.2 Dispatcher-Main-Thread

337

{ case CMessage::MOST_APPMSG_TYPE: case CMessage::MOST_POOL_REF_TYPE: case CMessage::MOST_INFOMSG_TYPE: dispatchMessage(theMsg); break; case CMessage::MOST_LOCK_TYPE: processLock(); break; case CMessage::MOST_UNLOCK_TYPE: processUnlock(); break; case CMessage::MOST_REGWRITE_TYPE: //set routing table for internal audio sources mostRegWrite(theMsg.getParam(0),theMsg.getParam(1)); break; } } Listing 19-5. Reaktionen von Dispatcher-Main-Thread

¨ Andert sich der Zustand des MOST-Rings, so wird ein entsprechendes Event an alle Komponenten gesendet. Dabei wird eine LOCK-Nachricht verz¨ogert (um sicher zu sein, dass der Ring stabil steht).

void CMostdispatcherComponent::processTimeOut(CSoftTimer& theTimer) { mLockTimer.stop(); mLockedState = true; CMessage msg(CMessage::MOST_LOCK_TYPE); CContext::sendBroadcast(msg); } void CMostdispatcherComponent::processUnlock() { mLockTimer.stop(); if (true == mLockedState) { mLockedState = false; CMessage msg(CMessage::MOST_UNLOCK_TYPE); CContext::sendBroadcast(msg); } } void CMostdispatcherComponent::processLock() { mLockTimer.start(); }

Listing 19-6. Reaktion auf Lock- und Unlock-Events

338

19 Main-Dispatcher-Komponente

MOST-Events werden intern durch die Methode dispatchMessage weitergeleitet. F¨ ur den Fall einer großen Nachricht wird im Event selbst nur eine Referenz u bertragen, die Daten nehmen den Weg durch einen Datencontainer ¨ im Shared-Memory. Die Unterscheidung ist anhand des mType m¨oglich.

void CMostdispatcherComponent::dispatchMessage(CMessage theMsg) { //map CMessage buffer to MostMsgUnion MostMsgUnion * bufferPtr= (MostMsgUnion *)(theMsg.getMostContentPtr()); //Get the header of the message. Might be //- in CMessage buffer (msgPtr==bufferPtr) //- in MostPool (msgPtr==) MostMsgUnion * msgPtr = mostmsg_getHeader (bufferPtr); UInt32 msgType = mostmsg_getType(msgPtr); //Get type of message if (CMessage::MOST_INFOMSG_TYPE==msgType) //Handle INFO messages { UInt16 cmd = mostinfomsg_getCommand(msgPtr); UInt8 value = mostinfomsg_getCommand(msgPtr); if ( MOSTINFO_MSV_LOCK == cmd ) { switch ( value ) { case MSV_LOCK_STABLE: sOwnCout << "Received LOCK from Most" << endl; processLock(); break; case MSV_UNLOCK: sOwnCout << "Received UNLOCK from Most" << endl; processUnlock(); break; } } } else if (CMessage::MOST_APPMSG_TYPE == msgType || //Handle APPmsg CMessage::MOST_POOL_REF_TYPE == msgType ) { UInt8 source = mostmsg_getSource ( msgPtr ); UInt8 fBlockID = mostappmsg_getFBlockID ( msgPtr ); UInt8 instID = mostappmsg_getInstID ( msgPtr ); UInt16 funcID = mostappmsg_getFuncID ( msgPtr ); //1. The exceptions for netblock and internal navi.

19.2 Dispatcher-Main-Thread

339

//Let all NetBlock message pass directly between model and MOST if ( 0x01 == fBlockID ) // NetBlock { if ( CMessage::EXTERNAL_TYPE == source ) { CComponentContext * netBlockContext = CContext::getContext(0x00, 0x01, CMessage::MODEL_TYPE); sendToContext(theMsg, netBlockContext); } else { sendToMost(theMsg); } return; //2. Handle messages received external from MOST //send messages received from MOST to the appropriate model if ( CMessage::EXTERNAL_TYPE == source ) { CComponentContext * context = CContext::getContext(instID,fBlockID,CMessage::MODEL_TYPE); sendToContext(theMsg, context); return; } //3. Handle messages from internal components else { //if a destination component is identified, //its context is referenced with this pointer //(NULL == unknown component) CComponentContext * deviceContext; CComponentContext * modelContext; deviceContext = CContext::getContext( instID, fBlockID, CMessage::DEVICE_TYPE); modelContext = CContext::getContext( instID, fBlockID, CMessage::MODEL_TYPE); //avoid to send messages back to origin if (CMessage::MODEL_TYPE == source) { modelContext = NULL; } if (CMessage::DEVICE_TYPE == source) { deviceContext = NULL; } //if we have no internal consumer -> sent to MOST if ( !modelContext && !deviceContext ) {

340

19 Main-Dispatcher-Komponente sendToMost(theMsg); } else { sendToContext(theMsg, deviceContext); sendToContext(theMsg, modelContext); } }

} else { sOwnCout << "Unhandled message type in MostDispatcher" << endl; } } void CMostdispatcherComponent::sendToContext( CMessage & theMsg, CComponentContext * theContext ) { if (NULLPTR != theContext) { theMsg.setSenderID(mMyId); theMsg.setReceiverID(theContext->getId()); theContext->getNormalQueue().add(theMsg); } } void CMostdispatcherComponent::sendToMost( CMessage & theMsg ) { MostMsgUnion * msgPtr = (MostMsgUnion *) (theMsg.getMostContentPtr()); Int32 returnValue = MostUMsgTransmit( mMostHandle, msgPtr ); if (MOSTERR_OK != returnValue) { sOwnCout<<"Mostdispatcher: error sending MOST paket."<<endl; } } Listing 19-7. Verteilung der MOST-Nachrichten im System-Dispatcher

20 Modell-Komponenten, logische Ger¨ ate

Eine Modell-Komponente bildet als Stellvertreter das entfernt im Netz gelegene physikalische Ger¨ at ab. Damit kann sich z.B. die HMI-Komponente direkt mit diesem Stellvertreter unterhalten, dieser wiederum regelt dann selbstst¨andig die Kommunikation zum eigentlichen Device (StellvertreterMuster). Die HMI implementiert demnach das Bedienwissen, w¨ahrend logische Ger¨ate das Ger¨atewissen und das Kommunikationswissen beheimaten. Man kann die Komponenten-Modelle in einen MOST-Codec unterteilen, der die Enkodierung und Dekodierung der MOST-Daten vornimmt, und in einen Steuerungsteil, oft Controller genannt. Ein Controller implementiert die Ger¨ate-Steuerung1 .

Abbildung 20.1. Blockbild des logischen Ger¨ ats 1

Der Begriff Controller passt nicht zur Terminologie des MVC-Konzeptes, wird aber meistens verwendet.

342

20 Modell-Komponenten, logische Ger¨ ate

Die Daten des Ger¨ ats werden in einem Datencontainer im Shared-Memory aufbewahrt, die Begr¨ undung daf¨ ur folgt sp¨ ater. Weiterhin besitzt ein logisches Ger¨ at einen Kontext mit allen Bausteinen, die jede Komponente bei der Erzeugung erbt. Es sind dies: drei Queues, ein Komponenten-Dispatcher und Hintergrunddienste wie Watchdog, Timer und Zustandsregister.

20.1 Aufgaben des logischen Ger¨ ats Zun¨achst konzentrieren wir uns auf den Controller. Der MOST-Codec wird sp¨ater in einem eigenen Abschnitt besprochen. Der Controller wird in der Regel mit Hilfe von Statecharts realisiert. Ein schwieriger Teil des Automaten ist die Erfassung aller m¨oglichen Fehlersituationen und die Maßnahmen zur Behandlung. Typische Aufgaben eines Controllers sind: • Ausf¨ uhren und Verfolgen einer Benutzeraktion. Beim Empfang eines Befehls muss der Controller u ufen, ob der Befehl zurzeit erlaubt ist ¨berpr¨ und sofort ausgef¨ uhrt werden kann. Ggf. muss die aktuell laufende Aktion abgebrochen werden. Dazu ist Ger¨ atewissen notwendig. • Garantieren der Datenkonsistenz. Die Daten sind zustandsabh¨angig. Wird gerade eine neue Spur eingestellt, darf die empfangene aktuelle Spielzeit nicht interpretiert werden. Ein neuer Sendername kann nur angezeigt werden, wenn die gew¨ unschte Frequenz eingestellt wurde. Das Ger¨atewissen ist hier notwendig. Beim Empfang eines neuen, g¨ ultigen Datums wird die HMI informiert, die daraufhin Daten abholen und anzeigen kann. ¨ • Wiederholung der Nachrichten, Uberwachung, Fehlerbehandlung, Handshake usw. Das ist das oben erw¨ ahnte Kommunikationswissen (siehe dazu die MOST-Beschreibung) entsprechend dem Schichtenmodell von ISO/OSI. Im Controller k¨ onnen aber auch Befehle realisiert werden, die das physikalische Ger¨at nicht umsetzen kann. Als Beispiel sei die Scan-Funktion genannt. Man will im Sekundenabstand alle verf¨ ugbaren Sender anspielen und dann automatisch weiterschalten. Die Tuner-Komponente kann das oft nicht so, wie es in der Spezifikation vorgegeben wird, so dass der Controller die Scan-Funktion ersatzweise aus Einzelbefehlen, Frequenz-Setzen, Spielen, EineSekunde-Warten zusammensetzt und damit den Befehlssatz erweitert. Auch die Ansteuerung der Quellenumschaltung wird im Controller realisiert, die Bedieneinheit gibt nur aus dem Radio-Mode heraus den Befehl, CD anzuspielen. Dann muss zun¨ achst gemutet werden, die Audio-Quelle auf CD umgeschaltet, der CD-Player gestartet und nach einer Zeit der Mute wieder aufgehoben werden. Dieser ganze Ablauf wird in einem Controller realisiert, bei sehr einfachen Systemen in der Tuner- und in der CD-Komponente, bei gr¨oßeren Systemen

20.2 Was erwartet die HMI von einem logischen Ger¨ at?

343

in einem eigenen Audio-Controller. Diese Delegation nach oben“ erspart viel ” Querkommunikation. Controller existieren immer, auch wenn das physikalische Ger¨at zeitweise nicht verf¨ ugbar sein sollte. • Im Controller l¨ auft immer nur eine Aktion. • Die Nachrichten zu den Controllern und zwischen den Controllern werden dem MOST-Katalog entnommen. • Es kann Controller bzw. Komponenten geben, die hierarchisch u ¨ber anderen Controllern stehen (Delegation) und kein eigenes Ger¨at organisieren, z.B. Audio-Manager, Audio-Controller, On/Off-Controller, DiagnoseController.

20.2 Was erwartet die HMI von einem logischen Ger¨ at? Logische Ger¨ate sind Objekte, die einfache Schnittstellen f¨ ur die HMI bieten. Sie kapseln die spezifische Logik der Aktionen und die Steuerung der Ger¨ate. Ferner werden die Besonderheiten von MOST und die Problematik der ¨ Ubertragung verborgen. In der in diesem Kapitel vorgeschlagenen Architektur wird versucht, viele bekannte Mechanismen in das Konzept zu integrieren. Sie hat nicht den Anspruch, alle Probleme in der Ger¨ atesteuerung abzudecken. Ein logisches Ger¨ at kommuniziert mit der HMI und dem MainDispatcher und spielt dabei die Rolle eines Adapters. Die HMI kann dadurch auf einem abstrakteren Level mit dem Ger¨ at reden. Da die Daten asynchron von einem physikalischen Ger¨at zum Controller kommen, arbeitet die HMI ebenfalls bez¨ uglich des logischen Ger¨ats nach dem Zuh¨orer-Prinzip. Die HMI k¨ onnte ihre Interessen bei dem logischen Ger¨at anmelden und sich nur f¨ ur die Daten registrieren, die sie aktuell anzeigen oder vorhalten will. Die entsprechenden Daten eines logischen Ger¨ats sind durch eine Aufz¨ahlung ansprechbar. Die Anmeldung beschr¨ ankt sich dabei nicht auf die notifizierbaren“ ” MOST-Daten. Alle anzuzeigenden Daten sind aus Sicht der HMI notifizierbar! Diese Registrierung ist allerdings nur bei sehr großen Systemen mit vielen, sich ¨andernden Daten ratsam. Zudem gibt es mittlerweile viele GUIKonzepte, bei denen in einem Statusrahmen am Rand des Displays fast alle Daten st¨andig angezeigt werden, z.B. Telefon-Feldst¨arke, Sendername, Uhrzeit, Heizungstemperatur und vieles mehr. Wir verzichten deshalb hier auf den Mechanismus und lassen die Controller alle Daten an die HMI weitergeben, die sich ver¨andert haben. Ein logisches Ger¨ at verwendet den bereits vorgestellten Main-Dispatcher, um Nachrichten zu versenden. Ankommende MOST-Nachrichten werden an-

344

20 Modell-Komponenten, logische Ger¨ ate

hand der FBlockID und InstID vom Main-Dispatcher weiter an die entsprechende Komponente geleitet. Jedes logische Ger¨ at ist eine zur Kompilierzeit bekannte Komponente. Zu versendende MOST-Nachrichten werden in Form von Framework-Nachrichten an den Main-Dispatcher weitergeleitet. Der Main-Dispatcher spricht dann den MOST-Treiber oder direkt ein internes Ger¨ at an, um die gew¨ unschte Aufgabe zu erledigen. Dabei muss der MOST-Treiber eventuelle Low-Level-RetryMechanismen anbieten. Um die Architektur eines logischen Ger¨ ats festzulegen, wird zun¨achst die Anforderung aus Sicht der HMI untersucht. Wir definieren aus Benutzersicht folgende Begriffe, die f¨ ur die Anforderungen an das logische Ger¨ at relevant sind: • Es gibt Daten, die angezeigt werden oder gesetzt werden. Ein Beispiel ist die aktuelle Spurnummer der gespielten CD. Daten k¨onnen sich im Betrieb ver¨andern, z.B. dadurch, dass die CD die n¨achste Spur anspielt. Daten k¨onnen angezeigt werden. • Es gibt Optionen, das sind spezielle Daten, die einmal gesetzt werden und bis zum n¨achsten Setzen erhalten bleiben. Beispiele sind TP (Verkehrsfunk aktiv/inaktiv), RDS-Status, Regional On/Off-Status und so weiter. Optionen k¨onnen ebenfalls angezeigt werden. • Es gibt Zust¨ ande der HMI. Das ist der Men¨ u- oder Bedien-Zustand, in dem sich die HMI und das System befinden, z.B. gibt es den CD-Mode. Diese Zust¨ande sind zun¨ achst nicht direkt vom externen Ger¨atezustand abh¨angig, sondern nur vom Bedienzustand der HMI. Wir m¨ ussen diese Zust¨ande der HMI oder des Gesamtsystems von den Zust¨anden des logischen und des physikalischen Ger¨ ats unterscheiden. Ein CD-Spieler kann sich beispielsweise im Pause-Zustand befinden, dies ist nicht notwendigerweise auch der Zustand der HMI oder des Gesamtsystems. • Es gibt Aktionen (high level), die durch Bedienung der HMI ausgel¨ost werden. Ein Beispiel ist das Dr¨ ucken des CD-Knopfes im Radio-Mode. ¨ Aus dieser Aktion leiten sich eine Reihe von Anderungen des Systems ab. Die hier definierten Begriffe werden im Folgenden n¨aher beleuchtet. Die HMI erwartet in der Regel von einem Ger¨at (aus der logischen Sicht, nicht aus Sicht von MOST!): • Eine Menge von Informationen, die angezeigt werden sollen. Dies sind eingestellte Optionen und r¨ uckgemeldete Daten. Die Daten m¨ ussen konsistent sein. D.h., sie d¨ urfen nur angezeigt werden, wenn sie g¨ ultig sind. • Eine Menge von Optionen (settings), die der Benutzer einstellen kann. Diese Optionen beeinflussen das Ger¨ atverhalten. Je nach Aktion oder Zustand des Ger¨ats kann der Benutzer nur eine beschr¨ankte Menge von Optionen einstellen. Es hat z.B. keinen Sinn, w¨ ahrend eines SCAN-Vorgangs die Option REPEAT zu erlauben. Viele Ger¨ ate-Optionen beeinflussen stark das Verhalten des Ger¨ ats. Eine TA-Meldung kann beispielsweise nur angezeigt und geh¨ ort werden, wenn es die dazugeh¨orige Option zul¨asst. Die

20.3 Zust¨ ande des Ger¨ ats

345

Abbildung 20.2. Anforderungen der HMI an das logische Ger¨ at

¨ Anderung einer Option w¨ ahrend einer Aktion kann durchaus zu einem Neustart der Aktion f¨ uhren (TA wird w¨ ahrend eines Suchlaufs eingeschaltet). Viele Optionen konnten fr¨ uher u ¨ber die Tastatur eingestellt werden. In den modernen HMI-Oberfl¨ achen sind sie u ¨ber Softkeys zu erreichen. Ein konsistentes Men¨ u-Konzept muss die Relation zwischen ausw¨ahlbaren Optionen und Aktionen ber¨ ucksichtigen. • Eine Menge von High-Level-Aktionen“. Anders als in der MOST-Spezifi” kation sind die Aktionen Benutzeraktionen. Sie werden u ¨ber MOSTProperties oder u ber MOST-Methoden abgewickelt. So werden z.B. die ¨ Aktionen Stop“, Play“, Pause“, Scan“ etc. eines CD-Spielers u ¨ber ” ” ” ” MOST-Properties gesteuert. Die Aktion Suchlauf“ eines Tuners wird u ¨ber ” eine MOST-Methode getriggert. • Ferner erwartet die HMI vom logischen Ger¨at die Verwaltung der Audiokan¨ale. Der Unterschied zwischen Optionen und Aktionen nach unserer Definition besteht darin, dass die Optionen aus der Benutzersicht keine Zeit“ ben¨otigen. ” Ferner sind die Optionen dauerhaft. Eine Aktion geht irgendwann zu Ende. Eine Option bleibt solange bestehen, bis der Benutzer sie ¨andert. Im Folgenden werden die erwarteten Aktionen von HMI sowie einige wichtige Informationen von einem logischen Ger¨ at diskutiert.

20.3 Zust¨ ande des Ger¨ ats Das logische Ger¨ at kann sich in verschiedenen Zust¨anden befinden. F¨ ur die HMI ist es aber nur von Bedeutung, ob das logische Ger¨at READY ist. D.h. das entsprechende Ger¨ at hat sich angemeldet, so dass die HMI ihre Registrierungen, Aktionen usw. absetzen kann. Andere Zust¨ande wie STANDBY,

346

20 Modell-Komponenten, logische Ger¨ ate

STANDBY NO MOST usw. werden durch die Menge der verf¨ ugbaren Aktionen bzw. Optionen widergespiegelt. Zur Vereinfachung wird davon ausgegangen, dass das Ger¨ at nur vier Zust¨ ande annimmt:

Abbildung 20.3. Zust¨ ande des logischen Ger¨ ats

Am Anfang ist das Ger¨ at im INIT-Zustand (alle Daten sind initialisiert, das zugeh¨orige Ger¨ at hat sich aber noch nicht gemeldet). Nach der Anmeldung des Ger¨ats geht die Komponente in den Zustand EXIST. Der Zustand READY wird dann angenommen, nachdem die Nachricht Ready to go“ erhalten wur” de. Das ist der Operationszustand des Ger¨ ats. Beim Herunterfahren schaltet die Komponente in den entsprechenden Zustand. Im Zustand TERMINATED wird keine Nachricht mehr angenommen. Das Ger¨at kann nur durch Neustart angesprochen werden. Im Zustand EXISTS kann keine Aktion gestartet werden, weil das gesamte System noch in einem unsicheren Zustand ist. Erst mit Ready to go“ wird signalisiert, dass das System operabel ist. ” Das Ger¨ at darf nur im Zustand READY benutzt werden

20.4 Gu ¨ ltigkeit der Daten Nicht alle Daten in einem logischen Ger¨ at sind g¨ ultig. Wegen der asynchronen ¨ Ubertragungen k¨ onnen folgende Fehlerf¨ alle auftreten: •

Ein Datum wurde vom Ger¨ at gesendet, w¨ ahrend das logische Ger¨at gerade eine neue Aktion startet (Datum auf dem R¨ uckkanal und neuer Befehl auf dem Hinkanal). ¨ • Eine Information u des Datums wurde zu HMI gesendet. ¨ber die Anderung Sie liegt noch in der Queue, w¨ ahrend die HMI aufgrund der Benutzereingabe schon eine neue Aktivit¨ at startet.

Um Daten nicht falsch anzuzeigen, werden G¨ ultigkeits-Flags f¨ ur die einzelnen Daten eingef¨ uhrt. Beim Lesen eines Datums erh¨alt die HMI als R¨ uckgabe einen Booleschen Wert, der angibt, ob das zu lesende Datum g¨ ultig ist. Generell sind alle Daten beim Starten des Systems ung¨ ultig. Auch werden einige Daten beim Kontextwechsel ihre G¨ ultigkeit verlieren. Nachdem ein Datum erhalten wurde und der Kontext es zul¨ asst, wird es als g¨ ultig erkl¨art. Eine entsprechende Update-Nachricht wird ggf. an die HMI gesendet.

20.7 Datencontainer versus Event-Prinzip

347

20.5 Kommunikationsanforderung Da die HMI eine neue Aktion starten kann, w¨ahrend eine Update-Nachricht vom logischen Ger¨ at zu HMI gesendet wird, kann diese Update-Nachricht nicht mehr aktuell und damit falsch sein. Ein Fehler tritt auch auf, wenn die HMI mehrere Aktionen gleichzeitig startet, obwohl das Ger¨at aufgrund seiner physikalischen Beschr¨ ankungen nur sequenziell Befehle annehmen kann. Zur Vermeidung dieser Probleme kann wie folgt festgelegt werden: •

Die Befehle werden von der HMI synchron u ¨ber die externe Queue des logischen Ger¨ ats an dieses gesendet. • Benachrichtigungen vom logischen Ger¨ at erfolgen asynchron. • Das logische Ger¨ at kann nur eine Aktion nach der anderen ausf¨ uhren. Eine neue Aktion kann eine alte abbrechen oder wird solange hinausgez¨ogert, bis die aktuelle Aktion beendet wird. Eine wartende Aktion kann unter Umst¨anden durch eine neue ersetzen werden. Dieser Umstand muss der HMI mitgeteilt werden. Da HMI-Befehle synchron abgesetzt werden, kann das logische Ger¨at entsprechende Flags in seinem Kontext steuern. Die Nachrichten, die zur alten Situation geh¨oren, k¨ onnen erkannt werden. Das Problem, dass die HMI solange blockiert bleibt, bis der Befehl abgenommen wird, ist durch die Separierung der logischen Ger¨ ate in getrennte Komponenten abgeschw¨acht. Zur Blockierung der HMI kann ein Semaphor verwendet werden. Erfahrungsgem¨aß ist die Logik im logischen Ger¨ at f¨ ur die Antwort an die HMI einfach und schnell, so dass der synchrone Betrieb an dieser Stelle zu keinen sp¨ urbaren Blockierungen f¨ uhrt.

20.6 Struktur eines logischen Ger¨ ats Controller sind je nach Anwendung sehr verschieden und erfordern viel spezifisches Fachwissen, so dass wir sie hier nicht n¨ aher beschreiben. Im Folgenden wird lediglich der Aufbau eines Datencontainers (zur Haltung der Daten) und die Konstruktion eines MOST-Codecs untersucht.

20.7 Datencontainer versus Event-Prinzip Betrachten wir ein Beispiel, in dem eine Tuner-Komponente mit der HMI kommuniziert und Sendernamen und Senderfrequenz anzeigt und ver¨andert. Die Komponente spiegelt die Ist-Ger¨ atezust¨ande und Ist-Daten, die in der abgesetzten Tuner-Box existieren, eben den eingestellten Sender und die aktuelle Frequenz, auch FM oder AM. Die Ist-Daten werden auch actual data“ ” genannt. Entsprechend gibt es auch Soll-Daten, requested data“, das sind die ”

348

20 Modell-Komponenten, logische Ger¨ ate

durch Bedienung des Ger¨ ats gew¨ unschten Daten, z.B. eine neue Spur der CD. Eigentlich sind Soll- und Ist-Daten in der Regel gleich, es gibt aber Laufzeiten zwischen der Tuner-Komponente und der Tuner-Box, die unvermeidbar sind, so dass erst nach einiger Zeit, wenn das physikalische Ger¨at erwartungsgem¨aß reagiert, die Ist-Daten den gew¨ unschten Soll-Daten entsprechen.. Je nach Architektur gibt es weitere Laufzeiten zwischen HMI und TunerKomponente, z.B. durch die Event-Queues. Diskutiert man diese Laufzeit-Probleme zwischen den Ist- und den SollOptionen und Ist- und Soll-Daten, so st¨ oßt man auf die Frage, wem welche Daten, Zust¨ande und Optionen geh¨ oren. Der Zustand des Tuners wird in der logischen Komponente gehalten, zum Beispiel ob er im Scan-Mode oder TP etc. ist, wird aber gleichzeitig auch zur Anzeige gebraucht. Es gibt Zust¨ ande in der logischen Komponente: Start, Stop, Play aber auch Bedienzust¨ ande in der HMI: Tuner Mode oder CD Mode, . . . .. Es gibt schließlich auch noch Zust¨ ande und Optionen, die beide kennen m¨ ussen, z.B. AM/FM und TP/TA. Die Daten des Tuners wie Frequenz und Sendername werden in der HMI verwendet, Lautst¨ arke und Sender werden ggf. inkrementell bestimmt, und der Kontext, der dazu gebraucht wird, ist nur in der HMI bekannt. In Ausnahmef¨allen braucht aber auch die logische Komponente Daten, zum Beispiel wenn Vol=0 ein Ersatz f¨ ur Mute ist. Auch wenn ein CDC die Funktion Shuffle nicht besitzt und die Komponente das simulieren muss, besch¨ aftigt sie sich mit Daten, die Option ist dann Shuffle. Das Problem zwischen logischen Ger¨ aten und der HMI ist, dass sie sich die Daten und Zust¨ande teilen m¨ ussen. Die Komponente kennt die Zust¨ande, gelegentlich muss die HMI diese anzeigen. Ein Beispiel f¨ ur einen Ger¨ate-Zustand, der nicht u ¨ber Power-off restauriert wird, ist Scan. Fazit: Es klingt danach, als g¨ abe es keine klare Trennung. Ein Prinzip zeichnet sich aber ab. Daten und Zust¨ ande geh¨ oren dem, der sie ver¨ andern darf. Ansatz: Soll-Daten geh¨ oren der HMI, Ist-Daten geh¨ oren dem logischen Ger¨ at. Nun gilt es zu kl¨ aren, ob wir einen gemeinsamen Speicher f¨ ur Daten und Zust¨ande implementieren oder ob wir uns auf den Event-Austausch beschr¨anken. Wenn die Daten u ¨ber Events in die HMI getragen werden, sind sie zeitrichtig im Sinne der Reihenfolge, aber ggf. alt und im Kontext nicht mehr g¨ ultig, wir hatten dies weiter oben besprochen. Ein weiteres Beispiel w¨are, dass der Benutzer einen Scan-Lauf des Tuners startet. Unterdessen bekommt die HMI einen Stationsnamen zur¨ uckgemeldet, der noch aus einer vorherigen Anfrage resultiert.

20.8 Architektur eines Datencontainers

349

Alle Daten und Zust¨ ande m¨ ussen nach Erhalt der Events abgespeichert werden, damit bei Men¨ uwechseln schnell die neuen Informationen gezeigt werden k¨onnen. Das w¨ urde zum Anlegen vollst¨ andiger Kopien f¨ uhren.

20.8 Architektur eines Datencontainers Um dieses Kopieren der Daten zu vermeiden, werden die Soll- und Ist-Daten in einem Datenspeicher - dem Datencontainer - gehalten. In der Regel liegt der Datencontainer im Shared-Memory (wenn die beteiligten Objekte in verschiedenen Prozessen liegen). Hat man die Architektur auf eine Multithread-Version beschr¨ankt, k¨onnen die Container in einem einfachen Array liegen (Multithread-Objekte). In unserer Architektur unterscheiden sich beide Versionen nicht.

Abbildung 20.4. Daten-Container f¨ ur die HMI

Logisch gesehen geh¨ ort der Soll-Datencontainer der HMI, wird von ihr gef¨ ullt und von dem logischen Ger¨ at gelesen. Dagegen wird der Ist-Datencontainer nur von dem logischen Ger¨ at gef¨ ullt. Immer wenn dem logischen Ger¨ at neue, g¨ ultige Daten vorliegen, werden diese in den Container gelegt und zus¨ atzlich ein Update“-Event an die HMI ” gesendet. Umgekehrt legt die HMI neue Soll-Daten ebenfalls in den gemeinsamen Container und sendet ein Anfrage-Event Service-Request“ an das entspre” chende logische Ger¨ at.

350

20 Modell-Komponenten, logische Ger¨ ate

Abbildung 20.5. Container f¨ ur Soll- und Ist-Daten

Da ein Datencontainer im Shared-Memory liegt, kann er keine dynamischen Daten wie Zeichenketten beliebiger L¨ange unterst¨ utzen. Ein Ersatz daf¨ ur muss geschaffen werden oder die Zeichenketten werden in ihrer L¨ange festgelegt. Ferner wird er von mehreren Komponenten zugegriffen, so dass verschiedene Schnittstellen angeboten werden m¨ ussen: • Der HMI muss eine einfache Schnittstelle zum Lesen der Ist-Daten angeboten werden. • Eine Schnittstelle zum Setzen der Soll-Daten ist erforderlich. Die HMI sieht in der Regel diese Schnittstelle nicht. Sie startet eine Anfrage in Form einer High-Level-Methode. Die Methode ist zust¨andig f¨ ur die Synchronisierung, das Schreiben in den Datencontainer und die Versendung einer entsprechenden Nachricht in die betreffende Komponente. • Der MOST-Codec muss eine einfache M¨ oglichkeit haben, u ¨ber einen Index (siehe unten) auf die Daten zugreifen zu k¨onnen. Statt verschiedene Schnittstellen zu vererben (im Sinne von OOP), wird der Datencontainer als einfache C-Struktur definiert. Die Schnittstellen“ wer” den durch konkrete Adapterklassen implementiert, die das Wissen u ¨ber den Aufbau des Datencontainers haben. 20.8.1 Struktur des Datencontainers Der Datencontainer beinhaltet unter anderem: • Einen Mutex f¨ ur die Synchronisierung der Zugriffe. • Einen Bin¨arsemaphor zur Realisierung synchroner Aufrufe zwischen der HMI und dem logischen Ger¨ at. • Eine Sammlung von Strukturen und Variablen, die die Ist-Daten widerspiegeln.

20.8 Architektur eines Datencontainers

351

Abbildung 20.6. Klassendiagramm des Datencontainers

• Eine Sammlung von Strukturen und Variablen f¨ ur die Soll-Daten. Dabei ist ein Wert reserviert, um den R¨ uckgabewert eines HMI-Aufrufs abzuspeichern. In diese Variable kann z.B. der Grund einer Ablehnung, die abgebrochene Aktion usw. geschrieben werden. Die Verwendung ist anwendungsabh¨ angig. • Ein Flag-Array. Jedes Flag markiert, ob ein bestimmtes Datum g¨ ultig ist oder nicht (es ist die Aufgabe eines Automaten, diese Flags anzupassen. Ein Datum, z.B. der Sendername, ist nur g¨ ultig, wenn die Frequenzeinstellung best¨ atigt wird und ein neuer Sendername empfangen wird.) • Die Instanz-ID. • Die Angabe, ob der entsprechende Container g¨ ultig ist oder nicht (der Datencontainer darf nur verwendet werden, wenn sich das Ger¨at meldet). In jedem Datencontainer werden dynamische Daten“ wie Strings, Streams ” und Arrays durch Strukturen realisiert. Weil unser Datencontainer im SharedMemory liegt, kann er nicht beliebig wachsen. Ein Heap kommt hier auch nicht in Frage. Stattdessen wird ein Array mit maximaler Kapazit¨at verwendet. Die Grenzen der Daten sind im MOST-Protokoll vorgeschrieben. Beispielsweise besteht die Information einer Audio-Disk nach der MOST-Beschreibung aus einem String mit maximal 50 Zeichen, aus einer Spielzeit vom Typ UInt32, aus Track (Typ UInt32) und aus einem String f¨ ur Audiodateinamen (maximal 100 Unicode-Zeichen). Die Daten dazu haben in der MOST-Beschreibung das Format: Array of { Record of { String Number Number String } }

Die Liste mit einer maximalen Kapazit¨ at von 99 Eintr¨agen wird durch das folgende Array von Struktur beschrieben:

352

20 Modell-Komponenten, logische Ger¨ ate

Abbildung 20.7. Struktur des Datencontainers

struct { StringBuffer mAudioTitle; UInt16 mAudioTitleRestBuffer[50]; UInt32 mAudioTime; UInt32 mAudioTrack; StringBuffer mAudioFileName; UInt16 mAudiofileNameRestBuffer[100]; } mActualAudioDiscInfo[99]; UInt16 mActualAudioDiscInfoArrayLength; Listing 20-1. Datencontainer-Struktur f¨ ur AudioDiscInfo

Die Anzahl der g¨ ultigen Eintr¨ age des Arrays wird beispielsweise durch die Variable mActualAudioDiscInfoArrayLength wiedergegeben. Der Titel (ein String mit einer maximalen L¨ ange von 50 Zeichen) wird in einem Objekt vom Typ StringBuffer und einem Array von 50 Unicode-Zeichen abgespeichert. Ein Objekt vom Typ StringBuffer, a ¨hnlich wie ein Queue-Objekt, hat die Information u ber die tats¨ a chliche L¨ a nge des Arrays und ein Array der L¨ange ¨ 1. Hinter diesem Objekt stehen die restlichen Array-Elemente:

struct StringBuffer { UInt16 mLength; //current length of the buffer

20.8 Architektur eines Datencontainers

353

//buffer for the characters - here we use the trick that //the object is defined as an array of length 1. The array //in the data container that follows this structure //is automatically generated. This array contains the buffer //for the rest of the string UInt16 mBuffer[1]; }; Listing 20-2. Struktur StringBuffer

Durch diesen Trick kann man auf alle Arrays (beliebiger L¨ange) u ¨ber den Typ StringBuffer richtig zugreifen (vorausgesetzt, dass nach dem Element selbst die restlichen Array-Elemente folgen und dass der Benutzer auf die Grenze des Arrays achtet). F¨ ur allgemeine Streams (Byte-Array) wird entsprechend im Datencontainer die Struktur DataBuffer verwendet:

//structure for data buffer used in the data container. //Note that this buffer is used internally. The bound check //is done by other instance struct DataBuffer { UInt16 mLength; //current length of the buffer //buffer - Note that an array must follow this structure UInt8 mBuffer[1]; }; Listing 20-3. Struktur DataBuffer

Hinweis: Der Code f¨ ur den Datencontainer sollte auf der Basis der MOST-Beschreibung des logischen Ger¨ ats automatisch generiert werden. Der gesamte Datencontainer f¨ ur einen AudioDiscPlayer sieht etwa wie folgt aus (der Postfix DCShared besagt, dass es sich um einen Datencontainer im Shared-Memory handelt):

class CAudioDiscPlayerDCShared { public: CAudioDiscPlayerDCShared(UInt8 aInstanceId); struct { UInt8

mSourceNr;

354

20 Modell-Komponenten, logische Ger¨ ate UInt8 mDataType; DataBuffer mDataDescription; UInt8 mDataDescriptionRestBuffer[4]; } mActualSourceInfo; struct { UInt8 mSourceNr; StringBuffer mSourceName; UInt16 mSourceNameRestBuffer[11]; } mActualSourceName; struct { UInt8 mSourceCount; UInt8 mSinkCount; } mActualSyncDataInfo; UInt8

mActualDeckStatus;

struct { Int32 mDiscTime; Int32 mTrackTime; Int32 mTitleTime; } mActualTimePosition; UInt16 UInt8 UInt8 UInt8

mActualTrackPosition; mActualMagazineStatus; mActualActiveMagazine; mActualActiveDisc;

struct { StringBuffer mMediaTitle; UInt16 mMediaTitleRestBuffer[20]; UInt8 mMediaType; UInt8 mMediaFileSystem; } mActualMediaInfo[6]; UInt16 mActualMediaInfoArrayLength; struct { StringBuffer UInt16 UInt32 UInt16 StringBuffer

mAudioTitle; mAudioTitleRestBuffer[50]; mAudioTime; mAudioTrack; mAudioFileName;

20.8 Architektur eines Datencontainers UInt16 mAudiofileNameRestBuffer[100]; } mActualAudioDiscInfo[99]; UInt16

mActualAudioDiscInfoArrayLength;

UInt8 UInt8 UInt8 UInt8 UInt8

mActualDeckEvent; mActualMediaEvent; mActualRandomState; mActualScanState; mActualRepeatState;

bool

mActualDeemphasis;

UInt32

mReturnValue;

UInt8

//Used to store return val of //logical component //often value of an enum type mExpectedDeckStatus;

struct { Int32 mDiscTime; Int32 mTrackTime; Int32 mTitleTime; } mExpectedTimePosition; UInt16 UInt8 UInt8

mExpectedTrackPosition; mExpectedActiveMagazine; mExpectedActiveDisc;

UInt8 UInt8 UInt8 bool

mExpectedRandomState; mExpectedScanState; mExpectedRepeatState; mExpectedDeemphasis;

bool

mFlagArray[AudioDiscPlayer::END_OF_IDX];

UInt8 mInstanceID; CMutex mMutex; CBinarySemaphore mSync; bool mHasDevice;

//used to synchronize the call of HMI

}; Listing 20-4. MOST-Datencontainer f¨ ur AudioDiscPlayer

355

356

20 Modell-Komponenten, logische Ger¨ ate

20.8.2 Lesezugriffe der HMI Der Lesezugriff auf den Datencontainer wird gekapselt. Ein Adapter wird ebenfalls generiert“, der der HMI eine abstrakte Schnittstelle zur Verf¨ ugung ” stellt.

Abbildung 20.8. Adapter f¨ ur die HMI zum Lesen des Datencontainers

Jeder Anfrage der HMI muss eine Referenz mitgegeben werden, die von dem abstrakten Datencontainer gef¨ ullt wird, z.B.:

//AudioDiscInfo bool getAudioDiscInfoArrayLength (UInt8& aNumOfElements); bool getAudioDiscInfoAudioTitle (UInt8 pos, CString& aAudioTitle); bool getAudioDiscInfoAudioTime (UInt8 pos, UInt32& aAudioTime); bool getAudioDiscInfoaudioTrack (UInt8 pos, UInt32 &aAudioTrack); bool getAudioDiscInfoAudioFilename(UInt8 pos, CString& aAudioFilename); Listing 20-5. Einige get-Methoden f¨ ur AudioDiscInfo

Man beachte, dass der Anwender nicht auf die Synchronisierung achten muss. Ferner ist die Verwendung von dynamischen Zeichenketten (hinter der Klasse CString) nur in der HMI selbst erlaubt. Die dazugeh¨origen Implementierungen sehen etwa so aus:

bool CAudioDiscPlayerDataContainer ::getAudioDiscInfoArrayLength(UInt16& aNumOfElements) { mContainer.lock(); bool retVal = mContainer.getValidFlag(AUDIO_DISC_INFO_IDX);

20.8 Architektur eines Datencontainers

357

aNumOfElements = mContainer.mSharedData.mActualAudioDiscInfoArrayLength; mContainer.unlock(); return retVal; } bool CAudioDiscPlayerDataContainer ::getAudioDiscInfoAudioTime(UInt8 pos, UInt32& aAudioTime) { // pos= which Array = which CD mContainer.lock(); bool retVal=mContainer.getValidFlag(AUDIO_DISC_INFO_IDX); aAudioTime = mContainer.mSharedData.mActualAudioDiscInfo[pos].mAudioTime; mContainer.unlock(); return retVal; } Listing 20-6. Implementierung der get-Methoden f¨ ur AudioDiscInfo

Der Container wird zuerst gelockt. Dann werden die dazugeh¨origen Daten gelesen. Schließlich bildet das G¨ ultigkeits-Flag den R¨ uckgabewert. 20.8.3 Versenden eines HMI-Befehls Die HMI kann u ¨ber einen Adapter einen Befehl absetzen. Der Befehl wird, ullen und eine ¨ahnlich wie ein Lesebefehl, ggf. die notwendigen Soll-Daten f¨ Nachricht an die entsprechende Komponente versenden.

Abbildung 20.9. Versenden eines HMI-Befehls

Die HMI ruft z.B. den Befehl void CAudioDiscPlayerRequestPort::startscan();

des Adapters, der als erstes

358

20 Modell-Komponenten, logische Ger¨ ate

• die Aktion (Status) in den Soll-Datencontainer schreibt. Die Struktur des Containers ist ihm ja bekannt. • Anschließend wird eine Nachricht mit dem Op-Code START SCAN in die Queue der AudioDiscPlayer-Komponente geschrieben. • Die HMI wird solange blockiert (Warten auf ein Signal, synchroner Aufruf), bis eine Best¨ atigung des Befehls erhalten wird (ein R¨ uckgabewert wird in den Datencontainer geschrieben und ein Semaphor wird freigegeben). Die Nachricht wird, nachdem sie vom Controller empfangen und akzeptiert wurde, in einen Funktionsaufruf des MOST-Codecs umgewandelt, der darauf die entsprechende MOST-Nachricht zusammenbaut und versendet. 20.8.4 Menge der erlaubten High-Level-Aktionen Zur Vereinfachung der Steuerung wird zu jedem Zeitpunkt maximal nur eine High-Level-Aktion erlaubt. Im physikalischen Ger¨at ist festgelegt, welche Aktionen im Moment erlaubt sind, im Controller wird dies abgebildet. Wird eine neue Aktion ausgew¨ ahlt, so wird die gerade Laufende unterbrochen. Es ist f¨ ur die HMI auch sehr wichtig zu wissen, wann eine Aktion gestartet und beendet wird. Dieses Wissen ist leider unvermeidbar, da viele Ger¨ate ihre Anzeige auch in Abh¨angigkeit der Aktionen gestalten. Z.B. wird das Display w¨ahrend eines Suchlaufs in den Blink-Modus gewechselt. Je nach HMI-Strategie m¨ ussen Ist- und/oder Soll-Daten angezeigt werden. Z.B. werde f¨ ur den CD-Changer, der mechanisch sehr langsam ist, eine neue CD ausgew¨ahlt. Es kann spezifiziert sein, dass die neue gew¨ unschte CD solange blinkend oder grau angezeigt wird, bis die Ist-Daten den Wechsel best¨atigen. Wenn am Ende einer Aktion ein Fehler auftritt, muss die HMI die Anzeige eventuell wieder zur¨ ucknehmen. ¨ Es kann aber genauso gut auch gew¨ unscht sein, dass f¨ ur die Ubergangszeit beide Daten angezeigt werden. Im Controller wird festgelegt, ob w¨ahrend dieser Zeit neue Aktionen f¨ ur das angesteuerte Ger¨at zugelassen werden, in der Bedienlogik der HMI wird definiert, ob w¨ ahrend dieser Zeit andere Ger¨ate bedient werden d¨ urfen und welche. Eine Wiederherstellung des so genannten Last-Modes ist ebenfalls nicht ausgeschlossen. Auch kann eine wartende Aktion durch eine neue u ¨berschrieben werden. Es ist zu beachten, dass Aktionen nicht nur aus Men¨ us heraus angestoßen werden k¨onnen. Der Benutzer kann z.B. einen neuen Track anfordern und dann die EjectTaste am Player dr¨ ucken, so dass das Ger¨ at in einen Stop-Zustand kommt. F¨ ur die Ansteuerung der Aktionsmenge wird viel Fachwissen ben¨otigt.

20.8 Architektur eines Datencontainers

359

Abbildung 20.10. Expertenwissen in der Ger¨ atesteuerung

20.8.5 Abstrakte Klasse ADataContainerAccessor Wie im folgenden Abschnitt beschrieben wird, muss der MOST-Codec aufgrund seiner generischen Architektur auf verschiedene Datencontainer zugreifen. Um dies zu erm¨ oglichen, verwendet er nur eine abstrakte Accessor-Klasse, die verschiedene Zugriffsmethoden u ¨ber Index erlaubt. Die abgeleiteten Klassen m¨ ussen die rein virtuellen Methoden implementieren.

class ADataContainerAccessor { public: ADataContainerAccessor (); virtual ~ ADataContainerAccessor (); virtual void lock() = 0; virtual void unlock() = 0; virtual bool hasDevice() = 0; virtual void setDeviceStatus(bool hasDevice) = 0; //get corresponding flag the data stored numbered by index //index position in data container virtual bool& getValidFlag(UInt8 index) = 0; //get address of an actual variable using an index //index of the variable; virtual void * getActualVarPtr(UInt8 varIndex) = 0; //get address of actual variable using index and an offset //index of the variable (an array or a structure)

360

20 Modell-Komponenten, logische Ger¨ ate virtual void * getActualVarPtr(UInt8 varIndex, UInt8 offset) = 0; //get address of actual variable using index and 2 offsets //first describes position of array element (its a record) //second one describes the position in the record virtual void * getActualVarPtr(UInt8 varIndex, UInt8 offsetX, UInt8 offsetY) = 0; //get address of variable describing actual array length virtual UInt16 * getActualArrayLength(UInt8 varIndex) = 0; //similar comments for expected ones virtual void * getExpectedVarPtr(UInt8 varIndex) = 0; virtual void * getExpectedVarPtr(UInt8 varIndex, UInt8 offset) = 0; virtual void * getExpectedVarPtr(UInt8 varIndex, UInt8 offsetX, UInt8 offsetY) = 0; virtual UInt16 * getExpectedArrayLength(UInt8 varIndex) = 0; //utilities to simplyfy the access to the bool& getActualBool(UInt8 varIndex); bool& getActualBool(UInt8 varIndex, UInt8 bool& getActualBool(UInt8 varIndex, UInt8 Int8& getActualInt8(UInt8 varIndex); Int8& getActualInt8(UInt8 varIndex, UInt8 Int8& getActualInt8(UInt8 varIndex, UInt8

data offset); offsetX, UInt8 offsetY); offset); offsetX, UInt8 offsetY);

//similar methods for other data types //... similar methods for expected data //helper method static void copyContent(CByteVector& aByteVector, const DataBuffer& aBuffer); static void copyContent(CString& aString, const StringBuffer& aBuffer); private: //to avoid misuse - no implementation ADataContainerAccessor(const CDataContainerBase&); ADataContainerAccessor& operator=(const ADataContainerAccessor &); }; ... inline bool& ADataContainerAccessor::getActualBool(UInt8 varIndex) { return *(reinterpret_cast(getActualVarPtr(varIndex))); } inline bool& ADataContainerAccessor:: getActualBool(UInt8 varIndex, UInt8 offset)

20.8 Architektur eines Datencontainers

361

{ return *(reinterpret_cast(getActualVarPtr(varIndex,offset))); } ... Listing 20-7. Abstrakte Klasse ADataContainerAccessor.h

Die Zugriffsmethoden getActualBool usw. stehen dem Anwender zur Verf¨ ugung; da die Verwendung eher unwahrscheinlich ist, werden sie inline implementiert und verbrauchen deshalb keinen Platz, falls sie nicht verwendet werden. Ein Teil eines konkreten Accessors f¨ ur den AudioDiscPlayer sieht dann etwa wie folgt aus: Der Datencontainer wird im Konstruktor u ¨bergeben. Die abgeleitete Klasse muss die genauen Bedeutungen der Strukturelemente kennen, um auf sie zuzugreifen.

CAudioDiscPlayerDCAccessor:: CAudioDiscPlayerDCAccessor(CAudioDiscPlayerDCShared & aSharedData) : ADataContainerBase(), mSharedData(aSharedData) { // all infos are invalid memset(mSharedData.mFlagArray, 0, sizeof(mSharedData.mFlagArray)); } ... void* CAudioDiscPlayerDCAccessor::getActualVarPtr(UInt8 varIndex) { switch (varIndex) { case SOURCE_INFO_IDX: return &mSharedData.mActualSourceInfo; case SOURCE_NAME_IDX: return &mSharedData.mActualSourceName; .... //similar case REPEAT_STATE_IDX: return &mSharedData.mActualRepeatState; case DEEMPHASIS_IDX: return &mSharedData.mActualDeemphasis; default: // END_OF_IDX return 0; } } Listing 20-8. Teilimplementierung CAudioDiscPlayerDCAccessor

Hinweis: Man kann an dieser Stelle den Zugriff auf die Daten optimieren, in dem man den Offset der Variablen verwendet. Dabei m¨ ussen die Zeiger auf den Typ

362

20 Modell-Komponenten, logische Ger¨ ate

char-Zeiger umgewandelt werden. Die Bestimmung des Offsets erfolgt dann durch Subtraktion zweier Zeiger. Ein Zeiger zeigt auf den Beginn der Struktur, der andere auf eine Variable in der Struktur, wobei der Zeiger auf den Beginn der Struktur nur deklariert werden muss. Er braucht nicht angelegt zu werden (wir verwenden die Adresse 0 f¨ ur diesen Zweck). Die Zugriffsfunktion besteht dann im Wesentlichen aus einer Addition des Offsets zum this-Zeiger.

struct Test { int a; int b; bool c; };

#define CONST_PTR(S) (const S*) (0) #define OFFSET(S, var) (const char *)&((CONST_PTR(S))->var) - (const char*)(CONST_PTR(S))

\

enum OFFSET { A_OFFSET = OFFSET(Test, a), B_OFFSET = OFFSET(Test, b), C_OFFSET = OFFSET(Test, c) }; int main() { cout << A_OFFSET << " " << B_OFFSET << " " << C_OFFSET << endl; Test container; int * bPtr = reinterpret_cast (reinterpret_cast (&container) + B_OFFSET); *bPtr = 5; //einfaches Zugriffs-Beispiel bool * cPtr = reinterpret_cast (reinterpret_cast (&container) + C_OFFSET); *cPtr = true; //einfaches Zugriffs-Beispiel return 0; } Listing 20-9. Enum-Index f¨ ur den Datenzugriff

20.9 MOST-Codec

363

Bei der Zeigerarithmetik muss man beachten, dass der Typ eines Objekts eine große Rolle spielt. Bei der Definition der Konstanten sowie bei der Adressenbestimmung muss man alle beteiligten Zeiger in den Typ Zeiger auf Zeichen umwandeln. Dann kann der Compiler auf Grund seines statischen Wissens u ¨ber die Struktur die Offsets ohne Alignment-Probleme berechnen.

20.9 MOST-Codec Der MOST-Codec dient zur Dekodierung empfangener MOST-Nachrichten und zur Generierung geeigneter MOST-Nachrichten zum Versenden. Bekannte Ans¨ atze erzeugen zur Laufzeit einen Parser-Baum, der die verschiedenen MOST-Nachrichten dekodieren kann. Dies geschieht zur Laufzeit, weil erst dann die verschiedenen Objekte aus den Klassen lokal erzeugt werden. Vern¨ unftiger ist es, diesen Baum schon zur Compilier-Zeit zu erzeugen, da alle Informationen u ogliche Nachrichten in der MOST-Spezifikation ¨ber m¨ vorliegen. Verwendet man einfache statische Strukturen aus Elementardatentypen, so k¨onnen die Objekte schon zur Kompilierzeit festgelegt und im Datensegment angelegt werden. Beginnen wir mit dem Empfang der Nachricht und fassen den Durchlauf einer MOST-Nachricht von außen noch einmal zusammen: • Ein externes MOST-Device sendet eine Nachricht an eine Komponente in der Headunit. • Der zentrale Main-Dispatcher empf¨ angt die Nachricht aus dem Treiber, liest FBlock- und InstID und sendet die Nachricht in die Queue der entsprechenden Komponente. • Der Komponenten-Dispatcher sendet die Nachricht weiter an den Steuerautomaten, der ggf. den MOST-Codec beauftragt, den Datenteil der Nachricht mithilfe der MOST-Syntax zu zerlegen. • Die Daten werden in den Datencontainer geschrieben. • Der Automat informiert ggf. die HMI mit einem Update-Event. Im Folgenden besch¨ aftigen wir uns mit der Dekodierung einer MOSTNachricht. Zur Illustration der Vorgehensweise nehmen wir die Nachricht f¨ ur die Information AudioDiscInfo. Das Enkodieren einer MOST-Nachricht verl¨auft a¨hnlich. 20.9.1 Vorbereitung Da unsere Kommunikation u ¨ber CMessage-Objekte stattfindet und ein solches Objekt in einigen F¨ allen die MOST-Nachricht nicht vollst¨andig transportieren kann, wird eventuell ein Zeiger in der Nachricht mitgegeben, der auf ein

364

20 Modell-Komponenten, logische Ger¨ ate

(in der Regel verkettetes) Objekt in einem Pool zeigt. Um die Verwendung zu vereinfachen, wird eine Adapterklasse CMostInStream entworfen, die den Zugriff auf die Daten kapselt. Sie baut auf einem u ¨bergebenen existierenden Buffer auf, den sie nicht ver¨ andert. In wenigen Anwendungen (z.B. bei der Navigation) k¨onnen lange Datenstr¨ ome auftreten. Um sie zu lesen, wird intern in jeder Komponente im MOST-Handler ein privater Buffer verwendet, der bei der Konstruktion des CMOSTInStream-Objekts mitgegeben wird. Der Nachrichtenstrom wird ggf. in den Buffer kopiert. Die entsprechenden Zeiger werden angepasst, so dass die folgenden Lesemethoden einheitlich sind. Treten beim Lesen Fehler auf, so wird ein Fehlercode in dem Objekt gemerkt. Da ¨ ein Ubertragungsfehler selten ist, wird der Fehlercode in allen F¨allen erst am Ende mit der getError-Methode u uft. ¨berpr¨

class CMOSTInStream { public: enum ErrorTypeEnum //different masks for errors { BOOLEAN_OUT_OF_RANGE = 0x01, ENUM_OUT_OF_RANGE = BOOLEAN_OUT_OF_RANGE, NUMBER_OUT_OF_RANGE = ENUM_OUT_OF_RANGE, ARRAY_INDEX_OUT_OF_RANGE = 0x02, RECORD_POS_OUT_OF_RANGE = 0x04, STRING_WRONG_CODING = 0x08, STRING_TOO_LONG = 0x10, STREAM_TOO_LONG = 0x20, STREAM_TOO_SHORT = 0x40, MESSAGE_TOO_SHORT = 0x80 }; CMOSTInStream (CMessage & msg, UInt8* buffer = 0, UInt16 lengthOfBuffer = 0); ~ CMOSTInStream (); UInt16 getFBlock() const; UInt8 getInstanceID() const; UInt8 getOpType() const; //read the optype of the MOST-Message UInt16 getFuncID() const; void readBool(bool& aVal); //different read methods for the void readInt8(Int8& aVal); //basic data types supported by void readUInt8(UInt8& aVal); //MOST void readInt16(Int16& aVal); void readUInt16(UInt16& aVal); void readInt32(Int32& aVal); void readUInt32(UInt32& aVal);

20.9 MOST-Codec

365

//read MOST-String into a buffer //maxLength of string expected (terminate char NOT counted) void readStringBuffer(StringBuffer& aBuffer, UInt16 maxLength); //read a byte stream from MOST-stream void readDataBuffer(DataBuffer& aBuffer, UInt16 minLength, UInt16 maxLength); //check whether the stream is OK so far bool isOK(void) const; //check if end of stream is reached bool isEndOfStream(void) const; void setError(ErrorTypeEnum anError); //set error occurred UInt8 getError() const; private: CMOSTInStream(const CMOSTInStream& other); //to avoid misuse CMOSTInStream& operator = (const CMOSTInStream& other); //check if further data available bool checkStream(UInt16 length); const const const const UInt8

CMessage& mMsg; UInt8* const mBufferPtr; UInt8* const mEndPtr; UInt8* mCurrentPtr; mErrorFlags;

//pointer to the data stream //mark the end of the data stream //pointer to the current position //flags for errors

}; Listing 20-10. Adapterklasse zum Lesen einer MOST-Nachricht

In der Adapterklasse k¨ ummern wir uns auch um die eventuell erforderliche Endian-Konvertierung. Ausschnittsweise zeigen wir die Implementierung einiger Methoden:

void CMOSTInStream::readBool(bool& aVal) { if (checkStream(1)) //still one byte left? { UInt8 val = *mCurrentPtr; mCurrentPtr++; if (val >= 2) //check whether the data is correct { //MOST bool is one byte value 0 or 1 setError(BOOLEAN_OUT_OF_RANGE); } aVal = (val == 1); //now true or false } }

366

20 Modell-Komponenten, logische Ger¨ ate

void CMOSTInStream::readUInt8(UInt8& aVal) { if (checkStream(1)) //still one byte left? { aVal = *mCurrentPtr; mCurrentPtr++; //inc. by one } } void CMOSTInStream::readInt8(Int8& aVal) { UInt8 tmp; readUInt8(tmp); aVal = static_cast (tmp); } void CMOSTInStream::readUInt16(UInt16& aVal) { UInt8 high, low; //NOTE we must use a macro readUInt8(high); //depending on little or big endian readUInt8(low); //(for word) aVal = MAKE_UINT16(low, high); } void CMOSTInStream::readInt16(Int16& aVal) { UInt16 tmp; readUInt16(tmp); aVal = static_cast(aVal); } //... void CMOSTInStream::readDataBuffer(DataBuffer& aBuffer, UInt16 minLength, UInt16 maxLength) { //how many bytes are available UInt16 availableLength = (mEndPtr - mCurrentPtr); if (availableLength < minLength) //less than minimum required => { //error setError(STREAM_TOO_SHORT); return; } else if (availableLength > maxLength) { setError(STREAM_TOO_LONG); //longer than the allowed => error return; } else { //read stream and set data buffer

20.9 MOST-Codec

367

memcpy(&(aBuffer.mBuffer[0]), mCurrentPtr, availableLength); aBuffer.mLength = availableLength; mCurrentPtr = mEndPtr; } } bool CMOSTInStream::checkStream(UInt16 length) { if (mCurrentPtr + length <= mEndPtr) { return true; } else { setError(MESSAGE_TOO_SHORT); return false; } } Listing 20-11. Einige Methoden aus CMOSTInStream

20.9.2 Einfache Implementierung eines MOST-Decoders Aufgrund der FuncID wird eine entsprechende Funktion aufgerufen. Die Funktion kennt die Struktur der Nachricht, die Adressen und Namen der Variablen und kann die Nachricht zerlegen. Die komplexeste MOST-Nachricht ist die ¨ Ubertragung eines Array of Record. Dabei werden gem¨aß MOST-Protokoll zwei Informationen mit u ¨bertragen: eine Position im Array und eine Position im Record, wobei die Indexierung vom u ¨blichen Gebrauch abweicht. Eine 0 bedeutet hier alle Elemente des Arrays oder Records, die Indexierung beginnt dann bei 1. F¨ ur AudioDiskInfo sieht der Pseudo-Code etwa so aus: Hole die Array-Position und Record-Position in der MOST-Nachricht und interpretiere sie entsprechend des MOST-Protokolls: • Fall 1: Array-Position und Record-Position sind Null: In diesem Fall muss das ganze Array (und alle Strukturen zu den Elementen) neu gelesen werden. Der Rest der Nachricht umfasst Daten der Array-Elemente. • Fall 2: Array-Position == 0 und Record-Position != 0. In diesem Fall werden alle Struktur-Elemente des Arrays an der Stelle (Record-Position – 1, Index f¨angt bei 0 an) u ¨bertragen. Eine Schleife zum Einlesen der Elemente ist notwendig. • Fall 3: Array-Position != 0 und Record-Position == 0. Das Array-Element an der Stelle Array-Position -1 wird neu eingelesen. • Fall 4: Array-Position und Record-Position sind ungleich Null. In diesem Fall wird nur ein Struktur-Element ver¨ andert.

368

20 Modell-Komponenten, logische Ger¨ ate

In einer ersten einfachen Implementierung muss eine Funktion f¨ ur die Klasse CAudioDiscPlayer geschrieben werden. Die Funktion hat internes Wissen u ¨ber den Aufbau des Datencontainers, so dass sie auf die einzelnen Elemente zugreifen kann.

void CAudioDiscPlayerDecoder::readAudioDiscInfo(CMOSTInStream& aStream) { UInt8 arrayPos; UInt8 recordPos; //lies array- und record-Position von MOST-Nachricht aStream.readUInt8(arrayPos); aStream.readUInt8(recordPos); if (0 == arrayPos) //ganzes Array muss eingelesen werden { UInt8 posX; //array index if (0 == recordPos) // alle Elemente des Records lesen { //die L¨ ange des Arrays wird zur¨ uckgesetzt, //da wir ein neues Array lesen mDataContainer.mActualAudioDiscInfoArrayLength = 0; //liest alle Elemente. beachte, dass //maximal 99 Elemente erlaubt sind for (posX = 0; (posX < 99) && (false == aStream.isEndOfStream()); ++posX) { //liest die entsprechende Struktur readAudioDiscInfoRecord(posX, aStream); mDataContainer.mActualAudioDiscInfoArrayLength ++; } } else //nur Element der Struktur wird angesprochen { if (recordPos > 4) { //¨ Uberpr¨ ufe, ob die Position erlaubt ist oder nicht aStream.setError(CMOSTInStream::RECORD_POS_OUT_OF_RANGE); //falscher Index! return; } for (posX = 0; posX < mDataContainer.mActualAudioDiscInfoArrayLength; ++posX) { readAudioDiscInfoRecordElement(posX, recordPos-1, aStream); //liest die Daten der Elemente } } } else //nur ein Element ist adressiert {

20.9 MOST-Codec

369

//An dieser Stelle ist <= beabsichtigt! ein arrayPos //ist indiziert von 1. D.h. Elemente Nr 99 ist auch erlaubt //das Wachsen ist nur erlaubt f¨ ur eine ganze Struktur if (arrayPos <= 99 && arrayPos==mDataContainer.mActualAudioDiscInfoArrayLength + 1 && 0 == recordPos) { mDataContainer.mActualAudioDiscInfoArrayLength ++; } else if (arrayPos > mDataContainer.mActualAudioDiscInfoArrayLength) { //falsche Position ? aStream.setError(CMOSTInStream::ARRAY_INDEX_OUT_OF_RANGE); return; } if (0 == recordPos) //ganze Struktur ist adressiert? { readAudioDiscInfoRecord(arrayPos-1, aStream); } else //nur ein Element { //Ist die Position erlaubt? if (recordPos > 4) { aStream.setError(CMOSTInStream::RECORD_POS_OUT_OF_RANGE); //falscher Index! return; } readAudioDiscInfoRecordElement(arrayPos-1, recordPos-1, aStream); } } } Listing 20-12. Dekodierung

Nachdem die Nachricht gelesen wird, kann der Aufrufende u ufen, ob der ¨berpr¨ MOST-Stream in Ordnung ist. Falls ja, kann eine Benachrichtigung an die HMI geschickt werden. Treten beim Lesen Probleme auf, so wird ein entsprechender Fehler in dem CMOSTInStream-Objekt gemerkt. Die obige Implementierung ist zwar einfach, hat aber aufgrund der engen Beziehung zu den Besonderheiten der AudioDiscPlayer-Beschreibung einen schwerwiegenden Nachteil: Der Code zum Lesen von Arrays, Strukturen, Arrays von Strukturen usw. muss f¨ ur jede Komponente neu geschrieben werden, obwohl sie sich nur in wenigen Stellen unterscheiden. Das ist schlecht f¨ ur die Wartung. Wenn die Logik zum Lesen angepasst werden soll, m¨ ussen viele Klassen ge¨andert werden. Dieser Nachteil kann mithilfe eines Codegenerators

370

20 Modell-Komponenten, logische Ger¨ ate

im vertretbaren Maß reduziert werden. Es wird aber sehr viel Code produziert, was die Start-Up-Zeiten und den Speicherbedarf stark beeinflusst. 20.9.3 Objektorientierter Ansatz Um den Nachteil der obigen Implementierung zu eliminieren, werden Klassen eingef¨ uhrt, die alle Gemeinsamkeiten kapseln. Ein Objekt der Klasse CArrayOfRecord etwa hat die notwendigen Informationen, um die Nachricht zu dekodieren. Ein Objekt dieses Typs braucht den konkreten Datencontainer nicht zu kennen. Es reicht aus, dass es Zeiger oder Referenzen auf den Datencontainer und ggf. andere Datenelemente besitzt. Das Objekt hat unter anderem folgende Datenelemente: • Die maximale L¨ ange des Arrays (mMaxArrayLength). • Ein Objekt, das die Strukturen der Elemente dekodieren kann. Das Objekt wiederum ist ein Container oder eine Liste von Objekten, die die einzelnen Struktur-Elemente kennen (mRecordDecoder). • Die Adresse von AudioDiscInfo-Array sowie die Gr¨oße der Struktur, dies ist notwendig f¨ ur die Berechnung von mStartAddress und mRecordSize. • Referenz auf die Array-L¨ ange mArrayLength. Viele dieser Datenelemente k¨ onnen zur Laufzeit u ¨ber den Accessor erhalten werden. In etwa sieht die decode-Methode wie folgt aus:

void CArrayOfRecord::decode(CMOSTInStream& aStream) { UInt8 arrayPos; UInt8 recordPos; UInt8* adr = mStartAddress; aStream.readUInt8(arrayPos); aStream.readUInt8(recordPos); if (0 == arrayPos) //whole array will be read { UInt8 posX; //for index of array if (0 == recordPos) //full record { mArrayLength = 0; for (posX = 0; (posX < mMaxArrayLength) && (false == aStream.isEndOfStream()); ++posX, adr += mRecordSize) { mRecordDecoder.decode(adr, aStream); mArrayLength++; }

20.9 MOST-Codec

371

} else //element of record is addressed (for all array elements) { for (posX = 0; posX < arrayLength; ++posX, adr += mRecordSize) { mRecordDecoder.decode(adr, aStream, recordPos-1); } } } else //only one array element is addressed { if (arrayPos <= mMaxArrayLength && arrayPos == mArrayLength + 1 && recordPos == 0) { mArrayLength++; } else if (arrayPos > mArrayLength) { aStream.setError(CMOSTInStream::ARRAY_INDEX_OUT_OF_RANGE); return; } adr += (arrayPos-1)*mRecordSize; if (0 == recordPos) //whole record is addressed { mRecordDecoder.decode(adr, aStream); } else //single element { mRecordDecoder.decode(adr, aStream, recordPos-1); } } } Listing 20-13. Weitere Dekodierm¨ oglichkeit

Diese L¨osung ist eleganter als die letzte. Jede MOST-Nachricht wird durch ein entsprechendes Objekt geparst. Der Nachteil der Codewiederholung wird dadurch reduziert. Auch diese L¨ osung hat Nachteile: • F¨ ur jede Komponente muss ein Container von Objekten zur Laufzeit angelegt werden. Jedes Objekt ist daf¨ ur zust¨ andig, eine bestimmte MOSTNachricht zu dekodieren. Ein Objekt kann weitere Objekte beinhalten. Ferner m¨ ussen die Objekte mit entsprechenden Daten konfiguriert werden. In dem obigen Beispiel haben wir ein Objekt vom Typ CArrayRecord, das in seinem Konstruktor ein Objekt f¨ ur Struktur, die maximale Arrayl¨ange, die Startadresse des Arrays sowie die Gr¨ oße der einzelnen Struktur erwartet. Alternativ dazu kann das Objekt einen Index und einen Accessor erhalten und daraus die notwendige Information ablesen.

372

20 Modell-Komponenten, logische Ger¨ ate

• Es werden dynamische Datentypen ben¨ otigt, weil Anzahl und Typ der Elemente der Strukturen verschieden sind. F¨ ur jede Struktur wird ein Container eingef¨ uhrt. • Das Konzept der virtuellen Methoden muss eingesetzt werden, um die Polymorphie der Strukturen zu gew¨ ahren (die Methode decode von mRecorderDecode muss virtuell sein). Objekte k¨onnen erst zur Laufzeit angelegt werden, da der Datencontainer in der Regel im Shared-Memory konstruiert wird und die Adresse am Anfang nicht als bekannt vorausgesetzt werden darf. Die Aufrufe der Konstruktoren am Anfang f¨ uhren zu einer Zusatzbelastung f¨ ur die Start-Up-Zeit. 20.9.4 Objekte zur Kompilierzeit Eine andere L¨osung ist eine Technik, die versucht, zur Kompilierzeit einen konstanten Strukturen-Baum“ anzulegen. Der Baum beinhaltet gen¨ ugend ” Information, so dass zur Laufzeit die MOST-Nachrichten effizient dekodiert werden k¨onnen. Die Zeit zur Konstruktion des Strukturen-Baums muss klein gehalten werden. D.h., die Objekte sollten nicht u ¨ber aufw¨andige Konstruktoren, sondern weitgehend u ¨ber einfaches und schnelles memcopy initialisiert werden. Die wesentlichen Vorteile sind dann die verk¨ urzten Start-Up-Zeiten und die Vermeidung dynamischer Datentypen. Verwendet man einfache Strukturen aus Elementardatentypen, so k¨onnen die Objekte schon zur Kompilierzeit festgelegt und im Code- oder im Datensegment angelegt werden. Dabei wird der im Folgenden beschriebene Trick angewendet. Es ist bekannt, dass gilt: Die elementweise Initialisierung einer Strukturvariablen ist nur dann m¨ oglich, wenn alle Bestandteile der Struktur so genannte Plain-Old-Data sind. Zur Erinnerung trifft dies f¨ ur elementare Datentypen, Zeiger, Felder, Verbunde, unions und Klassen zu, vorausgesetzt, der betreffende Typ definiert keine besondere Funktion zur Initialisierung seiner Bestandteile (ein Konstruktor). Dabei werden die Konstanten, wie im Teil I beschrieben wurde, entweder im Text- oder im Datensegment untergebracht, je nach Compiler und nach Situation.

struct test { int a, int b; }; const test CONST1 = {1, 2}; const test CONST2 = {3, 4}; const test* const ptr = &CONST2; Listing 20-14. Objekte zur Kompilierzeit

20.9 MOST-Codec

373

Im obigen Beispiel kann es vorkommen, dass CONST1 im Textsegment und CONST2 im Datensegment angelegt werden. Die Initialisierungen der beiden Variablen sind aber selbst im ung¨ unstigsten Fall nur einige Kopierbefehle. Es werden dabei keine Konstruktoren aufgerufen (es sieht anders aus, wenn ein Konstruktor f¨ ur die Struktur existiert). Bei jeder Vererbung f¨ ugt der Compiler, wenn kein Konstruktor geschrieben wurde, einen Default-Konstruktor hinzu, der den Default-Konstruktor der Basisklasse aufruft. Damit akzeptiert der Compiler keine Initialisierungslisten f¨ ur abgeleitete Klassen mehr. Das bedeutet, dass wir unsere konstanten Objekte in der Regel nur durch Aufrufen von Konstruktoren anlegen k¨onnten. Da aber alle Klassen f¨ ur den MOST-Codec nur einfache Vererbung und keine virtuelle Methode haben sollen, k¨ onnen wir sie u ¨ber den unten stehenden Umweg/Trick initialisieren:

struct A { int a; }; struct B: public A { int b; }; struct C { int a; int b; }; const C CONST = {1, 2}; const B& B_CONST = reinterpret_cast(CONST); Listing 20-15. Objekte im Code- und Datensegment

Dabei wird das Wissen u ¨ber das Objekt-Layout verwendet. Der Compiler realisiert, solange keine virtuellen Methoden existieren, die Daten f¨ ur die Vererbung wie eine Komposition. Wir hatten diesen Trick im Teil I bereits kurz vorgestellt, nun verwenden wir ihn f¨ ur die Dekodierung von MOST-Nachrichten.

374

20 Modell-Komponenten, logische Ger¨ ate

20.9.5 Konstante Objekte zur Dekodierung der MOST-Nachrichten Verschiedene Nachrichten haben ganz verschiedene Kombinationen verschiedener in MOST spezifizierter Datentypen. MOST kennt 10 verschiedene elementare Datentypen.

enum ElementarTypeEnum { BOOLEAN, ENUM, INT8, INT16, INT32, UINT8, UINT16, UINT32, STRING, STREAM }; Listing 20-16. MOST-Datentypen

Da es z.B. zu einem MOST-Enum-Typ ein Minimum, ein Maximum und ggf. ein Array von konstanten Werten gibt, reicht ein ElementarTypeEnum-Wert nicht aus. Um die Einschr¨ ankungen und Nebenbedingungen der elementaren MOST-Datenobjekte zu beschreiben, werden folgende Strukturen mit Vererbungen eingesetzt:

Abbildung 20.11. Hierarchie der elementaren MOST-Datentypen

struct CTypeInfo { MOST::ElementarTypeEnum mType; } class CMOSTEnum : public CTypeInfo { public: void read(void* varPtr, CMOSTInStream& aStream) const; void write(void* varPtr, CMOSTOutStream& aStream) const; bool isValid(UInt8 aVal) const; UInt8 mMin; //min value of the enumeration

20.9 MOST-Codec UInt8 mMax;

375

//max value of the enumeration //The following two information are needed if values //are not in a normal order between min and max: //length of the array (0 = not needed) and the //array containing the allowed values

UInt8 mLength; //array containing the allowed values const UInt8* mAllowedValArray; }; //end of class CMOSTEnum class CMOSTInt8: public CTypeInfo { public: void read(void* varPtr, CMOSTInStream& aStream) const; void write(void* varPtr, CMOSTOutStream& aStream) const; bool isValid(Int8 aVal) const; Int8 mMin; Int8 mMax; Int8 mStep; Int8 mExponent; UInt8 mUnit; }; //end of class CMOSTInt8 .. similar declaration for CMOSTUInt16,.. CMOSTUInt32 class CMOSTString: public CTypeInfo { public: void read (void* varPtr, CMOSTInStream& aStream) const; void write(void* varPtr, CMOSTOutStream& aStream) const; bool isValid(UInt16 aLength) const; UInt16 mMaxLength; //max length of the string ( in number of char //char for terminated zero is also included) }; //end of class CMOSTString class CMOSTStream : public CTypeInfo { public: void read(void* varPtr,CMOSTInStream& aStream) const; void write(void* varPtr, CMOSTOutStream& aStream) const; bool isValid(UInt16 aLength) const; UInt16 mMinLength; //min length of the stream UInt16 mMaxLength; //max length of the stream }; //end of class CMOSTStream Listing 20-17. CTypeInfo und CMOSTEnum zur Beschreibung der MOST-Datentypen

376

20 Modell-Komponenten, logische Ger¨ ate

Die Struktur CTypeInfo beschreibt einen elementaren MOST-Typen. Ein ¨ Objekt dieses Typs wird sp¨ ater zum Uberpr¨ ufen und Auswerten der Daten/Properties gebraucht werden. Das Attribut mType wird verwendet, um Ersatz f¨ ur Polymorphie zu erhalten (es wird dabei ein Downcast durchgef¨ uhrt).

void invokeRead(const CTypeInfo* objPtr, void* varPtr, CMOSTInStream& aStream) { switch (objPtr->mType) { case MOST::BOOLEAN: (static_cast(objPtr))->read(varPtr,aStream); break; case MOST::ENUM: (static_cast(objPtr))->read(varPtr, aStream); break; case MOST::INT8: (static_cast(objPtr))->read(varPtr, aStream); break; ... similar ... case MOST::STRING: (static_cast(objPtr))->read(varPtr, aStream); break; deault: // MOST::STREAM (static_cast(objPtr))->read(varPtr, aStream); break; } } Listing 20-18. Die Methode invokeRead

Um ein konstantes Objekt, z.B. vom Typ CMOSTInt8, zur Kompilierzeit anzulegen, werden eine Hilfsstruktur und ein Makro definiert:

//structure describes additional information for Int8 like min, //max etc. See the section about MOST number for details //This structure is used to create const at the compile time //A constant object of type CMOSTInt8 is created using //the reinterpret_cast struct MOSTInt8Type { MOST::ElementarTypeEnum mType;

20.9 MOST-Codec

377

Int8 mMin; Int8 mMax; Int8 mStep; Int8 mExponent; UInt8 mUnit; }; #define CONST_MOST_INT8(name,min,max,step,exponent,unit) \ const MOSTInt8Type name##_ = {MOST::INT8,min,max,step,exponent,unit}; \ const CMOSTInt8& name = reinterpret_cast(name##_) Listing 20-19. Hilfsstruktur

Da die Hilfsstruktur nur Old-Plain-Type beinhaltet, werden ihre Konstanten durch Initialisierungslisten zur Kompilierzeit angelegt. Durch Uminterpretieren dieses Objekts erhalten wir die gew¨ unschten Konstanten. Beipielsweise definieren wir ein konstantes Objekt vom Typ MOSTInt8Type mit sofortiger Initialisierung: CONST_MOST_INT8(abc, 1, 10, 1, 0, MOST::MILLI);

Der Precompiler expandiert das Makro zu: const MOSTInt8Type abc_ = { MOST::INT8, 1, 10, 1, 0, MOST::MILLI}; const CMOSTInt8& abc = reinterpret_cast(abc_);

Wir erwarten in den Modellen der Headunit nur Status-Meldungen der Komponenten. In den Meldungen stehen dann die Daten/Properties, die ausgewertet werden und ggf. an die HMI zur Anzeige gegeben werden m¨ ussen. Die Properties oder Daten in den MOST-Nachrichten k¨onnen in vier Typen klassifiziert werden. Es kann sich um Einzeldaten der oben genannten Datentypen handeln, um ein Array, um eine Struktur oder um ein Array von Strukturen. Im ModelTypeEnum ist festgelegt, welcher der vier Property-Typen gelesen werden muss:

enum ModelTypeEnum { SINGLE_PROP, RECORD_PROP, ARRAY_PROP, ARRAY_RECORD_PROP };

//Properties //einfache Property //ein Record //ein Array //ein Array of Record

Listing 20-20. ModelTypeEnum

378

20 Modell-Komponenten, logische Ger¨ ate

W¨ ahrend CTypeInfo den Typ der elementaren Daten beschreibt, wird eine neue Struktur CModelInfo eingef¨ uhrt, die die Struktur der MOST-Funktionen beschreibt. Jede MOST-Funktion besteht aus: • • • • • •

einem Typ, der beschreibt, wie die Property in der Nachricht gebaut ist (mType); einer Funktions-ID (mFuncID); einer Beschreibung (mInOpTypeMask) der erlaubten Operationen beim Empfang; einer Beschreibung (mOutOpTypeMask) der erlaubten Operationen beim Versenden; einem Flag (mUseAsyncChannel), das anzeigt, ob die Nachricht u ¨ber den asynchronen Kanal zu versenden ist oder nicht; einem Index, der den Offset des entsprechenden Datums im Datencontainer beschreibt.

struct CModelInfo { MOST::ModelTypeEnum UInt16 UInt16 UInt16 bool UInt8 };

mType; mFuncID; mInOpTypeMask; mOutOpTypeMask; mUseAsyncChannel; mVarIndex;

Listing 20-21. Basis-Struktur CModelInfo

Aus dieser CModelInfo-Struktur werden nun wie bei CTypeInfo vier verschiedene Varianten abgeleitet.

class CSingleProp : public CModelInfo { public: void read(ADataContainerBase& aDataContainer, CMOSTInStream& aStream) const; void write(ADataContainerBase& aDataContainer, CMOSTOutStream& aStream) const; void readError(ADataContainerBase& aDataContainer, CMOSTInStream& aStream) const; // index of the corresponding variable

20.9 MOST-Codec const CTypeInfo * mPropInfoPtr;

379

// info describing the property

}; class CRecordProp : public CModelInfo { public: void read(ADataContainerBase& aDataContainer, CMOSTInStream& aStream) const; void write(ADataContainerBase& aDataContainer, CMOSTOutStream& aStream) const; void readError(ADataContainerBase& aDataContainer, CMOSTInStream& aStream) const; // index of the corresponding variable UInt8 mNumOfFields; // Type description for the field elements // array of pointers to the field descriptions const CTypeInfo * const * mPropInfoPtrArray; }; class CArrayProp : public CModelInfo { public: void read(ADataContainerBase& aDataContainer, CMOSTInStream& aStream) const; void write(ADataContainerBase& aDataContainer, CMOSTOutStream& aStream) const; void readError(ADataContainerBase& aDataContainer, CMOSTInStream& aStream) const; // index of the corresponding variable UInt8 mMaxArrayLength; // Type description for the field element const CTypeInfo * mPropInfoPtr; }; class CArrayRecordProp : public CModelInfo { public: void read(ADataContainerBase& aDataContainer, CMOSTInStream& aStream) const; void write(ADataContainerBase& aDataContainer, CMOSTOutStream& aStream) const; void readError(ADataContainerBase& aDataContainer, CMOSTInStream& aStream) const;

380

20 Modell-Komponenten, logische Ger¨ ate

private: void readRecord(ADataContainerBase& aContainer, UInt8 arrayPos, CMOSTInStream& aStream) const; void readRecordElement(ADataContainerBase& aContainer, UInt8 arrayPos, UInt8 recordPos, CMOSTInStream& aStream) const; public: // max length of array UInt8 mMaxArrayLength; // Number of fields of the record UInt8 mNumOfFields; // Type description for the field element const CTypeInfo * const * mPropInfoPtrArray; }; Listing 20-22. Beschreibungen von MOST-Properties, Prototyp

Abbildung 20.12. Vier Varianten von CModelInfo

¨ Ahnlich wie oben haben wir auch hier eine Funktion, die mType auswertet und richtig downcastet.

void invokeRead(const CModelInfo* objPtr, ADataContainerBase& container, CMOSTInStream& aStream) { switch (objPtr->mType) { case MOST::SINGLE_PROP:

20.9 MOST-Codec

381

(static_cast(objPtr))->read(container,aStream); break; case MOST::ARRAY_PROP: (static_cast(objPtr))->read(container,aStream); break; case MOST::RECORD_PROP: (static_cast(objPtr))->read(container,aStream); break; default: (static_cast (objPtr))->read(container,aStream); break; } } Listing 20-23. Polymorphie-Ersatz f¨ ur CModelInfo

Wie bei CTypeInfo wird f¨ ur jede abgeleitete Klasse eine Hilfsstruktur angelegt und ein Makro definiert. Die komplizierteste Struktur ist CArrayRecordProp

struct ArrayRecordModelInfo { MOST::ModelTypeEnum mType; UInt16 mFuncID; UInt16 mInOpTypeMask; UInt16 mOutOpTypeMask; bool mUseAsyncChannel; UInt8 mVarIndex; UInt8 mMaxArrayLength; //max length of array //Number of fields of the record UInt8 mNumOfFields; //Type description for the field element const CTypeInfo* const* mPropInfoPtrArray; }; #define CONST_ARRAY_RECORD_PROP(name, fID, inM, outM, async, idx, \ maxArrLength, numFields, propInfo) \ const ArrayRecordModelInfo name##_ = \ {MOST::ARRAY_RECORD_PROP, fID, inM, outM, async, idx,\ maxArrLength, numFields, &propInfo[0]}; \ const CArrayRecordProp& name = \ reinterpret_cast(name##_) Listing 20-24. ModellInfo f¨ ur Array of Record, CArrayRecordProp.h

382

20 Modell-Komponenten, logische Ger¨ ate

F¨ ur jede Komponente und jede verf¨ ugbare Funktion werden Strukturen statisch angelegt und initialisiert, mit denen die Dekodierung unterst¨ utzt werden kann. F¨ ur die Funktion AudioDiscInfo haben wir folgende konstante Strukturen:

static CONST_MOST_STRING(sAudioDiscInfoAudioTitle, 50 + 1 ); static CONST_MOST_UINT32(sAudioDiscInfoAudioTime, UINT32_MIN, UINT32_MAX, 1, 0, MOST::MILLISEC ); static CONST_MOST_UINT16(sAudioDiscInfoAudioTrack, UINT16_MIN, UINT16_MAX, 1, 0, MOST::NONE ); static CONST_MOST_STRING(sAudioDiscInfoAudioFileName, 100 + 1 ); static const CTypeInfo* sAudioDiscInfoTypeInfoArray[] = { &sAudioDiscInfoAudioTitle, &sAudioDiscInfoAudioTime, &sAudioDiscInfoAudioTrack, &sAudioDiscInfoAudioFileName }; static CONST_ARRAY_RECORD_PROP(sAudioDiscInfoFunc, FID_AUDIO_DISC_INFO, MOST::OP_STATUS_MASK | MOST::OP_ERROR_MASK, 0, false, AUDIO_DISC_INFO_IDX, 99, //max array length 4, sAudioDiscInfoTypeInfoArray ); Listing 20-25. CArrayRecordProp-Struktur f¨ ur AudioDiscInfo

Es folgen auf die Funktions-IDs zwei Masken, die in- und die outOpTypeMask, von denen wir zum Dekodieren nur die in-Maske verwenden.

20.9 MOST-Codec

383

Mit AUDIO DISC INFO IDX wird sp¨ ater im Datencontainer indexiert, in dem die dekodierten Daten abgelegt werden. Auf den Audio-Index folgen die Anzahl der Elemente des Arrays und die Anzahl der Elemente der Struktur. Schließlich folgt die Adresse des sAudioDiscInfoTypeInfoArray, in dem wiederum Adressen der Parameterinformationen angegeben werden. Diese Unterinformationen sind die formalen Beschreibungen der zu lesenden Daten, mit denen zul¨ assige Grenzwerte u uft werden k¨onnen. ¨berpr¨ Was wir hier erkennen k¨ onnen, ist ein kleiner exemplarischer Zweig des zur Kompilierzeit erzeugten Parser-Baums. Beim Erhalten einer MOST-Nachricht kann aufgrund der Funktions-ID eine passende Beschreibung gefunden werden. Mit dem abgespeicherten EnumTyp wird die passende Methode gefunden.

void invokeRead(const CModelInfo* objPtr, ADataContainerAccessor& container, CMOSTInStream& aStream) { switch (objPtr->mType) { case MOST::SINGLE_PROP: (static_cast(objPtr)) ->read(container, aStream); break; case MOST::ARRAY_PROP: (static_cast(objPtr)) ->read(container, aStream); break; case MOST::RECORD_PROP: (static_cast(objPtr)) ->read(container, aStream); break; default: (static_cast(objPtr)) ->read(container, aStream); break; } Listing 20-26. Vom mType abh¨ angige Lesefunktion

Der Lesefunktion wird der Datencontainer, in den die dekodierten Informationen abgespeichert werden, mitgegeben. Schließlich wird das CMOSTInStreamObjekt als Parameter u ¨bergeben, das die Basisfunktionen zum Lesen und den Lesepuffer selbst bereitstellt. Die Implementierung f¨ ur ein Array von Struktur ist dann:

384

20 Modell-Komponenten, logische Ger¨ ate

void CArrayRecordProp::read(ADataContainerAccessor & aDataContainer, CMOSTInStream& aStream) const { //to read the poxX, posY position (ArrayPos + 1, RecordPos + 1) UInt8 posX; UInt8 posY; aStream.readUInt8(posX); //read array and record pos aStream.readUInt8(posY); UInt16& arrayLength //length of the array = *(aDataContainer.getActualArrayLength(mVarIndex)); if (0 == posX) //whole array will be read { UInt8 i; //for index of array if (0 == posY) //full record { //reset array length because we read a new array //go through the array and read the record element arrayLength = 0; for (i = 0; (i < mMaxArrayLength) && (false == aStream.isEndOfStream()); ++i) { readRecord(aDataContainer, i, aStream); arrayLength++; } } else //address element of record (for all array element) { if (posY > mNumOfFields) //check the position { aStream.setError(CMOSTInStream::RECORD_POS_OUT_OF_RANGE); //out of record range! return; } for (i = 0; i < arrayLength; ++i) { readRecordElement(aDataContainer, i, posY - 1, aStream); } } } else //only one array element is addressed { //allow to grow the array if ( (posX <= mMaxArrayLength) && (posX == arrayLength + 1) && (0 == posY))

20.9 MOST-Codec

385

{ arrayLength++; } else if (posX > arrayLength) { aStream.setError(CMOSTInStream::ARRAY_INDEX_OUT_OF_RANGE); return; } if (0 == posY) //whole rec is addressed { readRecord(aDataContainer, posX - 1, aStream); } else //single element { if (posY > mNumOfFields) //check the position { aStream.setError(CMOSTInStream::RECORD_POS_OUT_OF_RANGE); return; } readRecordElement(aDataContainer, posX - 1, posY - 1, aStream); } } } void CArrayRecordProp:: readRecord(ADataContainerAccessor & aDataContainer, UInt8 arrayPos, CMOSTInStream& aStream) const { void *varPtr; for (UInt8 j = 0; j < mNumOfFields; ++j) { varPtr = //get the address of the element aDataContainer.getActualVarPtr(mVarIndex, arrayPos, j); //get the corresponding TypeInfo const CTypeInfo* typeInfo = mPropInfoPtrArray[j]; invokeRead(typeInfo, varPtr, aStream); } } void CArrayRecordProp:: readRecordElement(ADataContainerAccessor& aDataContainer, UInt8 arrayPos, UInt8 recordPos, CMOSTInStream& aStream) const { void *varPtr; //get the address of the element varPtr = aDataContainer.getActualVarPtr(mVarIndex, arrayPos, recordPos);

386

20 Modell-Komponenten, logische Ger¨ ate //get the corresponding TypeInfo const CTypeInfo* typeInfo = mPropInfoPtrArray[recordPos]; invokeRead(typeInfo, varPtr, aStream); Listing 20-27. Lesefunktion f¨ ur Array of Record

Aufgrund der invokeRead-Methode wird die passende Methode zum Einlesen des Datums ermittelt. Die Funktion zum Einlesen eines Enum sieht wie folgt aus:

void CMOSTEnum::read(void* varPtr, CMOSTInStream& aStream) const { //get reference to actual value UInt8& actualVal = *(reinterpret_cast(varPtr)); aStream.readUInt8(actualVal); //read new value //check value in prescribed range? if (false == isValid(actualVal)) { //If not set the error aStream.setError(CMOSTInStream::ENUM_OUT_OF_RANGE); } } bool CMOSTEnum::isValid(UInt8 aVal) const { if ( (mMin > aVal) || (mMax < aVal)) { return false; } //check if array of allowed values is specified //if yes we must compare the value //array of specified values for Enum exists (rarely happens) if (mLength == 0) { return true; } const UInt8* valArray = mAllowedValArray; for (UInt8 i = 0; i < mLength; ++i) { //if (valArray[i]==val) if (*valArray++ == aVal) { //for efficiency we can use the this construct return true; } } return false; //not found } Listing 20-28. Lesen von Enum

20.10 Zusammenfassung

387

Das Dekodieren einer Nachricht verl¨ auft analog. ¨ Auch wenn die Uberlagerung konstanter Strukturen ein wenig trickreich anmutet, bringt diese L¨ osung viele Vorteile. Sie kann einige Sekunden Startzeit sparen und einen Faktor 5-10 an Speicherplatz (je nach Gr¨oße des ParserBaums) gegen¨ uber dem Anlegen eines dynamischen Parser-Baums auf dem Heap zur Laufzeit. Auch ist die L¨ osung einfach und vermeidet viele Implementierungsfehler, die durch Komplexit¨ at entstehen k¨onnten.

20.10 Zusammenfassung Eine Besonderheit in unserer Vorgehensweise ist die Trennung von Zugriffsmethoden und Daten. Die Daten sind in reinen C-Strukturen untergebracht. Es gibt keine dynamischen Daten. Der Datencontainer wird f¨ ur Strings und Streams auf maximal m¨ogliche L¨ angen gem¨aß des MOST-Katalogs f¨ ur diese Komponente ausgelegt. Da er keinerlei Methoden hat, kann er im Shared-Memory untergebracht werden. Die HMI greift auf Daten u ¨ber vorgefertigte Adapter (getter-Methoden) zu, die genaue Kenntnisse u ullt ¨ber den Aufbau des Containers besitzen. Gef¨ wird der Datencontainer z.B. von dem generischen MOST-Codec u ¨ber virtuelle Methoden. Der Datenteil der MOST-Nachricht wird vom Codec an die richtige Stelle im Datencontainer unter Ber¨ ucksichtigung von Alignments direkt eingetragen. Der MOST-Codec benutzt daf¨ ur die Strukturbeschreibungen zur Dekodierung der Headerinformationen und bestimmt Offset und Index. Der Accessor muss das Wissen u ¨ber den Datencontainer haben und liefert dazu u ¨ber Offset und Index die richtigen Adressen. Die MOST-Nachrichten werden in unserem Konzept durch einfache Strukturen beschrieben, die zur Laufzeit vom MOST-Codec zum Interpretieren der Nachrichten benutzt werden. Die vorgestellten Tricks dienen dazu, die StartZeiten zu verbessern. Allerdings werden in einer Multiprozess-Umgebung diese Strukturen, falls sie im Datensegment angelegt wurden, beim forken vervielfacht. Der Umfang dieser Strukturen betr¨ agt aber auch bei großen Systemen nur wenige kByte. Sollte dies dennoch st¨ oren, so k¨onnten die Komponenten, die den MOST-Codec verwenden, als Threads eines Prozesses umkonfiguriert werden. Alternativ kann man die Strukturbeschreibungen als Text im Codesegement speichern um sie zur Laufzeit zu interpretieren und zur Verf¨ ugung zu stellen. Wichtig ist, dass Accessoren, Datencontainer, Adapter und Strukturen alle aus einer MOST-Beschreibung erzeugt werden.

21 HMI-Komponente

In der HMI-Komponente sind alle Bedienabl¨ aufe implementiert.

Abbildung 21.1. HMI-Komponente

• Die HMI-Komponente enth¨ alt zwei Schichten, zum einen eine Schicht f¨ ur den Bedien- und GUI-Ablauf, oft auch Main-Desktop-Manager“ genannt, ” zum anderen eine Schicht f¨ ur die grafische Darstellung. Dort sind auch kleine Animationen autark realisiert, wie z.B. die Darstellung eines Knopfdruckes, einer Listenweiterschaltung etc. Auch schwierige Themen wie Internationalisierung werden hier implementiert. • Da die HMI nur Keys und Datennachrichten erh¨alt, l¨asst sie sich einfach mithilfe GUI-Buildern wie MFC oder Photon-GUI-Builder realisieren und simulieren. • Die HMI Komponente verwaltet das aktive Fenster und komponiert die erforderlichen Daten. • Die HMI kennt durch ihr Kontextwissen die richtige Bedeutung von eingehenden Softkey-Events und gibt die entsprechenden logischen TastaturEvents an die Komponenten weiter.

390

21 HMI-Komponente

• Die Controller d¨ urfen nicht wissen, in welchem Men¨ u sich die HMI gerade befindet. Sie d¨ urfen nur wissen, welche Information die HMI ben¨otigt. • Die HMI muss, bevor sie die Daten anzeigt, u ufen, ob die Information ¨berpr¨ g¨ ultig ist oder nicht. • Wichtig f¨ ur die HMI ist die Information, welche Aktionen zurzeit erlaubt sind (z.B. darf der Benutzer w¨ ahrend eines Suchlaufs TP-Status ab¨andern? Darf der Benutzer Play starten? usw.). Diese Information muss abh¨angig vom Zustand des entsprechenden Controllers verf¨ ugbar sein (wenn man richtig modelliert, kann diese Information bei onEntry-Aktion des Controllers geschrieben werden). Deshalb werden die groben, standardisierten Zust¨ande wie Aktionsbeginn, Aktionsende, Play-Modus usw. der HMI u ¨ber Update-Events mitgeteilt. Die HMI sollte so weit wie m¨oglich von den Controllern unabh¨ angig sein. • Alternativ kann die HMI versuchen, eine Aktion beim Controller zu starten und bekommt ggf. ein nicht erlaubt“ zur¨ uck. ”

22 Persistenz-Controller und On/Off-Konzepte

Es ist in Systemen oft erforderlich, Daten u ¨ber das Abschalten des Systems hinaus zu erhalten. Wir unterscheiden zwischen normalen und kritischen Daten. Normale Daten sind die letzten Klangeinstellungen, der zuletzt geh¨orte Sender oder eine Navigationskarte, deren neues Laden einige Zeit dauern w¨ urde. Sollten diese Daten einmal nicht abgespeichert werden k¨onnen, so kann noch auf die vorletzten oder auf Default-Daten zur¨ uckgegriffen werden oder sie k¨onnen neu von einem Datentr¨ ager geladen werden. Normale Daten bewegen sich im Gr¨ oßenbereich von einigen kByte bis zu MByte (Adressb¨ ucher, Telefonlisten). Kritische Daten w¨ aren die letzte Fahrzeugposition vor dem Abschalten, die nach dem Neustart restauriert wird und solange wichtig ist, bis der Satellitenempf¨anger selbst wieder eine aktuelle Position errechnen kann (1-3 Minuten). Auch die letzte Lautst¨ arke oder die letzte Sitzposition z¨ahlt zu den kritischen Daten. Selbst der R¨ uckfall auf Default-Daten f¨ uhrt hier schon mindestens zur Ver¨argerung des Kunden. Es gibt nur wenige kritische Daten in einem Infotainment-System, eine Gr¨oßenordnung von weniger als 1 kByte ist vertretbar. Da in den meisten modernen Systemen aus Ruhestrom-Anforderungen heraus die Systeme nach einer Zeit ganz stromlos geschaltet werden m¨ ussen, werden Persistenz-Daten in so genannten Flash-Speichern gespeichert. Die wenigsten Systeme besitzen bisher Festplatten, auch w¨are deren Hochlaufzeit zu groß. Deshalb wird dieser Spezialfall hier nicht diskutiert. Die Flash-Speicherbausteine haben in der Regel einige unangenehme Eigenschaften: • Sie k¨onnen nur blockweise gel¨ oscht werden, • dieses L¨oschen braucht Zeit, • deshalb werden Eintr¨ age zun¨ achst nur ung¨ ultig markiert und die Eintr¨age auf neue Pl¨atze geschrieben. Dieses Vorgehen erfordert eine Art GarbageCollection in HW oder SW (Reorganisation).

392

22 Persistenz-Controller und On/Off-Konzepte

• W¨ahrend ein Block gel¨ oscht wird, kann bei vielen Bausteinen aus anderen Bl¨ocken nicht gelesen werden. • Ein Flash-Baustein hat nur begrenzte Schreibzyklen pro Speicherzelle, im Moment >100.000. Aus diesen Eigenschaften heraus kann es passieren, dass das Schreiben eines neuen Werts einen Reorganisations-Vorgang ausl¨ost, der je nach Baustein, Alter und Datenverteilung bis zu einigen Sekunden dauern kann. In dieser Zeit ist der Baustein auch f¨ ur Leseoperationen gesperrt. W¨ urde jede Applikation direkt in den Flash-Bereich schreiben, k¨onnten sich Applikationen unvorhersehbar ebenfalls bis zu einigen Sekunden gegen¨ seitig blockieren. Uberl¨ aufe und Abst¨ urze k¨ onnen die Folge sein oder der Watchdog w¨ urde ausl¨ osen. Eine erste L¨ osung ist die Einrichtung eines Flash-File-Systems mit vorgeschaltetem RAM als write-back Cache. Diese L¨osung ist aufw¨andig und unterscheidet außerdem nicht zwischen normalen und kritischen Daten. Der Einsatz des Flash-File-Systems wirkt sich direkt auf die On/OffStrategie derart aus, dass zun¨ achst ein RAM-Bereich, der die persistenten Daten h¨alt, in den Flash-Speicher geschrieben werden muss (Flush-Operation), bevor das Ger¨at ausgeschaltet werden darf. Das erfordert dann ein per SW steuerbares Netzteil und f¨ uhrt zu einem Herunterfahren“ des Systems statt eines richtigen“ Ausschaltens. Wer am ” ” Abend an Autos der letzten Generation aufmerksam vorbeispaziert, kann erkennen, dass so manche Headunit nicht abgeschaltet hat und dieses Herunterfahren nicht immer gelingt. Schwierig ist auch die Situation, in der w¨ahrend des Herunterfahrens wieder gestartet werden soll. Eine Alternative ist die Implementierung einer Persistenz-Komponente, die Daten entgegennimmt und im Flash abspeichert. Normale und kritische Daten werden im Betrieb im Moment ihrer Ver¨anderung in einem Cachebereich (RAM) zwischengespeichert und nacheinander im Hintergrund auch im Flash abgelegt (write-through). Beim Start des Systems werden alle normalen und kritischen Daten aus dem Flash in diesen Cache-Bereich kopiert, so dass Leseoperationen auf dem Cache ausgef¨ uhrt werden k¨ onnen und nicht durch m¨ogliche L¨osch- oder Schreiboperationen im Hintergrund blockiert werden. Wird das Ger¨ at u undschl¨ ussel von der Betriebsspannung ge¨ber den Z¨ trennt, so bekommt der Persistenz-Controller eine Vorwarnung per HWInterrupt, mit dem das Absinken der Batteriespannung detektiert wird. Die Ladekondensatoren in der Prozessorversorgung sind so dimensioniert, dass das System nach dem Abschalten der Spannung und nach der Vorwarnung f¨ ur noch etwa 20 ms operabel ist. Diese realistische Zeit reicht selbst im ung¨ unstigen Fall f¨ ur die Speicherung der kritischen Daten aus, die immer Priorit¨at haben. Noch nicht weggespeicherte normale Daten d¨ urfen ausnahmsweise verloren gehen.

22 Persistenz-Controller und On/Off-Konzepte

393

Eine besondere Behandlung ben¨ otigt die kritische Positions-Information der Navigation. Sie a ndert sich w¨ a hrend der Fahrt st¨andig und darf wegen ¨ der begrenzten Schreibzyklen des Flashs nicht dauernd geschrieben werden. Deshalb wird die Position nur bei detektiertem Stillstand des Fahrzeugs abgespeichert. Sollte es andere Daten geben, die sich ebenfalls dauernd a¨ndern (keine bekannt), k¨ onnten sie ebenfalls nur im Stand geschrieben werden, da nur dann auch ein Ausschalten des Systems zu erwarten ist. Ebenfalls eine Sonderbehandlung k¨ onnte f¨ ur ein großes Adressbuch n¨otig sein. Eine vollst¨andige Kopie im Cache k¨ onnte zuviel RAM ben¨otigen, eventuell werden nur die aktuellen Bl¨ ocke im Cache gehalten. Die SW-Architektur der Persistenz-Komponente nutzt das bereits vorgestellte Container-Muster und den Adapter. Jede betroffene Komponente schreibt ihre Daten mit Methoden ihres eigenen Persistenz-Adapters in einen reservierten Cache im Shared-Memory. Unten stehendes Beispiel ist f¨ ur eine Tuner-Komponente und f¨ ur ein zu sicherndes Datum LastStation“ dargestellt. ” Das Schreiben in den Cache wird synchronisiert, so dass es nicht mit dem ¨ Auslesen und Ubertragen in den Flash-Speicher kollidiert. Nach dem Schreiben wird ein dirty-Flag“ gesetzt, das anzeigt, dass sich das Datum ver¨andert ” hat und von einem Hintergrund-Thread in den Flash-Speicher geschrieben werden muss. Dieser Hintergrund-Thread pr¨ uft Ver¨ anderungen der Bereiche, liest mit niedriger Priorit¨ at den jeweils ganzen ver¨ anderten Persistenz-Bereich im RawByte-Format synchronisiert aus und transferiert ihn in den Flash-Bereich. Anschließend setzt er das entsprechende dirty-Flag zur¨ uck.

class CTunerPersistenzAdapter { public: CTunerPersistenzAdapter(UInt8* ptr, bool& dirtyFlag, CMutex& syncMutex) : mDataPtr(0), mDirty(dirtyFlag), mSyncMutex(syncMutex) { mDataPtr = reinterpret_cast(ptr); mDataPtr->mIsDirty = false; } void setLastStation(UInt8 freq) { mSyncMutex.take(); mDataPtr->mLastStation = freq; mIsDirty = true; mSyncMutex.give();

394

22 Persistenz-Controller und On/Off-Konzepte }

... ... UInt8 getLastStation() const { return mDataPtr->mLastStation; } ... ... private: struct TunerPersistenz { UInt8 mLastStation; }; TunerPersistenz *mDataPtr; bool& mIsDirty; CMutex& mSyncMutex; };

Listing 22-1. Persistenz-Manager, Prototyp

Ein separater Transfer-Thread in der Persistenz-Komponente wird auf h¨ochste Priorit¨at gesetzt und sorgt im Unterspannungsfall f¨ ur das Retten der letzten kritischen Daten. Dieser Thread blockiert im Normalfall auf einem Semaphor, der nur nach einem Unterspannungssignal von der UnterspannungsInterruptroutine freigegeben wird. Dann werden verbliebene kritische Daten in den Flash-Speicher geschrieben. Alternativ wird der oben erw¨ahnte Hintergrund-Transfer-Thread f¨ ur den Fall der Unterspannungsvorwarnung in seiner Priorit¨at hochgesetzt. Fazit Das vorgestellte Konzept, zusammen mit der F¨ahigkeit des beschriebenen Frameworks, schnell zu starten, f¨ uhrt zu einer sehr einfachen On/OffImplementierung.

23 Codegenerierung

Auch wenn die Codegenerierung nicht Gegenstand dieses Buches sein soll, sei im Folgenden kurz beschrieben, aus welchen Daten und in welcher Art Code generiert wird. Im jetzigen Generator werden die Komponenten und ihre Kontexte, die MOST-Codecs, Proxies und die Kommunikationsmechanismen erzeugt. Im Moment nicht automatisch generiert werden die Zustandsautomaten der Controller, die Bedienlogik und die GUI. Der Codegenerator erzeugt C++-Files, die anschließend kompiliert werden m¨ ussen.

23.1 Erstellen der XML-Eingabe-Dateien Der eigentliche JAVA-Code-Generator wird hier nicht vorgestellt. Allerdings werden Ein- und Ausgabedaten erl¨ autert, so dass eine eigene Implementierung leichter f¨allt. Anmerkung: Die vorgestellten generierten Code-Passagen stimmen nicht in allen Aspekten mit unseren vorgestellten Konzepten u ¨berein, sind aber dennoch ein gutes Beispiel f¨ ur den Einsatz von Code-Generatoren. F¨ ur den Codegenerator werden zwei XML-Dateien erstellt, die dem Generator als Eingabe dienen. Eine Datei beschreibt die Schnittstelle einer Komponente, die andere den Aufbau des Projekts aus einer oder mehreren Komponenten. Der Aufbau einer Schnittstellenbeschreibung sieht dabei wie folgt aus:



396

23 Codegenerierung

<request-port> <parameter /> <parameter /> <parameter t1="UInt32" i1="channels" /> <parameter t1="UInt16" i1="channels" /> <parameter /> <parameter t1="UInt8" i1="sink" /> <parameter t1="UInt8" i1="sink" /> Listing 23-1. Schnittstellenbeschreibung f¨ ur die Code-Generierung

Hierbei handelt es sich um die gek¨ urzte Schnittstellenbeschreibung des AudioVerst¨arkers, die in einer Datei mit der Endung .cbe abgelegt wird. Sie beinhaltet neben den eigentlichen Funktionen auch Eintr¨age f¨ ur Funktionsblock und Instanz-ID sowie die Gr¨ oßen der Queues und ob die Komponente als Prozess

23.2 Erzeugen des Quellcodes

397

oder als Thread ausgef¨ uhrt werden soll. F¨ ur jede Funktion wird deren Name und eine optionale Liste von Parametern und ein Kommentar angegeben. Die zweite XML-Datei tr¨ agt die Endung .cdp und beschreibt, aus welchen Komponenten sich das Projekt zusammensetzt. Sie hat folgendes Format:

<project syntaxVersion="1.0"> <system name="ExampleApp"> <executables> <executable name="ExampleApp"> Listing 23-2. Komponenten f¨ ur den Code-Generator

Diese Datei beschreibt ein Projekt mit dem Namen ExampleApp, welches aus einem Executable mit demselben Namen besteht. Innerhalb dieses Executables werden die aufgef¨ uhrten Komponenten erzeugt und gestartet. Wichtig f¨ ur den Codegenerator ist, dass die angegebenen Pfade zu den Komponentenbeschreibungen relativ zum aktuellen Arbeitsverzeichnis sind, in dem der Codegenerator ausgef¨ uhrt wird. In obigem Fall sollten sich diese also in einem Unterordner Components befinden.

23.2 Erzeugen des Quellcodes Hat man alle XML-Dateien erstellt, kann man auf der Kommandozeile nun den Quellcode f¨ ur das Projekt generieren:

java -jar CoffeeMaker.jar exampleapp.cdp Listing 23-3. Generierung des Projekts

398

23 Codegenerierung

Der erste Parameter ist die erstellte Projektbeschreibung im XML-Format, der zweite Parameter gibt das Verzeichnis an, in dem die erzeugten Dateien abgelegt werden. Der Code-Generator erzeugt ein gemeinsames Projektverzeichnis und darin ein Verzeichnis f¨ ur jedes Executable. In diesen werden die erzeugten Dateien angelegt.

¨ 23.3 Ubersicht der erzeugten Dateien Am Beispiel eines Projekts mit dem Namen ExampleApp, welches die Komponente AudioAmplifier enth¨ alt, werden die erzeugten Dateien beschrieben. Folgende Dateien werden einmal pro Projekt erzeugt: • ExampleApp.cpp Enth¨alt die main-Funktion, in der alle Komponenten erzeugt und gestartet werden. Danach f¨ uhrt main() eine admin-Funktion aus, die den Watchdog enth¨alt.

// Create and start thread Audioamplifier CAudioamplifierComponent audioamplifier (CContext::getNaviboxContext(), 1, 1); CThread audioamplifierThread(audioamplifier, CContext::getAudioamplifierContext().getContextNamePtr(), CContext::AUDIOAMPLIFIER_STACK_SIZE, CContext::AUDIOAMPLIFIER_PRIORITY); audioamplifierThread.start(); Listing 23-4. Starten einer Komponente als Thread

// Create and start process Mostdispatcher if ((mostdispatcherPID = fork()) == 0) { // Set the component thread priority (yet main thread priority) CThread::setPriority(CContext::MOSTDISPATCHER_PRIORITY); CMostdispatcherComponent mostdispatcher(CContext::getMostdispatcherContext(), 1, 1); mostdispatcher.init(); mostdispatcher.run(); } Listing 23-5. Starten einer Komponente als Prozess am Beispiel MostDispatcher

¨ 23.3 Ubersicht der erzeugten Dateien

399

while (true) { CThread::sleep(100); counter++; for (i = 0; i < CContext::NUM_OF_COMPONENTS; ++i) { if ( CContext::sContextTable[i].mType == LOCAL_COMPONENT ) { CContext::sContextTable[i].mLocal.handleTick(); // alle 500 ms checkAlive if (counter % 5 == 0) { CContext::sContextTable[i].mLocal.checkAlive(); } } } if (counter % 10 == 0) { for (i = 0; i < CContext::NUM_OF_COMPONENTS; ++i) { if ( CContext::sContextTable[i].mType == LOCAL_COMPONENT ) { if (false == CContext::sContextTable[i].mLocal.isAlive()) { sOwnCout<< CContext::sContextTable[i].mLocal. getContextNamePtr() << " died" << endl; signalHandler(SIGINT); } } } } } Listing 23-6. Der Watchdog, der innerhalb main() ausgef¨ uhrt wird

Context.cpp und Context.h Sie enthalten eine Funktion zum Erzeugen der Kontexte, die vor dem Erzeugen der Komponenten aufgerufen wird. Parallel zu den Kontexten werden auch die ben¨otigten Datencontainer f¨ ur jede MOST-Komponente erstellt. Außerdem beinhalten sie Zugriffsmethoden auf die einzelnen Kontexte der Komponenten und deren Datencontainer sowie gemeinsam genutzte Funktionen, um z.B. den MostDispatcher anzusprechen. Die Schleife zum Erzeugen der Kontexte und Datencontainer wurde bereits weiter oben vorgestellt:

400

23 Codegenerierung

for (Int32 i = 0; i < NUM_OF_COMPONENTS; i++) { if ( sDescriptionTable[i].mComponentType == LOCAL_COMPONENT ) { sContextTable[i].mType = LOCAL_COMPONENT; sContextTable[i].mLocal= CComponentContext::createComponentContext (sDescriptionTable[i].mComponentName, ptr, sDescriptionTable[i].mWatchdogLimit, sDescriptionTable[i].mSystemQueueSize, sDescriptionTable[i].mNormalQueueSize, sDescriptionTable[i].mId, sDescriptionTable[i].mBufferSize, shmAlreadyOpened); ptr += sDescriptionTable[i].mSizeNeeded; switch(i) { case AUDIODISCPLAYER_INDEX: { if (!shmAlreadyOpened) { new(ptr) CAudioDiscPlayerDCShared(0); } CAudioDiscPlayerDCShared & sharedData = *(reinterpret_cast(ptr)); ptr += sizeof(CAudioDiscPlayerDCShared); sDataContainerTable[i]= new CAudioDiscPlayerDC(sharedData); } break; case AMFMTUNER_INDEX: ... } } } Listing 23-7. Schleife zum Erzeugen der Kontexte

SystemConfig.cpp und SystemConfig.h In den Konfig-Dateien befinden sich Konstanten, die jeder Komponente eine ID zuordnen. Beispiel f¨ ur ein Projekt mit einer Komponente zus¨atzlich zu MostDispatcher und Debug-Komponente:

¨ 23.3 Ubersicht der erzeugten Dateien

extern #ifdef extern { #endif extern extern extern #ifdef }; #endif

401

const Int32 TICK_DURATION = 100; WIN32 "C"

const Int32 AUDIOAMPLIFIER_COMPONENT_ID = 1; const Int32 DEBUG_COMPONENT_ID = 2; const Int32 MOSTDISPATCHER_COMPONENT_ID = 3; WIN32

Listing 23-8. Projekt mit Amp-, Debug- und Dispatcher-Komponente

DebugConfig.cpp Enth¨alt Konfigurationsinformationen f¨ ur die Debug-Komponente bez¨ uglich der im System vorhandenen Komponenten und deren Schnittstellen.

const char* c1[] = //Beispiel einer Komponenten Info { "void trebleUp();", "void trebleDown();", "void bassUp();", "void bassDown();", "void volumeUp();", "void volumeDown();", "void connect(UInt32 channels);", "void connect(UInt16 channels);", "void disconnect();", "void setAddress(UInt32 address);", "void mute(UInt8 sink);", "void deMute(UInt8 sink);", "void sendSoundSettings();", 0L }; extern const char** componentInfo[] = { c1 }; extern const char* componentNames[] = { "AudioAmplifier", 0L }; Listing 23-9. DebugConfig.cpp am Beispiel eines Audioamplifiers

402

23 Codegenerierung

F¨ ur jede Komponente im Projekt werden nachstehende Dateien generiert: • AudioamplifierConst.h Ordnet jeder Schnittstellenfunktion eine Konstante zu. Diese werden im Port und im Handler verwendet.

class CAudioamplifierConst { public: enum AudioamplifierRequestPort { TREBLE_UP, TREBLE_DOWN, BASS_UP, BASS_DOWN, VOLUME_UP, VOLUME_DOWN, CONNECT_UINT32, CONNECT_UINT16, DISCONNECT, SET_ADDRESS_UINT32, MUTE_UINT8, DE_MUTE_UINT8, SEND_SOUND_SETTINGS, __LAST_REQUEST_FUNCTION__, }; enum AudioamplifierUpdatePort { }; }; Listing 23-10. Beispiel f¨ ur den Audioamplifier

• AudioamplifierPort.cpp und AudioamplifierPort.h Dient als Proxy f¨ ur die Komponente und wird mit deren Queue initialisiert. M¨ochte eine Komponente einer anderen eine Nachricht schicken, greift sie auf deren Port zu und ruft dort die gew¨ unschte Funktion. Hier wird der Aufruf in eine Message umgewandelt und der zugeh¨origen Komponente zur Bearbeitung in die Queue gestellt. Alternativ sendet sie ihre Message an den System-Dispatcher, der sie dann der zugeh¨origen Komponente zustellt. Die erste Variante ist sehr effizient, die zweite systematischer und besser zu debuggen.

¨ 23.3 Ubersicht der erzeugten Dateien

403

void CAudioamplifierRequestPort::trebleUp() { CMessage msg(CMessage::REQUEST_TYPE); msg.setSenderID( (CComponentServices::getComponentContextPtr())->getId()); msg.setReceiverID(CContext::getAudioamplifierContext().getId()); msg.setOpcode(CAudioamplifierConst::TREBLE_UP); mAudioamplifierQueuePtr->add(msg); msg.setParam( 3, DbgStream::getElapsedTime() ); CContext::getDebugContext().getNormalQueue().add(msg); } void CAudioamplifierRequestPort::trebleDown() { CMessage msg(CMessage::REQUEST_TYPE); msg.setSenderID( (CComponentServices::getComponentContextPtr())->getId()); msg.setReceiverID(CContext::getAudioamplifierContext().getId()); msg.setOpcode(CAudioamplifierConst::TREBLE_DOWN); mAudioamplifierQueuePtr->add(msg); msg.setParam( 3, DbgStream::getElapsedTime() ); CContext::getDebugContext().getNormalQueue().add(msg); Listing 23-11. AudioamplifierPort.cpp, AudioamplifierPort.h

• AudioamplifierHandler.cpp und AudioamplifierHandler.h Der Dispatcher einer Komponente entnimmt der Queue eine Nachricht und gibt diese an den Handler weiter. Dort wird sie aufgeschl¨ usselt und in einen Funktionsaufruf umgewandelt.

void CAudioamplifierRequestHandler::handleMessage(const CMessage& msg) { Int32 param0 = msg.getParam(0); Int32 param1 = msg.getParam(1); Int32 param2 = msg.getParam(2); switch (msg.getOpcode()) { case CAudioamplifierConst::TREBLE_UP: mAudioamplifier.trebleUp(); break; case CAudioamplifierConst::TREBLE_DOWN: mAudioamplifier.trebleDown();

404

23 Codegenerierung break; . . . default: break; }

} Listing 23-12. AudioamplifierHandler.cpp und AudioamplifierHandler.h

¨ 23.4 Ubersetzen des Quellcodes Damit der Quellcode erfolgreich u ¨bersetzt werden kann, muss das Projektverzeichnis im selben Verzeichnis liegen wie die Ordner Base und System des Frameworks. Nachdem der Code des Frameworks u ¨bersetzt wurde, kann mit¨ tels des generierten Jamfiles der Ubersetzungsvorgang f¨ ur das Projekt gestartet werden. Dabei werden alle Dateien u ¨bersetzt und anschließend zu einem Executable zusammengefasst. Bei Interesse an der Code-Generierung kann Kontakt mit den Autoren aufgenommen werden.

24 Sonstige Aspekte

24.1 Internes non-MOST-Device, Beispiel Mediaplayer Beispiele f¨ ur interne Non-MOST-Devices sind Third Party Module“ wie der ” Mediaplayer, Browser oder Sprachbedienung usw. Diese Module k¨onnen mit Adaptern in unsere Komponenten eingebettet werden.

24.2 Internes MOST-Device, Beispiel Tastatur Wir nehmen als Beispiel eine Bedientastatur, die u ¨ber eine serielle Schnittstelle angeschlossen ist. Wir haben mehrere Konzepte der Anbindung zur Wahl. • • •

• •

Ein serieller Ressource-Manager k¨ onnte eine POSIX-API implementieren, und die Applikationen k¨ onnten per Filehandle und read-Funktionen die Daten lesen. Ein serieller Ressource-Manager k¨ onnte als Thread an den System-Dispatcher angeh¨angt werden und Key-Events im internen Format direkt in die Dispatcher-Queue legen. Da die Tastatur Softkeys realisiert, m¨ ussen alle Tastendr¨ ucke in der HMI im Zusammenhang mit dem aktuellen Men¨ u interpretiert werden. Ein Ressource-Manager k¨ onnte deshalb auch direkt in der HMI-Komponente realisiert werden. Ein serieller Ressource-Manager verschickt z.B. unter QNX Photon-Events. Eine Komponente erzeugt MOST-gerechte Events und legt sie in die Dispatcher-Queue.

Wir entscheiden uns f¨ ur die letzte Variante, da nur damit das Ziel, durch Tracen am Main-Dispatcher alle Vorg¨ ange im System zeitlich richtig erfassen und verstehen zu k¨ onnen, gew¨ ahrleistet wird. Auch wenn wir die Tastatur f¨ ur die Fernbedienung anderer Komponenten im Ring einsetzen wollten, w¨are das die richtige L¨osung.

406

24 Sonstige Aspekte

Einige Ausschnitte der Implementierung werden auf unserer Web-Seite dargestellt.

24.3 Treiber im Framework Treiber sind eigene Tasks. Es gibt Treiber, die entweder interne Device-HW ansteuern oder Bussysteme nach außen bedienen. Wir unterscheiden zwischen • dem MOST-Treiber, der MOST-Events versendet und nach innen POSIXkonform sein kann und • den Non-MOST-Treibern, die POSIX-konform sind und normalerweise direkt mit der Applikation u ¨ber ein POSIX-API verbunden sind. • Wie f¨ ur den Main-Dispatcher gezeigt, kann auch eine Adapter-Komponente zwischen Treiber und Applikation geschaltet werden, so dass die Komponenten nur auf der Ebene von Events kommunizieren m¨ ussen. Ein Ger¨atetreiber besteht im Allgemeinen aus einem Interrupt-Handler und einem Thread, der die Daten abholt. Um Daten nicht zu verlieren, m¨ ussen wir f¨ ur datenintensive Nachrichten wie MOST-Events f¨ ur die Navigation ausreichende große Buffer haben. Eine L¨ osung daf¨ ur ist die Verwendung des Objekt-Pools im Shared-Memory.

24.4 Einfaches Debugging-Konzept Ein Multiprozess-System zu debuggen, das mit asynchronen Nachrichten von außen arbeitet, ist schwierig. Single-step oder Breakpoints f¨ uhren schnell zum ¨ Uberlauf von Queues, da die Events von außen nicht gestoppt werden k¨onnen. ¨ Nach dem Uberlauf ist das Debuggen sinnlos. Nicht jeder Debugger kann nach dem Forken von Prozessen auf die neu erzeugten Prozesse attachen. Das alles f¨ uhrt dazu, dass sich Enwickler schnell mit dem steinzeitlichen printf-Debugging zufrieden geben, indem sie an den zu untersuchenden Codestellen Testausgaben auf die Konsole einf¨ ugen. Regelm¨aßig w¨ahrend der Entwicklung und gelegentlich auch noch im Produkt wird dann entdeckt, dass die vielen Testausgaben zuviel Rechenleistung absorbieren und das Ger¨ateverhalten unn¨otig verschlechtern. Selten n¨ amlich entfernt ein Entwickler einmal eingebaute Testausgaben. In dem vorliegenden Framework aber, das ja sehr streng Event-basiert ist, kann durch Anzapfen des Systemdispatchers das gesamte Ger¨ateverhalten von außen gut beobachtet und verstanden werden. Es m¨ ussen lediglich die Queue-Methoden gleichzeitig auch eine Dummy-Queue bedienen (Stub), die an eine Socket-Verbindung zu einem Debug-PC angebunden ist. Auf dem PC kann man dann die Events interpretieren, aufzeichnen und sogar gezielt

24.4 Einfaches Debugging-Konzept

407

zur¨ uckspielen. Diese letzte M¨ oglichkeit ist sehr vorteilhaft f¨ ur ConformanceTests, in denen untersucht wird, ob sich das einmal aufgezeichnete Verhalten ver¨andert oder verschlechtert hat.

// CCommQueueStub is a placeholder for a queue on another machine. // All functions have dummy implementations except add // which will pass the CMessage through a socket connection to the // real queue. class CCommQueueStub { public: // constructor - create a stub // remoteAddress the ip-address of the remote system // the port of the remote system CCommQueueStub(const char *address, Int16 port); ~CCommQueueStub(); // add a message into the queue bool add(const CMessage& msg, bool waitForever = true); Int32 getNumOfMessages(void) { return 0; } bool getMessage(CMessage& msg) { return false; } Int32 getNumOfBytesNeeded(void) { return MAKE_ALIGNMENT_SIZE(sizeof(CCommQueueStub)); } Int32 getSizeNeeded(Int32) { return sizeof(CCommQueueStub); } private: CCommQueueStub (const CCommQueueStub& rhs); //avoid wrong usage const CCommQueueStub& operator=(const CCommQueueStub& rhs); bool mConnected; CInetAddr mAddr; CSockStream mRemote; CSockConnector mConnector; CBinarySemaphore mAccessSem; }; ... // Die Implementierung ... CCommQueueStub::CCommQueueStub(const char *address, Int16 port) { mAddr.set(port, address); mConnected = mConnector.connect(mRemote, mAddr); } CCommQueueStub::~CCommQueueStub() { }

408

24 Sonstige Aspekte

bool CCommQueueStub::add(const CMessage& msg, bool waitForever ) { // try to block queue (no reader is allowed) if (false == mAccessSem.take(waitForever)) { return false; // someone has the access right } if ( !mConnected ) // check if we are connected { // this call will block! mConnected = mConnector.connect( mRemote, mAddr ); } if ( !mConnected ) { mAccessSem.give(); // give up and discard message return false; } if (mRemote.send(&msg, sizeof(msg)) == -1) //at this point we have the whole control and send the { // message over the socket mRemote.close(); // receiver closed connection mConnected = false; } mAccessSem.give(); // Give the access right back return true; } Listing 24-1. Implementation of CCommQueue

¨ 24.5 Uberlastverhalten des Systems ¨ In den fr¨ uheren klassischen Radios gingen bei Uberlast einfach nur Tastendr¨ ucke verloren oder das gesamte reaktive Verhalten wurde langsamer. Dies war f¨ ur den Nutzer auch aktzeptabel, wenn er zuviel bediente, reagierte das System eben nicht mehr. ¨ Bei modernen Systemen kann Uberlast leicht zu undefiniertem Verhalten oder zum Absturz f¨ uhren. Komponenten werden nicht mehr gescheduled, Events gehen verloren oder werden u ¨berschrieben und das Verhalten ist nicht mehr vorhersagbar. ¨ Ein Maß f¨ ur den drohenden Uberlauf k¨ onnen volllaufende Queues oder hochlaufende Watchdog-Z¨ ahler sein. Beides l¨asst sich mit einfachen Mitteln detektieren. Weniger einfach sind die Maßnahmen darauf. Man kann: • alle Tastenevents sperren, analog zu den klassischen Systemen, • Grafik und Animationen reduzieren oder • allgemeine Ausgaben abschalten, die Software-seitige Refresh-Rate des Displays herabsetzen.

24.6 Anmerkungen zur Komplexit¨ at und zum Testing

409

24.6 Anmerkungen zur Komplexit¨ at und zum Testing Statisches Komplexit¨ atsmaß Es gibt verschiedene statische Komplexit¨ atsmaße in der Software-Technik. Die zyklomatische Komplexit¨ at beispielsweise gibt die Zahl der Verzweigungen an, die durchlaufen werden k¨ onnen. Damit erh¨alt man auch ein Maß daf¨ ur, wie viele unabh¨angige Black-Box-Tests man durchf¨ uhren m¨ usste, um alle Verzweigungen einmal getestet zu haben, noch unabh¨angig von Daten. Es gibt Tools, z.B. das McCabe-Tool, mit denen man dieses Maß als Gesamtzahl oder pro SW-Modul automatisch bestimmen kann. In einem gr¨oßeren Projekt geh¨ ort es zu den Pflichten jedes Bearbeiters, vor Abgabe seiner Software die Komplexit¨ at bestimmt zu haben. Ist sie gr¨oßer als ein festgelegtes Maß, z.B. 15, so muß die Implementierung vereinfacht werden. Systeme des beschriebenen Umfangs erreichen in Summe leicht eine Komplexit¨at u ¨ber der Millionengrenze. Solche Systeme sind im Black-BoxVerfahren nicht mehr zuverl¨ assig testbar. Es sind Modultests einzuf¨ uhren, siehe unten. Coverage Test, Testabdeckung Die Durchf¨ uhrung von Tests im Betrieb kann durch ein dynamisches Mo¨ nitoring unterst¨ utzt werden. In einem zus¨ atzlichen Ubersetzungslauf werden alle Zweige der Software instrumentiert, d.h. mit Kenn-Nummern versehen. Diese Nummer wird beim Durchlauf durch einen Zweig im Test in einen Speicher oder direkt auf einen Debug-Kanal geschrieben. Nach allen Tests kann ausgelesen werden, welche Zweige nie durchlaufen wurden und welche ¨ Testabdeckung man erreicht hat. Ubliche Werte liegen bei 50 %. Mit dieser Auswertung k¨onnen dann weitere gezielte Tests vorgenommen werden. Modul-Tests Eine L¨osung f¨ ur die fehlende Testbarkeit des Gesamtsystems sind ModulTests durch den Entwickler, die Teil der Framework-Spielregeln sein m¨ ussen. Es ist darauf zu achten, dass die Modul-Tests dem Projektstand folgen, die Bemerkung bei mir l¨ auft es“ geh¨ ort zum Standard-Spr¨ ucherepertoire eines ” Softwerkers. Die eigene Testumgebung verf¨ uhrt zu einer solchen Sichtweise. In falsch verstandenenen Modul-Tests erzeugt jeder Projektbearbeiter sein eigenes Projekt. Null-Warning Es ist eigentlich eine Selbstverst¨ andlichkeit, dass abgegebene Software keine Warnungen beim Kompilieren mehr erzeugen darf. Dennoch ist es Standard, dass Produkt-Software viele hundert Warnings hat. Unter diesen vielen unsinnigen Warnungen verstecken sich einige ernste Probleme, die beim Kunden zu Fehlern f¨ uhren werden. Ebenso wie die Messung und Angabe der Komplexit¨atszahl, geh¨ ort die Best¨ atigung von Null-Warnings zu den Spielregeln bei Abgabe von Software.

25 Anhang

Intention war, dass das Framework auf Linux, QNX und Windows baut und ” l¨ auft“. Der Quelltext des Frameworks wurde unter unter QNX geschrieben und immer gleich auch unter Linux gebaut. Die Lauff¨ahigkeit unter Windows Cisual C++ wurde gefordert, um das Framework auch unter dieser Umgebung entwickeln zu k¨onnen. Mit einer MOST-over-IP-Verbindung konnte dann ein MOST-f¨ahiges Target als MOST-Umsetzer f¨ ur ein Infotainment-System eingesetzt werden. Die einfachste L¨ osung f¨ ur die Kompilierung der Quellen unter Windows Visual C++ w¨are die Verwendung einer verf¨ ugbaren Unix-Umgebung f¨ ur Windows, die entsprechende Systemaufrufe einschliesslich Headerfiles und Bibliotheken bereith¨alt, so dass der eigentliche Code nicht an Windows angepasst werden muss. Cygwin: In der Cygwin-Umgebung von RedHat wird Posix Shared-Memory shm open(), shm unlink()... nicht unterst¨ utzt. Die Includes von Cygwin haben ein GNU-Compiler spezifisches Format. UWin: Microsoft Windows Services for Unix“ ist eine Unix-¨ahnliche Um” gebung vergleichbar mit Cygwin. Auch hier vertragen sich Header teilweise nicht mit Visual C++. MingW: MingW l¨ aßt sich in Visual Studio integrieren, liefert aber einige essentielle Funktionen nicht (Shared-Memory, Semaphore, POSIX-Sockets...). Portierung Die vom Aufwand her schwierigere aber erfolgreichere Methode ist die Anpassung der Quelltexte an die Windows-API, bzw. das Portieren einiger CodeModule. Die meisten Quellen k¨ onnen direkt in Visual C++ mit den Microsofteigenen Headerfiles integriert werden. Einige Header m¨ ussen ge¨andert oder erg¨anzt werden. Einige wenige Anweisungen m¨ ussen f¨ ur den Visual-Compiler ge¨andert werden.

412

25 Anhang

Windows besitzt eine nicht vollst¨ andige Posix-Kompatibilit¨at, was dazu f¨ uhrt, dass spezielle Funktionen, wie z.B. Shared-Memory oder SemaphoreFunktionen, durch die entsprechenden Funktionen der Windows-SDK abgebildet werden m¨ ussen. Funktionen der Posix-Thread-Library“ (pthread) k¨onnen u ¨ber eine open” source Bibliothek ’pthread-for-win32’ von Redhat emuliert werden. Der Code dieser Bibliothek ist ohne Anpassung direkt mit dem Microsoft-Compiler und den Microsoft-Headern kompilierbar. Die Socketklassen m¨ ussen um eine Initialisierung der Windows-Sockets erg¨anzt werden, und manche Zugriffsfunktionen, die es unter Windows nicht gibt, m¨ ussen durch Windows-eigene Funktionen ersetzt werden. F¨ ur den Shared-Memory-Zugriff ist ein Wrapper erforderlich. Dieser bietet die Posix-shmem-Funktionen an, die im Framework genutzt werden, und bildet sie auf die Windows-API ab. Es wird nur das umgesetzt, was vom Framework tats¨achlich ben¨ otigt wird. Einige Ausschnitte der Anpassungen werden im Folgenden kurz aufgelistet. F¨ ur weitere Informationen sei auf die Web-Site verwiesen.

25.1 Timer und Zeitmessung

// On Windows we define our own gettimeofday() function. #ifdef WIN32 #include <windows.h> #include #define EPOCHFILETIME (116444736000000000i64) struct timezone { int tz_minuteswest; //minutes W of Greenwich int tz_dsttime; //type of dst correction }; inline int gettimeofday(struct timeval *tv, struct timezone*) { FILETIME ft; LARGE_INTEGER li; __int64 t; static int tzflag; if (tv) { GetSystemTimeAsFileTime(&ft); li.LowPart = ft.dwLowDateTime; li.HighPart = ft.dwHighDateTime; t = li.QuadPart; //In 100-nanosecond intervals t -= EPOCHFILETIME; //Offset to the Epoch time t /= 10; //In microseconds

25.1 Timer und Zeitmessung

413

tv->tv_sec = (long)(t / 1000000); tv->tv_usec = (long)(t % 1000000); } return 0; } #else #include <sys/time.h> #endif // WIN32 };

//other than windows

Listing 25-1. Timer und Zeitmessung

25.1.1 Sleep Eine eigene Komponenten- bzw. Thread-Methode f¨ ur Sleep muss f¨ ur die unterschiedlichen Betriebssysteme adaptiert werden.

#ifdef __GNUC__ #ifndef _UNISTD_H #include #endif #endif

// Lib

#ifdef WIN32 #ifndef _WINDOWS_ #include <windows.h> #endif #endif .... // Implementierung .... void CThread::sleep(Int32 mSecs { #ifdef WIN32 Sleep(mSecs); #endif #ifdef __GNUC__ usleep(mSecs*1000); #endif }

//Sleep w/o consuming CPU

//measure in nano seconds

//measure in nano seconds

Listing 25-2. OS-Abh¨ angigkeiten f¨ ur eine sleep-Methode

414

25 Anhang

25.1.2 Timeout

#ifdef __GNUC__ #ifndef _SYS_TIME_H #include <sys/time.h> #endif #endif

// because of time used

#ifdef WIN32 #ifndef _INC_TIME #include #endif #endif

// because of time used

Listing 25-3. Abh¨ angige includes f¨ ur Sem.take mit timeout

25.2 Socket Wir hatten im Kapitel 9.3 bereits einen objektorientierten Ansatz f¨ ur eine Socket-Kommunikation vorgestellt. Die Klasse CInetAddr wird nun um OSabh¨angige includes erg¨ anzt. 25.2.1 InetAddr

#include "CInetAddr.h" #include "CSockAcceptor.h" #include "CInetAddr.h" #ifdef __GNUC__ #ifndef _SYS_SOCKET_H #include <sys/socket.h> #include #include <arpa/inet.h> #endif #endif #ifdef WIN32 #ifndef _WINSOCK2API_ #include <winsock2.h> #endif #endif

25.2 Socket

#if !defined (_SYS_TYPES_H) || !defined (_INC_TYPES) #include <sys/types.h> #endif } Listing 25-4. OS-abh¨ angige includes f¨ ur CInetAddr.h, Header

Es gibt auch OS-Abh¨ angigkeiten in der Implementierung:

bool CInetAddr::set( UInt16 port, const char *address ) { memset( &mInetAddr, sizeof( mInetAddr ), 0 ); mInetAddr.sin_family = AF_INET; mInetAddr.sin_port = htons( port ); #ifdef __GNUC__ if ( inet_aton( address, &mInetAddr.sin_addr ) <= 0 ) { return false; } #endif #ifdef WIN32 if (( mInetAddr.sin_addr.S_un.S_addr = inet_addr( address )) == INADDR_NONE ) { return false; } #endif return true; } bool CInetAddr::set( UInt16 port ) { memset( &mInetAddr, sizeof( mInetAddr ), 0 ); mInetAddr.sin_family = AF_INET; mInetAddr.sin_port = htons( port ); mInetAddr.sin_addr.s_addr = htonl( INADDR_ANY ); return true; } Listing 25-5. OS-abh¨ angige Implementierungen in CInetAddr

25.2.2 CSockAcceptor Die Abh¨angigkeiten f¨ ur die Klasse CSockAcceptor sind wie folgt:

415

416

25 Anhang

#ifdef __GNUC__ #ifndef _SYS_SOCKET_H #include <sys/socket.h> #endif #endif #ifdef __QNX__ #include <sys/select.h> #endif #ifdef WIN32 #ifndef _WINSOCK2API_ #include <winsock2.h> #endif #endif #if !defined (_SYS_TYPES_H) || !defined (_INC_TYPES) #include <sys/types.h> #endif #ifdef WIN32 int CSockAcceptor::mW32InitCounter = 0; #endif } Listing 25-6. OS-abh¨ angige includes und Definitionen f¨ ur CSockAcceptor, Header

Nun die abh¨angigen Implementierungen:

CSockAcceptor::CSockAcceptor(){} CSockAcceptor::~CSockAcceptor() { #ifdef WIN32 // cleanup the windows socket(s) again. for (; mW32InitCounter > 0; mW32InitCounter--) { WSACleanup(); } #endif } bool CSockAcceptor::open( CInetAddr& address ) { #ifdef WIN32

25.2 Socket

417

if (INVALID_SOCKET == (mListenfd=socket(AF_INET,SOCK_STREAM,0))) { if (WSANOTINITIALISED == WSAGetLastError()) { WORD wVersionRequested; WSADATA wsaData; int err; wVersionRequested = MAKEWORD( 2, 2 ); err = WSAStartup( wVersionRequested, &wsaData ); if ( err != 0 ) { return false; } if ( LOBYTE( wsaData.wVersion ) != 2 || HIBYTE( wsaData.wVersion ) != 2 ) { WSACleanup(); return false; } // Winsock initialized, try again: if (INVALID_SOCKET == (mListenfd=socket(AF_INET,SOCK_STREAM,0))) { return false; } // We got the Socket. Remember to clean it up: mW32InitCounter++; } else { return false; } } #else //WIN32 if ( ( mListenfd = socket( AF_INET, SOCK_STREAM, 0 ) ) < 0 ) { return false; } #endif //WIN32 bind( mListenfd, (sockaddr*) &address.mInetAddr, sizeof( address.mInetAddr ) ); listen( mListenfd, 5 ); return true; } Listing 25-7. OS-abh¨ angige Implementierungen f¨ ur CSockAcceptor

418

25 Anhang

25.2.3 CSockConnector Die Abh¨angigkeiten f¨ ur CSockConnector sind wie folgt:

#ifdef WIN32 private: static int mW32InitCounter; #endif #ifdef __GNUC__ #ifndef _SYS_SOCKET_H #include <sys/socket.h> #endif #endif #ifdef WIN32 #ifndef _WINSOCK2API_ #include <winsock2.h> #endif #endif #if !defined (_SYS_TYPES_H) || !defined (_INC_TYPES) #include <sys/types.h> #endif #ifdef __GNUC__ #ifndef _UNISTD_H #include #endif #ifndef _FCNTL_h #include #endif #endif #ifdef WIN32 int CSockConnector::mW32InitCounter = 0; #endif

Listing 25-8. OS-abh¨ angige Includes f¨ ur CSockConnector, Header

Nun die abh¨angigen Implementierungen:

CSockConnector::CSockConnector() { }

25.2 Socket

419

CSockConnector::~CSockConnector() { #ifdef WIN32 // cleanup the windows socket(s) again. for (; mW32InitCounter > 0; mW32InitCounter--) { WSACleanup(); } #endif } bool CSockConnector::connect( CSockStream& stream, CInetAddr& address, bool block ) { int sockfd; #ifdef WIN32 if ( INVALID_SOCKET == (sockfd = socket( AF_INET, SOCK_STREAM, 0)) ) { if (WSANOTINITIALISED == WSAGetLastError()) { WORD wVersionRequested; WSADATA wsaData; int err; wVersionRequested = MAKEWORD( 2, 2 ); err = WSAStartup( wVersionRequested, &wsaData ); if ( err != 0 ) { return false; } if ( LOBYTE( wsaData.wVersion ) != 2 || HIBYTE( wsaData.wVersion ) != 2 ) { WSACleanup(); return false; } // Winsock initialized, try again: if (INVALID_SOCKET == (sockfd = socket(AF_INET,SOCK_STREAM,0))) { return false; } // We got the Socket. Remember to clean it up: mW32InitCounter++; } else { return false; } }

420

25 Anhang #else //WIN32 if ( ( sockfd = socket( AF_INET, SOCK_STREAM, 0 ) ) < 0 ) { return false; } #endif //WIN32 if ( ::connect( sockfd, (sockaddr*) &address.mInetAddr, sizeof( address.mInetAddr ) ) < 0 ) { return false; } stream.mSocket = sockfd; return true;

}

Listing 25-9. OS-abh¨ angige Implementierungen f¨ ur CSockConnector

25.2.4 CSockStream Die Abh¨angigkeiten f¨ ur CSockStream sind wie folgt:

#include <signal.h> #include "CInetAddr.h" #include "CSockStream.h" #if !defined _STRING_H || !defined(_INC_STRING) #include <string.h> #endif #ifdef __GNUC__ #ifndef _SYS_SOCKET_H #include <sys/socket.h> #endif #endif #ifdef WIN32 #ifndef _WINSOCK2API_ #include <winsock2.h> #endif #ifndef _INC_IO #include #endif #endif

25.2 Socket

#if !defined (_SYS_TYPES_H) || !defined (_INC_TYPES) #include <sys/types.h> #endif Listing 25-10. OS-abh¨ angige Includes f¨ ur CSockStream, Header

Nun die abh¨angigen Implementierungen:

CSockStream::CSockStream() : mSocket( 0 ) { // We need to ignore this signal, otherwise we won’t // receive and error from send when the // connection is closed but instead the process // would be terminated. #ifdef __GNUC__ signal( SIGPIPE, SIG_IGN ); #endif // todo: implement for windows } CSockStream::~CSockStream() {} bool CSockStream::operator==( const CSockStream& rhs ) { return mSocket == rhs.mSocket; } int CSockStream::recv( void *buffer, Int32 size ) { #ifdef __GNUC__ return read( mSocket, buffer, size ); #endif #ifdef WIN32 return ::recv (mSocket,(char *)buffer,size,0); #endif } int CSockStream::send( const void *buffer, Int32 size ) { #ifdef __GNUC__ return write( mSocket, buffer, size ); #endif #ifdef WIN32 return ::send (mSocket,(char *)buffer,size,0); #endif }

421

422

25 Anhang

void CSockStream::close() { ::close( mSocket ); mSocket = 0; } Listing 25-11. OS-abh¨ angige Implementierungen f¨ ur CSockStream

Auch f¨ ur die Terminierung in der Applikation gibt es eine Besonderheit:

#ifdef WIN32 // Under Windows, accept returns false, if Winsock // is terminated with WSACleaup(). While terminating // the process, WSACleaup() gets called in another // thread, while this one is still runnning. // The result is, accept() doesn’t block (returns false) // and if this is not handled, a lot of threads would // get spawned. Sleep (100); #endif Listing 25-12. OS-abh¨ angige Terminierung von Socket

25.3 Keyboard In der Entwicklung am PC k¨ onnen wir Eingaben per Tastatur bei WindowsBetrieb und serielle Mini-Commander“-Eingaben bei Linux/QNX-Betrieb ” unterscheiden:

#ifndef WIN32 #include "unistd.h" #endif #ifdef __QNX__ #include <stdlib.h> #include <errno.h> #include <sys/neutrino.h> #include #endif // init and cleanup code

25.3 Keyboard void CKeyeventdispatcherThread::init(void) { mStop = false; #ifdef USE_MINICOMM_SERIAL if (!initMiniComm()) { sOwnCout()<<"Error opening Mini-Comm. or serial device"<<endl; mStop = true; } #endif #ifdef WIN32 if (!initWin32()) { sOwnCout() << "Error opening win32 keyboard"<< endl; mStop = true; } #endif #ifdef USE_PHOTON_EVENTS if (!initPhoton()) { sOwnCout() << "Error opening Photon region"<< endl; mStop = true; } #endif } // cleanup im Dispatcher { #ifdef USE_MINICOMM_SERIAL cleanupMiniComm(); #endif #ifdef WIN32 cleanupWin32(); #endif #ifdef USE_PHOTON_EVENTS cleanupPhoton(); #endif } } Listing 25-13. Tastatur- und Keyboard-Eingaben

423

424

25 Anhang

25.4 Shared-Memory

#ifdef __GNUC__ #ifndef _SYS_MMAN_H #include <sys/mman.h> #endif #ifdef __QNX__ #include #else #ifndef _SYS_SHM_H #include <sys/shm.h> #endif #endif #ifndef _UNISTD_H #include #endif #ifndef _FCNTL_h #include #endif #endif #ifdef WIN32 #ifndef POSIXSHM_H #include "..\..\System\PosixShm.h" #endif #endif } Listing 25-14. Abh¨ angige Definitionen f¨ ur Shared-Memory

Es folgt eine Wrapper-Implementierung zur Simulation des POSIX SharedMemories unter Windows. Zun¨ achst das Header-File.

#ifdef WIN32 #ifndef POSIXSHM_H #define POSIXSHM_H // These classes and static functions provide a Posix Shared Memory // wrapper for Windows. Beware, not all details are implemented. // If in doubt, please have a look at the sources. #include #include <string> #ifndef _WINDOWS_ #include "windows.h"

25.4 Shared-Memory

425

#endif #if !defined (_ERRNO_H) || !defined (_INC_ERRNO) #include <errno.h> // for the error constants #endif using namespace std; typedef vector PVEC; #define #define #define #define #define #define #define #define #define #define #define #define #define

SHM_DEFAULT_SIZE 1024 MAX_FD 256 O_EXCL 1 O_RDWR 2 O_CREAT 4 O_EXHB 8 S_IRUSR 16 S_IWUSR 32 S_IRGRP 64 S_IROTH 128 PROT_READ 256 PROT_WRITE 512 MAP_SHARED 1024

// constants

class CShmInfo //helper class stores info for a SHM { //object created with wrapper fct. shm_open() public: CShmInfo(int aFd, const string& aName, HANDLE aHandle) CShmInfo(); int getFd (); string getName (); HANDLE getHandle (); void setHandle (HANDLE aHandle); void addAddress (void * aAdr); int getAddrCount (); void * removeAddress (); private: int std::string HANDLE PVEC };

mFd; mName; mHandle; mAddresses;

class CShmMutexGuard { public: CShmMutexGuard(); ~CShmMutexGuard(); static HANDLE sMutex; };

// // // // //

the virtual file descriptor the name of the shared memory the win32 api handle to SHM the mapped addr (to know what to unmap in unlink())

//Protects shm_open & other shared memory //wrappers in multi-threading context. //All objects of this class use same mutex.

//gets initialized to NULL later

426

25 Anhang

// wrapped posix shm functions. Simple wrapper around shm_open(). // lot of functionality of shm_open, which is NOT implemented, beware // Name of the SHM to open, flags If O_EXCL, an error is returned, // if SHM exists, return -1 on error (see errno), 0 on success int shm_open(const char *name, int flags, int mode); // This function closes + re-opens the SHM to change the size. // fd: virtual file descriptor. // Mapped to new handle,length The new length. // return -1 on error, 0 on success int ftruncate(int fd, int length); // This function maps the shared memory into the current process space. // There is lot of functionality of mmap, which is NOT implemented! // Only the last two parameters are considered! // fd Virt file descriptor returned by shm_open) to identify the SHM. // offset Start-offset of the shared memory object, // return The adress: <= 0 on error (see errno), > 0 on success void * mmap(void *addr,int len,int prot,int flags,int fd,int offset); // This function removes all address space mappings and closes handle // to the SHM object, so the SHM gets erased. // name Name of SHM to unlink. // return -1 on error (see errno),0 on success int shm_unlink (const char *name); // used internally by shm_open() int getFreeFd (); #endif //POSIXSHM_H #endif //WIN32 } Listing 25-15. PosixShm.h f¨ ur WIN

Die Implementierung:

#ifdef WIN32 // The VC++ debugger can’t handle symbols more than 255 characs long. // STL often creates symbols longer than that. Disable warnings. #pragma warning(disable:4786) #include "PosixShm.h" CShmInfo::CShmInfo(int aFd, const string& aName, HANDLE aHandle) : mFd(aFd), mName(aName), mHandle(aHandle)

25.4 Shared-Memory {} CShmInfo::CShmInfo() : mFd(-1), mName(""), mHandle(NULL) {} int {

CShmInfo::getFd () return mFd;

} string CShmInfo::getName () { return mName; } HANDLE CShmInfo::getHandle () { return mHandle; } void CShmInfo::setHandle (HANDLE aHandle) { mHandle = aHandle; } void CShmInfo::addAddress (void * aAdr) { mAddresses.push_back(aAdr); } int CShmInfo::getAddrCount () { return mAddresses.size(); } void * CShmInfo::removeAddress () { if (mAddresses.size() == 0) { return NULL; } void * adr = mAddresses.begin(); mAddresses.erase(mAddresses.begin()); return adr; } CShmMutexGuard::CShmMutexGuard()

427

428

25 Anhang

{ if (NULL == sMutex) { sMutex = CreateMutex( NULL, true, "CShmMutexGuard"

// // // //

pointer to security attributes flag for initial ownership (true == take it directly) pointer to mutex-object name

); } else { WaitForSingleObject( sMutex, INFINITE ); } } CShmMutexGuard::~CShmMutexGuard() { if (NULL != sMutex) { ReleaseMutex( sMutex ); } } // static data HANDLE CShmMutexGuard::sMutex = NULL; typedef vector INFOVEC; static INFOVEC shmInfo; int shm_open(const char *name, int flags, int mode) { //Simple wrapper around shm_open() CShmMutexGuard mutexGuard; HANDLE hMap = CreateFileMapping( //create a new SHM object (HANDLE)0xFFFFFFFF, NULL, //optional security attributes PAGE_READWRITE, //protection for mapping object 0, //high-order 32 bits of obj. size SHM_DEFAULT_SIZE, //low-order 32 bits of obj. size name //name of file-mapping obj. ); // if O_EXCL is set,we return EEXIST, // if shm with name "name" already exists if ( flags & O_EXCL != 0 && hMap != NULL && GetLastError() == ERROR_ALREADY_EXISTS { errno = EEXIST; return -1;

)

25.4 Shared-Memory } int fd = getFreeFd(); if (-1 == fd) { errno = EFAULT; return -1; }

429

//search a free Fd //we already have more than //FD_MAX virtual filedescriptors

CShmInfo info(fd,name,hMap);

//store SHM info for later use in //ftruncate(),mmap(), shm_unlink()

shmInfo.push_back(info); return fd; } int ftruncate(int fd, int length) { CShmMutexGuard mutexGuard; bool found = false; int index;

//This fctn closes + re-opens SHM //to change the size //fd: virtual file descriptor. //Gets mapped to new handle //length The new length

for (index=0; index<shmInfo.size(); index++) { //try find shmInfo object for fd. if (fd == shmInfo[index].getFd()) { found = true; break; } } if (!found || shmInfo[index].getAddrCount() > 0) { return -1;

// if not found, or some addr. spaces // are already mapped: error

} const char * name = shmInfo[index].getName().c_str(); CloseHandle(shmInfo[index].getHandle()); // close SHM object HANDLE hMap = CreateFileMapping ( // reopen SHM object (HANDLE)0xFFFFFFFF, NULL, // optional security attributes PAGE_READWRITE, // protection for mapping object 0, // high-order 32 bits of object size length, // low-order 32 bits of object size name // name of file-mapping object ); shmInfo[index].setHandle(hMap); return 0;

//store new handle (map to fd)

430

25 Anhang

} void * mmap(void *addr,int len,int prot, int flags, int fd, int offset) { //maps SHM into current process space CShmMutexGuard mutexGuard; //Only last 2 parameters considered! bool found = false; int index; for (index=0; index<shmInfo.size(); index++) //try find shm info { if (fd == shmInfo[index].getFd()) { found = true; break; } } if (!found) { errno = EBADF; return (void *)-1; } void * adr = MapViewOfFile( shmInfo[index].getHandle(), FILE_MAP_ALL_ACCESS, 0, offset, 0 );

//do mapping //file-mapping obj.into addr.space //access mode //high-order 32 bits file offset //low-order 32 bits file offset //# of bytes to map (0=complete file)

if (NULL != adr) { shmInfo[index].addAddress(adr); //remember addr. for shm_unlink() } return adr; //might be NULL in case of error } int shm_unlink (const char *name) //removes all addr. space mappings { //and closes the handle so SHM CShmMutexGuard mutexGuard; //gets erased int index; bool found = false; void * adr; for (index=0; index<shmInfo.size(); index++) //try to find shm info { if (name == shmInfo[index].getName()) { found = true; break; }

25.4 Shared-Memory } if (!found) { errno = ENOENT; return -1; }

431

//named shm does not exist

while (NULL != (adr = shmInfo[index].removeAddress())) { //unmap all adr.mappings UnmapViewOfFile(adr); } CloseHandle(shmInfo[index].getHandle()); //close handle shmInfo.erase(&shmInfo[index]);//remove shm info fr. shmInfo vector return 0; } int getFreeFd () //find unused virt. fd in range 0..MAX_FD-1 { //Used internally by shm_open() for (int fd=0; fd<MAX_FD; fd++) { bool free = true; for (int i=0; i<shmInfo.size(); i++) { if (fd == shmInfo[i].getFd()) { free = false; break; } } if (free) { return fd; } } return -1; } #endif //WIN32 Listing 25-16. PosixShm.cpp f¨ ur WIN

432

25 Anhang

25.5 CBinarySemaphore Die Klasse CBinarySemaphore hat ebenfalls einige Abh¨angigkeiten vom OS, so dass der Prototyp und die gesamte Klassendefinition abgebildet werden muss. Zun¨achst das Headerfile:

#ifdef __GNUC__ #if !defined (_PTHREAD_H) || !defined(PTHREAD_H) #include //sem. must be simulated #endif #endif #ifdef WIN32 #ifndef _WINDOWS_ #include "windows.h" #endif #endif class CBinarySemaphore { public: // constructor. Create a binary semaphore. CBinarySemaphore(bool isFull = true, bool isProcessShared = false); ~CBinarySemaphore(); bool take(bool waitForEver = true); //lock the semaphore bool takeWithTimeOut(Int32 timeOut); void give(void); //unlock the semaphore private: // to avoid misuse CBinarySemaphore(const CBinarySemaphore& rhs); CBinarySemaphore& operator=(const CBinarySemaphore& rhs); // NOTE that POSIX-sem_t does not support the possibility // of timeout. Threfore we must use the mechanism of // condition variable to implement a binary semaphore // with the well known semantic // mutex for loking #ifdef __GNUC__ pthread_mutex_t mMutex; // condition variable used to implement take with timeout pthread_cond_t mCondition; #endif //__GNUC__ // counter (0 or 1) - Int32 is used because of efficiency Int32 mCounter;

25.5 CBinarySemaphore #ifdef WIN32 HANDLE unsigned long #endif //WIN32

433

mSemHandle; mCreatorProcessID;

}; // end of class CBinarySemaphore #endif // end of CBINARYSEMAPHORE_H

Listing 25-17. OS-abh¨ angige CBinarySemaphore.h

Nun die Implementierung:

CBinarySemaphore::CBinarySemaphore(bool isFull, bool isProcessShared) : mCounter(1) { #ifdef __GNUC__ Int32 retVal; // init the pthread_mutexattr_t with default values pthread_mutexattr_t mutexAttribut; retVal = pthread_mutexattr_init(&mutexAttribut); ASSERT(0 == retVal); //for safety set values explicitely!needed for pthread_cond_wait retVal = pthread_mutexattr_settype(&mutexAttribut, PTHREAD_MUTEX_ERRORCHECK); ASSERT(0 == retVal); // set the sharing property retVal = pthread_mutexattr_setpshared(&mutexAttribut, isProcessShared ? PTHREAD_PROCESS_SHARED :PTHREAD_PROCESS_PRIVATE); // out commented because retVal is 0 with cygwin // ASSERT(0 == retVal); // initialize the mutex with defined structure retVal = pthread_mutex_init(&mMutex,&mutexAttribut); ASSERT(0 == retVal); // destroy the mutex attribut retVal = pthread_mutexattr_destroy(&mutexAttribut); ASSERT(0 == retVal); // Attribut for condition variable pthread_condattr_t conditionAttribut; retVal = pthread_condattr_init(&conditionAttribut); ASSERT(0 == retVal); // set the pshared-attribut of the condition variable

434

25 Anhang retVal = pthread_condattr_setpshared(&conditionAttribut, isProcessShared ? PTHREAD_PROCESS_SHARED :PTHREAD_PROCESS_PRIVATE); //the following assertion is out commented to avoid problem //with cygwin (pthread_condattr_setpshared is not supported) //ASSERT(0 == retVal); //init cond. variable. Scnd parameter is always ignored in Linux pthread_cond_init(&mCondition, &conditionAttribut); // destroy the attribut pthread_condattr_destroy(&conditionAttribut); // reset the counter if needed if (false == isFull) { mCounter = 0; } #endif // __GNUC__ #ifdef WIN32 mSemHandle = CreateSemaphore(NULL,(isFull? 1 : 0),1,NULL); //store processId to decide, if duplicate handle be called or not mCreatorProcessID = GetCurrentProcessId(); #endif // WIN32

}

// end of constructor

CBinarySemaphore::~CBinarySemaphore() //destructor { #ifdef __GNUC__ pthread_mutex_destroy(&mMutex); //destroy mutex Int32 retVal = pthread_cond_destroy(&mCondition);//and condvar //thread still holds condvar can not delete it ASSERT(EBUSY != retVal); retVal = 0; //avoid "‘unused var"’,in case ASSERT not enabled #endif // __GNUC__

}

#ifdef WIN32 CloseHandle(mSemHandle); #endif // WIN32 // end of destructor

/* If the semaphore is locked by other task. The task will be queued. * @param waitForEver if true the task will wait until the * semaphore is free. * @return true if the lock is successfully done. */ bool CBinarySemaphore::take(bool waitForEver) // lock the semaphore. { #ifdef __GNUC__

25.5 CBinarySemaphore

435

bool result = true; pthread_mutex_lock(&mMutex); // free? if (mCounter == 1) { mCounter = 0; } else if (false == waitForEver) { result = false; } else { // idiom when working with condition variable while (0 == mCounter) { // calling pthread_cond_wait will release mMutex! calling // thread is blocked until the signal is true pthread_cond_wait(&mCondition, &mMutex); } // reset the counter to signal that we have taken it mCounter = 0;

}

} pthread_mutex_unlock(&mMutex); return result; #endif // __GNUC__ #ifdef WIN32 return takeWithTimeOut(-1); #endif // WIN32 // end of take

/* lock the semaphore. * If the semaphore is locked by other task the task will be queued. * @param timeOut is time in milliseconds until task returns. * if -1 the task will wait until the * semaphore is free forever. * @return true if the lock is successfully done. */ bool CBinarySemaphore::takeWithTimeOut(Int32 timeOut) { #ifdef __GNUC__ ASSERT(-1 <= timeOut); // delegate the case -1 if (-1 == timeOut) { return take(true); } else if (0 == timeOut) {

436

25 Anhang return take(false); } bool result = true; pthread_mutex_lock(&mMutex); if (mCounter == 1) { mCounter = 0; } else { // counter is not free struct timeval now; struct timespec timeExpire; // get the current time gettimeofday(&now, NULL); // calculate the timeout: seconds timeExpire.tv_sec = now.tv_sec + (timeOut / 1000); // and nano second timeExpire.tv_nsec = (now.tv_usec+(timeOut%1000)*1000)*1000; Int32 retcode = 0; while ( (0 == mCounter) && (ETIMEDOUT != retcode) ) { retcode = pthread_cond_timedwait(&mCondition, &mMutex, &timeExpire); } // check whether the condition is OK or timeout result = (ETIMEDOUT != retcode); // if mCounter is 1 in the time interval given // we must set it to zero again if (true == result) { mCounter = 0; } } pthread_mutex_unlock(&mMutex); return result; #endif // __GNUC__ #ifdef WIN32 // using the same semaphore handle across process boundaries // (supplied over shared memory) does not work under windows // we have to duplicate the handle in our process space in order // to use it // if (GetCurrentProcessId() != mCreatorProcessID) { // it is not our own sem. handle ( created by another process)

25.5 CBinarySemaphore

437

// => duplicate it, use it, destroy it // might be an performance issue, but we have no place to store // duplicated process handles, becaus this is normally stored in // shared memory. to be improved. // int ret; HANDLE tempSemHandle; HANDLE tempProcessHandle; tempProcessHandle = OpenProcess( PROCESS_DUP_HANDLE,0,mCreatorProcessID); DuplicateHandle ( tempProcessHandle, mSemHandle, GetCurrentProcess(), &tempSemHandle, SEMAPHORE_ALL_ACCESS, 0, DUPLICATE_SAME_ACCESS );

// // // // // // //

handle to the source process handle to duplicate handle to process to duplicate to pointer to duplicate handle access for duplicate handle handle inheritance flag optional actions

// now, lets try ret = WaitForSingleObject(tempSemHandle, (timeOut == -1 ? INFINITE : timeOut)); CloseHandle(tempSemHandle); CloseHandle(tempProcessHandle); if (WAIT_OBJECT_0 == ret) { return true; } else { ASSERT (WAIT_FAILED != ret); } return false;

}

} // if we are here, it is our own sem. (this process created it) return (WAIT_OBJECT_0 == WaitForSingleObject( mSemHandle, (timeOut == -1 ? INFINITE : timeOut))); #endif // WIN32 // end of takeWithTimeOut

void CBinarySemaphore::give(void) { #ifdef __GNUC__

//unlock the semaphore

438

25 Anhang pthread_mutex_lock(&mMutex); mCounter = 1; // we use signal instead of broadcast because of efficiency pthread_mutex_unlock(&mMutex); pthread_cond_signal(&mCondition); #endif //__GNUC__ #ifdef WIN32 // using the same semaphore handle across process boundaries // (supplied over shared memory) does not work under windows // we have to duplicate the handle in our process space in order // to use it // if (GetCurrentProcessId() != mCreatorProcessID) { // not our semaphore handle (was created by another process) // => duplicate it, use it, destroy it // might be performance issue, but we have no place to store // duplicat. process handles, bcs "this" is normally stored // in shared memory. to be improved. // HANDLE tempSemHandle; HANDLE tempProcessHandle; tempProcessHandle = OpenProcess(PROCESS_DUP_HANDLE, 0,mCreatorProcessID); DuplicateHandle ( tempProcessHandle, //handle to the source process mSemHandle, //handle to duplicate GetCurrentProcess(), //handle to process to duplicate to &tempSemHandle, //pointer to duplicate handle SEMAPHORE_ALL_ACCESS, //access for duplicate handle 0, //handle inheritance flag DUPLICATE_SAME_ACCESS //optional actions ); // now, lets try ReleaseSemaphore(tempSemHandle, 1, NULL); CloseHandle(tempSemHandle); return;

}

} // if we are here,it’s our own sem. (this process created it) ReleaseSemaphore(mSemHandle, 1, NULL); #endif // WIN32 // end of give Listing 25-18. OS-abh¨ angige Implementierungen f¨ ur CBinarySemaphore

25.6 Extern const

25.6 Extern const F¨ ur externe const-Definitionen unter Win ist extern "C" erforderlich:

#ifdef extern { #endif extern extern extern ... #ifdef }; #endif

WIN32 "C"

const Int32 AUDIODISCPLAYER_COMPONENT_ID = 1; const Int32 AUDIODISCPLAYERDEVICE_COMPONENT_ID = 2; const Int32 KEYEVENTDISPATCHER_COMPONENT_ID = 3; WIN32

Listing 25-19. Abh¨ angige externe const-Definitionen

439

Literatur

[Bus]

Buschmann, F.: Meunier, R.; Rohnert, H.; Sommerlad, P.; Stal, M. Pattern-Oriented Software Architecture; 1996; Wiley

[Doug]

Douglass, Bruce Powel: Real-Time Design Patterns; 2003; Addison-Wesley

[Gal]

Gallmeister, Bill O.: POSIX 4.; 1995; O’Reilly & Ass.

[Gan]

Gang of Four: Design Patterns, Elements of Reusable Object-Oriented Software; 1995; Addison-Wesley

[Gray]

Gray, John Shapley: Interprocess Communications in LINUX; 2003; Prentice Hall

[Hor]

Ian Horrocks: Constructing the User Interface with Statecharts; 1999; Addison-Wesley

[Klein]

Klein, Karsten: Grundlegende Konzepte eines Embedded Automotive Frameworks und erste Implementierung; 2005; Masterarbeit, FH-Darmstadt

[Knu]

Knuth, Donald E.: Fundamental Algorithms, 1.Vol; 1997; Addison-Wesley

[Li]

Li, Qing; Yao, Caroline: Real-Time Concepts for Embedded Systems; 2003; CMP Books

[Lin]

Linden, Peter van der: Expert C Programming; 2003; Prentice Hall

442

Literatur

[Lip]

Lippmann, Stanley B: Essential C++; 2000; Addison-Wesley

[Mad]

Maddox, Randall A.: Distributed Application Programming in C++; 2000; Prentice Hall

[Mey]

Meyers, Scott: Effektiv C++ programmieren; 1998; Addison-Wesley

[Mey1]

Meyers, Scott: More effective C++; 2003; Addison-Wesley

[Mis]

The Motor Industry Software Relieability Association: C Guidelines; 2004

[MOST] Multimedia and Control Networking Technology, Function Catalog MOST Cooperation, z.B. Rev 2.3, V1.0, 2001 [Nob]

Noble, James; Weir, Charles: Small Memory Software; 2001; Addison-Wesley

[Pla]

Plauger, P.J.: The standard C++ Library; 1995; Prentice Hall

[Sam]

Samek, Miro: Practical Statecharts in C/C++; 2002; CMP-Books

[Stev]

Stevens, W. Richard: UNIX Network Programming; 1999; Prentice Hall

[Schmi]

Schmidt, Douglas; Stal, Michael; Rohnert, Hans; Buschmann, Frank: Patternorientierte Software-Architektur; 2002; dpunkt.verlag

[Tan]

Tanenbaum, Andrew S.: Modern Operating Systems; 2001; Prentice Hall

[Thoe]

Thoemmes, Peter: Notizen zu C++; 2004; Springer-Verlag

[Vlis]

Vlissides, John: Pattern Hatching; 1998; Addison-Wesley

[Lee]

Lee, Richard C./ Tepfenhart, William M.: UML and C++; 2001; Prentice Hall

Index

Adapter, 343 Aktionen, 345 Alignment-Probleme, 60 Allocator Methode, 75 Allocator-Pattern, 71 Automaten, 217 Bedingungsvariable, 168 benannter Semaphor, 160 Betriebssystem, 17 Big-Endian, 24 Blockieren, 57 Call-Events, 185 Captain-Oates-Strategie, 85 CBinarySemaphore, 432 Change-Events, 186 Code-Generierung, 395 Code-Segment, 29 Condition Variable, 168 Const Definitionen, 25 Controller, 342 copy on write, 94 Datencontainer, 82, 347 Datensegement, 33 Deadlock, 177 Deallocate, 80 Debugging, 406 delete, 32 Design-Rules, 21 Dispatcher, 211, 212 Dispatcher-Komponente, 331 DLLs, 151

Down-cast, 47 Dynamic-Cast, 54 Dynamische Allokation, 75 Dynamische Speicherverwaltung, 31 Embedded Pointer, 81 Embedded Speicherkonzepte, 63 Event-Basisklasse, 195 Events, 183 Events mit Cookies, 185 Exceptions, 27 exec(), 94 Externe const-Deklarationen, 26 Externe MOST-Devices, 255 Filedescriptor, 125 finite state machine, 215 fork, 93 Framework, 10 Framework-Prinzipien, 11 FSM, 215 Garbage-Collection, 61 Globale Objekte, 33 Globale Variablen, 34 Harel-Statecharts., 217 Headunit, 8 Heap-Segment, 29 HMI, 7, 344 HMI-Komponente, 389 ifndef, 26 Infotainment-System, 7 Inter-Prozess-Kommunikation, IPC, 121

444

Index

Interne MOST-Devices, 255 Ist-Daten, 347 Keyboard, 422 Klassenstatische Variable, 34 Kommunikationsanforderungen, 347 Komponentenrahmen, 327 Konstante Strukturenbeschreibung, 372 Konstruktoren, Reihenfolge, 63 Kontextwechsel, 20 Kontrollfluss, 16 Konventionen, 21 Kopierkonstruktor, 57 Lazy Initialisation, 39 Linux, 411 Little-Endian, 24 Livelock, 179 Load on Demand, 39 LogDev, 341 Logisches Ger¨ at, 341, 346 Lokale statische Variablen, 34, 39 Lokation von Variablen, 33 Makros zur Allokation, 68 Mealy-Automaten,, 217 Mehrfachvererbung, 52 Message-Queue, 134 MMU, 20 Modul-globale Variable, 34 Moore-Automaten,, 217 MOST, asynchroner Kanal, 255 MOST, FunctionID, 261 MOST, InstanceID, 260 MOST, Kontrolkanal, 255 MOST, NetBlock, 260 MOST, Notifikation, 264 MOST, Registry, 263 MOST, synchroner Kanal, 254 MOST-Bus, 253 MOST-Codec, 359, 363 MOST-Datentypen, 374 MOST-Dekodierung, 363, 370 MOST-Device, 405 MOST-Konstanten, 269 MOST-Sequenz, 266 mprotect, 144 Mutex, 37, 156, 161 Mutex-Guard, 167

MVC, 13 named Semaphor, 160 Namenskonventionen, 22 new, 32 Non-MOST-Devices, 405 Non-MOST-devices, 255 Notifikation, 186 Object Pool Allokation, 78 Objektpool, 72 Optionen, 344 OS-Grundmechanismen, 277 Padding-Probleme, 59 PartiellerFehler, 87 Persistenz, 391 Pipe, 121 PlacementNew, 67 Plug&Play, 16 POD, Plain old Data, 34 Priorit¨ atsinversion, begrenzte , 179 Priorit¨ atsinversion, unbegrenzte, 179 PrioritaetsInversion, 19 Properties, 258 Proxy, 258 Prozess, 18, 89, 90 Prozessattribute, 97 Prozessvererbung, 97 QNX, 411 QNX Message, 137 Quasi statische Allokation, 66 Queues, 197 Referenzz¨ ahler, 83 reinterpret cast zur Vermeidung von Konstruktoren, 373 RoundRobin, 19 RTC, run till completion, 185 Scheduler, 19 select, 126 Semaphore, 153 Shared-Code, 151 Shared-Memory, 137, 424 Shared-Verzeichnis, 22 SharedObjects, 82 Signal-Events, 184 Signale, 27

Index Singleton, 36 Singleton mit Doppel-Checking, 38 Sleep, 413 Smartpointer, 84 Socket, 125, 414 Soll-Daten, 347 Sp¨ ate Initialisierung im Datensegment, 38 Sp¨ ate Konstruktion, 36 spawn, 96 Speicheranforderungen, 15 Speicherbedarf, 43 Speicherfragmentierung, 15, 60 Speicherlimit, 86 Speicherverwaltung, 29 Stack-Segment, 29 Standard-Typen, 22 Start-Up, 33 Startzeiten, 15 Statechart, 217 Statische Allokation, 73 Statische Speicherverwaltung, 31 Statischer Allokator, 72 Statischer Puffer, 67 StatischeVariablen, 63 Stellvertreter, 341 Struktur mit Konstruktor-Aufruf, 42 Synchronisierungsmechanismen, 153

445

Task, 90 TaskSwitch, 20 Tempor¨ arer Heap, 72, 75 Text-Segment, 29 Thread Spezifische Daten, 106 Thread-Attribute, 101 Threads, 89, 92, 99 Timeout, 414 Timer-Events, 185 Treiber, 406 Trick mit Strukturen, 372 TSD, 106 Unbenannter Semaphor, 157 Up-Cast, 47 V-Table, 45, 49 Vektoren, 61 Vererbung, 45 Virtuelle Methode, 44 Windows, 411 Zahlengrenzen, 25 Zeitverhalten der Synchronisationen, 177 Zombies, 92 Zustandsautomaten, 215