diplomarbeit - uni-rostock.de

Universität Rostock Fakultät für Ingenieurwissenschaften

Fachbereich Elektrotechnik & Informationstechnik Institut für Angewandte Mikroelektronik und Datentechnik

Diplomarbeit

Automatisches Entwurfs- und Entwicklungssystem für harte Echtzeitsysteme

Bearbeiter: cand. ing. Jan Blumenthal

Betreuer: Dr. Frank Golatowski

U N I V E R S I T Ä T R O S T O C K Rostock, 04.02.2002 FACHBEREICH ELEKTROTECHNIK UND INFORMATIONSTECHNIK Institut für Angewandte Mikroelektronik und Datentechnik Diplomarbeit für cand.ing. Jan Blumenthal

Automatisches Entwurfs- und Entwicklungsframework für harte Echtzeitsysteme Im Rahmen der Diplomarbeit soll ein integratives und universelles Entwicklungssystem für harte Echtzeitsysteme entwickelt werden. Ein Echtzeitsystem besteht aus mehreren Threads, die miteinander kommunizieren. Die Reihenfolge in der die Threads gestartet und ausgeführt werden, wird durch einen Schedu-lingalgorithmus bestimmt. Dieser kann in einer Softwareimplementierung als Teil des Be-triebssystems bzw. als unterstützender Hardware-Coprozessor vorliegen. Mit Hilfe einer Analysesoftware (Schedulinganalyser) wird bestimmt, welcher Algorithmus und welche Art der Implementierung (Hardware oder Software) in einem bestimmten Kon-text verwendet wird. Aufgabe des zu entwickelnden Systems ist eine möglichst plattformunabhängige Codierung und Integration der vielfältigen Teilsysteme. Das Werkzeug soll verschiedene Hardware- und Softwaremodule derart miteinander verbinden, dass im Ergebnis ein deterministisches Echtzeitsystem entsteht. Als Zielplattform soll RT-Linux verwendet werden. Betreuer: Dr.-Ing. Frank Golatowski Tag der Ausgabe: 01.02.2002 Tag der Abgabe: 31.07.2002 Prof. Dr.-Ing. D. Timmermann Prof. Dr. Weber Betreuender Hochschullehrer Vorsitzender des Prüfungsausschusses

Danksagung

Die vorliegende Arbeit entstand während meines Studiums am Institut für Angewandte Mikroelektronik und Datentechnik an der Universität Rostock. Ich möchte mich an dieser Stelle bei meinem wissenschaftlichen Betreuer Herrn Dr. Frank Golatowski sehr herzlich bedanken. Er hat diese Arbeit konstruktiv, beratend und vor allem sehr motivierend begleitet. Mein Dank gilt weiterhin Herrn Dipl. Ing. Jens Hildebrandt für seine hilfreichen Hinweise und Anregungen. Weiterhin möchte ich mich beim Fachbereich Elektrotechnik für das angenehme Lernklima und die nahezu persönliche Atmosphäre zu allen Mitarbeitern bedanken. Mein Dank geht an die Abgeordneten des Landtages Mecklenburg/Vorpommern für ihre Weitsicht, eine Gesetzesgrundlage zu schaffen, die mir das Studium an einer Hochschule ohne reguläres Abitur ermöglichte. Mein spezieller Dank gilt meiner Freundin Andrea. Sie hat viele Einschränkungen während der Zeit der Anfertigung dieser Arbeit ertragen. Insbesondere möchte ich an dieser Stelle meinen Eltern, Gisela und Joachim Blumenthal, für die jahrelange Unterstützung danken. Rostock, 8. Juli 2002

Inhaltsverzeichnis

IV

Inhaltsverzeichnis

Verzeichnisse.................................................................................................VII Abkürzungsverzeichnis..................................................................................................VII Abbildungsverzeichnis....................................................................................................IX Tabellenverzeichnis ........................................................................................................XI Gleichungsverzeichnis ...................................................................................................XII Beispielverzeichnis ........................................................................................................XII Verzeichnis verwendeter Symbole .............................................................................. XIII

1. Einleitung .....................................................................................................1 1.1 Thematischer Hintergrund....................................................................................... 1 1.2 Ausgangssituation.................................................................................................... 1 1.3 Ziele des Frameworks.............................................................................................. 2 1.4 Gliederung ............................................................................................................... 6

2. Grundlagen von Echtzeitsystemen.............................................................7 2.1 Echtzeitbetriebssysteme .......................................................................................... 7 2.2 Prozesse ................................................................................................................... 7 2.3 Scheduling ............................................................................................................... 9

2.3.1 Klassifikation von Schedulern ................................................................... 11 2.3.2 Zyklische Scheduler ................................................................................... 11 2.3.3 Statische Scheduler .................................................................................... 11

2.3.3.1 Priority Based Scheduling............................................................ 12 2.3.3.2 Rate Monotonic Scheduling......................................................... 12 2.3.3.3 Deadline Monotonic Scheduling.................................................. 13

2.3.4 Dynamische Scheduler............................................................................... 13 2.3.4.1 Earliest Deadline First.................................................................. 14 2.3.4.2 Least Laxity First ......................................................................... 15 2.3.4.3 Enhanced Least Laxity First ........................................................ 16

2.4 Synchronisation von Prozessen ............................................................................. 17 2.4.1 Einführung in kritische Abschnitte und Semaphoren ................................ 17 2.4.2 Prioritäteninversion .................................................................................... 18

2.5 Synchronisationsprotokolle ................................................................................... 20 2.5.1 Statische Synchronisationsprotokolle ........................................................ 20

2.5.1.1 Priority Inheritance Protocol........................................................ 20 2.5.1.2 Priority Ceiling Protocol .............................................................. 21

Inhaltsverzeichnis

V

2.5.1.3 Ceiling Semaphore Protocol ........................................................ 22 2.5.1.4 Semaphore Control Protocol........................................................ 23

2.5.2 Dynamische Synchronisationsprotokolle................................................... 24 2.5.2.1 Dynamic Priority Ceiling Protocol .............................................. 24 2.5.2.2 Stack Resource Policy.................................................................. 24

2.5.3 Kernel Priority Protocol ............................................................................. 27 2.6 Interprozesskommunikation .................................................................................. 28

2.6.1 Einführung.................................................................................................. 28 2.6.2 Signale........................................................................................................ 28 2.6.3 Nachrichten ................................................................................................ 28 2.6.4 Pipes ........................................................................................................... 29 2.6.5 Shared Memory.......................................................................................... 29

2.7 Schedulinganalyse ................................................................................................. 29 2.7.1 Auslastung.................................................................................................. 30 2.7.2 Worst-Case Antwortzeit............................................................................. 31 2.7.3 Jitter............................................................................................................ 32

3. Einführung in RT-Linux...........................................................................34 3.1 RT-Kernel.............................................................................................................. 34

3.1.1 Der Scheduler............................................................................................. 36 3.2 Entwicklung von Echtzeitanwendungen ............................................................... 36 3.3 Synchronisationsprotokolle in RT-Linux .............................................................. 39

4. Scheduling Analyser ..................................................................................40 4.1 Einleitung .............................................................................................................. 40 4.2 Konzept.................................................................................................................. 41 4.3 Die Executives....................................................................................................... 42

4.3.1 Synchronisationsprotokolle........................................................................ 45 4.3.2 Deadline-Behandlung................................................................................. 46 4.3.3 Der Logging-Mechanismus........................................................................ 48 4.3.4 Simulator Executive ................................................................................... 49 4.3.5 RT-Linux Executive................................................................................... 50 4.3.6 Potenzielle Executives ............................................................................... 53

4.4 Die Scheduler ........................................................................................................ 54 4.5 Projektverwaltung.................................................................................................. 57 4.6 Konventionen ........................................................................................................ 59 4.7 Quelltextgenerierung ............................................................................................. 59 4.8 Ausführung einer Projektanwendung .................................................................... 62

Inhaltsverzeichnis

VI

4.9 Auswertung einer Anwendung .............................................................................. 62 4.10 Geschwindigkeitsaspekte ...................................................................................... 64 4.11 Einsatzgebiete........................................................................................................ 65

5. Programmierung des Front-Ends............................................................67 5.1 Einleitung .............................................................................................................. 67 5.2 Die Klassenbibliothek Qt ...................................................................................... 68

5.2.1 MOC – Der Metacompiler ......................................................................... 69 5.2.2 Der Signal-Slot Mechanismus.................................................................... 69 5.2.3 Widgets ...................................................................................................... 70 5.2.4 Der Translator ............................................................................................ 71

5.3 Vorstellung wichtiger Klassen .............................................................................. 72 5.3.1 YObject ...................................................................................................... 72 5.3.2 YDataTypes................................................................................................ 74 5.3.3 YFrame....................................................................................................... 77 5.3.4 YWidget ..................................................................................................... 78 5.3.5 Auswertung und Darstellung...................................................................... 80

6. Zusammenfassung und Ausblick .............................................................85

Literaturverzeichnis .......................................................................................87

A Anhang........................................................................................................90 A.1 Beispielprogramm für RT-Linux........................................................................... 90 A.2 Echtzeitanwendung in YASA................................................................................ 91 A.3 Quelltext des EDF-Schedulers .............................................................................. 92 A.4 Vergleich dynamischer Prioritäten ........................................................................ 94 A.5 XML-Attribute der Konfigurationsdateien............................................................ 95

A.5.1 Executive-Konfigurationsdateien............................................................... 95 A.5.2 Scheduler-Konfigurationsdateien............................................................... 97

A.6 Logging-Ereignisse................................................................................................ 98 A.7 Patchvorgang unter RT-Linux............................................................................. 100 A.8 Generierte Quelltexte........................................................................................... 102 A.9 Logfile der Prioritäteninversion .......................................................................... 105 A.10 Konfiguration der Schedulingumgebung ............................................................ 107 A.11 Darstellung von Zeitdiagrammen in YASA........................................................ 108 A.12 Ausgewählte Klassendiagramme......................................................................... 111

Abkürzungsverzeichnis

VII

Verzeichnisse


API Application Programmable Interface Bi Max. Blockierungszeit von Prozess i Ci Rechenzeit eines Prozesses i CPT Calc Preemption Time, Einstellung in YASA, ob nächster Scheduleraufruf

berechnet werden soll CPU Central Processing Unit, Hauptprozessor Cs Kontextwechselzeit (Context switch time) CSP Ceiling Semaphore Protocol D Deadline in Periode des Prozesses D(t) Aktuelle Deadline zum Zeitpunkt t DMS Deadline Monotonic Scheduler DPCP Dynamic Priority Ceiling Protocol E(t) Restfirst bis zur Deadline in aktueller Periode EDF Earliest Deadline First Scheduler ELLF Enhanced Least Laxity First Scheduler FTP File Transfer Protocol GPOS General Purpose Operation System, Betriebssystem für zeitunkritische

Aufgaben hp(i) Prozess-Satz mit höherer Priorität als τi IPC Inter process communication, Interprozesskommunikation ISR Interrupt Service Routine Job Jx Instanz eines Prozesses während einer Periode kgV Kleinstes gemeinsames Vielfaches KPP Kernel Priority Protocol Li Spielraum des Prozesses i, Schlupf (Laxity) LLF Least Laxity First Scheduler lp(i) Prozess-Satz mit niedrigerer Priorität als τi MDI Multi-Document Interface MFC Microsoft Foundation Classes, Klassenbibliothek für Windows NFS Network File Service Oi Offset des Prozesses i OS Operating System, Betriebssystem


VIII

Pi Periode des Prozesses i PCB Process Control Block, Prozesskontrollblock PCP Priority Ceiling Protocol PID Prozess Identifier, Prozessidentifikationsnummer PIP Priority Inheritance Protocol PPID Parent Process Identifier, Prozessidentifikationsnummer des übergeordneten

Prozesses Ri Antwortzeit eines Prozesses i RMS Rate Monotonic Scheduler RTL Real-Time Linux RTOS Real-Time Operating System, Echtzeitbetriebssystem RTS Real-Time System S* Systemceiling-Konstante Si Semaphore i SMP Symmetric Multi Processing, Multiprozessorbetrieb SRP Stack Resource Policy t Zeit Ti Periode eines Prozesses i U Utilization, Auslastung X11 Window-Management System für UNIX XML Extensible Marking Language, Objektbeschreibungssprache YASA Yet Another Scheduling Analyzer Π* System-Preemptionlevel τi Prozess i

Abbildungsverzeichnis

IX


Abbildung 2.2-1: Definition der Prozesseigenschaften.......................................................... 8 Abbildung 2.2-2: Erweitertes Prozesszustandsmodell ........................................................... 8 Abbildung 2.3-1: Klassifikation von Schedulern ................................................................. 11 Abbildung 2.3-2: Fehlerhaftes Schedulingverhalten von RMS trotz Auslastung < 1 .......... 13 Abbildung 2.3-3: a) EDF-Beispiel b) Dominoeffekt beim EDF-Scheduler......................... 15 Abbildung 2.3-4: Definition des Spielraumes bei Least Laxity First................................... 15 Abbildung 2.3-5: Darstellung des Trashings bei Least Laxity First..................................... 16 Abbildung 2.3-6: Beispiel zu ELLF anhand von Beispiel in Abbildung 2.3-5 .................... 17 Abbildung 2.4-1: Deadlock .................................................................................................. 18 Abbildung 2.4-2: Zeitdiagramm einer Prioritäteninversion (Direct Blocking).................... 19 Abbildung 2.4-3: Zeitdiagramm einer Prioritäteninversion (Pass-Through-Blocking) ....... 20 Abbildung 2.5-1: Zeitdiagramm eines Priority-Inheritance Protocols ................................. 21 Abbildung 2.5-2: Zeitdiagramm eines Priority-Ceiling-Protocols ....................................... 22 Abbildung 2.5-3: Schedulingverlauf von Beispiel 3 mit Ceiling Semaphore Protocol........ 23 Abbildung 2.5-4: Schedulingverlauf von Beispiel 4 unter SRP........................................... 27 Abbildung 2.5-5: Beispieldiagramm eines Kernel Priority Protocols .................................. 27 Abbildung 3.1-1: Aufbau von RT-Linux.............................................................................. 35 Abbildung 3.2-1: Struktogramm eines periodischen Echtzeitthreads .................................. 37 Abbildung 3.2-2: Startvorgang von Echtzeitprozessen in RT-Linux ................................... 38 Abbildung 4.2-1: Struktur des YASA-Frameworks ............................................................. 41 Abbildung 4.3-1: Struktur eines Executives......................................................................... 43 Abbildung 4.3-2: Erweiterung der OS-Systemstrukturen durch Executive-Patch ............... 44 Abbildung 4.3-3: Makrodefinition eines Loggingereignisses .............................................. 49 Abbildung 4.3-4: Deklaration der Projekt-Makros in RT-Linux ......................................... 52 Abbildung 4.4-1: Deklaration der Scheduling-Funktion...................................................... 56 Abbildung 4.5-1: Zyklus eines YASA-Projekts ................................................................... 57 Abbildung 4.8-1: Angepasstes runit-Skript .......................................................................... 62 Abbildung 5.2-1: Herausragende Eigenschaften von Qt ...................................................... 68 Abbildung 5.2-2: Signal-Slot Mechanismus ........................................................................ 70 Abbildung 5.2-3: Aufbau eines Fensters mit Widgets ......................................................... 71 Abbildung 5.3-1: Assoziation zwischen YObject und YActions ......................................... 73 Abbildung 5.3-2: Vererbung der Klasse YDerivedObject ................................................... 74 Abbildung 5.3-3: Vererbungsdiagramm der Klasse YTime................................................. 75


X

Abbildung 5.3-4: Vererbungsdiagramm von YFrame.......................................................... 77 Abbildung 5.3-5: Anwendungen von YFrames.................................................................... 78 Abbildung 5.3-6: Vererbungsdiagramm der Klasse YWidget ............................................. 79 Abbildung 5.3-7: Vererbungsdiagramm der Klasse YYasaTimeWidget ............................. 79 Abbildung 5.3-8: Assoziationen zwischen Objekten und YFrames (vereinfacht) ............... 79 Abbildung 5.3-9: Vererbungsdiagramm der Klasse YResultFrame..................................... 80 Abbildung 5.3-10: Kompositionsdiagramm der Klasse YTimingInfo................................. 82 Abbildung 5.3-11: Vererbungsdiagramm der Klasse YStatisticEntry<T> .......................... 84 Abbildung A-1 Quelltext des EDF-Schedulers in YASA .................................................... 93 Abbildung A-2: Vergleich dynamischer Prioritäten............................................................. 94 Abbildung A-3: Scheduler-Struktur vor dem Patch der Scheduler-Struktur...................... 100 Abbildung A-4: Scheduler-Struktur nach dem Patch der Scheduler-Struktur ................... 100 Abbildung A-5: Definition des Makros YASA_SCHED_CPU_STRUCT........................ 100 Abbildung A-6: Scheduler-Struktur während des Kompilierens ....................................... 101 Abbildung A-7: Beispiel einer generierten Header-Datei .................................................. 102 Abbildung A-8: Beispiel einer generierten Quelltext-Datei............................................... 104 Abbildung A-9: Logfile aus Abbildung 2.4-2 .................................................................... 106 Abbildung A-10: Konfiguration der vererbbarer Projekteigenschaften ............................. 107 Abbildung A-11: Beispiel 4 in Thread-Ordnung (Prioritätsbasierter Scheduler)............... 108 Abbildung A-12: Beispiel 4 in Thread Ordnung (ELLF-Scheduler) ................................. 108 Abbildung A-13: Beispiel 4, Threads einzeln in Environment-Ordnung........................... 109 Abbildung A-14: Beispiel 4, Mutexe einzeln in Environment-Ordnung ........................... 110 Abbildung A-15: Beispiel 4, CPU einzeln in Environment-Ordnung................................ 110 Abbildung A-16: Vererbungsdiagramm der Klasse YObject............................................. 111 Abbildung A-17: Vererbungsdiagramm der Klasse YSet .................................................. 111 Abbildung A-18: Kompositionsdiagramm der Klasse YProject ........................................ 112 Abbildung A-19: Kompositionsdiagramm der Klasse YEnvironment............................... 113 Abbildung A-20: Kompositionsdiagramm der Klasse YScheduler ................................... 113 Abbildung A-21: Kompositionsdiagramm der Klasse YTask............................................ 114

Tabellenverzeichnis

XI

Tabellenverzeichnis

Tabelle 1: Mögliche Prozesszustandsübergänge .................................................................... 9 Tabelle 2: Kriterien für einen optimalen Schedulingalgorithmus ........................................ 10 Tabelle 3: Preemptionlevel von Beispiel 4 unter Nutzung von SRP................................... 26 Tabelle 4: Zeitwerte in RT-Linux......................................................................................... 36 Tabelle 5: Synchronisationsverfahren in RT-Linux ............................................................. 39 Tabelle 6: Dynamische Prioritätstypen in YASA................................................................. 46 Tabelle 7: Verhalten bei Verpassen einer Deadline ............................................................. 47 Tabelle 8: Dateiänderungen in RT-Linux............................................................................. 51 Tabelle 9: Potenzielle Executives......................................................................................... 54 Tabelle 10: Komponenten eines Schedulers......................................................................... 55 Tabelle 11: Erzeugte Projekt-Dateien................................................................................... 61 Tabelle 12: Tabellentypen eines Environments bei der Projektauswertung......................... 64 Tabelle 13: Geschwindigkeitsvergleich einiger Scheduler .................................................. 65 Tabelle 14: Einsatzgebiete von YASA................................................................................. 66 Tabelle 15: Wichtige YDataTypes ....................................................................................... 76 Tabelle 16: Klassenübersicht der Timingdiagramme.......................................................... 81 Tabelle 17: Klassenübersicht der Statistiktabellen.............................................................. 83 Tabelle 18: XML-Attribute der Exekutive-Konfigurationsdateien ...................................... 96 Tabelle 19: XML-Attribute der Scheduler-Konfigurationsdateien ...................................... 97 Tabelle 20: Logging-Ereignisse............................................................................................ 99

Gleichungsverzeichnis

XII

Gleichungsverzeichnis

Gleichung 1: Berücksichtigung der Kontextwechselzeit...................................................... 10 Gleichung 2: Berechnung der Restfrist bei EDF.................................................................. 14 Gleichung 3: Berechnung des Schlupfes .............................................................................. 15 Gleichung 4: Berechnung des Preemptionlevels für EDF.................................................... 25 Gleichung 5: Berechnung des Preemptionlevels für LLF .................................................... 25 Gleichung 6: 1. Bedingung zur Durchführbarkeit von Prozessen ........................................ 30 Gleichung 7: 2. Notwendige Bedingung zur Durchführbarkeit von Prozessen ................... 30 Gleichung 8: 3. Hinreichende Bedingung zur Durchführbarkeit von Prozessen ................. 30 Gleichung 9: Durchführbarkeitstest mittels Reaktionszeit ................................................... 31 Gleichung 10: Rekursive Berechnung der worst-case Antwortzeit...................................... 31 Gleichung 11: Bestimmung der max. Blockierungszeit ....................................................... 32 Gleichung 12: Berechnung der max. Antwortzeit inkl. Blockierungszeit........................... 32 Gleichung 13: Berechnung der max. Antwortzeit unter Berücksichtigung des Jitters........ 33

Beispielverzeichnis

Beispiel 1: Prozessparameter für Prioritäteninversion Direct-Blocking .............................. 18 Beispiel 2: Prozessparameter für Prioritäteninversion Pass-Through-Blocking .................. 19 Beispiel 3: Prozessparameter für PCP .................................................................................. 22 Beispiel 4: Prozessparameter für Stack Resource Policy ..................................................... 26

Verzeichnis verwendeter Symbole

XIII

Verzeichnis verwendeter Symbole

Arbeitender Prozess (running)

Ruhender Prozessor (idle)

Jitter eines Prozesses

Ausgeschlossener Prozess (excluded)

Systemceilingkonstante, Höhe ist proportional zur Ceilingkonstanten

Erzeugung eines Prozesses T Wechsel des Thread-Typs

Beenden eines Prozesses

Synchronisierter Start von Echtzeitprozessen

Prozessaktivierung

Ignorieren einer Prozessaktivierung

Aktivieren eines Notfallprozesses

Erstmaliger Start eines Jobs

Fortsetzung eines Jobs

Beenden eines Jobs

Start eines Jobs innerhalb der Deadlinetoleranz

Fortführen des Jobs innerhalb der Deadlinetoleranz

Beenden eines Jobs innerhalb der Deadlinetoleranz

Start des Schedulers

Ende des Schedulers

Kontextwechsel

Einhalten einer Deadline

Verpassen einer Deadline (deadline miss)

Erkennung einer verpassten Deadline

Verpassen einer Deadlinetoleranz

Setzen einer Semaphore

Freigeben einer Semaphore

Versuch, eine gesetzte Semaphore erneut zu setzen

Freigabe einer nicht gesetzten Semaphore

Erneutes Setzen einer bereits gesetzten Semaphore P Änderung der Priorität durch Mutexanforderung C Änderung der System-Ceilingkonstanten

1. Einleitung

1

1. Einleitung

1.1 Thematischer Hintergrund

In modernen Betriebssystemen werden Programme aus Sicht des Anwenders quasi-parallel abgearbeitet. In der Realität erfolgt die Ausführung jeweils in kurzen Abständen hinterein-ander. Die Umschaltung der einzelnen Prozesse übernimmt eine Komponente des Betriebs-systems - der Scheduler. Er hat die Aufgabe, den Prozess-Satz der CPU unter Beachtung von sich z.T. widersprechenden Kriterien wie Gerechtigkeit, Effizienz, Antwortzeit und Durchsatz optimal zuzuteilen. In Echtzeitsystemen besitzen Prozesse Zeitschranken, die einzuhalten sind, um die Funkti-onalität der gesamten Anwendung nicht zu gefährden. Das Verpassen einer Deadline könn-te fatale Auswirkungen bis hin zur Gefährdung von Menschen und Maschinen zur Folge haben. Für die Entwicklung harter Echtzeitsysteme ist daher der Einsatz von Schedulern erforderlich, die das Einhalten von Zeitschranken der einzelnen Prozesse garantieren. Die Ausführung mehrerer Prozesse erfordert ein Management der Systemressourcen und Zuteilungsstrategien für die Betriebsmittel. So wird durch das Setzen von Semaphoren si-chergestellt, dass grundsätzlich nur ein Prozess Zugriff auf ein Betriebsmittel erhält, alle anderen blockieren. Die Auswahl dieses Prozesses und die dazu nötigen unterschiedlichen Strategien werden in Synchronisationsprotokollen zusammengefasst. Das Blockieren der Prozesse erschwert eine Aussage über die Durchführbarkeit eines Prozess-Satzes unter Verwendung des eingesetzten Schedulers. Für die meisten Scheduler existieren umfangreiche theoretische Untersuchungen, die das Verhalten unter bestimmten Bedingungen beschreiben und die Durchführbarkeit garantie-ren. Die Voraussetzungen dieser Untersuchungen sind zumeist ideal und statisch, sodass kein wirklicher Praxisbezug hergestellt wird. Die Effizienz des Schedulingverhaltens wird in der Praxis stark von der Systemumgebung geprägt, wie von der Anzahl der Prozesse, den Prozessumschaltzeiten und den externen Einflüssen wie das Warten auf Geräte oder Hardwareinterrupts. Es kann keine generelle Aussage über einen optimalen Scheduler gegeben werden. Er muss grundsätzlich an die Prozessumgebung angepasst werden.

1.2 Ausgangssituation

In der Praxis werden vielfach statische Scheduler und Synchronisationsprotokolle einge-setzt, die mit dem Betriebssystem fest verbunden sind. Der Standardscheduler ist der priori-

1. Einleitung

2

tätsbasierte Scheduler, der durch seine einfache Realisierung, aber schlechtes und nicht dynamisches Schedulingverhalten gekennzeichnet ist. Der Einsatz von dynamischen Sche-dulern und Synchronisationsprotokollen erfordert einen umfangreichen und fehleranfälligen Eingriff in die Betriebssysteme, da keine einheitliche Programmierschnittstelle existiert. Die Optimierung des Schedulingverhaltens erweist sich als schwierig, da die aktuellen Be-triebssysteme keine Möglichkeit der Protokollierung und späteren Auswertung zur Verfü-gung stellen. Ein Vergleich von verschiedenen Schedulern ist nicht möglich. Ebenso problematisch ist der Einsatz von Hardwareschedulern. Sie bieten aufgrund der Parallelität der Verarbeitung einen massiven Geschwindigkeitsvorteil gegenüber Software-schedulern [Hil98]. Ihr Einsatz ist begrenzt auf Systeme mit geeigneter Hardware und Be-triebssystemen mit entsprechenden Schnittstellen zur Programmierung der Coprozessoren.

1.3 Ziele des Frameworks

Die Ziele dieser Diplomarbeit liegen in der Vorstellung einer Lösung, die die theoretischen und praktischen Aspekte gleichermaßen berücksichtigt und gewissermaßen eine Symbiose aus einem Schedulinganalyser und der Schedulingumgebung eines Echtzeitbetriebssystems darstellt. Im Rahmen dieser Arbeit wird ein Entwicklungsframework vorgestellt, dass ganzheitliche Lösungsvorschläge für die aufgezeigten Probleme enthält. Bei der Entwick-lung des Softwareprodukts wurden mehrere Teilziele definiert:

Start der Echtzeitsysteme unter realen Bedingungen

Es soll eine Entwicklungsumgebung entstehen, die es ermöglicht, einen Prozess-Satz inklu-sive der dazugehörigen Programme unter Echtzeitbedingungen in einer realen System-umgebung auszuführen. Nach der Beendigung des Programm soll eine Auswertung und Analyse vorgenommen werden, um die Schedulingparameter zu optimieren.

Unterstützung verschiedener Echtzeitbetriebssysteme bzw. Hardware-Coprozessoren

Die Unterstützung von verschiedenen Zielsystemen erfordert eine Schnittstelle (Application programmable Interface = API) zwischen Anwendungen und Zielsystemen. Nur auf diese Weise ist ein Wechsel zwischen unterschiedlichen Echtzeitbetriebssystemen möglich. Die Schnittstelle soll sich nur auf Schedulingparameter beschränken, da sonst die Entwicklung eines virtuellen Betriebssystems erforderlich wäre. Für den Austausch der Scheduler bzw. Synchronisationsprotokolle eines Betriebssystems muss ein Konzept entwickelt werden, um die Systemfunktionen der Zielsysteme zu erweitern. Die möglichst plattform-unabhängige Programmierung erfordert eine hohe Abstraktion und genaue Definition der Schnittstellen.

1. Einleitung

3

Einheitliche Entwicklungsumgebung für Simulationen und Echtzeitanwendungen

Die Forderung nach Unterstützung verschiedener Echtzeitbetriebssysteme schließt die Ent-wicklung eines Simulators als eigenständiges Zielsystem mit ein. Dadurch wird aus Appli-kationssicht die Entwicklung standardisiert, da dieselbe Schnittstelle zwischen Anwendung und Zielsystem benutzt wird. Ein direkter Vergleich wird möglich.

Erweiterbarkeit durch Entwicklung neuer Scheduler

Es soll die Möglichkeit bestehen, neu entwickelte Scheduler zu implementieren. Diese sol-len auf jedem Zielsystem einsetzbar sein. Die Scheduler-API muss aus diesem Grund sehr klein, effizient und eindeutig sein. Eine Begrenzung der Aufgaben ist notwendig.

Einfacher Wechsel des Schedulers in der Zielumgebung

Ein Wechsel des Schedulers innerhalb der Zielumgebung erfordert erneut die Definition einer Schnittstelle (Scheduler-API). Um einer größtmöglichen Anzahl von Schedulern die nötigen Informationen zur Verfügung zu stellen, muss die Schnittstelle Daten der folgenden Kategorien bereitstellen:

• Daten des Prozess-Satzes • Schedulinginformationen • Zeitauflösungen und –informationen des Systems • Konfiguration des Schedulers • Schedulerabhängige Daten • Informationen über unterstützte Synchronisationsprotokolle

Unterstützung verschiedener Synchronisationsprotokolle unabhängig vom Scheduler

In vielen theoretischen Publikationen werden Synchronisationsprotokolle im Zusammen-hang mit einzelnen Schedulern betrachtet. Diese Herangehensweise spiegelt sich in allen betrachteten Schedulinganalysern wieder. Wird der Scheduler geändert, kann das gewählte Synchronisationsprotokoll meist nicht mehr verwendet werden, da die Programme zu statisch auf bestimmte Konstellationen fi-xiert sind. Besonders deutlich wird das Problem bei Verwendung dynamischer Synchroni-sationsprotokolle wie DPCP und SRP, die in allen Programmen lediglich mit EDF funktio-nieren, mit LLF bzw. ELLF aber versagen.

Wahl der Synchronisationsprotokolle pro Semaphore

Vielfach kann in anderen Schedulinganalysern die Wahl des Synchronisationsprotokolls vorgenommen werden, allerdings nur für die gesamte Simulation. Das entspricht nicht den

1. Einleitung

4

in der Praxis benutzten Betriebssystemen, die dem POSIX-Standard gehorchen. In POSIX ist die Wahl des Synchronisationsprotokolls pro Semaphore definiert [Gal97].

Behandlung aperiodischer Ereignisse

Die korrekte Behandlung aperiodischer Ereignisse ist von entscheidender Bedeutung für die Einhaltung der Zeitschranken in Echtzeitsystemen. Diese Ereignisse starten i.d.R. aperiodi-sche Prozesse, die in Servern, z.B. Polling-Servern, verarbeitet werden.

Notfallmaßnahmen

Ein weiteres Ziel ist die Einführung von Notfallmaßnahmen in Software, wenn Deadlines nicht eingehalten werden können. Eine Behandlung sollte nach einer der folgenden Mög-lichkeiten durchgeführt werden:

• Starten eines Notfallprozesses • Ignorieren der verpassten Deadline • Ignorieren der nächsten Periode des Prozesses

Vermeidung von Grenzen bzw. Grenzwerten

Die Vermeidung von Grenzen ist ein entscheidender Punkt, um die Zukunftsfähigkeit des Programms zu sichern. Selbstauferlegte Grenzen sind vermeidbar und wirken kontrapro-duktiv, da sie bei einer Änderung bzw. Weiterentwicklung einen mehrfachen Aufwand ver-ursachen. Typische Grenzen sind:

• Limitierung von Daten ohne ersichtlichen Grund, z.B. max. Zeitdauer • Vermeidung von API’s • Festlegung auf Betriebssysteme bzw. Systemumgebungen • Verwendung statischer Datentypen, z.B. int64 statt hrtime_t

Multiprozessorfähige Anwendungen

Das Framework soll in der Lage sein, Anwendungen mit mehreren Prozessoren zu verarbei-ten und für jede CPU einen anderen Scheduler zu definieren. Ein interessanter Aspekt ge-genüber mehreren Einzelsimulationen ist der Einfluss durch Setzen und Freigeben von Se-maphoren.

Protokollierung von Ereignissen

Die spätere Auswertung und Analyse erfordert eine Protokollierung der Ereignisse während der Ausführung des Echtzeitsystems. Besondere Beachtung muss der schnellen Bearbeitung

1. Einleitung

5

geschenkt werden. Eine Filterung von Ereignissen ist wünschenswert, um das Laufzeit-verhalten zu verbessern und das Datenvolumen zu minimieren.

Ausführliche Auswertung und umfangreiche grafische Darstellung der Ergebnisse

Nach der Ausführung des Echtzeitsystems muss das Ereignisprotokoll ausgewertet werden. Hierzu ist eine grafische Oberfläche nötig. In dem Front-End soll die Möglichkeit bestehen, die Ergebnisse in Form von Zeitdiagrammen (Timing-Diagramme) und Tabellen ein-zusehen. Der Entwickler soll die Ergebnisse vergleichen, analysieren und gegebenenfalls das System neu konfigurieren können. In der Praxis basieren Echtzeitsysteme größtenteils auf UNIX oder seinen Derivaten, sodass eine Auswertung unter UNIX-Systemen möglich sein muss. Da viele Entwickler bevorzugt Windows-Systeme im Desktop-Bereich zur Simulation einsetzen, muss das grafische Front-End auch unter dem Microsoft-System laufen.

Programmierung des Front-Ends

Die Programmierung des Front-Ends soll in einer objekt-orientierten Programmiersprache unter Nutzung von Entwurfsmustern (Design-Pattern) erfolgen, um eine hohe Wieder-verwendbarkeit und Erweiterbarkeit zu garantieren. Die grafische Benutzeroberfläche muss auf verschiedenen Betriebssystemen ausführbar sein. Dazu ist der Einsatz einer plattformübergreifenden Klassenbibliothek notwendig. Um die Portabilität zu erhöhen und eine multilinguale Darstellung zu ermöglichen, sollen alle internen Zeichenketten im UNICODE-Format abgelegt werden. Für Konfigurationsdateien empfiehlt sich die Speicherung in Textformaten, die eine spätere Erweiterung des Formats ermöglichen.

Konsequente Trennung von Entwicklungsframework und Front-End

Durch die konsequente Trennung von Entwicklungsframework und Front-end soll eine bes-sere Datenkapselung erreicht werden. Die Komponenten sind unabhängig voneinander, sodass ein Einsatz des Frameworks auf Systemen ohne grafische Benutzeroberfläche, wie z.B. auf eingebetteten Systemen, möglich ist.

Ansprechende und zeitgemäße Oberfläche

Für den Erfolg von Entwicklungssystemen ist nicht zuletzt auch die angemessene und style-guide konforme Bedienung entscheidend. Eine ansprechende Optik und Einbettung in die verschiedenen Zielsysteme muss gewährleistet sein.

1. Einleitung

6

Laufzeitverhalten

Bei der Entwicklung des grafischen Front-Ends soll ein flüssiges und stabiles Laufzeitver-halten erreicht werden. Die absehbare Komplexität der Anwendung erfordert bereits wäh-rend der Entwicklung eine ständige Implementierung von Fehlerkorrekturmechanismen. Es müssen Konzepte entwickelt werden, um grafikintensive Funktionen, wie vergrößerte Zeit-diagramme, in angemessener Geschwindigkeit auszuführen.

1.4 Gliederung

In dieser Arbeit werden in Kapitel 2 zunächst die theoretischen Grundlagen von Echtzeit-systemen und Echtzeitbetriebssystemen erläutert. Es wird dargelegt, wie Prozesse mit-einander kommunizieren und welche besonderen Effekte auftreten können. In diesem Zu-sammenhang wird eine Einführung in die unterschiedlichen Schedulertechniken gegeben. Im Anschluss erfolgt die Definition einiger Synchronisationsprotokolle. Die angewandten Techniken der Scheduler und Protokolle werden in zahlreichen Beispielen illustriert. Das Kapitel 3 enthält eine kurze Einleitung zu dem Betriebssystem RT-Linux. Der Einlei-tung schließt sich eine Kernelbeschreibung an. Sie beinhaltet eine Darlegung der groben Gliederung und betrachtet den Aufbau der Schedulingumgebung. Es wird ferner auf beson-dere Probleme bei der Initialisierung von periodischen Echtzeitanwendungen eingegangen. Das entwickelte Framework YASA 2 wird in Kapitel 4 vorgestellt. Es folgt die Erläuterung der Konzepte, um den Austausch von Schedulingumgebungen zu realisieren. Anschließend wird veranschaulicht, welche Komponenten eines Betriebssystems wie ersetzt werden und wie plattformunabhängige Scheduler arbeiten. Das Kapitel gibt weiterhin Auskunft über zusätzliche Eigenschaften von YASA 2 zur Behandlung von Notfallmaßnahmen. Es erklärt den Ablauf einer Echtzeitanwendung und gibt Aufschluss über mögliche Einsatzgebiete des Frameworks. In Kapitel 5 werden spezielle Themen der Programmierung des grafischen Front-Ends dar-gelegt. Zunächst werden besondere Eigenschaften der verwendeten Klassenbibliothek her-vorgehoben. Im Anschluss erfolgt die Vorstellung der YASA 2 Basisklassen. Das Kapitel wird abgerundet durch die Beschreibung herausragender Eigenschaften in YASA, die durch spezielle Softwaretechniken und Entwurfsmuster erreicht wurden.

2. Grundlagen von Echtzeitsystemen

7


2.1 Echtzeitbetriebssysteme

Echtzeitsysteme sind Computersysteme, in denen nicht nur das Ergebnis einer Operation, sondern ebenso der Zeitpunkt, zu dem das Ergebnis vorliegt, entscheidend ist. Zu diesem Zweck werden Zeitlimits (Deadlines) definiert, bis zu denen das System reagieren muss. Es werden harte und weiche Deadlines unterschieden. Das Verpassen weicher Zeitschranken kann abhängig vom Überschreiten der Deadline Leistungseinbußen nach sich ziehen, z.B. Ruckeln einer Videoübertragung bis hin zum völligen Ausfall. Der Nutzen nimmt mit zu-nehmender Zeit ab. Harte Deadlines müssen eingehalten werden, um System und Umge-bung nicht zu gefährden. Ein nicht behandeltes Not-Aus Signal einer blockierenden Dreh-maschine kann Mensch und Maschine stark gefährden. In der Praxis werden Echtzeitsysteme, die harte Deadlines verwenden als harte Echtzeitsys-teme bezeichnet. Folglich werden Systeme mit weichen Endterminen als weiche Echtzeit-systeme bezeichnet. In Echtzeitsystemen mit leistungsstarken Prozessoren und hohen Erweiterungsanforderun-gen werden zur Steuerung der komplexen Aufgaben Echtzeitbetriebssysteme eingesetzt. In der Praxis sind u.a. folgende (UNIX-)Echtzeitbetriebssysteme im Einsatz: RT-Linux, Lyn-xOS, VxWorks, IRIX und RTAI. Für leistungsschwächere Prozessoren und eingebettete Systeme existieren spezielle Lösungen wie TinyOS. Die Betriebssysteme (Real Time Operating System = RTOS) verwalten die Prozesse bzw. den Hauptspeicher und sind in der Lage, verschiedene Ein- bzw. Ausgabeeinheiten anzu-sprechen. Sie müssen, im Gegensatz zu General Purpose Operating Systems (GPOS) wie Windows bzw. Linux, in der Lage sein, auf interne und externe Ereignisse in der vorgege-benen Zeit zu reagieren. Interne Ereignisse werden ausgelöst, um Zustandsänderungen bzw. Zeitabläufe zu signalisieren, auf die eine Antwort erzeugt werden muss. Externe Ereignisse charakterisieren in der Regel die dynamischen Anforderungen an das System, z.B. durch Sensoren.

2.2 Prozesse

In Betriebssystemen sind Prozesse die Instanzen, die gestarteten Programmen zugeordnet werden, um sie zu verwalten. In der GPOS sind Prozesse im allgemeinen nicht periodisch, d.h. sie werden abgearbeitet und beendet. In RT-Systemen gibt es zusätzlich periodische und aperiodische Prozesse. Periodische Prozesse werden durch eine Periode Pi, die worst-


8

case Rechenzeit Ci, die Deadline Di und den Startzeitpunkt Oi definiert. In Abbildung 2.2-1 ist das Zeitdiagramm eines periodischen Prozesses dargestellt. Aperiodische Prozesse kön-nen weiche oder harte Deadlines enthalten. Aperiodische Prozesse, die sich durch eine harte Deadline und einen minimalen Ereignisabstand auszeichnen, bezeichnet man als sporadi-sche Prozesse. In Echtzeitbetriebssystemen kann jeder Prozess mehrfach aktiviert und bearbeitet werden. Er wird in diesem Zeitraum als Job Jx bezeichnet. Vielfach wird auch die Bezeichnung Task verwendet.

Rechenzeit C

Deadline D

Periode T

Ereignis 1 Ereignis 2

Abbildung 2.2-1: Definition der Prozesseigenschaften

In modernen Betriebssystemen besteht zwischen Prozessen Speicherschutz, d.h. ein illega-ler Speicherzugriff auf fremde Daten durch einen Prozess führt zu dessen vorzeitigem Ab-bruch. Alle anderen Prozesse werden nicht beeinflusst. Erzeugen Prozesse neue Sohnpro-zesse, die in einem gemeinsamen Speicherbereich liegen, so heißen diese Prozesse Threads. Unter den Threads existiert kein Speicherschutz, sodass ein Fehlverhalten schlecht diagnos-tiziert und zum Abbruch des gesamten Programms durch das Betriebssystem führen kann.

Ready

ASleep Running Suspended

4

51

3 26

Abbildung 2.2-2: Erweitertes Prozesszustandsmodell

Ein Prozess kann zur Laufzeit vier verschiedene Zustände annehmen, die in dem Prozess-zustandsmodell in Abbildung 2.2-2 dargestellt sind. Die Übergänge zwischen den Zustän-den sind in Tabelle 1 definiert. Die Verwaltungsinformationen des Betriebssystems über die Prozesse werden in Struktu-ren, den Prozesskontrollblöcken PCB, gespeichert. Der PCB enthält Informationen wie die ProzessIdentifikationsnummer PID, die Prozessidentifikationsnummer des übergeordneten Prozesses PPID, den momentanen Prozesszustand, die statische Priorität des Prozesses, die Stackadresse, den Programmzähler sowie über die vom Prozess belegten Betriebsmittel. In


9

den Betriebssystemen mit Rechteverwaltung (UNIX, Windows) enthalten die PCB zusätz-lich Informationen über die Berechtigungen der zugeordneten Benutzer bzw. Gruppen. In Echtzeitbetriebssystemen sind weitere Daten nötig, um die festgelegten Zeitschranken einzuhalten. Zu diesen Daten gehören die aktuelle Deadline, die benötigte Rechenzeit, die bereits verbrauchte Rechenzeit, der Aktivierungszeitpunkt u.a. Die Implementierung im Betriebssystem ist stark vom verwendeten Scheduler und dessen Prioritätstypen abhängig. Übergang Beschreibung

1 Der Prozess blockiert, da er auf externe Ereignisse, z.B. Tastatureingaben, wartet. Er geht in den Zustand ASleep über und nimmt nicht mehr am Sche-duling teil.

2 Der Scheduler hat diesen Prozess zur weiteren Abarbeitung ausgewählt und teilt ihm den Prozessor zu. Er wechselt in den Zustand Running.

3 Der Scheduler hat einen anderen Prozess zur weiteren Abarbeitung ausge-wählt und entzieht dem laufenden Prozess die CPU.

4 Es sind externe Ereignisse eingetreten, auf die der Prozess gewartet hat. Der Zustand geht in Ready über und der Scheduler wird aufgerufen, da sich die Eigenschaften des Prozess-Satzes verändert haben.

5 Der Prozess ist nicht mehr am Ablaufgeschehen beteiligt. Er wurde durch einen fremdem Prozess oder das Betriebssystem suspendiert, z.B. durch das Anfordern einer bereits belegten Semaphore.

6 Der Prozess kann wieder am Ablaufgeschehen teilnehmen, da die Bedingun-gen der Suspendierung, z.B. durch Freigabe einer Semaphore, beseitigt sind.

Tabelle 1: Mögliche Prozesszustandsübergänge

2.3 Scheduling

In Betriebssystemen, die mehrere Programme gleichzeitig abarbeiten können (Multitas-kingbetriebssysteme), müssen zur Laufzeit ständig Entscheidungen über die Zuteilung des Prozessors zu den einzelnen Programmen erfolgen. Diese Entscheidungen, die in Abhän-gigkeit von dem gewünschten Systemverhalten, der eingestellten Prozesszuteilungsstrategie und der dem Betriebssystem bekannten Prozessparameter gefällt werden, übernimmt der Scheduler. Der Scheduler eines Betriebssystems kann abhängig von der Implementierung bei folgenden Aktivitäten aufgerufen werden:

• Start/Aktivierung eines Prozesses • Beendigung eines Prozesses • Freigabe einer Ressource • Ablauf des Timer Ticks • Manueller Aufruf


10

Der Scheduler sollte bei der Wahl des nächsten Prozesses die Kriterien in Tabelle 2 mög-lichst optimal beherrschen. Sie stehen zumeist im Widerspruch zueinander. Die Stärkung eines Kriteriums führt zwangsläufig zur Benachteilung eines anderen Kriteriums.

Kriterium Beschreibung

Gerechtigkeit Jeder Prozess sollte möglichst gleichberechtigt an der CPU-Zeit beteiligt sein, um ein ausgewogenes Verhältnis zwischen allen Prozessen zu errei-chen.

Effizienz Durch das Scheduling ist eine 100%ige Auslastung des Prozessors ohne Wartezeiten anzustreben. Die Dauer des Schedulings sollte kurz sein.

Antwortzeit Eine Minimierung der Antwortzeiten ist anzustreben, um schnell auf Er-eignisse zu reagieren und die Gefahr einer Zeitüberschreitung zu verrin-gern.

Verweilzeit Die Verweilzeit von Prozessen in Stapelaufträgen ist zu minimieren. Durchsatz Die Anzahl der bearbeiteten Prozesse pro Zeiteinheit ist zu maximieren.

Tabelle 2: Kriterien für einen optimalen Schedulingalgorithmus

Die Wahl des richtigen Schedulers hat eine weit höhere Bedeutung als allgemein ange-nommen wird. In theoretischen Betrachtungen wird grundsätzlich davon ausgegangen, dass die Zeit des Schedulings null ist. Bei nicht-unterbrechbaren (non-preemptive) Schedulern ist die Zeitdauer vernachlässigbar, da er sehr selten aufgerufen wird. Bei periodisch aufge-rufenen Schedulern wie Least Laxity First (LLF) ist das Verhalten deutlich kritischer. Ähn-lich verhält es sich mit der Zeitdauer, die für das Umschalten auf einen neuen Prozess be-nötigt wird (Context Switch Time). Eine einfache Möglichkeit ist, die Kontextwechselzeit Cs in die für den Prozess benötigte Rechenzeit C* hineinzurechnen (Gleichung 1). Der Fak-tor 2 erschliesst sich aus der Unterbrechbarkeit durch höher priorisierte Prozesse. Diese Methode funktioniert allerdings nur für nicht-preemptive Scheduler, da die Anzahl der Kontextwechsel sonst nicht zwei beträgt.

si CCC *2* +=

Gleichung 1: Berücksichtigung der Kontextwechselzeit

Weiterhin wird in theoretischen Betrachtungen über Schedulingverfahren in der Regel vor-ausgesetzt, dass ein Blockieren durch Semaphoren ausgeschlossen ist. Viele Scheduling-verfahren werden in der Theorie als optimal dargestellt, sind in der Praxis aufgrund der Komplexität und Unvorhersagbarkeit von Ereignissen aber kaum anwendbar. Die Praxistauglichkeit der in Gleichung 1 vorgestellten Methode zur Berücksichtigung der Kontextwechselzeit wird durch die Verwendung von Semaphoren weiter eingeschränkt, da sie Blockierungen, z.B. durch eine Prioritäteninversion (s. Kap. 2.4.2) nicht berücksichtigt.


11

2.3.1 Klassifikation von Schedulern

Die Zuteilung des Prozessors erfolgt, wie in Kapitel 2.3 erwähnt, mittels eines Schedulers, der unterschiedliche Zuteilungsstrategien anwenden kann. Eine Übersicht ist in Abbildung 2.3-1 dargestellt. Neben den einfachen Strategien gibt es hybride Verfahren, die mehrere Schedulingtechniken kombinieren. Die MultiLevel-Feedback Queue unter Windows NT ist ein Beispiel für eine Kombination aus Round Robin und Priority based.

Scheduler

Zyklische SchedulerPrioritätsbasierte Scheduler

DynamischStatisch

Rate MonotonicDeadline Monotonic

Priority based Earliest Deadline First

Largest Execution Time FirstLeast Laxity First

Round RobinFirst come first serve

Abbildung 2.3-1: Klassifikation von Schedulern

2.3.2 Zyklische Scheduler

Die zyklischen Scheduler zeichnen sich durch eine sequenzielle Abarbeitung der Prozesse aus. Es erfolgt keine Vergabe von Prioritäten in Abhängigkeit von Prozesseigenschaften. Sie werden in der Praxis vor allem in Kombination mit statischen Schedulern eingesetzt. Die zwei typischen Vertreter sind:

• Round Robin Alle Prozesse werden gleichrangig behandelt und erhalten der Reihe nach den Prozessor für eine festgelegte Zeitscheibe. Der Scheduler arbeitet preemptiv.

• First Come First Serve Umsetzung des in der Technik bekannten FIFO-Prinzips. Der Prozess, der als erstes erzeugt wurde, erhält den Prozessor bis zur vollständigen Abarbeitung (nicht-preemptiv).

2.3.3 Statische Scheduler

Die statischen Scheduler sind die in der Praxis am häufigsten anzutreffenden Scheduler. Sie zeichnen sich durch eine relativ einfache Implementierung aus.


12

Die statischen Scheduler werten zur Laufzeit eine Priorität aus, die im Vorfeld, z.B. beim Erzeugen des Prozesses, festgelegt wurde. Es besteht die Möglichkeit, einen simplen ganz-zahligen Wert zuzuweisen oder die Priorität von der Deadline, der benötigten Zeit oder des Schlupfes abhängig zu machen. Die Reihenfolge der Abarbeitung ist somit im Vorfeld fest-gelegt. Der Nachteil des statischen Schedulings besteht in der unflexiblen Behandlung dynami-scher Ereignisse, die zur Laufzeit auftreten können. Ferner müssen Betrachtungen zur max. Auslastung des Prozessors im Vorfeld erfolgen (s. Kap. 2.7.1). Eine Auslastung von 100% ist lediglich bei Prozess-Sätzen mit einem Prozess möglich (Gleichung 8).

2.3.3.1 Priority Based Scheduling

Das prioritätsbasierte Scheduling benutzt als Kriterium eine vom Programmierer festgelegte Priorität. Der Scheduler wählt bei jedem Aufruf den Prozess mit der höchsten Priorität aus und teilt ihm den Prozessor zu. Dieses Verfahren eignet sich besonders gut für Systeme mit periodischen und nicht-periodischen Prozessen, da die Implementierung im Scheduler für beide gleich und zudem sehr effizient, einfach sowie robust ist. In der Praxis wird dieses Verfahren in unterschiedlichen Varianten bei allen POSIX-Derivaten eingesetzt und ist zugleich für den Einsatz in GPOS geeignet. Um ein gewisses Maß an Dynamik zu erreichen, kann in den meisten Betriebssystemen die Priorität zur Laufzeit geändert werden. Vielfach werden auch nach Prozessornutzung gewichtete Ver-fahren verwendet (Linux).

2.3.3.2 Rate Monotonic Scheduling

Das Rate Monotonic Verfahren (RMS) setzt voraus, dass alle Prozesse periodisch sind und die Deadline des Prozesses gleich der Periode des Prozesses ist. Weiterhin müssen die Pro-zesse unabhängig voneinander sein und besitzen eine über alle Perioden konstante Rechen-zeit. Die Prioritätsvergabe erfolgt bei RMS umgekehrt proportional ihrer Periode, d.h. je kürzer die Periode, desto höher die Priorität. Der Scheduler wählt zur Laufzeit den Prozess mit der höchsten Priorität aus und teilt ihm den Prozessor zu. Der Prozess wird nicht-preemptiv ausgeführt, es sei denn, es liegt eine Ressourcenanforderung vor, die nicht durchgeführt werden kann. Die Rate-Monotonic Schedulinganalyse erlaubt im Vorfeld eine Betrachtung der Durch-führbarkeit des Schedulings für einen Prozess-Satz. Erfüllt er die hinreichende Bedingung nach Gleichung 8, ist er durchführbar mit RMS. Da RMS ein optimales Verfahren ist, kann


13

der Prozess-Satz mit jedem optimalen statischen Schedulingverfahren verplant werden. Umgekehrt gilt, dass ein Prozess-Satz, der nicht mit RMS verplant werden kann, mit kei-nem anderen statischen Scheduler ausführbar ist.

0 105 15 20

P1

P2

Abbildung 2.3-2: Fehlerhaftes Schedulingverhalten von RMS trotz Auslastung < 1

Das Beispiel in Abbildung 2.3-2 zeigt ein Schedulingverhalten nach RMS, in dem trotz einer Auslastung, die kleiner als 1 ist, Deadlines verpasst werden. Der Grund liegt in der Nichtbeachtung der hinreichenden Bedingung (Gleichung 8). Der Prozess-Satz in dem ge-zeigten Beispiel hat folgende Eigenschaften:

Prozess Priorität Periode Deadline Rechenzeit Auslastung 1 hoch 5 5 2 0,4 2 niedrig 7 7 4 0,57

Gesamtauslastung: 97,03534

74

52

≈=+=U

2.3.3.3 Deadline Monotonic Scheduling

Bei Verwendung des Deadline Monotonic Schedulings (DMS) wird die statische Priorität vorab durch die Deadline des Prozesses bestimmt. Je kürzer die Deadline, desto höher die Priorität des Prozesses innerhalb des Prozess-Satzes. Die Deadlines dürfen kleiner als die Periode sein. Der Spezialfall, bei dem alle Deadlines gleich dem Wert der Periode entspre-chen, ergibt dasselbe Schedulingverhalten wie bei RMS. Insofern ist RMS ein Spezialfall des Deadline Monotonic Schedulings.

2.3.4 Dynamische Scheduler

Die dynamischen Scheduler sind in der Praxis seltener anzutreffen als die statischen Sche-duler. Sie benutzen als Schedulingkriterium eine Priorität, die dynamisch ist und sich dem-nach zur Laufzeit ändert, d.h. die aktuelle Zeit ist maßgeblich beteiligt. Um dies zu ermög-lichen, werden die Prozesskontrollblöcke mit weiteren Attributen ausgestattet, wie z.B. Ankunftszeiten des Prozesses, benötigte Zeiten, Semaphorenbelegungen etc. Die Priorität


14

könnte z.B. aus dem zeitlichen Abstand zur nächsten Deadline bestehen oder dem kleinsten Schlupf. Diese Scheduler zeichnen sich besonders durch die vorteilhafte Bearbeitung dynamischer Ereignisse aus. Optimale dynamische Scheduler erreichen im Gegensatz zu statischen Schedulern eine theoretische Auslastung von 100% (Gleichung 7). In dynamischen Schedulern kann allerdings im Vorfeld kein Durchführbarkeitstest gemacht werden, da sich die Prioritäten zur Laufzeit ändern. Aus diesem Grund werden „online“ Tests durchgeführt, wenn neue Prozesse aktiviert werden. Derzeit sind zwei Näherungsver-fahren bekannt [Jos96]:

• Dynamic planning based approaches

Die Ausführung eines Prozesses ist statthaft, wenn er seine Deadline noch erreichen kann.

• Dynamic best-effort approaches

Die Durchführbarkeit des Prozesssatzes wird nicht überprüft. Das System versucht, alle Deadlines zu halten. Verpasst ein Pro-zess seine Deadline, kann er abgebrochen werden.

2.3.4.1 Earliest Deadline First

Der Earliest Deadline First Algorithmus (EDF) ist der bekanntestes und einfachste dynami-sche Scheduler. Das Schedulingkriterium ist die Zeitspanne E(t) zwischen dem aktuellen Zeitpunkt und der aktuellen Deadline des Prozesses (Gleichung 2). Je kleiner der Zeitraum (Restfrist) ist, desto höher ist die Priorität des Prozesses.

ttDtE −= )()(

Gleichung 2: Berechnung der Restfrist bei EDF

EDF ist ein optimales Verfahren, d.h. falls ein Prozess-Satz mit irgendeinem Scheduler durchführbar ist, dann ist er ebenso mit EDF durchführbar [Der74]. Eine weitere herausra-gende Eigenschaft des EDF Schedulers ist die Minimierung der Latenzzeiten, wie in [But97] gezeigt wird. Der Scheduler arbeitet nicht-preemptiv, was die Anzahl der Schedu-lingdurchläufe deutlich reduziert. Ein Nachteil des Schedulers besteht in dem Verpassen von z.T. allen Deadlines, wenn eine einzige Deadline verpasst wird (Dominoeffekt). Eine Abmilderung des Effekts kann durch gezielte Maßnahmen zur Deadlinebehandlung erreicht werden. In Abbildung 2.3-3a ist das Zeitdiagramm eines Prozess-Satzes mit 4 Prozessen dargestellt. Bei t=2 wird P4 aktiviert, bei t=4 wird P3 aktiviert usw. Der Prozess mit der kürzesten Deadline bekommt jeweils den Prozessor zugesprochen. Alle Deadlines werden eingehal-ten.


15

In Abbildung 2.3-3b ist das Schedulingverhalten bis t=10 identisch. Zum Zeitpunkt t=10 wird der Prozess Pnew erzeugt, der aufgrund der kürzesten Deadline den Prozessor erhält und bis t=14 rechnet. Durch diese Verzögerung kann P1 seine Abarbeitung nicht rechtzeitig beenden, verpasst seine Deadline und beendet sich nach seiner Abarbeitung. P2 kann seine Deadline ebenfalls nicht einhalten. Die Kette setzt sich bis P4 fort. Die Prozesse verpassen ihre Deadlines alle nacheinander (Dominoeffekt).

0 105 15 20

P3

P4

P1

P2

0 105 15 20

P3

P4

P1

P2

PNew

t0 Abbildung 2.3-3: a) EDF-Beispiel b) Dominoeffekt beim EDF-Scheduler

2.3.4.2 Least Laxity First

Der Least Laxity First Scheduler (LLF) benutzt als Schedulingkriterium den kleinsten Spielraum (Schlupf, Laxity). Als Schlupf wird der zeitliche Abstand zwischen noch benötigter Rechenzeit und Deadline bezeichnet. Ein Prozess bekommt die CPU zugeteilt, wenn er den geringsten Spielraum aller Prozesse hat.

))()(()()( 0 tCtCttDtL −−−=

Gleichung 3: Berechnung des Schlupfes

Da sich dieser Spielraum jederzeit ändert bzw. ändern kann, muss der LLF-Scheduler peri-odisch aufgerufen werden. Er arbeitet preemptiv. Daraus resultiert ein enormer Anstieg der Scheduleraufrufe.

0 105 15 20P

CP

C(t1)

t1L(t1)

DP Abbildung 2.3-4: Definition des Spielraumes bei Least Laxity First


16

Ist der Spielraum eines Prozesses negativ, kann er seine Deadline nicht mehr erreichen, da die zu benötigende Zeit größer als die Restfrist ist. Diese Eigenschaft kann ausgenutzt wer-den, um frühzeitig Prozesse zu erkennen, die ihre Deadline verpassen werden und um ent-sprechende Notfallmaßnahmen einzuleiten.

0 105 15 20P2

P1

L(2) L(7) L(8) L(9) L(15) L(16)P1 - 5 5 4 1 1 P2 5 5 4 4 1 0

Abbildung 2.3-5: Darstellung des Trashings bei Least Laxity First

In Abbildung 2.3-5 ist ein Prozess-Satz dargestellt, der mit dem LLF-Scheduler arbeitet. Die Spalten in der rechten Tabelle stellen die jeweiligen Spielräume zum Zeitpunkt t dar. In dem Beispiel startet P2 seine Ausführung bei t=2 und arbeitet bis zum Zeitpunkt t=7, an dem P1 aktiviert wird. Alle Prozesse, die sich in der Ready-Warteschlange befinden, verrin-gern mit jedem Zeittick ihren Schlupf. Der Prozess, der bearbeitet wird, verändert seinen Schlupf nicht. Durch die sich ändernden Spielräume kann es vorkommen, dass zwei Pro-zesse den gleichen Schlupf haben (t=7). Ein beliebiger Prozess wird vom Scheduler ausge-wählt und eine Zeiteinheit bearbeitet – sein Schlupf bleibt konstant. Beim nächsten Schedu-leraufruf wird der andere Prozess ausgewählt, da er jetzt einen kleineren Spielraum hat. Der Schlupf des ersten Prozesses verringert sich während des nächsten Ticks, womit beide Pro-zesse wieder denselben Schlupf haben. Dieser Effekt wird Trashing genannt. Er ruft eine unnötig hohe Anzahl von Kontextwechseln hervor und setzt sich fort, bis einer der beiden Prozesse beendet ist oder andere Prozesse den Schedulingverlauf beeinflussen.

2.3.4.3 Enhanced Least Laxity First

Die Weiterentwicklung des LLF Schedulers wird als Enhanced Least Laxity First (ELLF) bezeichnet [Hil98]. Dieser Scheduler hat dieselben Eigenschaften wie LLF, verhindert aber das Trashing von Prozessen. Zu diesem Zweck wird ein zusätzlicher Prozesszustand eingeführt (ausgeschlossen = exc-luded). Wenn in einem Schedulerdurchlauf zwei Prozesse den kleinsten Schlupf haben, wird der mit der späteren Deadline ausgeschlossen. Der Prozess mit der früheren Deadline kann ohne Trashing weiter bearbeitet werden. Der ausgeschlossene Prozess nimmt am Schedulingverfahren weiter teil, kann aber nicht mehr ausgewählt werden - sein Prozesszu-stand ist weiterhin Ready. Er verringert kontinuierlich seinen Spielraum und bildet damit eine Schwelle. Der laufende Prozess kann während seiner Ausführung nur durch neue Pro-zesse mit einem geringeren Spielraum als dem des ausgeschlossenen Prozesses unterbro-


17

chen werden. Nach Beendigung des laufenden Prozesses wird der ausgeschlossene Prozess wieder zugelassen. In Abbildung 2.3-6 ist das Verhalten des Prozess-Satzes aus dem vorangegangenen LLF-Beispiel nochmals mit ELLF-Scheduling dargestellt. Der Prozess P1, der zum Zeitpunkt t=7 aktiviert wird, wird sofort ausgeschlossen, da er denselben Schlupf wie P2 hat, aber eine spätere Deadline. Daher kann P2 bis zu seiner Terminierung weiterarbeiten. Zum Zeitpunkt t=12 wird der Prozessor an P1 übergeben und dieser kann bis zum Ende weiterrechnen. Der Nachteil des Verfahrens besteht in dem höheren Rechenaufwand und dem periodischen Aufruf des Schedulers. Er ist daher nur für Hardwarescheduler interessant.

0 105 15 20P2

P1

L(2) L(7) L(8) L(9) L(11) L(12)P1 - 5 4 3 1 0 P2 5 5 5 5 5 5

Abbildung 2.3-6: Beispiel zu ELLF anhand von Beispiel in Abbildung 2.3-5

2.4 Synchronisation von Prozessen

2.4.1 Einführung in kritische Abschnitte und Semaphoren

Die Arbeit mit modernen Multitaskingbetriebssystemen erfordert einen Datenaustausch zwischen mehreren Prozessen. Bei diesem Austausch werden Speicherbereiche von min-destens zwei Prozessen bearbeitet. Prozesse, die auf diese Bereiche zugreifen, befinden sich im kritischen Abschnitt. In kritischen Abschnitten werden nicht nur Daten ausgetauscht, sondern auch Zugriffe auf Systemressourcen wie externe Schnittstellen und Datenspeicher abgesichert. Um zu verhindern, dass sich mehrere Prozesse gleichzeitig lesend oder schrei-bend in diesen Abschnitten befinden, muss das Betreten synchronisiert werden, d.h. es muss sichergestellt werden, dass immer nur ein Prozess Zutritt hat. Diese Aufgabe über-nehmen Synchronisationsmechanismen, i.d.R. Semaphoren [Gol98a]. Sie werden vom Be-triebssystem als Funktionen bereitgestellt. In der Praxis werden binäre Semaphoren (Mute-xe) benutzt. Das Betreten eines kritischen Abschnitts durch einen Prozess P1 wird durch das Setzen ei-nes Semaphors S eingeleitet. Ist diese Semaphore S frei, wird S gesetzt und P1 kann die Arbeit ungehindert fortsetzen. Nach Verlassen des kritischen Abschnitts gibt P1 die Sema-phore S wieder frei. Ist S bei Eintritt in den kritischen Abschnitt allerdings besetzt, wird der Prozess blockiert und der Scheduler aufgerufen. Eine Semaphore S kann nur besetzt sein,


18

wenn zur selben Zeit eine zweiter Prozess P2 im kritischen Abschnitt ist. Nach Freigabe von S durch P2 kann P1 seine Arbeit fortsetzen, wenn er die Semaphore jetzt belegen kann. Das Belegen und Freigeben einer Semaphore tritt immer paarweise auf. Falls nicht, kommt es zu einer Verklemmung (Deadlock) aller Prozesse, die diese Semaphore nutzen (s. Abbildung 2.4-1). Die Nutzung von geschachtelten Semaphoren muss immer nach dem LIFO-Prinzip (Last in – First out) erfolgen. Eine Semaphore, die zuerst gesetzt wurde, darf nur als letzte freigegeben werden. Wird diese Reihenfolge nicht eingehalten, besteht eben-falls die Gefahr einer Verklemmung. Der Vorteil von Semaphoren gegenüber anderen Synchronisationsmechanismen wie einfa-chen Synchronisationsvariablen besteht darin, dass kein aktives Warten benutzt wird und keine Aufwecksignale verloren gehen.

0 105 15 20P2

P12

1 2

1

Abbildung 2.4-1: Deadlock

Ohne Synchronisationsmaßnahmen treten Wettlaufbedingungen auf, die die Funktionswei-se der Prozesse stark beeinträchtigen und zu fehlerhaftem Verhalten führen können. Ein Abbruch des Prozesses durch das Betriebssystem ist sehr wahrscheinlich. Die Ursachen liegen in den teilweise ungültigen Daten im gemeinsamen Speicherbereich und in der zeit-lichen Reihenfolge des Zugriffs.

2.4.2 Prioritäteninversion

Die Interaktion von Prozessen durch Semaphoren kann zu dem Phänomen der Prioritäten-inversion führen. Sie tritt auf, wenn ein nieder priorer Prozess PL eine Semaphore belegt und ein höher priorisierter Prozess PH während diese Phase dieselbe Semaphore ebenfalls setzen will. PH wird daraufhin blockiert. PL kann nicht mehr durch PH unterbrochen werden.

Prozess Priorität Periode Offset Deadline Rechenzeit AuslastungPH 3 (hoch) 120 20 120 30 0,25 PL 1 (niedrig) 120 0 120 50 0,42

Beispiel 1: Prozessparameter für Prioritäteninversion Direct-Blocking


19

In Abbildung 2.4-2 ist das Beispiel 1 zur Prioritäteninversion dargestellt. Es sei ein System von zwei Prozessen gegeben. PH hat eine hohe und PL eine niedrige Priorität. Zu Beginn erhält PL den Prozessor und setzt die Semaphore S bei t=10. Zum Zeitpunkt t=20 wird PH aktiviert und dem Prozessor sofort zugeteilt. Das Setzen der Semaphore bei t=30 führt zum Blockieren von PH, da S durch PL gesetzt wurde. Daraufhin kann PL seine Arbeit fortsetzen, obwohl ein höher priorisierter Prozess im System aktiv ist. Die in diesem Beispiel gezeigte Prioritäteninversion wird als Direct Blocking bezeichnet, da keine anderen Prozesse invol-viert sind [Raj91]. Nach dem Freigeben der Semaphore bei t=50 wird sofort auf den höher priorisierten Prozess umgeschaltet. Er kann seinen kritischen Abschnitt jetzt betreten und bis zu seiner Terminierung weiterarbeiten.

0 50PL

PH

100 Abbildung 2.4-2: Zeitdiagramm einer Prioritäteninversion (Direct Blocking)

Gesetzt den Fall, PL würde weitere Semaphoren mit anderen nieder prioren Prozessen tei-len, könnte dies zu einer kaskadierten Prioritäteninversion führen. Um das zu vermeiden, sollten Prozesse, die Semaphoren benutzen, gleiche oder ähnliche Schedulingprioritäten besitzen. Der Effekt der Prioritäteninversion kann durch kurze kritische Abschnitte mini-miert werden. Neben dem Direct Blocking gibt es noch das Push-Through-Blocking. Bei diesem Effekt beeinflussen andere Prozesse das Schedulingverhalten zusätzlich. Zur Illustration wurde dem vorangegangenen Beispiel ein Prozess PM mit einer mittleren Priorität hinzugefügt. Der Prozess-Satz ergibt sich somit aus den Daten in Beispiel 2.

Prozess Priorität Periode Offset Deadline Rechenzeit AuslastungPH 3 (hoch) 120 20 120 30 0,25 PM 2(mittel) 120 40 120 30 0,25 PL 1 (niedrig) 120 0 120 50 0,42

Beispiel 2: Prozessparameter für Prioritäteninversion Pass-Through-Blocking

Das Schedulingverhalten ist bis t=40 identisch mit dem aus Beispiel 1. PM wird zum Zeit-punkt t=40 aktiviert und entzieht PL sofort den Prozessor. Da dieser Prozess die Semaphore S nicht benötigt, kann er seine Arbeit bis zur Terminierung fortsetzen. PM verzögert dem-nach die Freigabe der Semaphore S um seine Rechenzeit und verstärkt den Effekt der Prio-ritäteninversion.


20

0 50PL

PM

PH

100 Abbildung 2.4-3: Zeitdiagramm einer Prioritäteninversion (Pass-Through-Blocking)

2.5 Synchronisationsprotokolle

Aus den Betrachtungen zur Synchronisation von Prozessen und der Prioritäteninversion ergeben sich folgende Forderungen an den Entwickler:

• Ergreifen von Maßnahmen zur Verhinderung der Prioritäteninversion • Minimierung kritischer Abschnitte zur Verkürzung des Effekts der

Prioritäteninversion • Optimierung der Prioritäten • Verhinderung von Deadlocks

Eine Möglichkeit, um die unterschiedlichen Effekte der Prioritäteninversion zu verhindern bzw. zu mildern, ist der Einsatz von Synchronisationsprotokollen. Die verschiedenen An-sätze für Uniprozessoren sollen kurz vorgestellt werden.

2.5.1 Statische Synchronisationsprotokolle

Die statischen Synchronisationsprotokolle sind nur sinnvoll im Zusammenarbeit mit stati-schen Schedulern. Sie gehen von festen Prioritäten aus, die zur Laufzeit nicht verändert werden. Die Priorität entspricht einem Integerwert, der im Vorfeld aus den Bedingungen des Schedulers errechnet wurde. Typische Scheduler, die statische Synchronisations-protokolle unterstützen, sind Rate Monotonic Scheduling (RMS), Deadline Monotonic Scheduling (DMS) und das prioritätsbasierte Scheduling (Prio).

2.5.1.1 Priority Inheritance Protocol

Das Priority Inheritance Protocol (PIP) ist das einfachste Synchronisationsprotokoll. Es wurde entwickelt, um die Prioritäteninversion zu mildern und um das Pass-Through-Blocking zu eliminieren. Verklemmungen können nicht verhindert werden.


21

Der Ansatz ist, die Priorität des nieder prioren Prozesses im kritischen Abschnitt zu erhö-hen, wenn der höher priorisierte Prozess die bereits gesetzte Semaphore anfordert. Dadurch wird eine Unterbrechung von PL durch PM verhindert. Die Prioritäteninversion zwischen PL und PH findet trotzdem statt. Nach Verlassen des kritischen Abschnitts durch den nieder prioren Prozess wird dessen Priorität wieder auf den ursprünglichen Wert zurückgesetzt. In Abbildung 2.5-1 ist das Schedulingverhalten aus Beispiel 2 unter Verwendung des Prio-rity Inheritance Protocols dargestellt. Die Höhe der grünen Rechtecke in dem Diagramm symbolisiert die Priorität des laufenden Prozesses. Zum Zeitpunkt t=30 wird durch die Semaphorenanforderung des Prozesses PH die Priorität von PL angehoben. Dadurch kommt es bei t=40 nicht zur Unterbrechung durch PM. PL kann seine Arbeit bis zur Freigabe von S fortsetzen und wird dann sofort von PH abgelöst. PM erhält den Prozessor erst nach Beendigung von PH.

0 50PL

PM

PH

100

P=3 P=1

Abbildung 2.5-1: Zeitdiagramm eines Priority-Inheritance Protocols

2.5.1.2 Priority Ceiling Protocol

Das Priority Ceiling Protocol (PCP) wurde eingeführt, um Deadlocks und Mehrfach-blockierungen zu vermeiden [Raj91]. Das PCP ist eine vereinfachte Version des SCP. Der Grundgedanke bei PCP ist, sicherzustellen, dass ein Prozess, der andere Prozesse in kritischen Abschnitten unterbricht und einen eigenen betritt, eine höhere Priorität in diesem Abschnitt garantieren muss als die Prioritäten aller unterbrochenen kritischen Abschnitte. Kann diese Bedingung nicht erfüllt werden, wird der Prozess blockiert. Die Umsetzung wird durch den Einsatz einer Ceiling-Konstante c(Sj) pro Semaphore Sj realisiert, die im Vorfeld berechnet werden muss. Diese Konstante entspricht der Priorität des höchst prioren Prozesses, der diese Semaphore nutzen wird. Ein Prozess P kann eine Semaphore S nur setzen, wenn seine Priorität größer als die Ceiling-Konstanten aller nicht von P belegten Semaphoren ist. Um den Rechenaufwand durch Einsparung der Vergleiche zur Laufzeit zu verringern, wur-de eine Systemceilingkonstante S* eingeführt, die den höchsten Ceiling-Wert aller belegten Semaphoren enthält. Versucht ein Prozess eine Semaphore zu setzen, wird lediglich seine Priorität mit dem Wert von S* verglichen. Ist diese niedriger, wird der Prozess blockiert.


22

In der Praxis wird die Systemceilingkonstante bei jedem Setzen einer Semaphore in einem LIFO-Stacks abgespeichert, um den vorherigen Wert bei Freigabe der Semaphore wieder-herzustellen.

Prozess Priorität Periode Offset Deadline Rechenzeit AuslastungP0 3 (hoch) 150 50 150 40 0,27 P1 2(mittel) 150 20 150 30 0,2 P2 1 (niedrig) 150 0 150 70 0,47

Beispiel 3: Prozessparameter für PCP

Das Schedulingverhalten in Abbildung 2.5-2 genügt den in Beispiel 3 dargelegten Prozess-parametern. P2 startet zum Zeitpunkt t=0 als einziger Prozess und setzt die Semaphore S2 bei t=10. Die Systemceilingkonstante wird auf den Wert S*=2 gesetzt, da 2 die max. Priori-tät aller Prozesse ist, die S2 setzen können. Bei t=20 beginnt P1 seine Ausführung und ver-sucht bei t=30 S2 ebenfalls zusetzen. P1 wird blockiert, da die Semaphore belegt ist. Die Priorität von P2 wird auf P(P2)=S*=2 erhöht. Das Setzen von S1 bei t=40 führt zum Erhö-hen von S* auf 3, da P0 und P2 S1 nutzen werden. Die Ausführung von P0 beginnt bei t=50. Das Setzen von S0 scheitert, da die Priorität von P0 nicht größer als von S* ist. P2 setzt die Arbeit fort, bis S1 freigegeben wird. S* sinkt kurzzeitig auf 2. Der Prozessor wird an P0 abgegeben. P0 setzt S0 und erhöht S* wieder auf 3. Er arbeitet bis t=100 und beendet sich. Der Scheduler wählt P2 aus, da P1 blockiert ist. P2 gibt S2 bei t=110 frei – S* sinkt auf 0. Der Scheduler wird aufgerufen und teilt P1 den Prozessor zu. Dieser kann nun S2 setzen und setzt die Systemceilingkonstante erneut auf S*=2. Der restliche Schedulingverlauf ist trivi-al.

0 50P2

P1S2

S2P0

100

S*=2 S*=3S1

S0

S1S*=2

S*=3

S0

S*S*=2

S0

S*=2

S*=3

S1

S*=2 S*=2S*=3

S2S*=0

S*=2

S2S*=2

S2S*=0

150 Abbildung 2.5-2: Zeitdiagramm eines Priority-Ceiling-Protocols

2.5.1.3 Ceiling Semaphore Protocol

Das Ceiling Semaphore Protocol (CSP) ist eine Vereinfachung des PCP, um die Implemen-tierung in Betriebssystemen zu vereinfachen. In der Literatur wird das Protokoll auch als


23

Instant Priority Ceiling Protocol (IPCP) bezeichnet. Im Gegensatz zu PCP erbt ein Prozess PL, der die Semaphore S hält, nicht die Priorität des Prozesses PH, sondern die Ceiling-Priorität der angeforderten Semaphore S direkt während des Setzens der Semaphore. Eine Systemceilingkonstante wird nicht benötigt. Ein Prozess PH kann eine Semaphore nur set-zen, wenn seine Priorität höher als die temporäre Priorität von PL und S nicht belegt ist. Nach der Freigabe von S wird die Priorität von PL wieder auf den ursprünglichen Wert zu-rückgesetzt. Der Vorteil des CSP ist die Reduzierung der Kontextwechsel, da der Prozess PL nur von Prozessen unterbrochen werden kann, die die Semaphore S nicht benutzen. In der Praxis ist die Implementierung des CSP deutlich einfacher, da auf den Stack zur Sicherung der Systemceilingkonstanten verzichtet werden kann.

0 50P2

P1S2

S2

P0

100

S*=2 S*=3

S1 S1S*=2

S*=3

S0

S*S*=2

S0

S*=2

S*=3

S1

S*=2 S*=2S*=3

S2S*=0

S*=2

S2S*=2

S2S*=0

150

S*=2S*=3

Abbildung 2.5-3: Schedulingverlauf von Beispiel 3 mit Ceiling Semaphore Protocol

2.5.1.4 Semaphore Control Protocol

Das Semaphore Control Protocol (SCP) ist eine Erweiterung des PCP. Es ist in der Lage, Deadlocks zu vermeiden und minimiert die max. Prioritäteninversion [Raj91], [Aud91]. Das SCP benötigt zur Laufzeit Informationen über die gesetzten Semaphoren der laufenden Prozesse. Die Umsetzung dieser Forderung in Betriebssystemen gestaltet sich relativ schwierig im Gegensatz zu anderen Protokollen CSP. Aus diesem Grund ist das Protokoll selten implementiert. Die Zuteilung einer Semaphore S erfolgt im Semaphore Control Pro-tocol bei Einhaltung einer der drei Bedingungen:

• Die Priorität des Jobs J ist größer als die Systemceilingkonstante S* • Die Priorität des Jobs J ist gleich der Systemceilingkonstanten S* und der kritische

Abschnitt von J wird keine Semaphoren setzen, die durch den laufenden Task ge-setzt wurden.

• Die Priorität des Jobs J ist gleich der Systemceilingkonstanten S* und in dem kriti-schen Abschnitt des unterbrochenen Prozesses wird S nicht angefordert.


24

2.5.2 Dynamische Synchronisationsprotokolle

Die dynamischen Synchronisationsprotokolle sind nicht nur sinnvoll in Zusammenarbeit mit dynamischen sondern auch statischen Schedulern. Sie gehen von flexiblen Prioritäten aus, die sich zur Laufzeit ständig ändern können. Prioritäten, die sich nicht ändern, stellen insofern eine Teilmenge der dynamischen Prioritäten dar. Typische Scheduler, die zusam-men mit dynamischen Synchronisationsprotokollen verwendet werden sind Earliest Dead-line First (EDF) und Least Laxity First (LLF).

2.5.2.1 Dynamic Priority Ceiling Protocol

Das Dynamic Priority Ceiling Protocol (DPCP) ist aus dem PCP hervorgegangen, da das PCP nur mit statischen Prioritäten und nicht mit dynamischen Schedulern wie EDF zu-sammenarbeiten kann [Che90]. Der Grundgedanke bei PCP wie auch bei DPCP ist, sicherzustellen, dass ein Prozess, der andere Prozesse in kritischen Abschnitten unterbricht und einen eigenen betritt, eine höhere Priorität in diesem Abschnitt garantieren muss als die Prioritäten aller unterbrochenen kriti-schen Abschnitte. Kann diese Bedingung nicht erfüllt werden, wird der Prozess blockiert. Da sich die Prioritäten bei dynamischen Schedulern zur Laufzeit ändern, müssen die Cei-lingkonstanten der Prozesse bei DPCP innerhalb der aktiven Phase eines Prozesses und nach dessen Beendigung ständig angepasst werden. Im Falle des EDF Schedulers erhöht sich die Priorität ständig mit geringer werdendem Abstand zur absoluten Deadline des Pro-zesses (Gleichung 2). Die Ceilingkonstanten werden in diesem Fall auf die geringste abso-lute Deadline aller sie nutzenden Prozesse gesetzt. Mit fortschreitender Zeit tritt bei EDF der Effekt auf, dass die Ceilingkonstanten daher kontinuierlich größer werden, wobei die mit dem geringsten Wert die höchste Priorität darstellt. Wird Least Laxity First eingesetzt, erhöht sich die Priorität mit geringerem Spielraum (s. Kap. 4.3.1). Das Verhalten des Protokolls ist nach Anpassung der Prioritäten und Ceiling-Konstanten identisch mit dem von PCP.

2.5.2.2 Stack Resource Policy

Das Stack Resource Policy Protocol (SRP) wurde 1990 vorgestellt [Bak90], [But97]. Es beinhaltet eine Besonderheit, da es nicht nur das Setzen von Semaphoren beeinflusst, son-dern direkt in das Schedulingverhalten eingreift.


25

Bei Nutzung von SRP dürfen nur Prozesse ausgewählt werden, die zwei Bedingungen ein-halten:

(1) Erfüllung der Schedulingregel, z.B. Auswahl der Prozesse P mit der höchsten Priorität (2) Preemptionlevel des Prozesses P ist höher als das System Preemptionlevel Π* Das Preemptionlevel wird bei Verwendung von EDF aus der Deadline innerhalb der Perio-de und nicht aus der absoluten Periode errechnet (s. Gleichung 4). Es bleibt über die gesam-te Periode konstant. Insofern ergibt sich ein Unterschied zwischen Priorität und Preempti-onlevel, denn ein niedrigeres Preemptionlevel entspricht einer höheren Priorität.

iD1

=Π Πi Di

: Preemptionlevel : Deadline in Periode des Prozesses i

Gleichung 4: Berechnung des Preemptionlevels für EDF

In Schedulern mit dem kleinsten Spielraum als Schedulingkriterium gilt Gleichung 5. Für andere Schedulingkriterien ergeben sich ähnliche Gleichungen.

iL1

=Π Πi Li

: Preemptionlevel : Max. Laxity in Periode des Prozesses i

Gleichung 5: Berechnung des Preemptionlevels für LLF

Jeder Semaphore im System wird eine Preemption Ceiling Π zugeordnet. Diese Ceiling-konstante entspricht dem höchsten Preemptionlevel aller Prozesse, die diese Semaphore nutzen werden. Bei Start des Systems ist das System-Preemptionlevel Π* auf einen Wert kleiner als die niedrigste Priorität gesetzt, d.h. der ausgewählte Scheduler wählt nur nach seinem Schedulingkriterium den nächsten Prozess aus (Bedingung 1). Wenn dieser Prozess eine Semaphore S setzen will, muss die System-Ceilingkonstante kleiner als die Preemption Ceiling der Semaphore S sein. Ist das der Fall, wird dieser Ceiling Wert auf einen Stack (LIFO) gelegt und die System-Ceilingkonstante auf den Wert von S erhöht - daher der Na-me Stack Resource Policy. Nach dieser Änderung kann der Prozess von nieder prioren Pro-zessen nicht mehr unterbrochen werden (Bedingung 1), da durch Bedingung 2 garantiert wird, dass alle Semaphoren, die der Prozess benötigt, noch nicht belegt sind. Bedingung 2 ist erfüllt, da die Belegung irgendeiner Semaphore, die P benutzt, das System-Preemptionlevel erhöht hätte und P gar nicht hätte zugeteilt werden dürfen. Das Stack Resource Policy Protocol soll kurz an einem Beispiel vorgestellt werden. Die Prozessdaten aus Beispiel 3 werden übernommen. Allerdings wurden zur Übersichtlichkeit


26

die Deadlines verändert (Beispiel 4). Es soll der Enhanced Least Laxity First Scheduler zum Einsatz kommen. Das Preemptionlevel Π eines Prozesses ergibt sich bei ELLF aus seinem maximalen Spielraum in der Periode. Es ist umso höher, je kleiner der nominelle Wert von Π ist.

Prozess Priorität Perio-de

Offset Deadli-ne

Rechen-zeit

Auslastung LaxityMax

P0 3 (hoch) 150 40 110 40 0,27 70 P1 2(mittel) 150 20 150 30 0,2 120 P2 1 (niedrig) 180 0 180 70 0,38 110

Beispiel 4: Prozessparameter für Stack Resource Policy

In dem System sind 3 Semaphoren eingerichtet. Welcher Prozess welche Semaphoren nut-zen wird, steht im Vorfeld fest. Anderenfalls werden die Preemptionlevel zur Laufzeit ak-tualisiert. In Tabelle 3 sind die möglichen Preemptionlevel dargelegt. Für Semaphore S1 ergibt sich bei Verwendung von ELLF ein Preemptionlevel von 70, da dies die höchste Pri-orität aller Prozesse (P0, P2) darstellt, die S1 nutzen werden. Bei Nutzung des EDF-Schedulers hätte das Preemptionlevel von S1 den Wert 110.

Semaphore S0 Semaphore S1 Semaphore S2 P0 P0 P2 P1 P2

Priorität 3 3 1 2 1 Ausführungszeit 40 40 70 30 70 Deadline 110 110 180 150 180 LaxityMax 70 70 110 120 110

Tabelle 3: Preemptionlevel von Beispiel 4 unter Nutzung von SRP

Bei Start des Systems wird P2 aktiviert und beginnt mit der Ausführung. Zum Zeitpunkt t=10 setzt er die erste Semaphore S2. Das System-Preemptionlevel Π* wird von Unendlich, dem niedrigsten Level, auf 110 geändert, da 110 dem Preemptionlevel von S2 entspricht. P1 wird bei t=20 aktiviert und erhält aufgrund der geringeren Laxity L1=(20)=120 den Prozes-sor nicht. Nach 10 Zeiteinheiten würde ohne SRP der Trashing-Effekt von LLF greifen, da beide Prozesse einen Spielraum von L1,2(30)=110 besitzen. Bedingung 2 verhindert das Trashing, da P1 ein niedrigeres Preemptionlevel als P2 aufweist. Kurze Zeit später setzt P2 das Semaphor S1 und erhöht(!) damit das System Preemptionlevel auf Π *=70. Bei t=40 wirkt Bedingung 2 erneut und verhindert, dass P0 den Prozessor zugeteilt bekommt, denn Π0=70>Π*=70 ist nicht erfüllt. P2 gibt bei t=50 die Semaphore S1 frei und senkt das Preemptionlevel auf 110. Daraufhin erhält P0 bis zur vollständigen Abarbeitung die CPU, da Bedingung 2 nun erfüllt ist und somit alle benötigten Semaphoren verfügbar sind. Im Anschluss rechnet P2 weiter und gibt S2 frei, womit Π* auf Unendlich sinkt. P1 unterbricht P2 und arbeitet bis t=130.


27

0 50P2

P1S2

P0

100

S1 S1

S0

*S1

S2

150

S2

110 70 110 110 110 11070

8 88

70

Abbildung 2.5-4: Schedulingverlauf von Beispiel 4 unter SRP

2.5.3 Kernel Priority Protocol

Das Kernel Priority Protocol (KPP) beinhaltet einen sehr einfachen und effizienten Ansatz zur Lösung des Problems der Prioritäteninversion. Das KPP verhindert, dass Prozesse, die sich in kritischen Abschnitten befinden, von anderen Prozessen unterbrochen werden. Hö-her priore Prozesse können maximal für die Dauer des längsten nieder prioren kritischen Abschnitts blockiert werden. Die kritischen Abschnitte müssen kurz sein, um höher priore Prozesse nicht unnötig lange zu blockieren. Im Allgemeinen führt die Anwendung von KPP im Gegensatz zu anderen Synchronisati-onsprotokollen zu einer Verringerung der Kontextwechsel. Die Nachteile bei Einsatz des KPP sind genau zu analysieren, da sonst die Gefahr eines Systemabsturzes sehr wahr-scheinlich ist. Es muss sichergestellt sein, dass bei Verwendung geschachtelter Semaphoren alle Semaphoren in dem System mit dem KPP als Synchronisationsprotokoll arbeiten. An-derenfalls kann ein Prozess im kritischen Abschnitt durch Setzen einer belegten Semaphore blockiert werden. In Abbildung 2.5-5 ist das Beispiel 4 unter Verwendung des KPP und des Earliest Deadline First Schedulers dargestellt. Im Schedulingverlauf ist deutlich zu erkennen, dass die kriti-schen Abschnitte nie unterbrochen werden. Die Taskumschaltzeiten sind auf ein Minimum reduziert. Zu beachten ist, dass die Aktivierungen der Prozesse P0 und P1 bis zur Freigabe von S2 bei t=60 verzögert werden.

0 50P2

P1S2

P0

100

S1 S1

S0 S1

S2

150

S2

Abbildung 2.5-5: Beispieldiagramm eines Kernel Priority Protocols


28

2.6 Interprozesskommunikation

2.6.1 Einführung

Prozesse laufen in modernen Betriebssystemen in eigenen, meist privaten Adressräumen ab und haben keinerlei Zugriff auf Daten anderer Prozesse (Speicherschutz), wodurch die Sta-bilität des Betriebssystems deutlich erhöht wird. Die Betriebssysteme stellen für den Datenaustausch und zur Synchronisation von Prozessen umfangreiche Mechanismen und Betriebssystemfunktionen zur Verfügung. Diese werden unter dem Begriff Interprozesskommunikation IPC zusammengefasst. Innerhalb der IPC haben sich vier wichtige Objekttypen herausgebildet. Sie benutzen intern die in Kapitel 2.4.1 eingeführten Semaphoren zur Synchronisation.

2.6.2 Signale

Signale sind die einfachsten Einrichtungen zur Synchronisation von Prozessen. Auf Signale muss gewartet werden, ansonsten werden sie verpasst. Signale werden in der Regel nicht gezählt, sodass bei Eintreffen eines Signals keine Auskunft darüber gegeben werden kann, wie oft das Signal bereits aktiviert wurde. Weiterhin ist bei Signalen keine Auskunft über den Sender erhältlich. Signale werden z.B. benutzt, um anzuzeigen, ob sich neue Daten in Empfangspuffern be-finden oder die Fenstergröße geändert hat. Eine Angabe über Häufigkeit und Umfang der Daten erfolgt nicht.

2.6.3 Nachrichten

Nachrichten (Messages) dienen dem einfachen Datenaustausch zwischen Prozessen. Dabei können mehrere Prozesse mit einem einzigen Zielprozess kommunizieren. Nachrichten bieten den Vorteil einer begrenzten Datenübertragung, die allerdings im Vergleich zu den anderen Objekttypen relativ langsam ist. Der Versand von Nachrichten kann synchron bzw. asynchron erfolgen. Bei einer synchro-nen Übertragung wird der sendende Prozess solange suspendiert, bis der Zielprozess die Nachricht beantwortet hat. Die asynchrone Übertragung ist gekennzeichnet durch das sofor-tige Zurückkehren nach Aufruf der Sendefunktion, unabhängig davon, ob die Nachricht bereits beantwortet wurde. Die Bearbeitung der Nachrichten erfolgt immer in der Reihen-folge des Eintreffens der Messages (FIFO-Prinzip). Die Nachrichten werden zu diesem Zweck in einer Nachrichtenwarteschlange (Messagequeue) gespeichert.


29

2.6.4 Pipes

Die Pipe (Röhre) stellt einen temporären und begrenzten Datenspeicher dar, der als FIFO (First in – First out) organisiert ist. Er kann von einem schreibenden Prozess gefüllt wer-den. Ist der Datenspeicher voll, wird der Prozess suspendiert und beendet den Schreibvor-gang erst, wenn wieder Platz in der Pipe ist. Der lesende Prozess kann Daten aus der Pipe entnehmen. Sind während des Lesevorgangs keine Daten vorhanden, wird der Prozess sus-pendiert bis der schreibende Prozess die Pipe mit genügend Daten gefüllt hat.

2.6.5 Shared Memory

Als Shared Memory wird Speicher bezeichnet, der von Prozessen eingerichtet wird, um größere Datenmengen untereinander schnell auszutauschen. Dieser Speicher wird durch Betriebssystemroutinen initialisiert, um beiden Prozessen die entsprechenden Rechte einzu-richten, die den lesenden bzw. schreibenden Zugriff auf diesen Speicherbereich ermögli-chen. Die Synchronisation zwischen Prozessen ist nicht spezifiziert. Sie könnte z.B. über Signale oder Nachrichten erfolgen.

2.7 Schedulinganalyse

Die Schedulinganalyse beschäftigt sich mit der Vorhersage, ob ein Prozess-Satz unter den gegebenen Bedingungen und mit dem verwendeten Scheduler erfolgreich ausgeführt wer-den kann. Die Analyse ist notwendig, um deterministische Aussagen über das System tref-fen zu können, z.B. über:

• Einhaltung der Deadlines • Max. Reaktionszeiten der Prozesse • Unterbrechungen der Prozesse • Auslastung des Prozessors

Die theoretische Betrachtung kann durch zwei Herangehensweisen vorgenommen werden. Einerseits kann die reine Auslastung als Kriterium benutzt werden. Um den Einfluss des Schedulers in die theoretische Betrachtung miteinfließen zu lassen, empfiehlt sich der Durchführbarkeitstest über die Reaktionszeit der Prozesse.

2. Grundlagen von Echtzeitsystem

Ci Ti

n

: Benötigte Zeit : Periode des Prozesses : Anzahl der Prozesse

Gleichung 8: 3. Hinreichende Bedingung zur Durchführbarkeit von Prozessen

en

30

ii TCi <∀ *

2.7.1 Auslastung

In einem Echtzeitsystem ist die Durchführbarkeit theoretisch nachzuweisen. Ein System ist durchführbar (feasible), wenn alle Deadlines eines Prozess-Satzes garantiert eingehalten werden. Der Nachweis wird anhand von 3 Bedingungen erbracht und gilt unter folgenden Voraussetzungen [Jos96]:

• Prozesse laufen auf einem Prozessor • Ci und Ti sind konstant • Jitter, Blocking- und Taskumschaltzeiten sind null

Die erste Bedingung verlangt, das die benötigte Zeit des Prozesses kleiner als die Periode sein muss.

Ci Ti

: Benötigte Zeit (Computation time) : Periode des Prozesses

Gleichung 6: 1. Bedingung zur Durchführbarkeit von Prozessen

In der zweiten Bedingung wird verlangt, dass die relative Auslastung des Prozessors kleiner oder gleich 1 ist. Die Auslastung berechnet sich aus der Summe der Verhältnisse von benö-tigter Zeit und Periode des Prozesses.

∑=

≤i

j j

j

TC

1

1)( Ci Ti

: Benötigte Zeit : Periode des Prozesses

Gleichung 7: 2. Notwendige Bedingung zur Durchführbarkeit von Prozessen

Die Bedingung 2 ist notwendig, aber nicht hinreichend, da sie nur die arithmetische Auslas-tung betrachtet, d.h. es besteht die Möglichkeit, dass durch ungünstiges Schedulingverhal-ten trotzdem Deadlines verloren gehen.

)12(*)(1

1

−≤∑=

i

j

n

j

j nTC

In statischen Schedulern muss für einen Prozess-Satz Gleichung 8 erfüllt sein, die im Zu-sammenhang mit dem Rate-Monotonic Scheduler entwickelt wurde. Diese Bedingung ist hinreichend und gilt für alle statischen Scheduler.

2. Grundlagen von Echtzeitsystem

R C T hp(i)

: Antwortzeit : Benötigte Zeit : Periode des Prozesses : Prozess-Satz mit höherer Priorität

Gleichung 10: Rekursive Berechnung der worst-case Antwortzeit

en

31

In dynamischen Schedulern ist die hinreichende Bedingung schwierig aufzustellen, da sich die Prioritäten zur Laufzeit ändern und keine Aussage über Ankunft von Prozessen gemacht werden kann. Dynamische Systeme benutzen bei Änderungen des Prozess-Satzes online-Verfahren, um die Durchführbarkeit zu ermitteln.

2.7.2 Worst-Case Antwortzeit

Bei der Benutzung von Echtzeitprozessen sind worst-case Betrachtungen von entscheiden-der Bedeutung, um die Funktionalität des Systems zu beweisen. Eine wichtige Größe ist die max. Reaktionszeit eines Prozesses, d.h. die max. Zeitdauer von seiner Aktivierung bis zur Beendigung des Prozesses. Die Worst-Case Antwortzeiten eines Prozess-Satzes können zum Nachweis der Durchführ-barkeit benutzt werden. Er ist durchführbar, wenn folgendes Theorem zutrifft:

ii TRni ≤≤≤∀ ,1 n Ri Ti

: Anzahl der Prozesse : Reaktionszeit des Prozesses i : Periode des Prozesses i

Gleichung 9: Durchführbarkeitstest mittels Reaktionszeit

Bei der Berechnung der Reaktionszeit eines Prozesses Ri werden alle höher priorisierten Prozesse beachtet. Diese werden in der Menge hp(i) abgebildet und sind stark vom Schedu-ler abhängig. Die Berechnung erfolgt rekursiv (Gleichung 10). Daher resultiert die Berech-nung der Antwortzeit Ri aus der max. Reaktionszeit Ri-1. Um die Einhaltung der Zeit-schranken der Prozesse zu garantieren, müssen alle Deadlines Di kleiner oder gleich der Reaktionszeit des Prozesses Ri sein.

jihpj j

n

ini C

TR

CR i *)(

1 ∑∈

+

+=

In der Praxis treten allerdings häufig Blockierungen von Prozessen durch Anfordern von Betriebsmitteln auf. Die max. Antwortzeit wird um die max. Blockierungszeit Bi verlän-gert, die durch die Kenntnis des verwendeten Synchronisationsprotokolls bestimmt werden kann. Da Prozesse nur durch nieder priore Prozesse blockiert werden können, kann die max. Blockierungszeit aus der Menge der Ausführungszeiten der Semaphoren dieser Pro-zesse bestimmt werden. Dabei werden nur die Semaphoren betrachtet, die durch Prozessi


τi sem semtimesemseti

lp(i)

: Task i : Semaphore : Zeit im kritischen Abschnitt : Semaphorensatz des Prozesse i : Prozess-Satz mit niedrigerer Priorität

Gleichung 11: Bestimmung der max. Blockierungszeit

32

))),((max(max)()(

semsemtimeB iisemsetsemilpii

und eventuell höher priorisierte Prozesse angefordert werden können, da nur sie blockie-rend wirken können [Jos96].

ττ ∈∈

=

Die berechnete Blockierungszeit Bi wird in Gleichung 10 eingefügt und ergibt Gleichung 12, die zur rekursiven Berechnung der Reaktionszeiten unter Beachtung der Blockierungs-zeiten benutzt werden kann.

jihpj j

n

iini C

TR

BCR i *)(

1 ∑∈

+

++=

R B C T hp(i)

: Antwortzeit : max. Blockierungszeit : Benötigte Zeit : Periode des Prozesses : Prozess-Satz mit höherer Priorität

Gleichung 12: Berechnung der max. Antwortzeit inkl. Blockierungszeit

2.7.3 Jitter

Jedes Multitasking-Betriebssystem besitzt grundsätzlich einen Scheduler. Dieser Scheduler kann während eines Timer-Interrupts aufgerufen werden. Der Timer-Interrupt ist aber nicht die höchst priorisierte Unterbrechnungsanforderung im Interruptcontroller des Computers. Es handelt sich demnach um ein kaskadiertes Schedulingverfahren. Zu Beginn werden die höher priorisierten Interrupts, z.B. der NMI, bedient. Im Anschluss wird der Betriebs-systemscheduler aufgerufen. Die verzögerte Aktivierung von Prozessen aufgrund dieser Zeitspanne wird als Jitter bezeichnet. Ein Jitter kann zudem auftreten, wenn der Scheduler zu einem Zeitpunkt in der Zukunft ausgeführt werden soll, an dem die Systemuhr durch Hardwareeinschränkungen der Timer-Auflösung keinen Interrupt auslösen kann. Um den Jitter eines Prozesses JP theoretisch zu betrachten, wird von einem max. Jitter aus-gegangen, den das System einhalten muss. Der Wert wird zu der Reaktionszeit des Prozes-ses hinzuaddiert, sodass sich Gleichung 12 wie folgt erweitert wird:


R B C T hp(i)

: Antwortzeit : max. Blockierungszeit : Benötigte Zeit : Periode des Prozesses : Prozess-Satz mit höherer Priorität

Gleichung 13: Berechnung der max. Antwortzeit unter Berücksichtigung des Jitters

33

jihpj j

jn

iini C

TJR

BCR i *)(

1 ∑∈

+

+++=

Es muss jederzeit sichergestellt sein, dass T gilt, da sonst Gleichung 9 nicht

garantiert werden kann. iiii JRR +=< *

3. Einführung in RT-Linux

34


Realtime-Linux (RT-Linux) ist eine Kernelerweiterung von FSMLabs für konventionelle Linux- bzw. BSD-Systeme, um hartes Echtzeitverhalten zu ermöglichen. Die aktuelle Ver-sion V3.1 ist für verschiedene Hardwareplattformen verfügbar, u.a. x86, PowerPC und Al-pha. Es unterstützt neben Uniprozessoren auch Systeme mit Multiprozessoren (SMP). Die intelligente Aufsatztechnik ermöglicht es, Linux bzw. BSD auszuführen, wenn der Realtime-Kernel im Ruhezustand (Idle) ist. Dadurch wird die komplette Palette an Pro-grammen für RT-Linux nutzbar. Die Verfügbarkeit des Quelltextes von RT-Linux erhöht die Transparenz des Betriebssys-tems. Für Programmierer wird der Datenfluss besser sichtbar. Es können Fehler korrigiert, Erweiterungen vorgenommen oder Komponenten entfernt werden. Das Betriebssystem kann auf diese Weise optimal an die Bedürfnisse der jeweiligen Echtzeitanwendung ange-passt werden.

3.1 RT-Kernel

Der Kernel von RT-Linux (RTL) ist ein komplett eigenständiges Betriebssystem. Es ge-horcht dem POSIX 1003.13 PSE 51 Standard – dem Minimalprofil für Echtzeitsysteme. Physisch ist RT-Linux ein Patch für die frei verfügbaren Linux Kernel der 2.2er bzw. 2.4er Serien, d.h. RTL arbeitet mit jeder Linux-Distribution zusammen, auf der einer dieser Ker-nel lauffähig ist. Um einen RT-Kernel zu erstellen, muss vorher ein Linux-Kernel im Quell-text vorliegen. Dieser sollte bereits kompiliert, ausgeführt und umfangreich getestet worden sein, um seine Funktionsfähigkeit ohne RT-Erweiterung zu überprüfen. Im Anschluss wird dieser Linux-Kernel unter Einbeziehung des RT-Patches erweitert, erneut kompiliert und getestet [Bar01]. Der Aufbau des RTL-Systems ist in Abbildung 3.1-1 dargestellt. Der RT-Kernel teilt sich in mehrere, austauschbare Komponenten auf. Bei Start des Kernels werden diese Kompo-nenten durch Aufruf des Skripts „rtlinux start“ als Kernel-Module eingebunden. Der Start des RT-Kernels erfolgt durch die Initialisierung und die Übernahme der Hardware (Interruptbehandlung). Der bisherige Linux-Kernel wird als Echtzeitprozess mit niedrigster Priorität weitergeführt. Die Prozesse innerhalb des Linux-Kernels sind im RTL-Kontext und nach außen nicht sichtbar, wie in Abbildung 3.1-1 deutlich zu erkennen ist. Das Sche-duling dieser Prozesse übernimmt wie bisher der interne Linux-Kernelscheduler. Interrupts des Linux-Kernels werden erst bearbeitet, wenn die Echtzeitthreads sowie Echtzeitinter-rupts bearbeitet wurden. Der Linux-Kernel kann bei Bedarf komplett abgeschaltet werden.

http://www.fsmlabs.com/


35

In RT-Linux laufen alle Prozesse mit Administratorrechten. Es gibt keinen Speicherschutz. Der Zugriff auf Daten, sogar des Betriebssystems, ist jederzeit möglich. Prozesse werden daher als Threads bezeichnet.

LinuxTreiber Scheduler

RT-Linux Kernel

RT-FIFO RT-POSIXRT-Scheduler RT-Time

Echtzeitthread 1 Echtzeitthread 2

Hardware

Init Bash XFree

Systemfunktionen

I/O I/O

Linux-Thread

Abbildung 3.1-1: Aufbau von RT-Linux

Für die Programmierung von Anwendungen in RT-Linux werden ca. 120 Funktionen zur Verfügung gestellt [FSM02], die gemäß dem POSIX-Standard folgende Teilgebiete abde-cken:

• Starten/Beenden von Prozessen • Interruptbehandung und Interruptsteuerung • Scheduling- und Zeitfunktionen • Interprozesskommunikation von Echtzeittasks

Dieses Funktionenset ist für die meisten Echtzeitanwendungen absolut ausreichend. Es stellt sich allerdings ein Problem, wenn es nötig ist, Daten, z.B. Messwerte, auf Datenträ-gern zu speichern oder sie grafisch darzustellen. Eine direkte Möglichkeit ist unter RT-Linux nicht verfügbar, da für eine grafische Darstellung der XFreeServer-Prozess von Li-nux angesprochen werden müsste. FSMLabs entwickelte zur Lösung dieses Problems einen Realtime-FIFO [Yod00]. Dieser FIFO ermöglicht eine Kommunikation von Prozessen zwischen dem Echtzeitkernel (RT-Kernel) und dem Linux-Kernel. Im RT-Kernel wird jedem FIFO eine Nummer zugeordnet. Im Linux-Kernel hingegen ist jeder FIFO über das Filesystem als zeichenorientiertes Gerät in /dev/rtfifo eingeblendet. Für die Kommunikation wird in jedem Kernel ein Thread benö-tigt. Sie erfolgt aus RTL-Sicht im nicht-blockierenden Modus. Ist während eines Schreib-vorgangs des Echtzeitthreads der FIFO voll, wird der Schreibvorgang mit einer Fehler-


36

meldung abgebrochen – der Thread blockiert nicht. Für die Datenübertragung fehlt ein Synchronisationsmechanismus, da nicht garantiert werden kann, dass der Linuxthread die Daten rechtzeitig ausliest bzw. der Echtzeitthread alle Daten in die Queue schreiben kann.

3.1.1 Der Scheduler

RT-Linux enthält in dem Modul rtl_sched.o den Scheduler. In der Grundversion handelt es sich um einen rein prioritätsbasierten Scheduler, d.h. jedem Echtzeitthread wird eine Priori-tät zugeordnet (s. Kap. 2.3.3.1). Der Scheduler hat keinerlei Kenntnis von Deadlines bzw. dynamischen Prioritäten der Threads. Er arbeitet preemptiv, d.h. laufende Threads können vor Beendigung unterbrochen werden. Im günstigsten Fall arbeitet er den Thread ab oder lädt den Timer auf einen Zeitwert, an dem ein höher priorisierter Thread den Prozessor zu-geteilt bekommen soll. Ist kein Echtzeitthread bis auf den Linuxthread erzeugt worden, wird der Scheduler periodisch alle 5 ms aufgerufen, um Linux auszuführen. Die Umsetzung des RT-Schedulers als Linux-Modul und die Verfügbarkeit des Quellkodes erlauben es, den Scheduler mit geringem Aufwand auszutauschen. Diese Erkenntnis bildet die Grundlage für die Entwicklung des RT-Linux Executives, das in Kap. 4.3.5 vorgestellt wird. In RT-Linux wird eine proprietäre Zeitbasis verwendet. Alle Zeitwerte werden in Instanzen des Datentyps hrtime_t gespeichert. Es handelt sich in den aktuellen Kernelversionen um einen vorzeichenbehafteten 64-Bit Integer. Die Auflösung beträgt 1 ns, sodass sich folgen-de Zeitwerte ergeben:

hrtime_t Zeit 1 1 ns

5000000 5 ms 1000000000 1 s

Max.1 292 Jahre Tabelle 4: Zeitwerte in RT-Linux

3.2 Entwicklung von Echtzeitanwendungen

Die Erstellung von Echtzeitanwendungen für RT-Linux ist mit geringem Aufwand verbun-den. Allerdings zeigt der sehr einfache Scheduler schnell Grenzen auf. Es können keine Deadlines vergeben werden und es ist kein Mechanismus implementiert, der eine Behand- 1 Bei absoluten Zeitangaben beginnt die Zeitmessung üblicherweise bei Epoch. Epoch beschreibt in der Unix-Welt den Start der Computerära am 01.01.1970. Daher ist zum Jahreswechsel 2262 das erste mal mit einem „Jahr 2262 Problem“ unter RT-Linux zu rechnen.


37

lung von verpassten Deadlines (Deadline Miss) zulässt. Das Verpassen einer Deadline führt zum Ignorieren der nächsten Periode, ohne dass die Anwendung informiert wird. Mit der Grundversion von RT-Linux können demnach nur Echtzeitsysteme gesteuert werden, die garantiert keine Deadlines verpassen und deren Systemeigenschaften einen statischen Sche-duler verlangen. Echtzeitprogramme werden in RT-Linux ebenfalls als Linux-Kernel gestartet. In diesen Modulen müssen während der Initialisierung die Echtzeitthreads erzeugt werden. Das Er-zeugen wird über die sched_param und die thread_attr Strukturen und die dazugehörigen POSIX-Funktionen konfiguriert. In den Attribut-Strukturen wird die Priorität des Prozes-ses, die Stackgröße und die Nutzung der FPU festgelegt. Diese Threads erhalten in der Re-gel eine höhere Priorität als der Linuxthread, sodass sie sofort den Prozessor erhalten. Sie werden grundsätzlich als nicht-periodische Prozesse generiert.

Initialisierung des Threads Wechsel in periodischen Zustand 1 wait() Anweisungen in der Periode

Abbildung 3.2-1: Struktogramm eines periodischen Echtzeitthreads

Die Echtzeitprozesse laufen immer nach dem gleichen Schema ab (s. Abbildung 3.2-1). Zuerst beginnt die Initialisierung des Threads, d.h. die lokalen Variablen werden angelegt und können mit sinnvollen Werten gefüllt werden. Danach erfolgt die Umschaltung in den periodischen Zustand mittels nicht portabler RT-Funktionen2. Diese Prozedur ist riskant in Bezug auf die Synchronisation von mehreren Echtzeitprozessen, v.a. wenn die Startoffsets mehrerer Prozesse auf denselben Zeitpunkt fallen. Es kann nicht garantiert werden, dass zwischen Erzeugung des ersten Echtzeitprozesses und Start der ersten Periode die anderen Echtzeitprozesse ebenfalls erzeugt werden können. Ist der Thread im periodischen Zustand, führt er wait() und die darauf folgenden Anwei-sungen entsprechend seiner Zeitvorgaben immer wieder aus. Alle Anweisungen aus dem Struktogramm können in einer C-Funktion liegen. Das hat den Vorteil, dass lokale Variab-len nur einmal angelegt und initialisiert werden müssen. Hieraus resultiert eine Zeiteinspa-rung und eine Verringerung von Stackfehlern. Darüber hinaus ist es so möglich, mit gerin-gem Aufwand Werte aus der letzten Periode zur weiteren Bearbeitung heranzuziehen.

2 Die Umschaltung erfolgt über eine nicht-portable Erweiterung mit Hilfe der folgenden Funktion: int pthread_make_periodic_np(pthread_t thread, hrtime_t start_time, hrtime_t period);


38

In Abbildung 3.2-2 ist ein typischer Startvorgang eines Echtzeitprogramms unter RT-Linux vereinfacht dargestellt. Es handelt sich um den Startprozess zweier periodischer Echtzeit-prozesse, Prio(P1)>Prio(P2). Der C-Quelltext eines RT-Linux Programms ist in Anhang A aufgelistet.

Linux-Modul

Echtzeitthread P1

Echtzeitthread P2

t1

Linux

t5t4t3t2 t8t7t6 t12t11t10t9 t13 t

O1 P1

Abbildung 3.2-2: Startvorgang von Echtzeitprozessen in RT-Linux

Zum Zeitpunkt t1 wird das Kernelmodul des Programms KMP in den Linux-Kernel geladen und beginnt mit seiner Initialisierung. Bei t2 wird der erste Echtzeitprozess P1 gestartet und beginnt mit seiner Ausführung. Nach der Initialisierung geht dieser in den periodischen Zustand über (t3), suspendiert sich kurze Zeit später selbst(t4), indem er wait() aufruft und den Start der ersten Periode abwartet. Als Offset für P1 wurde O1=t9-t3 dem Betriebssystem als Parameter übergeben. Ab t4 übernimmt das Kernelmodul KMP erneut die Kontrolle über den Prozessor und erzeugt P2, welcher sofort startet und sich bei t7 ebenfalls selbst suspen-diert. Die Initialisierung des Moduls wird beendet und der Linux-Kernel kehrt zur Eingabe-konsole zurück. Bei t9 wird durch den Timer ein Interrupt ausgelöst und der RT-Scheduler wählt P1 aufgrund der höheren Priorität zur weiteren Abarbeitung aus. Der Linux-Kernel wird unabhängig von der derzeitigen Aufgabe auf jeden Fall unterbrochen. Nachdem die Endlosschleife von P1 einmal durchlaufen wurde, wird sie am Anfang fortgesetzt und ruft erneut wait() auf (t10), um zu Beginn der nächsten Periode weiterzuarbeiten. P2 verhält sich äquivalent (t10-t11). Nach t11 sind die Echtzeitthreads fertig, somit wird Linux bis t12 ausge-führt. In diesem Zeitraum kann das Echtzeitprogramm durch Entladen des Moduls gestoppt werden. Es können bei dieser Art der Initialisierung Probleme auftreten, wenn:

• O1+t3=t9 < t7 ist und somit die Initialisierung von P2 durch die erste reguläre Periode von P1 unterbrochen wird. Anhand des Prozess-Satzes verpasst P2 seine erste Perio-de. Dieses Phänomen kann auftreten, wenn die Zeiten falsch berechnet wurden oder deutlich langsamere Hardware benutzt wird als geplant. Dieses Problem wird in YASA durch zusätzlichen Startup-Code eliminiert (s. Kap. 4.3.5).


39

• die Startzeitpunkte der periodischen Threads nicht gleich sind. Das Problem ist die Bestimmung von O2, der bei t6 angegeben werden muss und bis t9 reicht. Zur Lauf-zeit kann dieser Offset nicht berechnet werden, wenn detaillierte Kenntnisse der Hardware fehlen.

3.3 Synchronisationsprotokolle in RT-Linux

RT-Linux unterstützt in der Grundversion zwei Synchronisationsprotokolle für statische Scheduler. Die unterstützten Verfahren sind in Tabelle 5 dargestellt (s. [TOG97]). Die Pro-tokolle müssen bei der Erstellung des RT-Kernels über Compilerschalter (Compilerswit-ches) zugelassen werden [Bar01]. Das Synchronisationsprotokoll kann wie im POSIX-Standard festgeschrieben für jedes Mutex einzeln bei der Initialisierung festgelegt werden. Die Wahl des Protokolls hat erheblichen Einfluss auf das Schedulingverhalten (s. Kap. 2.4).

Verfahren Beschreibung Kein Verfahren Es wird kein Synchronisationsprotokoll verwendet. Die

Kurzbezeichnung in RT-Linux ist PTHREAD_PRIO_NONE.

Priority Inheritance Protocol Das PIP wird verwendet (s. Kap. 2.5.1.1). Ein Thread τi erbt die Priorität eines blockierten, höher prioren Threads, der ein Mutex angefordert hat, das bereits durch T1 belegt ist. In RT-Linux wird das Protokoll als PTHREAD_PRIO_INHERIT bezeichnet.

Priority Ceiling Protocol Das PCP kommt zur Anwendung (s. Kap. 2.5.1.2). Dazu ist die Kenntnis der Prioritäten aller Threads nötig, die dieses Mutex nutzen werden, um die Ceilingkonstante korrekt zu bestimmen. Fordert ein Thread dieses Mutex an, wird seine Priorität auf den Wert der Ceilingkonstante erhöht. Die interne Bezeichnung ist PTHREAD_PRIO_PROTECT.

Tabelle 5: Synchronisationsverfahren in RT-Linux

Die gezeigten Verfahren beweisen, dass in RT-Linux keine dynamischen Synchronisati-onsprotokolle verfügbar sind. Um dynamische Scheduler in RT-Linux zu verwenden, ist es zwingend erforderlich, nicht nur den Scheduler auszutauschen bzw. zu erweitern, sondern zugleich die Schedulingumgebung zu ergänzen. Ein erster Versuch wurde bereits durch P. Balbastre und Ismael Ripoll durch Integration des Earliest Deadline First Schedulers (EDF) und des Stack Resource Policy (SRP) Protocols zur Synchronisation von Semaphoren vor-gestellt [Bal00].

4. Scheduling Analyser

40


4.1 Einleitung

In Echtzeitsystemen ist die Wahl des Schedulers bzw. des Synchronisationsprotokolls von enormer Bedeutung, wie in Kapitel 2.3 bereits herausgestellt wurde. Es muss sichergestellt werden, dass die Prozess-Sätze ihre Deadline einhalten. Herkömmliche Verfahren basieren auf einer rein theoretischen Betrachtung (s. Kap. 2.7). In den vorangegangenen Jahren wurden bereits erste Schritte unternommen, Prozess-Sätze mit verschiedenen Schedulern und Synchronisationsprotokollen zu simulieren, synthetische Belastungstests unter Windows NT durchzuführen und auszuwerten [Sch97]. 1998 wurde das Simulationsprogramm YASA fertig gestellt, das 7 verschiedene Scheduler, darunter RMS, DMS, PRIO, EDF, LLF sowie LEF unterstützt und abhängig vom Scheduler die wichtigsten Synchronisationsprotokolle wie PIP, PCP, IPCP, DPCP sowie SRP beherrscht. Weiterhin sind zur Behandlung von aperiodischen Ereignissen Server für statische und dy-namische Scheduler vorhanden. Vergleichbare Scheduling Analyser wie PERTS, CAISARTS, STRESS, SCAN sind in [Sch98] ausführlich beschrieben worden und bleiben wie später entwickelte Programme (Cheddar [Nic02] bzw. RapidRMA) weit hinter den Möglichkeiten von YASA zurück. Das Hauptproblem aller bekannten Scheduling Analyser ist die Begrenzung auf theoreti-sche Betrachtungen ohne die Möglichkeit, Prozess-Sätze in der Realität unter verschiede-nen Schedulern bzw. Synchronisationsprotokollen und in Verbindung mit der System-umgebung (Sensoren etc.) auszuführen. Aber gerade in der Realität wird die Komplexität deutlich, die in Kap. 3.2 erläutert wurde. Die in der Praxis verfügbaren Echtzeitbetriebssysteme wie Lynx, VxWorks, RT-Linux, RTAI und IRIX besitzen alle statische, meist prioritätsbasierte Scheduler, die nicht ohne weiteres ausgewechselt werden können. Eine Analyse des Schedulingverhaltens ist nicht oder nur mit riesigem Aufwand durchführbar. In dieser Arbeit wird ein Softwareprodukt vorgestellt, das die Möglichkeit bietet, den Sche-duler bzw. das Synchronisationsprotokoll eines Betriebssystems auszutauschen und zu er-weitern. Das Echtzeitsystem kann umfangreich konfiguriert werden und bietet die Mög-lichkeit der späteren Überprüfung zur Optimierung. Es ist allerdings nicht Ziel des Frame-works, portable Programme zu entwickeln, sondern lediglich das Schedulingverhalten zu optimieren.


41

4.2 Konzept

Das hier vorgestellte Entwicklungsframework YASA 2, ist eine komplette Neuentwicklung und lehnt sich nur aufgrund der historischen und geografischen Nähe der Autoren an den Namen den Vorgängers YASA an [Sch98]. Eine Neuentwicklung war notwendig, da das alte YASA diverse Ziele aus Kapitel 1.3 nicht hätte erfüllen können. So wäre eine Portie-rung des MFC-Quellkodes auf ein UNIX-Pendant einer Neuentwicklung gleichgekommen. Das entscheidende Problem war allerdings, dass es sich bei YASA um einen Simulator handelt und nicht um eine Entwicklungsumgebung. Das Design der beiden Anwendungen ist schon aus diesem Grund völlig verschieden. YASA 2 gliedert sich in zwei große Teilbereiche. Der erste Bereich umfasst die Ausfüh-rung von Prozess-Sätzen in der gewählten Umgebung und der zweite die grafische Darstel-lung und Auswertung. Beide Teile arbeiten komplett unabhängig voneinander. In Abbildung 4.2-1 ist die grobe Struktur des Frameworks dargestellt. Das Ziel von YASA 2 ist die Optimierung des Schedulingverhaltens in realen Situationen mit eventuellem Wechsel des Schedulers. Dazu ist ein Eingriff in das Betriebssystem notwendig. In der Gra-fik ist links das Betriebssystem veranschaulicht, von dem die Schedulingumgebung je nach Bedarf umgebaut werden muss. Hierzu ist eine Anpassungsschicht erforderlich, da nicht garantiert werden kann, dass jedes Betriebssystem alle Eigenschaften, z.B. Unterstützung dynamischer Scheduler, beherrscht. Diese Anpassungsschicht wird als Executive bezeich-net. Sie hat für die Prozessumgebung und die Scheduler nach außen hin zwei fest definierte API’s.

Threads

Scheduler / Synchronisationsprotokolle

Logfile GrafischeOberfläche

Scheduler-API

Anwendungs-API

Systemumgebung

Betriebssystem Schedulingumgebung

Executive

Abbildung 4.2-1: Struktur des YASA-Frameworks

Die Threads stellen den Prozess-Satz dar und kommunizieren mit den Funktionen des Be-triebssystems, der Prozessumgebung und über die Anwendungs-API mit den Executives,


42

um das Schedulingverhalten zu beeinflussen. Die Prozessumgebung symbolisiert äußere Einflüsse, wie Sensoren und Aktoren. Die unterschiedlichen Scheduler und Synchronisationsprotokolle arbeiten über die Schedu-ler-API mit den Executives zusammen. Die Scheduler haben keine Kenntnisse über die Systemumgebung, das Betriebssystem und das Executive. Sie sind plattformunabhängig. Die Module Threads, Executive und Scheduler/Synchronisationsprotokolle haben, bei ent-sprechender Kompilierung vorausgesetzt, die Möglichkeit, alle Ereignisse in ein system-weites Logfile zu schreiben. Das Logfile wird nach dem Lauf der Anwendung in der grafi-schen Oberfläche ausgewertet und bei Bedarf als Zeitdiagramm in verschiedenen Varianten dargestellt.

4.3 Die Executives

Die Executives sind das Kernstück des Entwicklungsframeworks. Sie ersetzen die internen Scheduling- und Synchronisationsroutinen des Betriebssystems und implementieren die nötigen Betriebssystem-Funktionen, um die zusätzlichen Eigenschaften von YASA zur Verfügung zu stellen. Ihre Aufgaben bestehen vor allem in:

• Festlegung von Grund-Datentypen • Definition wichtiger Präprozessor-Makros • Startumgebungen für Projekte und Scheduler • Bereitstellen eines Logging-Mechanismus’ • Ersetzen bzw. Erweitern von Schedulingfunktionen des Systems

o Unterstützung statischer & dynamischer Scheduler o Stat. & dyn. Synchronisationsprotokolle o Deadlinebehandlung

Die Executives liegen zumeist im Quelltext vor und werden bei Bedarf kompiliert. Das ist jedoch nicht zwingend erforderlich, da bei der Anwendung von Hardware-Schedulern eine andere Strategie angesetzt werden muss als bei Betriebssystemen (s. Kap. 4.8). In Abbildung 4.3-1 ist die Struktur eines Executives dargestellt. Die wichtigste Komponen-te ist das Betriebssystemanpassungs-Modul. Es stellt das Bindeglied zwischen den YASA-Modulen und dem OS dar. Das Executive besteht im Wesentlichen aus Präprozessoranwei-sungen, die die internen Systemstrukturen, z.B. des Prozesskontrollblocks PCB bzw. der Schedulingstrukturen der CPU’s, mit denen der YASA-Komponenten verbinden. Eine die-ser YASA-Komponenten sind die plattformunabhängigen Scheduler, die keinerlei Kenntnis über das Betriebssystem haben dürfen. Daher muss der Zugriff auf OS-Strukturen vollstän-dig über Mapping-Funktionen, sog. Wrapper erfolgen. Das sind Funktionen, die auf der


43

einen Seite dem Scheduler eine einheitliche API zur Verfügung stellen und andererseits intern die Zugriffe auf das OS bewerkstelligen.

Betriebssystem-Anpassung

Scheduler-Startup

Projekt-Startup

Logging-Modul

Scheduling-Modul

Ressourcen-Modul

Deadline-Modul

Scheduler

Prozeßsatz

Logfile

Executive Externe Komponenten

YASA-Komponenten

Abbildung 4.3-1: Struktur eines Executives

Das Modul hat weiterhin die Aufgabe, Grenzwerte des Betriebssystems und der Hardware zu definieren. So ist es wichtig, einen Datentyp zu deklarieren, der die korrekte Zeitangabe enthält. In RT-Linux wird standardmäßig ein 64 Bit breiter Integerwert namens hrtime_t verwendet. Diese Bezeichnung ist für YASA unangebracht, da YASA wegen der Plattfor-munabhängigkeit als Zeitbezeichnung YASA_TIME benutzt. Die Typdefinition wird im Executive vorgenommen, in diesem Fall durch: „typedef httime_t YASA_TIME“. Da die meisten Betriebssysteme lediglich statische Scheduler unterstützen, muss davon ausgegangen werden, dass die Systemstrukturen unterschiedlich stark erweitert werden müssen, um die Eigenschaften dynamischen Scheduler, z.B. Deadline, Spielraum, zusätz-liche Taskzustände oder YASA-spezifische Daten zu speichern. In Abbildung 4.3-2 wird die Erweiterung der wichtigsten Systemstrukturen demonstriert. Die Betriebssysteme er-zeugen für jeden Thread einen Prozesskontrollblock. Die Attribute, die ein PCB enthält, variieren von System zu System. Der Executive-Patch muss sicherstellen, dass alle nötigen Informationen in den PCB eingefügt werden. Die Schedulerstruktur wird für jede CPU angelegt und enthält Daten über die Prozesse, die auf der CPU laufen. Für die YASA-Kompatibilität müssen Attribute wie Start des Schedu-lers und Schedulertick hinzugefügt werden. Die Erweiterung erfolgt per Präprozessormapping direkt in den Kernelquellen der Struktu-ren. Auf diese Weise können die Strukturen mit ihrem originalen Namen in den originalen Quellen und gleichzeitig mit dem neuen Namen (YASA_*) in den YASA-Komponenten indirekt über Präprozessormakros adressiert werden.


44

PCB

PCB

YASA-PCBAttribute

Scheduler

Scheduler

YASA-SchedulerAttribute

Mutex

Mutex

YASA-MutexAttribute

OS-Thread

YASA_THREAD

OS-Scheduler

YASA_SCHEDULER

OS-Mutex

YASA_MUTEX

Patch

Betriebssystem mit Executive

Betriebssystem

Abbildung 4.3-2: Erweiterung der OS-Systemstrukturen durch Executive-Patch

Sollten die zusätzlich nötigen YASA-Attribute zusammen mit einer originalen System-struktur eine neue Struktur bilden, dann bestünde die Gefahr, dass Kopiervorgänge im Ker-nel nur die ursprüngliche Länge der Struktur kopieren. Der Quelltext würde zudem unleser-licher werden, da in YASA-Funktionen ständiges Casting3 nötig wäre. Das Projekt-Startup-Modul wird benötigt, um Projekte, die kompiliert wurden, definiert zu starten. Ein Projekt besteht aus den Quelltexten der Threads, die der Entwickler in externen Programmen erstellen kann, und den Thread-Strukturen, in denen die Parameter der Threads gespeichert sind. Sie werden von YASA im Vorfeld generiert (s. Anhang A.8). In diesem Modul werden alle Threads und Mutexe sequentiell erzeugt und initialisiert. Danach erfolgt ein synchronisierter Start. Jeder Scheduler, der in einem Executive benutzt wird, muss vorher für dieses Executive übersetzt werden. Er wird dabei gegen den Programmcode des Scheduler-Startup-Moduls gelinkt (dynamisches Linken). Das ist notwendig, um den Scheduler korrekt in das Be-triebssystem einzubinden. Es ist ebenso statisches Linken gegen den Kernel denkbar. Das Mitprotokollieren von Ereignissen erfordert einen Logging-Mechanismus. Hier erfolgt die temporäre Speicherung von Ereignissen in Puffern, die nach Ausführung der Anwen-dung in ein Logfile geschrieben werden (s. Kap. 4.3.3). Die unterschiedlichen Eigenschaften, die die Executives und die dazugehörigen Betriebs-systeme repräsentieren, müssen dem Entwicklungsframework bekannt sein. Sie sind unver-zichtbar, um funktionsfähigen Quelltext für Projekte zu generieren. So muss z.B. sicherge-stellt sein, dass Projekte, die auf SMP-Systemen laufen, Executives benutzen, die Multi-processing unterstützen und es richtig initialisieren. Zu diesem Zweck wurde eine XML-Konfigurationsdatei eingeführt, die jedes Executive besitzen muss. Diese Datei befindet sich im Executive-Verzeichnis und hat dessen Namen inkl. der Dateiendung „.yasa“. Die möglichen Attribute zur Konfiguration sind in Anhang A.5 dargelegt. 3 Unter Casting versteht man die Änderung des Typs einer Variablen ohne Überprüfung des Inhalts.


45

4.3.1 Synchronisationsprotokolle

Jedes Executive muss eine Möglichkeit zur Verfügung stellen, die YASA-internen Syn-chronisationsprotokolle zu verwenden. Die Synchronisationsprotokolle in YASA sind in den Dateien yasa_resources.c und ya-sa_resourcesdynamic.cpp definiert. Sie sind plattformunabhängig. Bei der Kompilierung des Executives werden diese Komponenten hinzugelinkt. YASA unterstützt derzeit sechs verschiedene Verfahren, die bei korrekter Implementierung der Executives vollständig funktionieren:

• PIP, Priority Inheritance Protocol • CSP, Ceiling Semaphore Protocol • PCP, Priority Ceiling Protocol • DPCP, Dynamic Priority Ceiling Protocol • SRP, Stack Resource Policy • KPP, Kernel Priority Protocol

Die Umsetzung der dynamischen Verfahren erfordert bei Verwendung verschiedener Sche-duler eine Beschreibung des dynamischen Prioritätstyps und Informationen über die Adres-sierung und Größe des Datums innerhalb des PCB. Die Beschreibung ist notwendig, da nicht davon ausgegangen werden kann, dass höhere Werte grundsätzlich einer höheren Pri-orität entsprechen (s. Anhang A.4) oder dass Prioritätswerte immer vom Typ int bzw. int64 sind. Intern werden die dynamischen Prioritäten in einer Union YASA_DYN_PRIORITY gehalten. Sie besteht aus den Prioritätstypen der Tabelle 6 und wird vom Scheduler während der Ini-tialisierung festgelegt. Um Speicherplatz und Seiteneffekte bei der Verwendung von mehre-ren Prozessoren und unterschiedlichen Synchronisationsprotokollen zu vermeiden, wurde definiert, dass die dynamischen Prioritäten systemweit gelten, d.h. es ist nicht gestattet, Scheduler mit unterschiedlichen dyn. Prioritäten einzusetzen. Der Vergleich der dynami-schen Prioritäten erfolgt bei YASA in einer Funktion mit Switch-Case Konstrukt, um die vielfältigen Möglichkeiten zu erfassen. (s. Abbildung A-2).

Prioritätstyp Datentyp Beschreibung PRIORITY int Die Priorität ergibt sich aus dem statischen Integer-

wert, der im PCB gespeichert ist. Die Priorität steigt mit höherem Wert. Der Zugriff auf die Priorität er-folgt über das Makro YASA_PRIORITY(thread).


46

Prioritätstyp Datentyp Beschreibung DEADLINE YASA_TIME Das Prioritätskriterium ist die Deadline des Threads.

Kürzere Deadlines haben eine höhere Priorität. In Abhängigkeit vom Protokoll wird die relative Deadline innerhalb der Periode oder die absolute Deadline (seit Systemstart bzw. Epoch) benutzt. Sie kann über das Makro YASA_DEADLINE(thread) ermittelt werden.

LAXITY YASA_TIME Der Schlupf des Threads entspricht der Priorität, die mit geringer werdendem Laxity steigt. Der Zugriff erfolgt über das Makro YASA_LAXITY(thread).

REQUIREDTIME YASA_TIME Die zu benötigende Zeit des Threads ist entscheidend für die Priorität. Eine höhere Zeit kommt einer höhe-ren Priorität gleich. Für den Zugriff wird das Makro YASA_REQUIREDTIME(thread) benutzt.

SHORTESTTIME YASA_TIME Die dynamische Priorität ergibt sich aus der zu benö-tigenden Zeit des Threads. Die Priorität steigt mit kürzeren Berechnungszeiten. Für den Zugriff wird das Makro YASA_REQUIREDTIME(thread) angewandt.

Tabelle 6: Dynamische Prioritätstypen in YASA

Die Implementierung von dynamischen Verfahren ist sehr aufwändig. Der Speicher-verbrauch wird durch Stacks (SRP) oder umfangreiche Prüfverfahren (DPCP) deutlich er-höht. Die Geschwindigkeit in den Schedulern wird bei Einsatz von SRP durch zusätzliche Überprüfungen verringert. In YASA existieren Präprozessoranweisungen, die den entspre-chenden Quelltext in den Executives und den Schedulern von der Kompilierung ausneh-men, falls er nicht benötigt wird.

4.3.2 Deadline-Behandlung

Es gibt verschiedene Möglichkeiten, verpasste Deadlines zu behandeln. Die bekannteste ist die Vogel-Strauss-Methode [Gol98a]. Sie besagt, dass bei einem Deadline-Miss der Kopf in den Sand gesteckt wird. Es wird so weiter gemacht wie bisher. Eine weitere Methode, die vor allem unter Zuhilfenahme der Hardware funktioniert, ist der Watchdog-Timer. Hierbei dekrementiert ein Timer stetig seinen Wert und löst bei Erreichen von 0 einen Interrupt zur Fehlerbehandlung aus. Der Timerwert wird per Software nach Beendigung der Arbeit regelmäßig zurückgesetzt, sodass der Interrupt im Idealfall nie aus-


47

gelöst wird. Verpasst ein Thread seine Deadline, wird der Timer zu spät oder gar nicht zu-rückgesetzt und ein Interrupt ausgelöst. Die angesprochenen Strategien finden ebenfalls Anwendung in YASA. Es ist möglich, für jeden Thread einzeln eine Behandlungsmethode anzugeben. Derzeit stehen zwei Verhal-tensweisen bei einem Deadline-Miss zur Verfügung, weitere sind in Planung (Tabelle 7).

Interne Bezeichnung Beschreibung YASA_DL_IGNORE Das Verpassen einer Deadline wird ignoriert. Der

Thread wird weder unterbrochen noch terminiert. Es kann aber zu Dominoeffekten kommen, da sich der Effekt meist fortsetzt (Vogel-Strauss-Methode).

YASA_DL_CANCEL_THREAD Diese Einstellung bewirkt, dass ein Thread sofort terminiert wird, wenn ein Deadline Miss erkannt wird (geplant). Eine Terminierung ist sehr kritisch, da sie stark ins System eingreift. Das Freigeben von belegten Semaphoren muss gewährleistet sein.

YASA_DL_SKIPOVER Bei Auftreten einer verpassten Deadline veranlasst die Einstellung „Skip Over“ die Schedulingumge-bung, die nächste Periode des Threads zu über-springen. In diesem Fall verliert der Thread zwar einen Job, aber die Gefahr eines Domino-Effekts wird gemindert. Skip Over wird im Standard RT-Linux eingesetzt.

YASA_DL_EMERGENCYTHREAD Die Einstellung “Emergency thread” bewirkt das Stornieren des Threads mit der verpassten Deadli-ne und gleichzeitiges Starten eines Notfallthreads. Dieser Thread bekommt den Prozessor nicht au-tomatisch zugeteilt, sondern nimmt als normaler Thread am Schedulingverfahren teil (Watchdog-Prinzip).

Tabelle 7: Verhalten bei Verpassen einer Deadline

Die Funktionen zur Behandlung von Deadline-Misses sind ebenfalls plattformunabhängig. Aus diesem Grund erfolgt der Zugriff auf Systemstrukturen erneut per Präprozessor-Makros. Die YASA-Funktionen sind im Modul „yasa/yasa_scheduling.cpp“ definiert.


48

4.3.3 Der Logging-Mechanismus

Die Logging-Komponente wird verwendet, um Ereignisse, die während des Systemlaufs auftreten, mitzuprotokollieren. Im Anschluss erfolgt die Ausgabe der Daten in ein Logfile, das in der grafischen Oberfläche ausgewertet werden kann. YASA 2 kann Ereignisse als Zeitdiagramme darstellen bzw. eine statistische Auswertung vornehmen und die Ergebnisse in tabellarischer Form ausgeben. Die Protokollierung erfolgt durch einen eigens entwickelten Logging-Mechanismus. Er ist Teil jedes Executives und wird durch den Patch dem Betriebssystem hinzugefügt, um eine einheitliche Protokollierung für die Weiterverarbeitung zu ermöglichen. Bei der Entwick-lung eines effizienten Verfahrens waren folgende Punkte zu beachten:

• Kernelprogrammierung • Speedoptimierung • Ereignisfilterung durch Kompilierung • Erweiterbarkeit

Die Fähigkeit der Logging-Komponente, im Betriebssystemkernel zu laufen, ist von ent-scheidender Bedeutung, da sonst keine Informationen über die Schedulinginformationen zur Verfügung stehen würden. Bei der Protokollierung der Daten muss gewährleistet wer-den, dass die Funktionen nicht blockieren, d.h. sie dürfen z.B. keine I/O Anforderungen starten. Die Speicherung der Daten erfolgt in temporären Speicherblöcken, die im Vorfeld alloziert wurden. Ist für weitere Ereignisse kein Platz mehr verfügbar, wird die Protokollie-rung gestoppt und alle weiteren Einträge ignoriert. Die Größe dieser Speicherbereiche ist abhängig vom Betriebssystem und der verwendeten Hardwarearchitektur (Page-Size).4 Nachdem die Anwendung abgeschlossen ist, erfolgt die Ausgabe der Daten in ein Logfile. Das Erzeugen dieser Datei ist zeitunkritisch, aber keineswegs trivial, da nicht davon ausge-gangen werden kann, dass alle Betriebssysteme im Kernelmodus File-Operationen gestat-ten. Die Umsetzung ist daher Executive-spezifisch. Ein Ereignis wird durch Aufruf der Funktion yasa_logscheduler() bzw. yasa_logentry() in das Logfile aufgenommen, die allerdings nicht direkt angesprungen werden. Stattdessen werden Makros benutzt, die je nach Bedarf, den Funktionssprung mitkompilieren. In Abbildung 4.3-3 ist die Deklaration des Makros für das Ereignis THREAD_ACTIVATE darge-stellt. Legt der Entwickler Wert auf die Protokollierung dieses Ereignisses, kann er dies durch Setzen des Präprozessorschalters YASA_SUPPORT_LOG_THREAD_ACTIVATE und an-schließendem Kompilieren erreichen. 4 In Systemen mit x86-Linux beträgt die max. Größe eines Speicherbereichs im Kernel 131072 Bytes. Bei Allozierung größerer Speicherblöcke wird eine Kernelpanic ausgelöst.


49

#ifdef YASA_SUPPORT_LOG_THREAD_ACTIVATE

#define YASAL_LOG_THREAD_ACTIVATE(thread, time, param) yasa_logentry(thread, YASAL_THREAD_ACTIVATE, time, param)

#else

#define YASAL_LOG_THREAD_ACTIVATE(a,b,c)

#endif

Abbildung 4.3-3: Makrodefinition eines Loggingereignisses

Das erzeugte Logfile enthält zur besseren Fehleranalyse die Namen und Versionsnummern des YASA-Entwicklungsframeworks, des benutzten Executives und aller Scheduler. Wei-terhin sind die grundsätzlichen Einstellungen der Simulation angegeben, um eine spätere Rekonstruktion bzw. Ferndiagnose durchführen zu können. In Anhang A.9 ist das gekürzte Logfile aus Abbildung 2.4-2 gezeigt.

4.3.4 Simulator Executive

Ein funktionsfähiges Executive ist der Simulator. Er ist in der Lage, komplette Prozess-Sätze mit verschiedenen Schedulern und Synchronisationsprotokollen zu simulieren. Der Simulator liegt im Quelltext vor und muss nach jeder Änderung des Prozess-Satzes bzw. der Systemeigenschaften teilweise neu kompiliert werden. Der Vorteil ist, dass der Simula-tor auf jedem Betriebssystem lauffähig ist und auf die Hardware optimiert werden kann. Aufgrund der umfangreichen Skriptfähigkeiten erfolgt die Übersetzung des Simulators in einer Unix-Umgebung. Dort sind Programmpakete wie make, bash und gcc verfügbar, die hervorragend geeignet sind, mit dynamischen Systemen wie YASA zusammen zu arbeiten. Unter Windows wird die UNIX-Emulation cygwin benutzt [Red02]. Der Simulator ist in seiner Arbeitsweise einem modernen Betriebssystem nachempfunden, wodurch eine sehr realitätsnahe Simulation, vor allem auf Mehrprozessorsystemen, erreicht wird. Es handelt sich um einen virtuellen Lauf des Prozess-Satzes unter synthetischer Last. Der Vorteil ist, dass die Abhängigkeiten, z.B. durch das Blockieren von Semaphoren, ein-deutig erkannt werden. Ferner können die plattformunabhängigen Scheduler verwendet werden. Der Simulator steht damit im Gegensatz zu rein theoretischen Verfahren, z.B. des YASA 1 [Sch98], die i.d.R. nur eine Simulation mit einem bestimmten Algorithmus in einer Schleife durchführen. Um das zu ermöglichen, existieren Funktionen zum Starten von Prozessen, Setzen bzw. Freigeben von Semaphoren. Die simulierten Threads besitzen PCB’s, die Attribute wie Pri-orität, Deadline, Offset und Taskzustand enthalten. Die Schedulingumgebung ist ebenfalls identisch mit der von Echtzeitbetriebssystemen. Für jede CPU wird eine Schedulingstruktur angelegt.


50

Die Zeitbasis des Simulators ist wie bei RT-Linux ein 64-Bit Integer (s. Kap. 3.1.1). Grundsätzlich wird im Simulator immer eine Zeiteinheit simuliert. Im Anschluss wird ge-testet, ob der Scheduler erneut aufgerufen werden muss oder ob die synthetische Last eine Ressourcenanforderung durchführen muss. Für eine realistische Simulation ergeben sich Zeitwerte von z.B. t(5ms)=YASA_TIME(5.000.000). Ein solcher Schedulertick führt nach dem ersten Schedu-ling zum Zeitpunkt t=0 4.999.999 unnötige Scheifendurchläufe aus, vorausgesetzt, der Schleifenzähler kann nur um jeweils 1 erhöht werden, um die synthetische Last und zeit-gleich die Ressourceanforderungen auszuführen. Um die unnötigen Schleifendurchläufe zu verhindern, wurde für den Simulator eine interne Optimierungsstufe entwickelt, die in Ab-hängigkeit des Ticks und der Ressourcenanforderungen berechnet, wann ein Schleifen-durchlauf das nächste mal erfolgen muss.5 Bei der Übersetzung eines Projekts mit dem Simulator werden externe Quelltexte nicht in die Kompilierung miteinbezogen, denn:

• Der Simulator kann Programme nicht in Echtzeit ausführen, da er selbst als Task in einem Betriebssystem läuft.

• Um Programme in einem Simulator auszuführen, sind alle Betriebssystemschnitt-stellen nachzubilden, auf die die Projekte zugreifen. Das ist unmöglich, da YASA keine Kenntnis haben kann, welche Funktionen aufgerufen werden. In verschiede-nen Betriebssystemen könnten zudem gleichlautende Funktionen existieren, die un-terschiedliche Sachverhalte bearbeiten.

4.3.5 RT-Linux Executive

Das RT-Linux Executive gestattet die Ausführung von Projekten inkl. eigenen Quelltexten auf einem Linux-Betriebssystem mit RT-Erweiterung. Es ist mit den aktuellen Versionen V3.0 und V3.1 kompatibel. Eine genauere Einführung wurde bereits in Kap. 3 gegeben. Für den Betrieb mit YASA wird ein installierter Quelltext des Linux-Kernels und der RT-Erweiterung von FSMLabs benötigt. Bei Starten eines YASA-Projekts wird einmalig der Betriebssystemkernel auf den aktuellen Stand, entsprechend den Vorgaben aus dem Pro-jekt, gebracht und im Anschluss kompiliert. Auf diese Weise wird eine optimierte und an-gepasste Kernelversion erstellt. Dazu wird ein YASA-Kernelpatch für die RT-Erweiterung benötigt. Durch die Begrenzung auf die Schedulingumgebung ist der Patch lokal begrenzt und tangiert lediglich 7 Dateien in minimalen Umfang, obwohl die wichtigsten System-funktionen und -strukturen erweitert werden (s. Tabelle 8).

5 Die Optimierungsstufe wird über den Compiler-Switch -DUSE_OPTIMIZATION freigeschaltet.


51

Datei Änderungsumfang

$(RTL)/include/rtl_mutex.h • Deklaration der Mutex-Systemstrukturen und Funkti-onen zum Setzen bzw. Freigeben der Semaphoren

• Hinzufügen von Funktionen im POSIX-Stil zum Ar-beiten mit Ceiling-Konstanten.

$(RTL)/include/rtl_sched.h • Erweiterung der Strukturdeklarationen des PCB, der Prozessoren und der Schedulingattribute.

• Erweitern des Funktionsumfangs zum Arbeiten mit dynamischen Prioritäten und Ceiling-Konstanten.

$(RTL)/linux/include/sched.h • Deklaration der sched_info Struktur $(RTL)/schedulers/rtl_mutex.c • Änderung der Funktionsrümpfe und Hinzufügen der

neuen Funktionen $(RTL)/schedulers/rtl_sched.c • Änderung der Funktionsrümpfe und Hinzufügen der

neuen Funktionen $(RTL)/schedulers/Makefile • Hinzufügen der Linkerinformationen für die zusätz-

lichen YASA-Komponenten $(RTL)/Makefile • Hinzufügen wichtiger Compileroptionen

Tabelle 8: Dateiänderungen in RT-Linux

Der Umfang der Änderungen in den originalen Dateien von RT-Linux ist auf ein Minimum begrenzt. In Anhang A.7 ist ein Patch am Beispiel der Schedulingstruktur von RT-Linux gezeigt. Anstatt jedes neue Attribut einzeln in die Struktur einzutragen, übernimmt ein Präprozessormakro die Prozedur. In RT-Funktionen wird das Verfahren äquivalent ange-wandt. Das hat entscheidende Vorteile:

• Eine Änderung des YASA-Quelltextes bedarf keiner weiteren Änderung des RT-Kernel Quelltextes, da die Präprozessormakros die YASA-Attribute bzw. Funktio-nen automatisch während der nächsten Kompilierung einsetzen.

• Die Anpassung an neuere Versionen von RT-Linux ist einfacher, da i.d.R. lediglich die Präprozessormakros eingesetzt werden müssen.

• Der modifizierte Kernelquelltext ist leichter zu lesen. • Verschiedene Kernelversionen lassen sich einfacher pflegen, da die YASA-Patches

in gemeinsamen Files verarbeitet werden. RT-Linux benötigt nicht nur Patch-Vorgänge, sondern zugleich die Entwicklung eigener Teilkomponenten. Eine dieser Komponenten ist das ProjectStartup-Modul(Projektstarter).


52

Es wird benötigt, um das Projekt zu initialisieren und die Threads des Projekts zu erzeugen bzw. zu synchronisieren (s. Anhang A.8). Der Projektstarter ist eine Teilkomponente, die neben den Projektdaten und weiteren YA-SA-Komponenten während der Kompilierungsphase zu einem ladbaren RT-Linux Modul zusammengebunden werden. Nach dem Laden des RT-Moduls werden die Scheduler des Betriebssystems ersetzt. Dazu werden die SchedulerInfo-Strukturen des Projekts ausgewer-tet. Im Anschluss erfolgt die Erzeugung der vordefinierten Mutexe, die in dem Projekt be-nutzt werden, gefolgt von den Threads. Die Threads beginnen ihre Arbeit bis zum Aufruf des Makros YASA_PERIODIC_START bzw. YASA_NONPERIODIC_START und wer-den suspendiert (s. Abbildung 4.3-4). Bis zu diesem Zeitpunkt können sie weitere Initiali-sierungen vornehmen. Nachdem alle RT-Threads suspendiert sind, beginnt der Synchroni-sationsvorgang im Projektstarter. Die Schedulingparameter wie Deadline, Periode und Off-set werden korrigiert und auf ein einheitliches Zeitmaß bezogen – den Synchronisationsoff-set. Nach der Synchronisation werden alle Threads, deren Offset kleiner als die aktuelle Zeit ist, in den Ready-State überführt und nehmen am Schedulingverfahren wieder teil. Dadurch werden die in Kap. 3.3 erläuterten Probleme eliminiert. #define YASA_PERIODIC_START pthread_suspend_np( pthread_self() ); \ do { pthread_wait_np();

#define YASA_PERIODIC_END } while (1);

#define YASA_NONPERIODIC_START pthread_suspend_np( pthread_self() );

#define YASA_NONPERIODIC_END(retvalue) return (void*)retvalue;

Abbildung 4.3-4: Deklaration der Projekt-Makros in RT-Linux

In Abbildung 4.3-4 sind die Deklarationen der vier wichtigsten Projekt-Makros dargestellt. Deutlich zu erkennen ist der Verzicht, im Gegensatz zu originalen RT-Linux Programmen, die Schedulingparameter, z.B. durch pthread_make_periode_np(), direkt zu setzen. Diese werden durch die Synchronisationsroutine des Projectstarters, die zeitlich zwischen phread_suspend_np() und do() liegt, gesetzt. Dadurch wird die Abhängigkeit von nicht-portablen RT-Linux-Funktionen verringert und gleichzeitig eine Synchronisation zwischen den Threads ermöglicht. Eine weitere zusätzliche Komponente für das RT-Linux Executive ist der LogFileReader. Er wird benötigt, um die protokollierten Daten aus dem Kernel-Modus in den User-Modus zu überführen und um sie später in eine Datei zu schreiben. Der LogFileReader besteht aus zwei Teilen, dem LogFileReaderModule (Module) und der LogFileReaderApplication (Re-ader). Das LogFileReaderModule ist ein Kernel-Modul für RT-Linux. Es wird nach der Ausführung von Programmen durch das Kommando insmod geladen und öffnet einen nicht-blockierenden RT-FIFO. Die Readeranwendung kann in jeder Shell gestartet werden und initialisiert ebenfalls den FIFO-Kanal. Sie beginnt mit dem Lesen aus dem FIFO. Ist


53

der FIFO leer, blockiert der Reader. Das Modul hat aufgrund seiner Kernelrechte die Mög-lichkeit, direkt auf die Logfiledaten der Scheduler zuzugreifen. Es schreibt die Daten in den FIFO. In einer eigenen Write-Funktion wird erkannt, ob die Daten aufgrund eines vollen FIFOs nicht geschrieben werden konnten. Ist das der Fall, wird der Modulthread für kurze Zeit suspendiert und versucht, den Schreibvorgang später erneut durchzuführen (Polling). Die Nutzung von Synchronisationsmechanismen ist nicht möglich, da im User-Modus kein Zugriff auf die Funktionen von RT-Linux existiert. Das Polling ist vernachlässigbar, da es keine anderen Echtzeitthreads behindert und nur alle 1 µs auftritt. In der Zwischenzeit kann der Reader die Daten lesen und gibt sie nach stdout aus. Die Zeitbasis in RT-Linux ist, wie in Kap. 3.1 erläutert, 64 Bit breit. Das führt dazu, dass selbst kleinere Zeitwerte schon beachtliche Zahlenwerte annehmen können (z.B. t(5ms)=YASA_TIME(5.000.000) ). Durch die ungenaue Messung der Zeit und die leicht unterschiedliche Abarbeitungsgeschwindigkeit schwanken die Zeiten erfahrungsgemäß um einige zehntausend Nanosekunden. Daraus folgt, vor allem bei periodischem Takt, eine zunehmende Zeitverschiebung.

4.3.6 Potenzielle Executives

Die Entwicklung von Executives ist prinzipiell für jedes Betriebssystem möglich. Das setzt in den meisten Fällen den Zugriff auf die Quelltexte des Betriebssystems voraus, da die Schedulingumgebung komplett ersetzt werden muss. In Tabelle 9 sind weitere Betriebssys-teme aufgelistet, die potentiell für die Entwicklung von Executives geeignet sind.

Name Quelltexte Beschreibung RTAI ja RTAI ist wie RT-Linux eine RT-Erweiterung für Linux Sys-

teme. Es basiert allerdings auf Kernel 2.2.x. Lynx OS nein Ein älteres, kommerzielles UNIX-Echtzeitbetriebssystem vom

LynuxWorks. QNX käuflich Ein Echtzeitbetriebssystem mit umfangreicher Softwareunter-

stützung. Es besitzt einen eigenen Bildschirmmanager, der in der Lage ist, X-Windows Programme auszuführen. Es ist frei für nicht-kommerzielle Anwendungen.

VxWorks nein VxWorks ist wie LynxOS ein älteres kommerzielle UNIX-Echtzeitbetriebssystem.

IRIX nein IRIX ist ein kommerzielles Echtzeitbetriebssystem von SGI. Es ist optimiert auf Echtzeit 3D-Anwendungen und ist kompa-tibel zum UNIX V5 Standard.


54

Name Quelltexte Beschreibung BlueCat RT käuflich BlueCat ist ein von LynuxWorks entwickeltes Linux auf Basis

der aktueller Kernel. BlueCat RT ist wie RTAI eine RT-Erweiterung für Linux, in diesem Fall für BlueCat. BlueCat ist für nicht-kommerzielle Versionen ohne RT-Erweiterung frei und kompatibel zu Lynx-OS.

Red Linux - Red Linux ist eine Echtzeiterweiterung für Linux.6 In [Wan00] ist ein Scheduling-Framework vorgestellt, das YA-SA auf sehr niedrigem Niveau ähnelt.

Tabelle 9: Potenzielle Executives

Neben dem Austausch der Schedulingumgebung durch neue Softwaremodule ist ferner ein Szenario denkbar, indem die Umgebung bzw. ein Teil von ihr durch Hardwareinstanzen ausgetauscht wird. In [Hil98] wurde ein speziell optimierter Hardwarescheduler für den Enhanced Least Laxity First Scheduler ELLF vorgestellt. Aufgabe weiterer Arbeiten ist dessen Implementierung in verschiedenen Executives.

4.4 Die Scheduler

Ein YASA-Scheduler hat die Aufgabe, in Abhängigkeit des Prozess-Satzes und der Schedulingeinstellungen des Systems, den Thread mit der höchsten Priorität auszuwählen. Er ist unabhängig von der CPU und kann für jeden Prozessor einzeln definiert werden. Ein Ziel bei der Entwicklung des Frameworks war, einen Scheduler-Port zu implementie-ren, der unabhängig vom jeweiligen Betriebssystem ist. Aus diesem Grund liegen die Sche-duler alle im Quelltext vor, der so formuliert sein muss, dass er unter allen Systemen kom-piliert werden kann. Erreicht wird das durch die Präprozessormakros. Den Kompilations-vorgang und das Ausgabeformat bestimmen die Executives durch Makefiles. Die Scheduler gliedern sich in mehrere Teile auf, die in Tabelle 10 beschrieben sind. Alle Namensgebungen in den Komponenten der Scheduler unterliegen strengsten Konventionen, um die Quelltextgenerierung zu vereinfachen. Der Name eines Schedulers ist gleich dem Verzeichnisnamen, in dem sich seine Dateien befinden. Dieser Name ist Teil aller weiteren Strukturen und Funktionen. Der zweite Teil der Namen ergibt sich aus der Funktion der Komponente, z.B. edf_schedule(). 6 Die Verfügbarkeit bzw. Existenz von Red-Linux konnte bisher nicht verifiziert werden, da keine Kontakt-aufnahme möglich ist und das Herunterladen der Software an fehlerhaften Links scheitert.


55

Part Beschreibung

Deklarationen Die Deklarationen eines YASA-Schedulers sind in einem Headerfile, das den Namen des Schedulers trägt, festgelegt. Es stellt die Verbin-dung zu den YASA-Includes dar und deklariert die Memberfunktionen des Schedulers für den globalen Namensraum.

Scheduler-Info Struktur

Die Struktur enthält die gebündelten Daten eines Schedulers, die zur Laufzeit erforderlich sind, um Informationen, wie Name und ID zu ermitteln. In ihr sind Zeiger auf Funktionen enthalten, die während des Auswechseln von Schedulern erforderlich sind. Der Prototyp ist grundsätzlich wie folgt definiert. const YASA_SCHEDULER_ATTR edf_attr={…};

Funktionen Ein Scheduler kann bis zu drei Funktionen exportieren. Diese Funkti-onen sind in der Schedulerstruktur definiert:

init() Die Initialisierung des Schedulers erfolgt einmalig vorBeginn des ersten Schedulingdurchlaufs. Der Schedulerhat die Möglichkeit, den Prozess-Satz zu analysieren undeventuell nötige Strukturen aufzubauen, deren Zeiger er inder Schedulerstruktur speichern kann. Der Returnwert dieser Funktion ist der Prioritätstyp, dervon verschiedenen Synchronisationsprotokollen benutztwird.

execute() Die execute()-Funktion wird bei jedem Schedulerlauf auf-gerufen, um den höchst prioren Prozess auszuwählen. DerReturnwert ist ein Zeiger auf den ausgewählten Prozessoder null.

cleanup() Bei einem Wechsel des Schedulers wird die cleanup()-Funktion aufgerufen, um eventuell allozierte Strukturenwieder freizugeben.

Konfigurationsfile Das Konfigurationsfile dient der grafischen Oberfläche als Informati-onsquelle, um die Eigenschaften des Schedulers zu ermitteln. Es han-delt sich um eine XML-Datei. Die unterstützten Attribute sind in An-hang A.5 aufgelistet.

Tabelle 10: Komponenten eines Schedulers

In Abbildung 4.4-1 ist der Prototyp der Scheduling-Funktion edf_schedule() des EDF-Schedulers dargestellt. Der komplette Quelltext ist in Anhand A.3 aufgelistet. Als Argu-mente werden der Funktion ein Zeiger auf die aktuelle Schedulingstruktur zur Referenzie-


56

rung der CPU und ein Zeiger auf die aktuelle Zeit übergeben. Ist der Scheduler in der Lage, einen Thread zur weiteren Bearbeitung auszuwählen, gibt er als Ergebnis einen Zeiger auf den PCB des Threads zurück. In der Adresse von ptime (von Preemptiontime) wird die Zeit gespeichert, zu der der Sche-duler als nächstes aufgerufen werden muss, da dann höher priore Prozesse aktiviert werden. YASA_THREAD* edf_schedule(YASA_SCHEDULER *scheduler, const YASA_TIME *now, YASA_TIME *ptime)

Abbildung 4.4-1: Deklaration der Scheduling-Funktion

In der Schedulerstruktur *scheduler sind Informationen über die Prozesse der aktuellen CPU enthalten. Ein direkter Zugriff ist allerdings nicht erlaubt, da es sich im allg. um eine erweiterte Schedulingstruktur des Betriebssystems handelt und die Namen der Attribute variieren können. Der Zugriff auf die erforderlichen Daten erfolgt indirekt über Präprozes-sor-Makros, z.B. bei Zugriff auf den Prozess-Satz gibt YASA_TASKSET(scheduler) den Zeiger auf den ersten und mittels YASA_NEXT_THREAD(thread) auf den nächsten Thread zurück. Auf diese Weise kann der Scheduler alle Threads nacheinander nach dem höchst prioren durchsuchen, ohne Kenntnis vom Betriebssystem zu haben. Intern verwaltet die lokale Variable newthread die Startadresse des nächsten Threads. Die Nutzung von Präpro-zessor-Makros ergibt im Vergleich zu anderen Verfahren folgende Vorteile: • Minimale Änderung

des Betriebssystems

Es liegt keine Notwendigkeit vor, die Namen von Systemvari-ablen zu ändern oder den Typ der Variablen anzupassen. Die Typsicherheit ist gewährleistet, da derselbe Typ wie in den Systemvariablen verwendet wird.

• Einsparungen Durch die Einsparungen von Mapping-Funktionen wird eine Vielzahl von Sprüngen und Stackoperationen vermieden. Die Prozesskontrollblöcke werden nicht unnötig erweitert.

• Portabilität des Schedulers

Die Verlagerung des Datenzugriffs in die Makros bewirkt eine Portabilität des Schedulersquelltextes.

Nach der Bestimmung von newthread, erfolgt die Berechnung von ptime. Dazu wird eine ähnliche Schleife wie bei der Wahl von newthread durchlaufen, um den Thread zu ermit-teln, der zur Zeit noch suspendiert ist, später aktiviert wird und newthread aufgrund der höheren Priorität verdrängen wird. Auf diese Weise wird ein unnötiges Aufrufen des Sche-dulers bis zu diesem Zeitpunkt verhindert. Sollte dieses Verhalten in der Prozessumgebung nicht erwünscht sein, kann die Eigenschaft in der Scheduling-Struktur abgeschaltet werden. Der Scheduler ermittelt in diesem Fall ptime aus der aktuellen Zeit (now) und dem Schedulertick aus der Schedulerstruktur. Dazu


57

muss das Makro YASA_SETTICKSCHEDULINGTIME() aufgerufen werden, um eventu-ell den Tick-Wert zu korrigieren. Einige Betriebssysteme benötigen diese Korrektur, z.B. RT-Linux um Linux als Idle-Thread auszuführen.

4.5 Projektverwaltung

In YASA können beliebig viele Projekte gleichzeitig in einem Arbeitsbereich (Workspace) verwaltet werden. Dieser Workspace wird als XML-Datei gespeichert, die einen plattfor-munabhängigen Datenaustausch ermöglicht und späteres Lesen bzw. Ändern der Konfigu-rationsdateien mit anderen Editoren gestattet. Das Einlesen erfolgt mittels eines eigenen Parsers. Der Arbeitsbereich beinhaltet neben den Definitionen der Projekte auch den Namen des Autors und speichert das letzte Zugriffsdatum. Für den Arbeitsbereich kann eine Beschrei-bung erstellt werden, die alle Projekte im Überblick erklärt. Die Verwaltung und Verarbeitung eines Projekts teilt sich in drei große Phasen auf, die Konfigurationsphase, die Erzeugungsphase und die Ausführungsphase. Der grundsätzliche Zyklus eines Projekts ist in Abbildung 4.5-1 abgebildet.

Pro

jekt

-Kon

figur

atio

n

Konfigurationsphase Erzeugungsphase Ausführungsphase

Prozesse

MutexSync-

protokolle

Executive

Scheduler

Kernel-Quellen

AusführbaresProjekt

Logfile

Prozess-Quelltexte

Prozess-Attribute

BetriebssystemKernel

Mutex-Attribute

Auswertung/Visualisierung

Kernel-Patch

YASA Support-Funktionen

Abbildung 4.5-1: Zyklus eines YASA-Projekts

In der Konfigurationsphase können in einem Projekt die Grundeinstellungen für alle Ziel-umgebungen vorgenommen werden, z.B. Dauer der Prozessausführung. Weitere Einstel-lungen sind CPT (Calc Preemption Time) und der Timer Tick. CPT legt fest, ob der Sche-duler den nächsten Schedulingzeitpunkt berechnen soll. Der Tick-Wert gibt an, in welchen Zeitabständen der Scheduler aufgerufen werden soll.


58

Für jedes Projekt können, unabhängig von anderen Projekten, eigene Prozess- und Mutex-Sätze definiert werden. Eine Begrenzung der Anzahl existiert nicht. Ein Prozess-Satz ent-hält alle definierten Prozesse inkl. deren festgelegte Eigenschaften wie:

• Name und Beschreibung des Prozesses • Statische Priorität • Deadline & benötigte Zeit • Aktivierungszeiten sowie Ressource-Zugriffe (Ceiling-Berechnung) • Namen für externe Thread-Startfunktionen

Kritische Abschnitte werden in YASA durch binäre Semaphoren (Mutexe) gesichert. Die Definition erfolgt analog zu Prozessen. Mutexe können folgende Eigenschaften besitzen:

• Name und Beschreibung des Mutexes • Verwendetes Synchronisationsprotokoll

Die für einige Scheduler bzw. Synchronisationsprotokolle wichtigen Ceiling bzw. Preemp-tionkonstanten berechnet YASA automatisch aus den Ressource-Zugriffen der Prozesse. In dem Konfigurationsdialog werden für alle Threads, die dieses Mutex nutzen, die Ceiling-Konstanten angezeigt (s. Tabelle 3). Environments beschreiben die Schedulingumgebungen eines Projekts. Sie enthalten den Namen des Executives sowie aller Scheduler. Es kann für jede CPU ein anderer Scheduler gewählt werden. Die Scheduler sind unabhängig voneinander. In jedem Projekt können beliebig viele Environments mit verschiedenen Schedulern einge-richtet werden. Auf diese Weise wird ein Vergleich von gleichen Prozess-Sätzen bzw. Mu-tex-Sätzen mit verschiedenen Schedulern möglich. Um den Entwickler die Konfiguration des Projekts zu vereinfachen, hat er die Möglichkeit, alle wichtigen Einstellungen einmal in dem Projekt-Dialog vorzunehmen. Diese werden automatisch an die Environments weitervererbt. Da die Eigenschaften der Scheduler bzw. der Executives stark voneinander abweichen können, kann nicht garantiert werden, dass Eigenschaften aus der Projekteinstellung im Endsystem wirklich funktionieren. Das kann z.B. passieren, wenn ein Tick von 2.222.222=2,222222 ms eingestellt ist und die Timer-werte der Hardware die Auflösung der YASA-Zeiteinheit nicht unterstützen oder überhaupt kein periodischer Betrieb möglich ist. Daher wird die Projekteigenschaft vorerst an das E-xecutive vererbt. Unterstützt das Executive die Konfiguration der Eigenschaft nicht, wird dessen Grundeinstellung übernommen. Anderenfalls wird die Eigenschaft, wenn erforder-lich, korrigiert und an die einzelnen Scheduler weitervererbt. Diese kontrollieren ebenfalls, ob sie die Eigenschaft unterstützen und verhalten sich äquivalent. Eine übersichtliche Ab-bildung des Vererbungsvorgangs ist in Anhang A.10 dargestellt.


59

4.6 Konventionen

Um die Erweiterbarkeit des Entwicklungsframeworks zu gewährleisten, wurde eine strenge Verzeichnishierarchie definiert. Jede einzelne Komponente wird in einem eigenen Unter-verzeichnis abgelegt, um Überschneidungen mit anderen zu verhindern und den Austausch mit neueren Versionen zu erleichtern. Um die Plattformunabhängigkeit und den Austausch von Daten zwischen verschiedenen Computersystemen zu gewährleisten, werden nach Möglichkeit relative Pfade benutzt. Die Trennung zwischen Verzeichnissen erfolgt grundsätzlich durch einen Slash „/“. Systeme, die M$ Windows benutzen, sind aus diesem Grund auf die UNIX-Umgebung cygwin an-gewiesen [Red02]. Für jedes der Projekte in einem Workspace wird relativ zum Speicherort dieser Datei ein Unterverzeichnis mit dem Namen des Projekts erzeugt. In diesem Ver-zeichnis können projekt-spezifische Daten abgelegt werden. Die Definition von Environ-ments innerhalb eines Projekts bewirkt die Erzeugung eines weiteren Unterverzeichnisses (Arbeitsverzeichnis) mit dessen Namen. In dieses Arbeitsverzeichnis werden die generier-ten Quelltexte und Startskripte geschrieben. Durch die konsequente Trennung der Executi-ves in verschiedene Verzeichnisse können mehrere Executive-Instanzen vom gleichen Typ parallel bearbeitet und später ausgewertet werden.

4.7 Quelltextgenerierung

Die Verwendung verschiedener Executives erfordert eine einheitliche Vorgehensweise, wie die Projektdaten den Executives übergeben werden können. Vor dem Start der Projektan-wendungen werden Quelltexte generiert, die die Einstellungen des Projekts, wie z.B. des Prozess-Satzes und der ausgewählten Scheduler enthalten. Die Verwendung eigener Quell-texte hat gegenüber proprietären Dateiformaten entscheidende Vorteile:

• C-Sourcecode ist ein plattformunabhängiges Dateiformat und kann von anderen Entwicklungssystemen ebenfalls benutzt werden.

• Erweiterbarkeit für YASA-spezifische oder Anwenderdaten ist gesichert • Die Typprüfung übernimmt der Compiler. Eine Änderung des Datentyps, z.B. der

Datenbreite der Deadline, wird während der Kompilierung automatisch korrigiert bzw. als Fehler angezeigt.

• Eine vom Executive abhängige Quelltexterstellung ist möglich, d.h. nur wirklich benötigte Daten werden geschrieben.

• Höhere Transparenz und einfachere Einarbeitung in Projekte und Framework • Kommentierung der generierten Daten mit Beschreibungen der Objekte • Optimierung auf Hardware möglich


60

Die Erzeugung der Quelltexte erstreckt sich über mehrere Dateien, um die Projekthierarchie einzuhalten und Geschwindigkeitsvorteile bei erneuter Kompilierung zu erhalten. In Tabelle 11 sind die erzeugten Dateien und deren Bedeutung aufgelistet. Während der Quell-textgenerierung überprüft YASA, ob sich der Inhalt der Dateien geändert hat. Ist das der Fall, wird das Datum aktualisiert, anderenfalls wird das Datum auf das des letzten Schreib-zugriffs zurückgesetzt. Die Verwendung des Programmpakets make garantiert, dass nur Quelltexte übersetzt werden, die wirklich aktualisiert werden müssen. Auf diese Weise wird die Kompilierungszeit nach dem ersten Aufruf deutlich minimiert. Ohne die Datumskorrek-tur müssten bei den meisten Executives vor jedem Start die Betriebssystemkernel übersetzt werden.

Datei Beschreibung yasa_projectconfig.h Diese Headerdatei wird von den YASA-Komponenten eingele-

sen, um die aktuelle Projekteinstellung zu laden. Sie lädt ihrer-seits die anderen drei Headerdateien ein. Somit ist der Sourcecode der YASA-Komponenten unabhängig von eventuell später hinzugefügten Headerdateien.

yasa_projectexecutive.h Diese Datei enthält die Einstellungen für das aktuelle Executive, die zur Kompilierung benötigt werden. Hier wird festgelegt, welche Synchronisationsprotokolle übersetzt werden und wie groß der Loggingpuffer ist (s. Kap. 4.3.3)

yasa_projectschedulers.h Diese Datei enthält die Einstellungen für die ausgewählten Scheduler, die zur Kompilierung benötigt werden. Zur Zeit ist diese Headerdatei ein Platzhalter.

yasa_projecttaskset.c In die Datei werden die Informationen für den Start der Projektanwendung geschrieben, z.B.

• Deklaration der Thread-Funktionen (init, execute, cleanup) • Deklaration der Info-Strukturen der Scheduler • Definition der Thread- und Mutex-Attributstrukturen, die

Eigenschaften wie Deadlines und Ceilingkonstanten enthal-ten

• Definition der Executive-Attributstruktur, die Informatio-nen über weitere Attributstrukturen (Threads, Mutexe) und alle Starteinstellungen enthält. Dazu zählen Laufzeiteinstel-lungen wie Endzeit, CPT und Timer Tick. Diese Struktur wird an die Startumgebung des Executives übergeben.


61

Datei Beschreibung yasa_projecttaskset.h Hier werden die aktuellen Eigenschaften des Thread-Satzes ge-

speichert. Dazu zählen:

• Synchronisationsoffset • Endzeit der Simulation • Mapping von Attribut-Strukturen, um Executives

Zugriff auf Projektstrukturen zu ermöglichen • Deklaration der Mutex-Identifier

cleanup Das Skript cleanup setzt die YASA-Umgebungsvariablen des Projekts und ruft das Skript runproject auf, um alle temporären Dateien im Arbeitsverzeichnis zu löschen.

runit Runit setzt ebenfalls die YASA-Umgebungsvariablen und star-tet den Kompilierungsvorgang mit anschließendem Lauf der Projektanwendung. Die Protokolldaten werden in die Datei log-file geschrieben.

uninstall Das Skript uninstall verhält sich wie cleanup, nur mit dem Un-terschied, dass der veränderte Kernel des Betriebssystems ent-fernt und durch den originalen ersetzt wird.

Tabelle 11: Erzeugte Projekt-Dateien

Die Quelltextgenerierung geht einher mit dem Test, ob alle Komponenten die eingestellten Eigenschaften verarbeiten können. Ist das nicht der Fall, werden die Eigenschaften entspre-chend korrigiert und eine Warnmeldung über das Ausgabefenster ausgegeben. Die Ver-wendung eines Prozess-Satzes, der mehrere Prozessoren benötigt, aber mit einem Executive zusammenarbeiten soll, das nur eine CPU unterstützt, erzwingt eine Korrektur der CPU-Zuweisungen. In diesem Fall würden alle Prozesse auf einer CPU laufen. Eine ent-sprechende Meldung wird ausgegeben. Neben der Erzeugung der in Tabelle 11 gezeigten Dateien werden nach der Generierung noch die Dateien aus dem Ordner $YASA/$YASA_EXECUTIVE/files in das aktuelle Ar-beitsverzeichnis kopiert. Hierbei handelt es sich i.d.R. um ein Makefile und das Startskript runproject. Das Makefile enthält die Erstellungsregeln und Abhängigkeiten zur Kompilierung der ge-nerierten Quelldateien und des Executives. Das Skript runproject wird von der Entwick-lungsumgebung indirekt über eines der drei erzeugten Skripte runit, cleanup bzw. uninstall aufgerufen. Ein zusätzlicher Parameter kennzeichnet die Aktion, die das Skript ausführen soll.


62

Der Executive-Entwickler hat somit die Möglichkeit, seine Kompilierungsumgebung kom-plett selbst zu konfigurieren. Durch entsprechende Skripte sind auch Prozessanwendungen remote startbar, z.B. auf Eingebetteten System. Die Kompilierung könnte per Crosscompi-ler und die Übertragung des entsprechenden Verzeichnisses per FTP bzw. NFS erfolgen.

4.8 Ausführung einer Projektanwendung

Nach der Generierung der Quelltexte und Skripte ist das Arbeitverzeichnis vollständig für die Ausführung des aktuellen Projekts vorbereitet. Der Start erfolgt durch Aufruf des Skrip-tes runit. In Abbildung 4.8-1 ist ein automatisch erzeugtes runit-Skript gezeigt, das unter RT-Linux lauffähig ist. Die Umgebungvariablen sind von entscheidender Bedeutung, da durch sie die Pfade der einzelnen Komponenten gesetzt werden. Diese Variablen können in Makefiles ausgewertet werden, wodurch eine Anpassung der Makefiles an die Projekte vermieden wird. Spätere Updates der YASA-Software werden erleichtert. #!/bin/sh

export YASA="/cygdrive/G/Hiwi/Diplom/Sources/yasa"

export YASA_PROJECTDIR="/cygdrive/G/Hiwi/Diplom/Sources/yasa/projects/multiplemutex/workdir"

export YASA_PROJECTFILENAME="RT_Linux__Prio_"

export YASA_WORKDIR="/cygdrive/G/Hiwi/Diplom/Sources/yasa/projects/multiplemutex/workdir/RT_Linux__Prio_"

export YASA_EXECUTIVE="rtlinux"

export YASA_EXECUTIVEDIR="/cygdrive/G/Hiwi/Diplom/Sources/yasa/executives/rtlinux"

export YASA_LOGFILE="/cygdrive/G/Hiwi/Diplom/Sources/yasa/projects/multiplemutex/workdir/RT_Linux__Prio_/logfile"

export YASA_SCHEDULERS="prio"

export YASA_CFLAGS="-D__YASA__ -D__KERNEL -D__MODULE__ -D__YASA__ -Wall -Wstrict-prototypes"

export YASA_CFILES="../testproject_thread1.c ../testproject_thread2.c"

./runproject simulate

cat "logfile" && echo "Press Ctrl+d to exit" && cat Abbildung 4.8-1: Angepasstes runit-Skript

Nach dem Start von runit beginnt die Kompilierung, falls nötig. Dabei entstehen temporäre Dateien, die nur im Arbeitsverzeichnis zwischengelagert werden dürfen. Im Anschluss wird das übersetzte Projekt gestartet und läuft bis zur Endzeit, die in den Executive-Attributen definiert ist. Danach erfolgt die Ausgabe der Protokolldaten in die Datei logfile.

4.9 Auswertung einer Anwendung

Nach der Ausführung des Projekts und dem erfolgreichen Schreiben des Logfiles beendet sich das runit-Skript und kehrt zur Entwicklungsumgebung zurück. Dort wird das Logfile gelesen und interpretiert. Im Anschluss kann eine Auswertung in grafischer Form durch Zeitdiagramme und in tabellarischer Form erfolgen. Beide Auswertungsformen besitzen


63

verschiedenen Ansichten und Vergleichsmöglichkeiten. YASA beherrscht vier wesentli-chen Darstellungstypen:

• Thread-Ordnung • Mutex-Ordnung • CPU-Ordnung • Environment-Ordnung

Die Thread-Ordnung bezeichnet die klassische Darstellungsform, in der alle Threads inkl. eines eventuell nicht existenten Leerlauf-Threads einer einzigen Projektausführung in ei-nem Diagramm angezeigt werden. Besonders geeignet ist diese Darstellung, um einen Ü-berblick zu erhalten, wann welcher Thread die CPU besaß und welche Ressource gesetzt bzw. freigegeben wurde. Diese Darstellungsart zeigt als einzige mögliche Jitter- und Excluded-Zeiten an. Dem Prozess-Satz wird ein Systemthread hinzugefügt, der die Schedu-lingzeiten repräsentiert und durch geeignete Symbole einen Taskwechsel kennzeichnet. Die Mutexanordnung zeigt das Setzen bzw. Freigeben von Mutexen in einer Projektausfüh-rung an. Diese Darstellungsart ist günstig, um Verweilzeiten in kritischen Abschnitten zu erfassen und einen Überblick zu erhalten, wann welches Mutex gesetzt bzw. nicht gesetzt wurde. Die CPU-Ordnung zeigt den Schedulingverlauf auf einem Prozessor an. Zu empfehlen ist diese Betrachtungsweise, um einen Eindruck zu erhalten, wie das Verhältnis zwischen Threads und System ist. Zudem erhält man einen Überblick über die Auslastung bei Multi-prozessoranwendungen. Diese drei Ordnungen beziehen sich grundsätzlich auf eine Projektausführung. Sie können zu deren Optimierung benutzt werden. Allerdings lässt sich mit ihnen kein Vergleich von verschiedenen Environments bewerkstelligen. Um diesen Nachteil zu beseitigen, wurde für jeden der drei Objekttypen eine Environment-Ordnung entwickelt. Die Darstellung erfor-dert die Erzeugung von Zeitdiagrammen für jeden Thread, jedes Mutex und jede CPU in Abhängigkeit vom Environment. In einem Thread-Zeitdiagramm in Environment-Ordnung kann das Schedulingverhalten von Threadi in den verschiedenen Umgebungen verglichen werden. Ein ausführliches Beispiel zu den verschiedenen Darstellungsordnungen ist in An-hang A.11 dargelegt. Neben der grafischen Ausgabe existiert eine Darstellung der Ergebnisse in tabellarischer Form. Die Inhalte der Tabellen werden nicht durch theoretische Berechnungen, sondern durch Auswertung der Logfiles bestimmt. Die Tabellen werden nach dem selben Schema aufgebaut wie die Zeitdiagramme. Es gibt die Möglichkeit, folgende Tabellen pro Envi-ronment zu erzeugen:


64

Objekt Beschreibung Threads Alle Threads eines Environments sind in einer Tabelle dargestellt.

Derzeit werden 34 Eigenschaften der Threads aufgelistet. Darunter sind Id, Periode, Deadline, Priorität, Unterbrechungen, verpasste bzw. eingehaltene Deadlines, min./max. Berechnungszeiten, Auslas-tung, Jitterzeiten, gesetzte Mutexe u.v.m.

Mutexe Die Mutexe des Environments werden in einer Tabelle dargestellt. Die 9 Eigenschaften umfassen Werte für Anzahl der gesetzten bzw. freigegebenen Mutexe und min./max. Verweilzeiten in kritischen Abschnitten.

CPU Die CPU-Tabelle enthält alle Informationen zu den benutzten Pro-zessoren des Environments. Sie enthält 32 Eintragungen wie Name des Schedulers, Anzahl der verpassten Deadlines, Threadwechsel, Leerlaufzeiten, Scheduleraufrufe, Schedulingdauer u.a.

Zusammenfassung Die Zusammenfassung (Summary) enthält 33 statistische Angaben über das gesamte Environment, wie z.B. Anzahl der CPUs, verpass-te/erreichte Deadlines, gestartete Threads, YASA-Version, Taskwechsel zwischen Prozessoren, Unterbrechungen u.v.m.

Tabelle 12: Tabellentypen eines Environments bei der Projektauswertung

Alle Tabellen in YASA können unabhängig vom Inhaltstyp (Zahlen, Text) horizontal und vertikal sortiert werden. Dadurch können auch bei größeren Prozess-Sätzen schnell min. und max. Werte herausgefiltert werden. Die Sortierung der Tabellen wird durch Iteratoren vorgenommen [Blu00]. Die Betrachtung der statistischen Daten in den einzelnen Environment-Tabellen (Tabelle 12) ist für einen Vergleich zwischen Environments nicht geeignet. Daher wurde wie bei den Zeitdiagrammen eine Environment-Ordnung für die Tabellendarstellung entwickelt. Diese Ordnung ermöglicht die Erzeugung von Tabellen, die ein Objekt (Thread, Mutex, CPU) in Abhängigkeit der definierten Environments eines Projekts darstellt. Eine theoretische Analyse nach Ausführung eines Projekts ist derzeit nicht implementiert, sollte aber Anregung für weiterführende Arbeiten sein.

4.10 Geschwindigkeitsaspekte

Bei der Entwicklung der Executives wurde darauf geachtet, die Abarbeitungsgeschwindig-keit der Schedulingumgebung möglichst konstant zu halten. Das wird z.B. durch die Ver-wendung der Präprozessor-Makros bei Patch des Betriebssystems erreicht, wodurch viele


65

Funktionssprünge vermieden werden. Der Patchvorgang bezieht sich in der Regel auf zeit-unkritische Funktionen wie Initialisierungsroutinen. Die zeitkritischen Funktionen wie der Kern der Schedulingumgebung wurden minimal verändert, wogegen der Wechsel des Schedulers starken Einfluss haben kann (s. Tabelle 13). Alle zusätzlichen Eigenschaften wie der Logging-Mechanismus sind auf Geschwindigkeit optimiert und können über Compiler-Schalter ausgeblendet werden. In Tabelle 13 sind die durchschnittlichen Zeitwerte für einen Schedulinglauf eines Prozess-Satzes mit 16 Threads unter verschiedenen Schedulern dargestellt. Als Vergleichswert ist zusätzlich die Dauer eines Hardwareschedulers in einem Virtex 1000 FPGA gezeigt [Blu02]. Anhand des fast 30mal schnelleren Coprozessors wird deutlich, welches Potenzial in einem Coprozessor liegt. Die Werte können allerdings nur Anhaltspunkte sein, da eine genaue Zeitmessung mittels Software nicht möglich.

Prioritätsbasiert ELLF Hardware-Coprozessor (ELLF) 27 µs 43 µs 1,5 µs

Tabelle 13: Geschwindigkeitsvergleich einiger Scheduler

4.11 Einsatzgebiete

Für den Einsatz des Entwicklungsframeworks bieten sich aufgrund der umfangreichen Konfigurationsmöglichkeiten und der offenen Struktur diverse Gebiete an. In Tabelle 14 sind einige beschrieben:

Einsatzgebiet Beschreibung Erstellung von Anwendungen für verschiedene Zielsysteme

Es besteht die Möglichkeit, mit YASA Anwendungen zu entwickeln, die auf verschiedenen Betriebssystemen bzw. Zielumgebungen funktionieren. Dazu ist allerdings der direkte Zugriff auf nicht portable Betriebssystem-Funktionen/Strukturen zu vermeiden.

Optimierung des Scheduling-verhaltens realer Prozessan-wendungen

Die Protokollierung des Schedulingverhaltens ermöglicht die Analyse und Optimierung des Schedulingverhaltens einer Anwendung, z.B. durch Auswahl eines geeigneteren Schedulers.


66

Einsatzgebiet Beschreibung Entwicklung neuer Scheduler Für die Entwicklung neuer Scheduler ist YASA prädesti-

niert, da die Entwicklung off-line mit einem Simulator erfolgen kann. Der Einsatz des Schedulers in Zielsystemen ist im Anschluss ohne größere Probleme möglich (Rapid-Prototyping).

Theoretische Ausbildung Ein weiteres Einsatzgebiet ist gekennzeichnet durch den Einsatz in Schule und Lehre. Nachwuchswissenschaftlern können die theoretischen Grundlagen an Beispielen de-monstriert werden. Besonders vorteilhaft sind die umfang-reichen grafischen Auswertungsmöglichkeiten, die den Sachverhalt für Einsteiger verständlich darlegen.

Fehlersuche in Programmen YASA eignet sich hervorragend für die Fehlersuche in Programmen. So ist es möglich, aus dem Scheduling-verhalten diverse Probleme zu erkennen, die ohne YASA kaum oder gar nicht zu erkennen sind: • Ursachen von Deadlocks • Erneutes Setzen bzw. Freigeben nicht gelockter

Mutexe • Trashing des Schedulers • Prioritäteninversionen

Tabelle 14: Einsatzgebiete von YASA

5. Programmierung des Front-Ends

67


5.1 Einleitung

Die grafische Benutzeroberfläche stellt das Bindeglied zwischen dem Entwicklungsframe-work und dem Benutzer her. Sie wurde im Gegensatz zu den meisten Schedulern und Exe-cutives komplett objekt-orientiert in C++ entwickelt. Die Entwicklung erfolgte streng ange-lehnt an die Ziele aus Kapitel 1.3. Bei der Entwicklung von objekt-orientierter Software bieten sich Klassenbibliotheken be-sonders an. Sie enthalten vordefinierte Basisklassen, die von Anwendungen genutzt und ergänzt werden können. Die Wahl der richtigen Klassenbibliothek ist entscheidend für den Erfolg eines Software-produkts. Die folgenden Punkte stellen die wichtigsten Entscheidungskriterien dar:

• Portabilität Um das Ziel der Plattformunabhängigkeit von YASA in Zu-sammenarbeit mit einer Klassenbibliothek zu gewährleisten, muss diese portabel sein. Die Basisklassen und deren Schnitt-stellen müssen so abstrahiert sein, dass ein Betriebssystem-wechsel möglich ist. Anderenfalls wäre eine Anpassung von YASA an die Bibliothek auf jedem neuen Betriebssystem nötig.

• Verfügbarkeit Es reicht nicht aus, wenn die Klassenbibliothek portabel ist. Sie muss auf dem Zielbetriebssystemen auch verfügbar sein. Ferner muss sichergestellt sein, dass die Klassenbibliothek vom Her-steller gewartet und gepflegt wird.

• Preis und Lizenz-bedingungen

Der Preis für Klassenbibliotheken variiert sehr stark abhängig von der kommerziellen Nutzung. Preise ab 1500$ für universi-täre Projekte und bis zu 15000$ für kommerzielle Produkte sind durchaus möglich. Die Lizenzbedingungen spielen eine nicht geringe Rolle, da sie teilweise die spätere kommerzielle Nut-zung ausschließen.

• Funktionsumfang Der Funktionsumfang sollte sich nicht nur auf Gebiete be-schränken, die im Entwicklungsstadium der Software benötigt werden. Eine spätere Erweiterung des Projekts sollte ohne Probleme zu bewerkstelligen sind.

• Dokumentation und Beispiele

Eine umfangreiche und gut strukturierte Dokumentation ist zwingend erforderlich, um die Einarbeitungszeit auf ein Mini-mum zu reduzieren. Dafür sind aussagekräftige Beispiele nötig.


68

5.2 Die Klassenbibliothek Qt

Nach Abwägung der Kriterien wurde die Qt-Klassenbibliothek von Trolltech ausgewählt. Sie stellt gegenüber allen anderen Kandidaten (MFC, GTK, StarView) den besten Kom-promiss dar. Qt ist plattformunabhängig und unterstützt die wichtigsten Betriebssysteme wie Windows, UNIX/X11 mitsamt seinen Derivaten, Mac-OS X und eingebettete Systeme. Die Bibliothek zeichnet sie sich durch ein exzellentes Klassen-Design und sehr nützliche Mechanismen aus, die die anderen Toolkits nicht bzw. nur teilweise haben:

Merkmal Beschreibung Signal-Slot Mechanismus

Slots sind Memberfunktionen einer Klasse, die mit einem oder mehreren Signalen verknüpft werden können. Ein Signal kann ebenfalls mit einem oder mehreren Slots verbunden werden. Es kann durch einen Aufruf ausgelöst werden. Dabei spielt es keine Rolle, ob und wie viele Slots an das Signal geknüpft sind. Mit Hil-fe dieses Mechanismus’ kann man komplette Datenstrukturen ü-berwachen.

Übersetzungen Qt verwaltet intern alle Zeichenketten (Strings) als UNICODE (16 Bit) und ist damit in der Lage, alle bekannten Sprachen in Strings zu kodieren. Die Übersetzung eines Programms in andere Spra-chen zur Laufzeit erfolgt automatisch über interne Klassen.

Datenbank-unterstützung

Für die Weiterverarbeitung von Daten stehen verschiedene Schnittstellen zur Verfügung, u.a. eine SQL-Datenbankanbindung.

Timer-Mechanismen Die Unterstützung von Timern unterliegt in vielen Betriebssyste-men Beschränkungen. Trotz der Limitierungen kann Qt auf allen Betriebssystemen beliebig viele Timer ausführen.

Events und Eventfil-ter

In grafischen Oberflächen werden bei unterschiedlichsten Aktio-nen Ereignisse (Events) ausgelöst. Die Eventfilter sortieren nur die relevanten Events heraus und schonen damit Ressourcen.

Konfigurierbare Fenster

Alle Fenster, Knöpfe und Rahmen können beliebig in der Größe und im Aussehen geändert werden. Es können eigene Stile defi-niert werden, die das Aussehen festlegen. Die Gestaltung der Bedienelemente passt sich, im Gegensatz zu JAVA-Programmen, automatisch dem Betriebssystem an.

Objekt Eigenschaften Alle von QObject abgeleiteten Klassen können eigene Property- Attribute definieren. Das sind Membervariablen, die neben dem Datum auch Statusinformationen über den Zustand der Variable liefern, z.B. ob die Variable bereits gesetzt wurde.

Abbildung 5.2-1: Herausragende Eigenschaften von Qt


69

Qt wurde ursprünglich als reine Bibliothek zur Programmierung grafischer Benutzerober-flächen konzipiert. Mit der Zeit entwickelte sie sich zu einer ausgereiften und leistungs-fähigen Klassenbibliothek. Qt besitzt eine sehr gut aufbereitete Dokumentation und bietet umfangreiche Foren sowie Mailinglisten zur Problemlösung an. Als Nachteil erweist sich der enorm hohe Preis für kommerzielle Produkte von mind. 1500$. Für Freewareentwickler gibt es freie Versionen für X11 und Windows.

5.2.1 MOC – Der Metacompiler

QObject ist die Basisklasse der meisten Klassen in der Qt-Klassenbibliothek. Sie stellt den Signal-Slot Mechanismus, Übersetzungen, Event-Filter und Objekt-Eigenschaften zur Ver-fügung. Um Funktionen wie Slots von herkömmlichen Methoden in den Klassendeklaratio-nen zu unterscheiden, wurden zusätzliche Klassenattribute (public slots, protected slots, private slots, signals) definiert. Da ein herkömmlicher C++ Compiler diese Syntax nicht kennt, läuft vor dem Kompilieren ein Pre-Compiler, der moc - auch Meta Object Compiler - und erzeugt daraus automatisch zusätzlichen Quelltext, der benötigt wird, um das Pro-gramm vollständig zu übersetzen. Diese C++ Quelltexte werden für jede Klasse in Qt er-zeugt, die von QObject abgeleitet sind und das Makro Q_OBJECT benutzen.

5.2.2 Der Signal-Slot Mechanismus

Die Entwicklung objekt-orientierter Software ist nur sinnvoll bei Verwendung von Ent-wurfsmustern (Design-Pattern) [Gam96]. Design-Pattern definieren sich vorwiegend aus bestehenden Referenzlösungen für Probleme bei der Softwareentwicklung, die meist erst mit großer Erfahrung und durch viele Versuche gefunden werden. Sie garantieren eine hohe Wiederverwendbarkeit und Flexibilität der Software. In Qt sind an mehreren Stellen Design-Pattern umgesetzt worden. Eine Implementierung betrifft das Beobachter-Muster (Observer-Pattern). Das Observer-Pattern dient dem Beob-achten zwischen Objekten in einer 1-zu-n Abhängigkeit. Eine Änderung des Objekts führt zur Benachrichtigung aller abhängigen Objekte mit dem Ziel der Aktualisierung. Der in Qt implementierte Signal-Slot Mechanismus ist nach dem Beobachter-Muster auf-gebaut. Beliebige Objekte, die von QObject abgeleitet sind, können sich mit einem Objekt verbinden und automatisch benachrichtigen lassen, wenn dieses Objekt ein Signal sendet, dass eine Aktualisierung anzeigt. Besonders ausgefeilt ist die Implementierung der Objekt-Registrierung durch einen simplen Aufruf der Funktion connect() gelöst. Das Entfernen der Registrierung erfolgt automatisch durch die Destruktoren der Objekte.


70

In YASA wird der Signal-Slot Mechanismus exzessiv benutzt, um die Datenkonsistenz zwischen den Objekten zu bewahren (s. Kap. 5.3.2). In Abbildung 5.2-2 ist eine typische Anwendung für den Signal-Slot Mechanismus unter Benutzung des Beobachter-Musters dargestellt. Ein Subjekt enthält drei Attribute (a,b,c). An dieses Subjekt haben sich 3 Beobachter angeschlossen, die den Inhalt des Objekts auf verschiedene Weise darstellen. Sie erhalten die Daten über eine Abfrage, üblicherweise Memberfunktionen des Subjekts. Änderungen werden ebenfalls über Memberfunktionen realisiert, um die Datenkapselung einzuhalten. In diesem Beispiel könnte die Auswahl einer anderen Zeile in der Tabelle eine Änderung der Daten des Subjekts auslösen. Übernimmt das Subjekt die Daten, sendet es an alle Beobachter die Nachricht, dass die Daten verändert wurden und damit inkonsistent sind. Diese müssen eine erneute Datenabfrage starten, um ihre Darstellungen zu aktualisieren.

Tabelle Balkendiagramm Kreisdiagramm

20 %50 %

30 %x

zy

a

20%20%

b

70%50%20% 60%

10%30%20%

c

a b c

Subjekt

a=50b=30c=20

DatenanfrageÄnderungVeränderungs-benachrichtigung

Abbildung 5.2-2: Signal-Slot Mechanismus

5.2.3 Widgets

Die einfache und flexible Erstellung von grafischen Oberflächen ist eines der Hauptziele bei der Entwicklung von Qt gewesen. Zu diesem Zweck wurde eine Basisklasse QWidget definiert, die alle wichtigen Basisfunktionalitäten von grafischen Objekten bereitstellt. Ein Widget ist ein Rahmen für ein abgeleitetes Objekt, das die endgültige Funktionalität ent-hält. Abgeleitete Objekte können z.B. einfache Knöpfe (QButton), Windows (QMainWin-dow) und Eingabefelder (QLineEdit) sein, aber auch durchaus komplexe Gebilde wie Text-editoren (QTextEdit) und HTML-Browser (QTextBrowser). Ein Widget stellt demnach die Trennung zwischen Windowmanagement und Inhalt der Objekte dar.


71

Widgets können in Rahmen (QFrame) angeordnet werden. Durch geschicktes Erstellen von Widgets in horizontalen (QHBox) bzw. vertikalen Rahmen (QVBox) können alle Objekte, die von QWidget abgeleitet sind, in einem Fenster dargestellt werden. Die endgültige exak-te Anordnung übernimmt die Klassenbibliothek zur Laufzeit. Sie berechnet anhand ver-schiedener Einflussfaktoren die optimalen Größen und Positionen der Widgets. Jede Ände-rung der Fenstergröße führt intern zu einer Neuausrichtung aller Widgets. Die Anwendung muss nicht eingreifen. Die Erzeugung der Oberfläche beschränkt sich auf das Anlegen der Objekt-Instanzen und die Übergabe von Zeigern auf das übergeordnete Widget als Parame-ter des Konstruktors. In Abbildung 5.2-3 ist ein einfaches Fenster zur Illustration dargestellt. Zu Beginn wird das Fenster erstellt. Im Anschluss wird in diesem Window ein Gruppenrahmen angelegt, der die eingeschlossenen Widgets mit einem Rahmen und der Überschrift „Personendaten“ umgibt. In dieser Gruppe wird eine horizontale Box (QHBox) kreiert. Diese Box teilt sich in zwei vertikale Boxen (QVBox) auf. In die linke Box werden die 3 Eingabefeldbeschrei-bungen (Name, Vorname, Beschreibung) abgelegt. In der rechten Box liegen die drei Ein-gabefelder. Die letztendliche Anordnung der Widgets übernimmt Qt.

Eingabemaske?

Personendaten

Blumenthal

Jan

Student an der Universität Rostock,Interessen sind Volleyball und Musik

Name

Vorname

Beschreibung

Abbildung 5.2-3: Aufbau eines Fensters mit Widgets

5.2.4 Der Translator

Qt ist in der Lage, Programme komplett zu lokalisieren, d.h. die Sprache anzupassen. Das Prinzip ist sehr einfach. Alle Zeichenketten in einem Programm werden indirekt über ein Makro [tr()] an die entsprechenden Variablen zugewiesen. Das Makro expandiert während der Kompilierung zu einem Funktionsaufruf. Die Funktion ermittelt für diese Zeichenkette das lokalisierte Pendant und weist sie den Variablen im Programm zu. Zur Extrahierung der benötigten Zeichenketten aus dem Quelltext wird das Programm lup-date benutzt. Es durchsucht den kompletten Quelltext nach dem tr()-Makro und schreibt die Zeichenketten in eine XML-Datei. Nach der Übersetzung wird durch das Übersetzungspro-gramm linguist ein Katalog erstellt, der in YASA geladen und ausgewertet wird.


72

5.3 Vorstellung wichtiger Klassen

Die Arbeit mit verschiedenen Betriebssystemen, Compilern und demzufolge unterschiedli-chen Includes zwingt zu einer eigenen Namenskonvention, um höchst ärgerliche Doppelbelegungen von Namen zu verhindern. In Qt beginnt jeder Klassenname mit „Q“. YASA lehnt sich diesem Vorbild an und hat den Präfix „Y“ definiert. Die Voranstellung von Buchstaben minimiert das Risiko der Doppeldeklaration von Funktionen deutlich und erhöht die Lesbarkeit des Quelltextes, da sofort eine Assoziierung des Quelltextkontextes mit der Klassenbibliothek möglich ist. In dieser Arbeit können nur die wichtigsten Klassen beschrieben werden, da die Anzahl inzwischen auf 261 angewachsen ist. Um eine umfassende Dokumentation zu gewährleis-ten, wurde in YASA frühzeitig mit der Entwicklung einer Online-Dokumentation begon-nen. Die Dokumentation wird automatisch bei Kompilierung des Projekts aus den Quell-texten erzeugt. Auf diese Weise ist sie immer aktuell. Es besteht keine Gefahr der zwei-gleisigen Wartung. Die Generierung der Dokumentation erfolgt durch das frei verfügbare Programm Doxygen [Hee02]. Es wertet die in einer Konfigurationsdatei angegebenen Quelltexte mit einem ei-genen C++ Parser aus und generiert eine komplette Beschreibung aller Klassen. Um zu-sätzliche Hinweise des Programmierers mit aufnehmen zu können, hat Doxygen zusätzliche Tags deklariert, die der Entwickler in C++ Kommentaren ablegen kann. Das Programm ist in der Lage, das Dokument in HTML, Latex, RTF und als Unix Manual-Page zu erstellen. Zusätzlich zur Beschreibung kann Doxygen das externe Programm Graphviz zur Generie-rung von Vererbungs- und Kompositionsdiagrammen ausführen [ATT02]. In Anhang A.12 sind einige von Graphviz erzeugte Diagramme dargestellt, auf die in den nächsten Kapiteln eingegangen wird.

5.3.1 YObject

Das YObject ist direkt von QObject abgeleitet. Es hat die Aufgabe, das QObject vor den YASA-Klassen zu kapseln. Auf diese Weise können jedem Objekt Basisfunktionalitäten hinzugefügt werden. Ferner ist es möglich, unterschiedliche Qt-Versionen durch eigene Memberfunktionen auszugleichen. YObject bildet die Basisklasse aller in die Projektver-waltung involvierten Klassen. Die Vererbungshierarchie ist in Abbildung A-16 gezeigt. Jedes YObject beinhaltet Signale und Slots, um die abgeleiteten Instanzen über Datenände-rungen zu informieren bzw. um an assoziierte Datenobjekte ohne genauere Kenntnis des abgeleiteten Typs gekoppelt werden zu können. Die Instanzen von YObject dienen als Datenspeicher, ähnlich dem Subjekt in Abbildung 5.2-2. Es besitzt gegenüber dem QObject Funktionen zum Setzen eines Objektnamens und


73

einer textbasierten Beschreibung des Objekts (Description). Die entscheidenden Attribute werden jeweils in den abgeleiteten Klassen angelegt. Eine abgeleitete Klasse bildet z.B. YProject, die alle Daten zu einem Projekt in einem Workspace des Entwicklungsframe-works enthält (s. Abbildung A-18). Das YObject bildet weiterhin eine Schnittstelle zur Pro-grammkonfiguration, sodass Eigenschaften und Inhalte in Konfigurationsdateien gespei-chert werden können.

«Signal»-ObjectUpdated()

-Name : Zeichenkette-Beschreibung : Zeichenkette

YObject

+Activate() : signed int

YActions

* 1

-Tasks : YTaskYProject

+Activate() : signed int

YProjectActions

Abbildung 5.3-1: Assoziation zwischen YObject und YActions

Jedes YObject hat eine Beziehung (Assoziation) zu einer Klasse YActions (s. Abbildung 5.3-1). YActions agiert als Basisklasse und hat die Aufgabe, die unterschiedliche Verarbei-tung der YObjects zu gewährleisten. Wenn z.B. der Menueintrag Execute() ausgewählt wurde, wird das aktuelle YObject, in diesem Fall YProject ermittelt. Die Assoziation zwi-schen den Klassen erlaubt den Zugriff auf die Klasse YActions. Es wird Activate() des ak-tuellen Projekts aufgerufen. Durch die Polymorphie von Activate() wird die Memberfunk-tion Activate() von YProjectActions aufgerufen. Auf diese Weise wird eine Trennung zwi-schen Datenobjekt (YProject) und Ausführung (YProjectActions) erreicht. Die Ausfüh-rungsklasse kann jederzeit ersetzt werden, ohne die Datenstrukturen zu ändern. Ähnliche Mechanismen werden in MFC-Programmen unter dem Pseudonym Document-View-Architektur beschrieben. Die Umsetzung von YObject erfolgt, wie bei den allen Klassen des Frameworks, größten-teils durch inline-Funktionen. Sie werden verwendet, um Funktionsaufrufe zu vermeiden und stattdessen den Programmkode der Funktion direkt an die Stelle des potenziellen Auf-rufs zu implementieren. Das Verfahren ist vor allem für kurze Funktionen interessant, da eventuell weniger Speicherplatz als für einen Funktionsaufruf benötigt wird und neben dem Sprung auch Stacksicherungsoperationen entfallen. Ein Test unter Linux ergab einen signi-fikanten Geschwindigkeitsunterschied bei der Kompilierung des Programms mit inline-Funktionen.


74

5.3.2 YDataTypes

In Abbildung A-21 ist das Kompositionsdiagramm der Klasse YTask dargestellt. Eine In-stanz dieser Klasse verwaltet alle eingegebenen Informationen zu einem Prozess, z.B. Na-me, Beschreibung, statische Priorität, Periode, Deadline, Typ, Name der Startfunktion. Alle Attribute, die eine Eigenschaft eines Threads darstellen, sind nicht direkt von YObject ab-geleitet, sondern von der Template-Klasse YDerivedObject<T>. Das Vererbungdiagramm ist in Abbildung 5.3-2 gezeigt.

YDerivedObject

YDerivedType< T >

YDerivedType< YASA_TIME >YDerivedType< QString > YDerivedType< int >YDerivedType< bool >

YObject

< YASA_TIME >< QString > < int >< bool >

Abbildung 5.3-2: Vererbung der Klasse YDerivedObject

Diese Klasse stellt zusätzlich für verschiedene Datentypen einen Vererbungsmechanismus von Eigenschaften zur Verfügung, der besonders bei der Konfiguration der Environments genutzt wird. Jedes YDerivedObject besitzt eine Assoziation auf ein Eltern-Objekt dessel-ben Typs, um die Vererbung zu realisieren. Prinzipiell bilden YDerivedType<T> und YDerivedType eine einheitliche Klasse. Qt bietet allerdings keine Unterstützung für den Signal-Slot-Mechanismus und weitere Eigenschaf-ten bei der Verwendung von Template-Klassen an. Die Nutzung von Templates ist notwen-dig, um für verschiedene Datentypen den Vererbungsmechanismus nur einmal zu imple-mentieren. Daher wurden zwei miteinander verwobene Klassen entwickelt, eine Basisklasse mit dem Qt-spezifischen Teil und eine abgeleitete Klasse, die den Template-Datentyp ent-hält. Der Vererbungsmechanismus wirkt sich besonders zeitsparend bei Konfigurationen des Projekts aus. Eine Eigenschaft kann z.B. im Projekt für alle Environments definiert werden. Das Environment hat die Möglichkeit, die Einstellung zu übernehmen oder falls dies nicht möglich ist, eine eigene Konfiguration für diese Eigenschaft festzulegen. Alle anderen En-vironments bleiben davon unbeeinflusst. Die Kette der Vererbung setzt sich über einen Konfigurationsdialog sowie die Schedulereigenschaften und deren Einstellungskataloge fort. Im Normalfall ändern die meisten Executives, Scheduler bzw. deren Konfigurations-

$classYDerivedType.html





$classYObject.html


75

dialoge nichts an den Einstellungen, sodass letztendlich die Einstellungen des Projekts bis zum Scheduler vererbt werden (s. Anhang A.10). Der Signal-Slot Mechanismus wird benutzt, um allen angeschlossenen Objekten ein Signal über eine Datenänderung zu schicken. Auf diese Weise kann bei Änderung einer Projekt-einstellung völlig automatisch auch die resultierende Schedulereinstellung aktualisiert wer-den. Der Vererbungsmechanismus unterstützt schreibgeschützte Attribute, d.h. er ist in der Lage, ein Eltern-Attribut in den Schreibschutzzustand zu setzen und durch ein Signal allen ange-schlossenen Objekten dieses Objekts zwingend vorzugeben. Besonders zu empfehlen ist dieser Modus bei der Vererbung von Zugriffsrechten. Ein schreibgeschützter Datenträger kann z.B. nicht in abhängigen Objekten wieder eine Schreiberlaubnis erhalten. Für Attribute, die Zeiteinheiten bearbeiten, wurde die Klasse YTIME konstruiert. Diese Klasse hat die Aufgabe, eine Zeit vom Typ YASA_TIME zu bearbeiten, auf zulässige Grenzwerte zu überprüfen und gegebenenfalls zu korrigieren. Dies ist allerdings nicht aus-reichend, um jeden Zeittyp komplett zu beschreiben. Es fehlen Definitionen zu den Start-werten und eventuell nötige Kontrollen. Die Voreinstellung bei der Zeiteingabe für Dead-lines ist z.B. unendlich, wogegen der Defaultwert eines Startoffsets 0 ist. Um diese Vorein-stellungen zu ermöglichen, wurde für jeden Zeittyp eine neue Klasse von YTIME abgeleitet (s. Abbildung 5.3-3).

YTIME

YASA_DEADLINE

YASA_DEADLINETOLERANCE

YASA_LAXITY

YASA_OFFSET

YASA_PERIOD

YASA_REQUIREDTIME

YASA_SCHEDULINGTIME

YASA_SYNCHRONIZATIONOFFSET

YASA_TICK

YDerivedType< YASA_TIME >

Abbildung 5.3-3: Vererbungsdiagramm der Klasse YTime

Alle Datentypen in YASA, die die Klassen YDerivedType<T> als Basisklasse besitzen, werden als YDataTypes bezeichnet. Sie haben gegenüber einfachen Datentypen wie int, int64 und bool deutliche Vorteile bzw. Erweiterungen:

$classYASA__DEADLINE.html

$classYASA__DEADLINETOLERANCE.html

$classYASA__LAXITY.html

$classYASA__OFFSET.html

$classYASA__PERIOD.html

$classYASA__REQUIREDTIME.html

$classYASA__SCHEDULINGTIME.html

$classYASA__SYNCHRONIZATIONOFFSET.html

$classYASA__TICK.html



76

• Kommunikation mit dem Besitzer des Objekts über den Signal-Slot-Mechanismus zur Erhaltung der Datenkonsistenz

• Vererbungsmechanismus von Eigenschaften • Datenänderung nur über Memberfunktionen möglich (Datenkapselung). • Interne Verarbeitung ist verborgen • Erweiterung des Datentyps jederzeit möglich. • Überprüfung und Korrektur von Grenzüberschreitungen des Objekts • Ausgabe lokalisierter Texte wie „unendlich“ oder „infinity“

YDataTypes existieren nicht nur für Zeittypen, sondern für alle Elemente, die für die Kon-figuration des Projekts notwendig sind. Die wichtigsten Datentypen sind in Tabelle 15 dar-gestellt.

Datentyp-Klasse Datentyp Beschreibung YTime YASA_TIME YTIME speichert bzw. korrigiert einen

Zeitstempel, der zwischen 0 und YASA_TIME_INFINITY liegen muss.

YASA_CPU int Das Objekt enthält die Anzahl der zuläs-sigen Prozessoren. Der Wert muss zwi-schen YG_MIN_CPU und YG_MAX_CPU liegen.

YASA_PRIORITY int Diese Klasse enthält Informationen über die Priorität des Prozesses. Der Wert kann zwischen den Werten YG_MIN_PRIORITY und YG_MAX_PRIORITY liegen.

YASA_TASKTYPE int Der Tasktyp beschreibt den Typ des Pro-zesses. Zur Zeit gibt es zwei verschiede-ne Typen: periodisch und aperiodisch.

YASA_SCHEDULERTYPE int Der Schedulertyp legt fest, ob der Sche-duler statisch oder dynamisch ist.

YASA_TIMERTICK bool Der Timertick gibt an, ob das assoziierte Objekt einen periodischen Timer unter-stützt. Die Klasse nutzt den Vererbungs-mechanismus von YDerivedObject.

Tabelle 15: Wichtige YDataTypes


77

5.3.3 YFrame

Die YASA-Oberfläche gliedert sich in drei große Bereiche auf. Die linke Seite stellt den Baum des Arbeitsbereiches mit Projekten, Prozessen, Mutexen und Environments dar. Im unteren Teil befindet sich das Ausgabefenster, das Fehlermeldungen und Warnungen sowie die Ausgaben des Compilers wiedergibt. Der größte Bereich des Fensters befindet sich rechts neben dem Baumdiagramm. Dort können wie in einer MDI-Anwendung verschiede-ne Fenster geöffnet und Ansichten eines Objekts dargestellt werden. Die Anordnung der Fenster kann als Fullsize, in geteilter oder kaskadierter Anordnung erfolgen. Alle Windows können mehrfach geöffnet werden, um verschiedene Ansichten zu ermöglichen. Die Daten-konsistenz wird von YFrame gewährleistet. Ferner kann jedes Fenster im Full-Screen Mo-dus unabhängig vom Hauptfenster geöffnet werden. In YASA werden alle eigenen Fenster durch virtuelle Rahmen (Frames) erstellt. Diese Rahmen benutzen als Basisklasse YFrame (s. Abbildung 5.3-4). Jeder Rahmen erzeugt bei der Instanziierung des Fensters eine eigene Box (QVBox bzw. QHBox) und im Anschluss die entsprechenden Widgets. Er stellt sicher, dass die Verbindungen zwischen den einzel-nen Objekten hergestellt werden (s. Abbildung 5.2-2), um jederzeit die Konsistenz der Da-ten zu gewährleisten. Die Frames bieten einen entscheidenden Vorteil gegenüber herkömmlichen Varianten der Fenstererzeugung. Sie haben keinen Einfluss auf Typ und Größe von Fenstern. Auf diese Weise können mehrere Fenster gleichzeitig in verschiedenen Größen geöffnet werden.

YFrame

YHelpFrame YObjectFrame YOutputWindowFrame

YEnvironmentFrame YFileViewFrame YMutexFrame YProjectFrame YResultFrame YTaskFrame YWorkSpaceFrame

YLogFileViewFrame YSourceViewFrame YEnvironmentResultFrame YProjectResultFrame

Abbildung 5.3-4: Vererbungsdiagramm von YFrame

In Abbildung 5.3-4 sind die in YASA definierten YFrames dargestellt. Jedes kann als Vor-lage für ein größenveränderbares Fenster wirken. Alle von einem YObject abhängigen Fenster sind von der Klasse YObjectFrame abgeleitet. Sie reagieren damit automatisch auf Veränderungen des mit ihnen assozierten Objekts. Wird z.B. die Einstellung des Timer-Ticks im Projektfenster (YProjectFrame) verändert, so ändert sich die Eintragung in allen assoziierten Fenstern ebenfalls, die durch den Vererbungsmechanismus den alten Timer-wert anzeigen. Wird ein Projekt gelöscht, wird allen abhängigen Objekt-Fenstern wie

$classYHelpFrame.html

$classYObjectFrame.html

$classYOutputWindowFrame.html

$classYEnvironmentFrame.html

$classYFileViewFrame.html

$classYMutexFrame.html

$classYProjectFrame.html

$classYResultFrame.html

$classYTaskFrame.html

$classYWorkSpaceFrame.html

$classYLogFileViewFrame.html

$classYSourceViewFrame.html

$classYEnvironmentResultFrame.html

$classYProjectResultFrame.html


78

Thread- und Mutex-Dialogen sowie Statistikenfenstern (YResultFrame) automatisch ein Destroy-Signal übermittelt, woraufhin sich die Fenster automatisch schließen. Es ist kein zusätzlicher Überwachungsmodus nötig. Die Festlegung, dass YFrames grundsätzlich eine eigene Box erzeugen, kann dazu benutzt werden, Frames, die ursprünglich für einzelne Fenster gedacht waren, auch als Teil eines anderen Fensters darzustellen. Abbildung 5.3-5 zeigt links drei Fenster, die auch in einem Window kombiniert angezeigt werden können. Dafür ist keine Änderung in den Quell-texten der YFrames erforderlich. Für das rechte Fenster ist ein übergeordnetes YFrame er-forderlich, welches die drei linken Frames als Child-Widgets einbindet.

Tabelle

Balkendiagramm

Kreisdiagramm

20 %50 %

30 %

x

zy

a

20%20%

b

70%50%20% 60%

10%30%20%

c

a b c

Datenvisualisierung

Daten

x

zy

a

20%20%

b

70%50%20% 60%

10%30%20%

c

Balkendiagramm Kreisdiagramm

20 %50 %

30 %

Abbildung 5.3-5: Anwendungen von YFrames

5.3.4 YWidget

Die meisten Fenster (YFrames) werden in YASA Objekten zugeordnet. Ein Task-Fenster wird z.B. immer einem Objekt vom Typ YTask zugeordnet. Damit wird die in Kapitel 5.2.2 beschriebene Datenkonsistenz garantiert. Bei Konfigurationsdialogen reicht dies meist nicht aus, da die Klassen aus anderen Klassen aufgebaut sind. Sie bilden eine Aggregation [Balz01], wie in Abbildung A-21 illustriert ist. Ein Konfigurationsfenster, wie das für ein YTask-Objekt, besteht aus Widgets, die die un-terschiedlichen Attribute eines Prozesses entgegennehmen können, z.B. Priorität (integer) und YASA_TIME (integer 64-Bit). Es wird deutlich, dass die einzusetzenden Widgets be-reits bei der Eingabe eine Bereichsprüfung vornehmen müssen. Aufgrund der unterschiedli-chen Datentypen müssen verschiedene Widgets deklariert werden. Um eine Erweiterbarkeit


79

der Software so einfach wie möglich zu gestalten, wurde für jeden Datentyp ein eigenes Widget deklariert. Die Vererbungshierarchie ist in Abbildung 5.3-6 dargestellt. Als Basis-klasse dient YWidget, dass die Datenkonsistenz zu YFrame garantiert.

YWidget

YCheckBoxWidget

YComboWidget

YDateTimeWidget

YIntegerWidget

YListViewGroup

YSchedulerListViewGroup

YStringWidget

YTextComboWidget

YTextWidget

YYasaTimeWidget

YYasaTimeWidget

YDeadlineToleranceWidget

YDeadlineWidget

YEndTimeProjectWidget

YOffsetWidget

YPeriodWidget

YRequiredTimeWidget

YSchedulingTimeWidget

YSynchronizationOffsetWidget

YTickEnvironmentWidget

YTickProjectWidget

YWidget

Abbildung 5.3-6: Vererbungs-diagramm der Klasse YWidget

Abbildung 5.3-7: Vererbungsdiagramm der Klasse YYasaTimeWidget

Für die unterschiedlichen Attribute, die den Datentyp YASA_TIME benutzen, wurden e-benfalls Widgetklassen deklariert (s. Abbildung 5.3-7). Der Vorteil besteht in der einfache-ren Bereichsprüfung und angenehmeren Anzeige der Werte. So kann eine unendliche Dead-line im YDeadlineWidget, die den internen Wert 0 hat, mit dem eindeutigeren Text „infini-ty“ dargestellt werden. Andere Widgets wie z.B. YOffsetWidget geben bei einem Zeitwert von t=0 den Text „no offset“ aus.

YTask YTaskFrame

YASA_Deadline YASA_Offset YOffsetWidget YDeadlineWidget

1

*

1

1

1

1

1

1

1 *

1 *1 *

1

1

1

1

1

1

1

1

Abbildung 5.3-8: Assoziationen zwischen Objekten und YFrames (vereinfacht)

$classYCheckBoxWidget.html

$classYComboWidget.html

$classYDateTimeWidget.html

$classYIntegerWidget.html

$classYListViewGroup.html

$classYSchedulerListViewGroup.html

$classYStringWidget.html

$classYTextComboWidget.html

$classYTextWidget.html

$classYYasaTimeWidget.html

$classYDeadlineToleranceWidget.html

$classYDeadlineWidget.html

$classYEndTimeProjectWidget.html

$classYOffsetWidget.html

$classYPeriodWidget.html

$classYRequiredTimeWidget.html

$classYSchedulingTimeWidget.html

$classYSynchronizationOffsetWidget.html

$classYTickEnvironmentWidget.html

$classYTickProjectWidget.html

$classYWidget.html


80

In Abbildung 5.3-8 sind die Assoziationen zwischen den Widgets und den Objekten unter Vernachlässigung einiger Basisklassen vereinfacht dargestellt. Die Instanzen von YA-SA_Deadline und YASA_Offset wurden während der Konstruktion mit YTask verbunden, d.h. tritt eine Änderung der internen Daten auf, wird das Signal UpdateObject ausgelöst, das an YTask weitergereicht wird. Bei Öffnen eines Task-Fensters wird es mit der YTask-Instanz verbunden und reagiert auf Änderungen von YTask. Tritt eine Änderung von Y-Task auf, wird allen angeschlossenen Widgets signalisiert, sich zu aktualisieren. Die Einga-be eines neuen Deadline-Wertes in einem Widget führt zu einem Aufruf der Memberfunk-tion SetDeadline() von YTask und dabei indirekt zu einer Änderung von YASA_Deadline. YASA_Deadline sendet bei Akzeptierung des neuen Deadlinewertes ein Signal zur Aktua-lisierung an YTask. Im Anschluss werden alle assoziierten Task-Fenster benachrichtigt.

5.3.5 Auswertung und Darstellung

In YASA ist eine umfangreiche Komponente zur Auswertung von Prozessanwendungen integriert, deren Funktionalität bereits in Kapitel 4.9 beschrieben wurde. In diesem Kapitel soll kurz die Programmierung der umfangreichen Komponenten skizziert werden.

YResultFrame

YEnvironmentResultFrame YProjectResultFrame

YObjectFrame

YFrame

YStatisticEnvironmentResultFrame YTimingEnvironmentResultFrame YStatisticProjectResultFrame YTimingProjectResultFrame

Abbildung 5.3-9: Vererbungsdiagramm der Klasse YResultFrame

Die Basisfunktionalität ist in der Klasse YResultFrame definiert (S. Abbildung 5.3-9). Sie wird von zwei Darstellungs-Klassen abgeleitet, der grafischen (YEnvironmentResultFrame) und der statistischen Klasse (YProjectResultFrame). Die beiden Klassen symbolisieren den Umfang der Auswertung. YEnvironmentResultFrame bezieht sich auf die Ausführung in einem Environment (s. Abbildung A-11), wobei YProjectResultFrame auf den Vergleich von mehreren Environments in einem Projekt spezialisiert ist (s. Abbildung A-13). Die Klassen YEnvironmentResultFrame und YProjectResultFrame werden nicht direkt, sondern von abgeleiteten Klassen benutzt, die die Darstellungsform (Tabelle oder Dia-gramm) festlegen. Sie erzeugen zur Laufzeit Instanzen der Klasse YResultHandler, die ein

$classYEnvironmentResultFrame.html

$classYProjectResultFrame.html

$classYObjectFrame.html

$classYFrame.html

$classYStatisticEnvironmentResultFrame.html

$classYTimingEnvironmentResultFrame.html

$classYStatisticProjectResultFrame.html

$classYTimingProjectResultFrame.html


81

Auslesen der Daten aus den Logfiles entsprechend der Vorgaben realisieren. Diese Handler gewährleisten eine Trennung zwischen YFrame-Funktionalität und eigentlicher Darstel-lung. Die Zeitdiagramme in Abbildung A-13 bis Abbildung A-15 werden in einem Fenster der Klasse YTimingProjectResultFrame dargestellt. Aus den Abbildungen folgt, dass es einen Mechanismus geben muss, der die unterschiedlichen Diagramme für Threads, Mutexe und Prozessoren in einem Fenster darstellt. Diese Aufgabe hat der YTimingHandler. Er verwal-tet die verschiedenen Diagramme in einer Liste. Für die Darstellung der Timingdiagramme gibt es 6 verschiedene Klassen, die als Basis-klasse YTimings besitzen. In Tabelle 16 ist eine Übersicht über die abgeleiteten Klassen und deren Eigenschaften dargestellt. Diese Klassen gewährleisten neben der korrekten Darstel-lung die richtige Beschriftung der Achsen sowie die Filterung der darzustellenden Daten aus dem Logfile. Das Sortierkriterium in Tabelle 16 beschreibt die Reihenfolge, in der die einzelnen Zeilen in einem Diagramm sortiert werden. Die Tabellenspalte ‚Anzeige’ gibt an, was für Informationen in einer Zeile des Zeitdiagramms angegeben werden. Die Angabe der Instanzen bezieht sich auf die Häufigkeit, mit der diese Klasse in einem der abgeleiteten YFrames instanziiert wird. Die Zeilenangabe gibt an, wie viele Zeilen ein Zeitdiagramm maximal enthält. Die Instanzen der Zeitdiagramme werden während der Initialisierung des YResultFrames erzeugt. In Abbildung A-11 wurden drei Diagramme erzeugt, wogegen das komplette Fens-ter, das in Abbildung A-13 bis Abbildung A-15 dargestellt ist, insgesamt 9 Timingdia-gramme enthält (vgl. Tabelle 16).

Klasse Sortierung Anzeige Instanzen Zeilen YTaskEnvironmentTimings Task Tasks 1 Taskanzahl YMutexEnvironmentTimings Mutex Mutexe 1 Mutexanzahl YCPUEnvironmentTimings CPU CPU 1 CPU-Anzahl YTaskProjectTimings Environment Task Taskanzahl Environmentanzahl YMutexProjectTimings Environment Mutex Mutexe Environmentanzahl YCPUProjectTimings Environment CPU Prozessoren Environmentanzahl

Tabelle 16: Klassenübersicht der Zeitdiagramme

Jedes Zeitdiagramm berechnet während der Initialisierung seine max. Höhe. Der Timing-Handler erzeugt zu jeder Instanz der Klasse YTimings eine YTimingInfo-Instanz, die die berechnete Höhe zwischenspeichert (s. Abbildung 5.3-10). Das Zeichnen von Linien, Punk-ten und Bildern übernimmt die Klasse YPainter, die die YTimingInfo-Klasse ausliest und


82

die Koordinaten entsprechend addiert. Dadurch kann jedes Zeitdiagramm in einem eigenen Koordinatensystem arbeiten. Der YPainter benutzt zum Darstellen von Bildern die Klasse YLogFileFigures, die die Bil-der erst bei Bedarf nachlädt und für den Rest der Programmlaufzeit im Speicher hält. Die Bilder liegen im XPM-Format einzeln in dem Unterverzeichnis /yasagui/figures/logfile vor, sodass ein Austausch jederzeit möglich ist.

YTimingInfo

YTimings

timings

YTimingParser

timings timingparser

YLoggingParser

YEnvironmentLogFileSet

environmentlogfile

YCPULogFile

cpulogfile

YPainter

painter

YLogFileFigures

logfilepixmaps

YPainterLogFileArgs

painterlogfileargs

Abbildung 5.3-10: Kompositionsdiagramm der Klasse YTimingInfo

Für die Darstellung benötigen die YTimings unterschiedliche Daten, die ein Parser zurückliefert. Der Parser (YLoggingParser) durchsucht alle Logfiles jeweils in einer einzigen Schleife. Findet er ein passendes Datum, übergibt er es an eine Callback-Funktion anstatt seine Abarbeitung zu beenden. Auf diese Weise werden eine Reihe von virtuellen Funktionsaufrufen und Stackoperationen vermieden, die vor allem bei stark vergrößerten Ansichten massiv ins Gewicht fallen würden. Jedem Parser wird in Abhängigkeit der darzustellenden Daten eine Filter-Funktion überge-ben, die unnötige Aufrufe der Paint-Funktionen verhindert. Die Filter-Funktion kann später erweitert und mit einem Konfigurationsdialog gekoppelt werden, um dem Benutzer die Entscheidung zu überlassen, welche Ereignisse in den Diagrammen dargestellt werden sol-len. Die Klassen YTimings, YLoggingParser und YPainter sind optimiert für die Darstellung von Vergrößerungen, d.h. es werden nur Elemente dargestellt, die im sichtbaren Bereich liegen (Clipping). Für die Darstellung der Ergebnisse in tabellarischer Form wurden ähnliche Klassen entwi-ckelt wie für die grafische. Die abgeleiteten Klassen von YFrame zur Erzeugung der Fens-ter sind vom Typ YStatisticEnvironmentResultFrame und YStatisticProjectResultFrame. YStatisticEnvironmentResultFrame zeigt die Ergebnisse der Simulation eines Environ-ments in drei Einzeltabellen an. In YStatisticProjectResultFrame-Fenstern wird für jeden Task, jedes Mutex und jeden Prozessor eine neue Tabelle erstellt. Statt des YTiming-

$classYTimings.html

$classYTimingParser.html

$classYLoggingParser.html

$classYEnvironmentLogFileSet.html

$classYCPULogFile.html

$classYPainter.html

$classYLogFileFigures.html

$classYPainterLogFileArgs.html


83

Handlers für grafische Anzeigen wird bei Tabellen der YStatisticHandler eingesetzt. Er verwaltet die einzelnen Tabellen in einem Statistikfenster. Für die Darstellung der Tabellen gibt es 6 verschiedene Klassen, die als Basisklasse YSta-tistics besitzen. Eine Übersicht über diese Klassen und deren Eigenschaften ist in Tabelle 17 dargestellt. Diese Klassen gewährleisten neben der Filterung der darzustellenden Daten aus dem Logfile auch die korrekten Überschriften sowie die Berechnungen und Zuordnun-gen der Ergebnisse in den Tabellen. Die Spalten einer Statistiktabelle sind entweder nach Threads, Mutexen, Prozessoren oder Environments sortiert. In den Zeilen sind die Eigen-schaften aufgelistet. Um in den Tabellen automatisch per Mausklick in einer Zeile sortieren zu können, wurde ein zusätzlicher Sortieralgorithus implementiert [Blu00]. In der Spalte Inhalt in Tabelle 17 wird angegeben, was für Informationen in einer Spalte einer Statistik-tabelle angegeben werden. Die Angabe der Instanzen bezieht sich auf die Häufigkeit, mit der diese Klasse in einem der abgeleiteten YFrames instanziiert wird. Die Spaltenangabe gibt an, wie viele Spalten eine Statistiktabelle hat.

Klasse Sortierung Inhalt Instanzen Spalten YTaskEnvironmentStatistics Task Tasks 1 Taskanzahl YMutexEnvironmentStatistics Mutex Mutexe 1 Mutexanzahl YCPUEnvironmentStatistics CPU CPU 1 CPU-Anzahl YTaskEnvironmentStatistics Environment Task Taskanzahl EnvironmentanzahlYMutexEnvironmentStatistics Environment Mutex Mutexanzahl EnvironmentanzahlYCPUEnvironmentStatistics Environment CPU CPU-Anzahl Environmentanzahl

Tabelle 17: Klassenübersicht der Statistiktabellen

Das Auslesen und Analysieren der Logfiledaten erfolgt ebenso wie bei den Timing-diagrammen durch einen Parser (YLoggingParser). Der Unterschied besteht bei Tabellen darin, dass keine Klasse YPainter benötigt wird. Die Darstellung in einem Tabelleneintrag erfolgt in Textform. Eine Umwandlung der diversen Datentypen in eine textbasierte Form ist erforderlich, um z.B. unterschiedliche Zahlentypen (YASA_TIME, int) anzeigen zu können. Sie erfolgt in der Klasse YStatisticEntry. Für jeden Eintrag in einer Tabelle wird in Abhängigkeit vom darzustellenden Datentyp eine Instanz der abgeleiteten Statistiktypen erzeugt.


84

YStatisticEntry< T >

YStatisticEntry< YASA_TIME >< YASA_TIME >

YStatisticEntry< double >< double >

YStatisticEntry< QString >< QString >

YStatisticEntry< int >

< int >

YStatisticEntry< PERCENTTYPE >

< PERCENTTYPE >

YStatisticEntry< bool >

< bool >

YStatisticBaseEntry

Abbildung 5.3-11: Vererbungsdiagramm der Klasse YStatisticEntry<T>

In Abbildung 5.3-11 ist die Klasse YStatisticEntry in Zusammenhang mit YStatisti-cEntry<T> gezeigt. Prinzipiell bilden die beiden Klassen wie die Klassen YDerivedObject aus Abbildung 5.3-2 eine gemeinsame Klasse und müssen aufgrund der Restriktionen von Qt getrennt werden. Sie bilden die Basisklasse für die Umwandung in die textbasierte Form in Abhängigkeit vom Datentyp. Zudem bieten sie Schutzmechanismen, z.B. für die Divisi-on durch null und Default-Zeichenketten für den Fall, dass die abgeleitete Klasse kein Er-gebnis zurückliefert. Es gibt weiterhin die Möglichkeit, jedem Tabelleneintrag einen Wert zuzuweisen, aber einen anderen darzustellen. Auf diese Weise können z.B. Werte wie 0.5 in „0,5 %“ umgewandelt werden, ohne dass die Funktionalität der eingebauten Sortier-algorithmen versagt.

$classYStatisticEntry.html






$classYStatisticBaseEntry.html

6. Zusammenfassung und Ausblick

85

6. Zusammenfassung und Ausblick In dieser Arbeit wurde das Entwicklungsframework YASA für harte Echtzeitsysteme vor-gestellt. Es ist in der Lage, das Schedulingverhalten von Programmen frühzeitig mit synthe-tischer oder echter Last auszuführen und zu analysieren. YASA bietet umfangreiche Mög-lichkeiten zur Auswertung von Schedulinginformationen mit anschließender Optimierung des Gesamtsystems. Die Einführung von Executives zur Kapselung der Schedulingumgebung gestattet die Aus-führung von Echtzeitprogrammen auf verschiedenen Betriebssystemen. Die Executives erweitern die internen Strukturen und Funktionen des Betriebssystems, sodass ein Wechsel der Scheduler sowie der Schedulingumgebung möglich wird. Eine sehr einfache und effi-ziente Möglichkeit zur nötigen Anpassung der Kernelquelltexte stellen die erläuterten Präprozessor-Makros dar. Die Executives sind als eigenständige Module in Quelltextform realisiert, wodurch eine hohe Flexibilität und Erweiterbarkeit erreicht wird. Es wurden Executives zur Simulation und für die Ausführung unter Realtime Linux umge-setzt. Die Programmierschnittstelle der Executives wurde so konzipiert, dass eine Erweite-rung durch neue Executives für bisher nicht unterstützte Betriebssysteme jederzeit möglich ist. Das YASA-Framework kann aufgrund seines Logging-Mechanismus’ neben der Schedu-linganalyse zur Fehlersuche in Programmen, vor allem im Zusammenhang mit der Kernel-programmierung von Betriebssystemen verwendet werden. Eine umfangreiche und erwei-terbare Ereignisliste erlaubt die nachträgliche Auswertung des Kernel- und Programm-ablaufs. Die geschriebenen Logfiles bilden die Basis für die Auswertung in dem grafischen Front-End. Weiterhin wurden in YASA umfangreiche Protokolle zur Synchronisation von Prozessen und zur Verhinderung der Prioritäteninversion implementiert. Die Einführung dynamischer Prioritäten erlaubt den Wechsel des Prioritätstyps, wodurch eine Entkopplung der dynami-schen Synchronisationsprotokolle und der Scheduler erreicht wird. Die Kombinations-möglichkeiten von Schedulern und Synchronisationsprotokollen sind gegenüber herkömm-lichen Systemen erheblich erweitert worden. Ferner wurde eine Möglichkeit vorgestellt, in die Executives der Zielsysteme verschiedene und vom Betriebssystem unabhängige Scheduler zu implementieren. YASA unterstützt sowohl statische, dynamische als auch zyklische Scheduler. Derzeit sind 12 eigenständige Module implementiert. Sie liegen ebenfalls im Quelltext vor und sind plattformunabhängig. Zur Konfiguration und Auswertung der Echtzeitprojekte wurde ein eigenständiges grafi-sches Front-End nach MDI-Vorbild entwickelt. Die Projekte können unabhängig voneinan-

6. Zusammenfassung und Ausblick

86

der erstellt und ausgeführt werden. Die Auswertung des Schedulingverlaufs ist in grafischer Form durch Zeitdiagramme oder in statistischer Form durch Tabellen möglich. Im Gegen-satz zu herkömmlichen Schedulinganalysern kann YASA nicht nur die Schedulingverläufe der Projekte sondern auch die der Prozesse einzeln sowohl in grafischer als auch in tabella-rischer Form vergleichen. Die zusätzliche Darstellung von Mutex- und Prozessor-diagrammen verbessert die Vergleichbarkeit deutlich. Die vollständige Plattformunabhängigkeit von YASA wurde durch den Einsatz der C++ Klassenbibliothek Qt von Trolltech erreicht. Sie zeichnet sich durch hohe Stabilität, kurze Einarbeitungszeit und vielfältige Mechanismen zur Vereinfachung der objekt-orientierten Programmierung aus. In YASA sind derzeit 261 Klassen umgesetzt, in denen die konsequente Behandlung inter-ner Fehler in ein sehr stabiles Laufzeitverhalten resultiert. Die Erweiterbarkeit und hohe Flexibilität wird durch den Einsatz von Entwurfsmustern erreicht. Das Forcieren auf UNI-CODE und die stetige Extraktion der textbasierten Zeichenketten erlaubt die vollständige Lokalisation auf unterschiedliche Sprachräume. Der Einsatz von Qt eröffnet eine einfache Erstellung flexibler und umfangreicher Konfigurationsdialoge. Die ca. 30.000 Zeilen umfassenden Quelltexte des Entwicklungsframeworks sind umfang-reich in Englisch dokumentiert. Durch den Einsatz externer Programme ist die automati-sche Erstellung einer umfangreichen Online-Dokumentation gegeben, wodurch eine zwei-gleisige Dokumentationspflege vermieden wird. In der vorliegenden Version ist YASA für den Einsatz von Servern zur Behandlung aperio-discher Ereignisse vorbereitet. Für die endgültige Umsetzung sind abschließende Konzept-überlegungen notwendig, um die erreichte Flexibilität von YASA zu erhalten. Eine der Hauptaufgaben in weiterführenden Arbeiten wird die Entwicklung neuer Executives und Hardwarescheduler sein. Ein weiteres Einsatzgebiet erschließt sich im weiten Feld der verteilten Anwendungen, in denen das Schedulingverhalten und die Auslastung optimiert werden kann. Der modulare Aufbau des grafischen Front-Ends erlaubt die Erstellung zusätzlicher Kom-ponenten zur automatischen Auswertung und Optimierung unter Angabe von Scheduling-kriterien. Dazu sind weiterführende Überlegungen in der theoretischen Analyse notwendig. Die Bedienung der Entwicklungsumgebung ist verbesserungswürdig. So sollten die spärli-chen Konfigurationsmöglichkeiten in Bezug auf Diagramme und Aussehen der Fenster durch Einstellungsdialoge ersetzt werden. Für die Diskussion von Ergebnissen in weiter-führenden Arbeiten und Dokumenten müssen Konzepte zur Einbettung der Diagramme bzw. Tabellen nach OLE-Vorbild erstellt werden.

Literaturverzeichnis

87


[ATT02] AT & T: “Graphviz - open source graph drawing software”, http://www.research.att.com/sw/tools/graphviz/, 2002

[Aud91] Neil C. Audsley: „Resource Control for hard real-time systems: a review“, Uni-versity of York, 1991

[Bak90]

T.P.Baker: „A Stack-Based Resource Allocation for Realtime Processes”, Pro-ceedings 11th IEEE Real Time Systems Symposium, IEEE Computer Society Press (December 1990)

[Bal00] Patricia Balbastre & Ismael Ripoll: „Integrated Dynamic Priority Scheduler for RTLinux”, Universität Valencia, 2000

[Balz01] Helmut Balzert: “Lehrbuch der Software-Technik”, 2. Auflage, Spektrum Aka-demischer Verlag Heidelberg, 2001

[Bar01] Michael Barabanov : “Open RTLinux Installation Instructions“, FSMLabs, So-corro, New Mexico, 2001

[Blu00] Jan Blumenthal: “Design Pattern: Iteratoren”, Seminar Objekt-orientierte Pro-grammierung, Universität Rostock, 2000

[Blu02]

Jan Blumenthal, Frank Golatowski, Jens Hildebrandt, Dirk Timmermann: ”Framework for validation, test and analysis of real-time scheduling algorithms and scheduler implementations”, 13th IEEE International Workshop on Rapid System Prototyping, July 1-3, 2002, Darmstadt, Germany

[Bus00] F. Bushmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal: „Pattern-orientierte Softwarearchitektur“, Addison Wesley, München, 2000

[But93]

G. Buttazzo and J. Stankovic: „RED: A Robust Earliest Deadline First Algo-rithm“, Proc. of 3rd International Workshop on Response Computing Systems, Austin, 1993

[But97] Giorgio C. Buttazzo: „Hard Real-Time Computing Systems”, Kluwer Academic Publishers, Boston, 1997

[Che90] M.-I. Chen, K.-J. Lin: „Dynamic Priority Ceilings: A Concurrency Control Pro-tocol for Real-Time Systems”, Journal of Real-Time Systems, 1990

[Der74] M.L. Dertouzos: „Control robotics: the procedural control of physical proc-esses”, Information Processing, 74, 1974

http://www.research.att.com/sw/tools/graphviz/

http://www.rsp-workshop.org/

http://www.rsp-workshop.org/


88

[FSM02] FSM Labs: „RTLinux Man-pages“, http://www.fsmlabs.com/developers/man_pages/function_list.htm, 2002

[Gal97] Bill O. Gallmeister: „POSIX.4 – Programming for the real world“, O´Reilly & Associates, Sebastopol , 1997

[Gam96]

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: „Entwurfsmuster – Elemente wiederverwendbarer objektorientierter Software“, Addison-Wesley, Bonn, 1996

[Gol98a] Frank Golatowski: „Vorlesung Echtzeitbetriebssysteme”, 1998, Universität Ros-tock

[Gol98b]

Frank Golatowski: “Ein Beitrag zur Entwurfsunterstützung, Leistungsanalyse und Leistungsbewertung von Echtzeitsystemen und Echtzeitbetriebssystemen“, Dissertation, Universität Rostock

[Hee02] Dimitri van Heesch: “Doxygen Manual”, www.doxygen.org, 2002

[Hil98] Jens Hildebrand: „Entwicklung eines Scheduling Hardware-CoProzessors“ U-niversität Rostock, 2001

[Jos96] Mathai Joseph: „Real-time Systems - Specification, Verification and Analysis“ 1996, Prentice Hall

[Nic02] Nicolas Chauvin & Stéphane Demurget: „The Cheddar project“, http://beru.univ-brest.fr/~singhoff/chedda, Universität Brest, 2002

[Pro01] Frederick M. Proctor: „Measuring Performance in Real-Time Linux”, National Institute of Standards and Technology, USA, 2001

[Raj91] Ragunathan Rajkumar: „Synchronization in Real-Time Systems – A Priority In-heritance Approach”, Kluwer Academic Publishers, Boston, 1991

[Red02] Red Hat: „GNU + Cygnus + Windows = cygwin“, www.cygwin.com, 2002

[Rip98a] Ismael Ripoll: „Real Time Linux II“, http://www.linuxfocus.org/English/July1998/article56.html, 1998

[Sch97] Mark Schlegel: „Schedulability Analyse von Echtzeitanwendungen in einer Win-dows-NT Umgebung“, Studienarbeit, Universität Rostock, 1997

[Sch98] Marc Schlegel: „Schedulinganalyse harter Echtzeitsysteme”, Diplomarbeit, U-niversität Rostock, 1998

[Str97] Bjarne Stroustrup: „Die C++ Programmiersprache“, Addison-Wesley, Mün-chen, 1992

http://www.doxygen.org/

http://beru.univ-brest.fr/~singhoff/chedda

http://www.cygwin.com/

http://www.linuxfocus.org/English/July1998/article56.html


89

[Tan93] Andrew S. Tanenbaum: „Betriebssysteme - Entwurf und Realisierung“, Hanser Verlag, 1993

[TOG97] The Open Group: “The Single UNIX ® Specification, Version 2”, http://www.opengroup.org/austin/, 1997

[Tro02] Trolltech: „QT- Documentation“, http://www.trolltech.com/developer/documentation/index.html, Olso, 2002

[Wan00] Yu-Chung Wang, Kwei-Jay Lin: „Implementing a General Real-Time Schedul-ing Framework in the RED-Linux Real-Time Kernel”, Universität Irvine, 2000

[Yod00] Victor Yodaiken: „Lean POSIX for Linux”, http://www.fsmlabs.com/developers/white_papers/posix.htm, 2002

http://www.opengroup.org/austin/

http://www.trolltech.com/developer/documentation/index.html

http://www.fsmlabs.com/developers/white_papers/posix.htm

Anhang A.1 - Beispielprogramm für RT-Linux

90

A Anhang

A.1 Beispielprogramm für RT-Linux

Der folgende Quelltext demonstriert ein einfaches RT-Linux Programm. Es erzeugt zwei Echtzeitprozesse, die alle 0,5 ms den Ausgangspegel an den Pins 0 und 1 des Parallelports eines Standard-PC’s invertieren.

//////////////////////////////////////////////////////////////////////////////////////////////// // Name: rtprinter.c //////////////////////////////////////////////////////////////////////////////////////////////// #include <rtl.h> #include <time.h> #include <pthread.h> #include <asm/io.h> //////////////////////////////////////////////////////////////////////////////////////////////// #define KERNEL _ #define MODULE #define LPT_PORT 0x378 // Output address int tperiod = 5000000; // 5 000 000 nsec = 0.5ms int toffset = 500000; // 500 000 nsec = 0.2ms int tcount1 = 0; int tcount2 = 0; pthread_t thread1, thread2; //////////////////////////////////////////////////////////////////////////////////////////////// void* rttask(void *parameter) { hrtime_t next; char t; // t represents the pin number t=(char)parameter; // read number from parameter next=clock_gethrtime(rtl_getschedclock())+2*tperiod; if (t != 0 ) next=next+toffset; pthread_make_periodic_np(pthread_self(), next, tperiod); while(1) // begin endless loop { pthread_wait_np(); // entering suspend state outb(t, LPT_PORT); // write to LPT_PORT }; } //////////////////////////////////////////////////////////////////////////////////////////////// int init_module(void) { int tstatus; pthread_attr_t attr; struct sched_param sched_param; pthread_attr_init(&attr); // initialize with defaults pthread_attr_setcpu_np(&attr, 0); // select CPU 0 sched_param.sched_priority=1; // priority 1 pthread_attr_setschedparam(&attr, &sched_param); // correct with own settings printk("rtprinter: Hello world!, tcount1: %d, tcount2: %d\n", tcount1, tcount2); tstatus = pthread_create(&thread1, &attr, rttask, (void*) 0); // pin 0 tstatus = pthread_create(&thread2, &attr, rttask, (void*) 1); // pin 1 return 0; } //////////////////////////////////////////////////////////////////////////////////////////////// void cleanup_module(void) { pthread_delete_np(thread1); pthread_delete_np(thread2); printk("rtprinter: Bye! tcount1: %d, tcount2: %d\n", tcount1, tcount2); }

Anhang A.2 - Echtzeitanwendung in YASA

91

A.2 Echtzeitanwendung in YASA

Der folgende Quelltext zeigt eine typische Anwendung in YASA 2. Das Programm wird periodisch ausgeführt und setzt in seiner Periode zwei Mutexe. Im Gegensatz zu dem Beispiel in Anhang A fehlen die Funktionen zur Initialisierung und zum Entfernen der Anwendung init_module() und cleanup_module(). Die Aufgabe der bei-den Funktionen wird vom Executive-Startupmodul übernommen. Die Funktion yp_thread1_execute() entspricht der Routine rttask() aus Anhang A. //////////////////////////////////////////////////////////////////////////////////////////////// // // YASA test project source code // // Project: Yasa 2 // Filename: $(YASA_PROJECT)/testproject.c // Author: Jan Blumenthal // date: 2002/05/02 // //////////////////////////////////////////////////////////////////////////////////////////////// #include <yasa/yasa.h> //////////////////////////////////////////////////////////////////////////////////////////////// pthread_mutex_t* yp_getmutex(int id); //////////////////////////////////////////////////////////////////////////////////////////////// // This is called periodically // Input: None // Output: return value of this thread void* yp_thread1_execute(void **userdata) { int retvalue=0; int k=1; int a=0; pthread_mutex_t *mutex1, *mutex2; rtl_printf("thread %s is entering loop\n", yasa_id_get_name( & (pthread_self()->id) ) ); mutex1=yp_getmutex(MUTEXID_MUTEX_1); mutex2=yp_getmutex(MUTEXID_MUTEX_2); YASA_PERIODIC_START // begin endless loop { if ( mutex1 ) pthread_mutex_lock( mutex1 ); if ( mutex2 ) pthread_mutex_lock( mutex2 ); outb(t, LPT_PORT); // write to LPT Port if ( mutex2 ) pthread_mutex_unlock( mutex2 ); if ( mutex1 ) pthread_mutex_unlock( mutex1 ); k++; if ( k==10 ) break; } YASA_PERIODIC_END // wait until next period return (void*)retvalue; }

Anhang A.3 - Quelltext des EDF-Schedulers

92

A.3 Quelltext des EDF-Schedulers

Nachfolgend ist der Quelltext des YASA-EDF Schedulers abgebildet. Die rot gekennzeich-neten Stellen markieren Präprozessormakros. Dort wird auf eine Systemstruktur zugegrif-fen, ohne Funktionen zu verwenden. //////////////////////////////////////////////////////////////////////////////////////////////// // // YASA - Earliest deadline first implementation // // Project: Yasa 2 // Filename: $(YASA)/schedulers/edf/edf.c // Author: Jan Blumenthal // date: 2002/01/26 // // Features: Support for Stack Resource Protocol (SRP) //////////////////////////////////////////////////////////////////////////////////////////////// #include "edf.h" //////////////////////////////////////////////////////////////////////////////////////////////// YASA_THREAD* edf_schedule(YASA_SCHEDULER *scheduler, const YASA_TIME *now, YASA_TIME *ptime) { YASA_THREAD *thread; YASA_THREAD *newthread; int reschedule; do { yasa_initschedulingcycle(newthread); reschedule=0; for (thread = YASA_TASKSET(scheduler); thread; thread = YASA_NEXT_THREAD(thread) ) { if ( YASA_CHECK_NEXT_ACTIVATION(thread) ) yasa_setnextactivationtime(thread, now); // Should the thread be (re)started in future? // thread->threadflags&TIMER_ARMED // The thread should be restarted. Did we reach the resume time? if ( YASA_TEST_TIMER_ARMED(thread) && *now >= YASA_RESUME_TIME(thread) ) { // timer is no more armed. thread is ready to compute // thread->threadflags&=~TIMER_ARMED YASA_UNSET_TIMER_ARMED(thread); // thread can be choosen in this scheduling ! // thread->pending will 'TRUE' YASA_SIGNAL_TIMER(thread); // set next(!) resume time yasa_setdeadline(thread); // set deadline of current thread } // find highest priority runnable task if ( YASA_SCHEDULABLE(thread) ) { // if deadline missed, there can be started an emergency thread // rescheduling neccessary !!! if ( YASA_TEST_DEADLINE_MISSED(thread, now) ) reschedule|=yasa_deadlinemissed(thread, now); // scheduling algorithm if (!newthread|| YASA_CURRENT_DEADLINE(thread)<YASA_CURRENT_DEADLINE(newthread)) { #ifdef YASA_SUPPORT_DYNAMICALLY_SYNCHRONIZATION_SCHEDULING if ( yasa_cmpdynamicpriority( &YASA_DEADLINE(thread) ) ) #endif

Anhang A.3 - Quelltext des EDF-Schedulers

93

newthread=thread; } } } } while (reschedule); ///////////////////////////////////////////////////////////////////////////////////////// // determine preemption time. Please pay attention to: // 1. should the tick or the preemption time be used // 2. what happens if newthread=0 ? // 3. what happens with non computing threads having deadlines until *ptime ? // 4. You cannot be sure to get valid values if the project does not support this scheduler // Example: In priority based schedulers the priority should be analyzed only? if ( YASA_CALCPREEMPTIONTIME(scheduler) ) { *ptime=YASA_TIME_INFINITY; for (thread = YASA_TASKSET(scheduler); thread; thread = YASA_NEXT_THREAD(thread) ) { if ( YASA_TEST_TIMER_ARMED(thread) ) { // if computed time=0 -> current deadline of thread is // not set and the thread will be started in future if( ! YASA_COMPUTED_TIME(thread) ) { if ( !newthread || YASA_DEADLINE(thread)+YASA_RESUME_TIME(thread) <

YASA_CURRENT_DEADLINE(newthread) ) if ( *ptime > YASA_RESUME_TIME(thread) ) *ptime=YASA_RESUME_TIME(thread); } else // current deadline is set, maybe thread is waiting for something if ( !newthread || YASA_CURRENT_DEADLINE(thread) < YASA_CURRENT_DEADLINE(newthread) ) if ( *ptime > YASA_RESUME_TIME(thread) ) *ptime=YASA_RESUME_TIME(thread); } } } else YASA_SETTICKSCHEDULINGTIME(ptime, now, scheduler) return newthread; } //////////////////////////////////////////////////////////////////////////////////////////////// int edf_init(YASA_SCHEDULER *scheduler) { return yasa_setdynamicprioritytype(YASA_SYNC_DEADLINE); } //////////////////////////////////////////////////////////////////////////////////////////////// // static definitions const YASA_SCHEDULER_ATTR edf_attr= { 0, // next { 0, "ys_edf" }, // id & name EDF_VERSION, // scheduler version 0, // userdata edf_init, // init() 0, // cleanup() edf_schedule, // schedule() 0, // findpreemptor() };

Abbildung A-1 Quelltext des EDF-Schedulers in YASA

Anhang A.4 - Vergleich dynamischer Prioritäten

94

A.4 Vergleich dynamischer Prioritäten

Abbildung A-2 zeigt einen Auszug aus dem Quelltext „yasa_resourcesdynamic.cpp“, um die Funktion zum Vergleich von dynamischen Prioritäten zu verdeutlichen. In Abhängig-keit vom systemweiten Prioritätstyp erfolgt innerhalb des Switch-Case Blocks ein Ver-gleich der Werte. Besonders markant sind die unterschiedlichen Vergleichsoperationen. Der Rückgabewert der Funktion ist wahr (true), wenn die Priorität von a höher bzw. gleich der von b ist.

/////////////////////////////////////////////////////////////////////////////////////////// // Output: True=prio(a) < prio(b) // False=do block the thread int yasa_cmpdynamicpriority2( YASA_DYN_PRIORITY *a, YASA_DYN_PRIORITY *b) { switch (yasa_syncstruct.prioritytype) { case YASA_SYNC_PRIORITY: if ( a->priority >= b->priority ) return 1; return 0; case YASA_SYNC_DEADLINE: if ( a->deadline <= b->deadline ) return 1; return 0; case YASA_SYNC_LAXITY: if ( a->laxity <= b->laxity ) return 1; return 0; case YASA_SYNC_REQUIREDTIME:if ( a->requiredtime >= b->requiredtime ) return 1; return 0; case YASA_SYNC_SHORTESTTIME:if ( a->shortesttime <= b->shortesttime ) return 1; return 0; default: PRINTK("Dynamically priority %d not supported!\n",

yasa_syncstruct.prioritytype); } return 1; // unknown type -> ignore }

Abbildung A-2: Vergleich dynamischer Prioritäten

Anhang A.5 - XML-Attribute der Konfigurationsdateien

95

A.5 XML-Attribute der Konfigurationsdateien

A.5.1 Executive-Konfigurationsdateien

Die folgende Tabelle zeigt die XML-Attribute, die in einem Executive-Konfigurationsfile benutzt werden dürfen. Alle Attribute sind optional. Wenn sie nicht definiert werden, wird die Default-Einstellung verwendet. Die Grundeinstellung für alle „support_“-Attribute ist no.

XML-Attribut Beschreibung description Enthält eine Beschreibung des Executives. gcc_compiler_options Diese Optionen werden zusätzlich zu den von YASA

erzeugten Optionen in die Makefiles der generierten Projektumgebung eingebunden. Auf diese Weise kann das Compiler-Verhalten beeinflusst werden.

maxcpu Die maximale Anzahl der Prozessoren, die dieses Exe-cutive verarbeiten kann, wird festgelegt. Ist der Wert null, ist die Anzahl der CPU’s variabel und ist abhängig von anderen Faktoren (Projekteinstellung, OS). Wird ein von Null verschiedener Wert n angegeben, kann das Projekt mit diesem Executive nur auf Systemen mit max. n Prozessoren laufen.

support_calcpreemptiontime Gibt an, ob dieses Executive in der Lage ist, eine zu-künftige durch den Scheduler berechnete Unterbrechung eines Threads zu verarbeiten. Mögliche Argumente sind yes oder no (default).

support_timer_tick Das Executive kann periodische Timer-Ticks verarbei-ten, d.h. der Scheduler kann periodisch aufgerufen wer-den.

support_source_codes Dieser Schalter gibt an, ob beim Kompilierungsvorgang die externen Projektquellen miteinbezogen werden dür-fen. Bei der Verwendung von Simulatoren, sind z.B. keine externen Quellen zugelassen.

support_resume_times Wenn diese Option angegeben ist, werden dem generier-ten Quelltext die Aktivierungszeiten der Threads hinzu-gefügt.


96

XML-Attribut Beschreibung support_resource_actions Ist diese Funktion eingeschaltet, werden allen Mutex-

Definitionen die Zeiten zum Setzen und Freigeben von Semaphoren hinzugefügt.

support_scheduling_time Ist diese Option freigeschaltet, wird jeder Scheduling-durchlauf um eine Zeit t verzögert. Diese Zeit wird im Projekt definiert. Auf diese Weise kann der Einfluss eines Schedulers simuliert werden. Für Echtzeitanwen-dung ist die Option nicht geeignet.

support_synchronization_offset Gibt an, ob dieses Executive in der Lage ist, nach dem Start aller Threads eine definierbare Zeit zur Synchronisation zu warten.

support_changeable_cpus Wenn diese Option eingeschaltet ist, können Threads zwischen verschiedenen Prozessoren wechseln, d.h. sie werden je nach Bedarf von einem beliebigen Prozessor ausgeführt.

map_idle_name In einigen Betriebssystemen, z.B. RT-Linux entspricht der Idle-Zustand des OS keinem Ruhezustand, sondern dem Ausführen eines untergeordneten Threads. Um das in den Timingdiagrammen zu verdeutlichen, kann der Name von Idle auf den angegebenen geändert werden.

Tabelle 18: XML-Attribute der Executive-Konfigurationsdateien


97

A.5.2 Scheduler-Konfigurationsdateien

Die folgende Tabelle zeigt die XML-Attribute, die in einem Scheduler-Konfigurationsfile benutzt werden dürfen. Alle Attribute sind optional. Wenn sie nicht definiert werden, wird die Default-Einstellung verwendet.

XML-Attribut Beschreibung description Enthält eine Beschreibung des Schedulers. scheduler_type Legt den Typ eines Schedulers fest. Zur Zeit werden

zwei Typen unterschieden: 0=statisch (default) 1=dynamisch

name Definiert des ausführlichen Namen des Schedulers, der innerhalb der grafischen Benutzeroberfläche als alias für die Kurzschreibweise des Verzeichnisnamens dient.

support_calcpreemptiontime Gibt Auskunft, ob dieser Scheduler in der Lage ist, die Preemptiontime des ausgewählten Prozesses zu berech-nen. Mögliche Argumente sind yes oder no (default).

support_timer_tick Legt fest, ob dieser Scheduler einen periodischen Tick verarbeiten kann. Mögliche Argumente sind yes oder no (default).

Tabelle 19: XML-Attribute der Scheduler-Konfigurationsdateien

Anhang A.6 - Logging-Ereignisse

98

A.6 Logging-Ereignisse

Die Tabelle 20 zeigt alle in YASA vordefinierten Ereignisse, die mitprotokolliert werden können. Nach der Ausführung kann das ausgegebene Logfile in der grafischen Oberfläche ausgewertet werden.

Ereignis Beschreibung THREAD_CREATED Ein Thread wurde erzeugt. THREAD_ACTIVATE Der angegebene Thread wurde aktiviert. Der aktuelle

Taskzustand spielt dabei keine Rolle. THREAD_EXIT Die Exit-Funktion des Threads wurde aufgerufen. Der

Thread wird terminiert. THREAD_START Ein neuer Job eines Threads ist gestartet. THREAD_CONT Der unterbrochene Job wurde fortgesetzt THREAD_SUSPEND Der laufende Thread wird suspendiert. Es wird keine

Aussage über die erfolgreiche bzw. nicht erfolgreiche Abarbeitung des Threads gemacht.

THREAD_TOLERANCE_START Nachdem die Deadline des Threads verpasst wurde, be-ginnt jetzt eine Abarbeitung zwischen Deadline und To-leranz (Robust Scheduling).

THREAD_TOLERANCE_CONT Der im Toleranzbereich arbeitende Thread wurde unter-brochen und wird nun fortgesetzt.

THREAD_TOLERANCE_SUSP Der Thread im Toleranzbereich wurde suspendiert. THREAD_SKIPPED Die Aktivierung eines Threads wird aufgrund einer ver-

passten Deadline ignoriert. THREAD_TYPE Der Thread-Typ hat gewechselt. Als Argument wird der

Typ angegeben. Dieses Ereignis tritt in Systemen wie RT-Linux auf, in denen ein Thread als nicht-periodischer Thread startet und später in den periodi-schen Zustand übergeht.

THREAD_EXCLUDED Während des Schedulings wurde ein Thread vom weite-ren Auswahlverfahren ausgeschlossen bzw. Wieder zu-gelassen (ELLF).

DEADLINE_MATCH Die Zeitschranke des Threads wurde erreicht. DEADLINE_MISS Die Deadline des Threads wurde verpasst. DEADLINE_MISS_DETECTED Eine zukünftige Deadline wird verpasst werden.

Anhang A.6 - Logging-Ereignisse

99

Ereignis Beschreibung DEADLINE_TOLERANCE_MISS Die Toleranz-Deadline wurde ebenso wie die normale

Deadline verpasst. TIME_TO_COMPUTE Gibt bei einem suspendierten bzw. stornierten Thread

an, wie lange dieser Thread noch hätte arbeiten müssen.

MUTEX_CREATED Es wurde ein Mutex erzeugt. MUTEX_DESTROYED Ein Mutex wurde aus dem System entfernt. MUTEX_LOCKED Der laufende Thread hat ein Mutex erfolgreich belegt.

Das Ereignis tritt häufig mit weiteren Ereignissen wie MUTEX_PRIORITY_CHANGED bzw. MUTEX_SYSTEM_CEILING auf.

MUTEX_TRY_N_BLOCKED Der laufende Thread versuchte, ein bereits belegtes Mu-tex zu setzen und wird blockiert.

MUTEX_UNLOCKED Der laufende Thread hat ein gesetztes Mutex wieder freigegeben.

MUTEX_RELOCKED Das angegebene Mutex wurde erneut gesetzt. Dieses Ereignis dient zur Fehlersuche bei Programmen.

MUTEX_NOT_LOCKED Bei der Freigabe des Mutexes wurde festgestellt, dass der Thread das Mutex nicht gesetzt hat.

MUTEX_PRIORITY_CHANGED Die Priorität des Threads wurde durch das Setzen eines Mutexes geändert.

MUTEX_SYSTEM_CEILING Die Systemceilingkonstante wurde durch Setzen bzw. Freigeben eines Mutexes geändert.

MESSAGE Eine Komponente hat eine Textnachricht in das Logfile geschrieben. Der Einsatz dieses Ereignisses kann sehr sinnvoll für die Fehlersuche in Programmen sein.

EMERGENCY_THREAD Durch Verpassen einer Deadline wurde ein Not-fallthread aktiviert.

SCHEDULER_CALLED Der Scheduler wurde aufgerufen. SCHEDULER_FINISHED Der Scheduler hat seine Arbeit beendet. SCHEDULER_SWITCH Ein Schedulerwechsel fand statt. SYNCHRONIZED_START Die Threads wurden synchron gestartet. IDLE_THREAD Vom Scheduler wurde kein Thread ausgewählt, stattdes-

sen wird der Leerlaufthread verwendet.

Tabelle 20: Logging-Ereignisse

Anhang A.7 - Patchvorgang unter RT-Linux

100

A.7 Patchvorgang unter RT-Linux

In diesem Beispiel ist verkürzt der Patchvorgang der CPU-Scheduler Struktur für RT-Linux dargestellt. Diese Struktur enthält alle Daten über den Prozessor wie den Thread-Satz, Flags sowie den aktiven Thread. Die genaue Erläuterung befindet sich in Kap. 4.3.5. struct rtl_sched_cpu_struct { struct rtl_thread_struct *rtl_current; struct rtl_thread_struct rtl_linux_task; struct rtl_thread_struct *rtl_task_fpu_owner; struct rtl_thread_struct *rtl_tasks; // the queue of RT tasks struct rtl_thread_struct *rtl_new_tasks; clockid_t clock; spinlock_t rtl_tasks_lock; int sched_flags; int sched_user[4]; };

Abbildung A-3: Scheduler-Struktur vor dem Patch der Scheduler-Struktur

struct rtl_sched_cpu_struct { struct rtl_thread_struct *rtl_current; struct rtl_thread_struct rtl_linux_task; struct rtl_thread_struct *rtl_task_fpu_owner; struct rtl_thread_struct *rtl_tasks; // the queue of RT tasks struct rtl_thread_struct *rtl_new_tasks; clockid_t clock; spinlock_t rtl_tasks_lock; int sched_flags; int sched_user[4]; /* YASA extensions --> */ YASA_SCHED_CPU_STRUCT /* <-- YASA extensions */ };

Abbildung A-4: Scheduler-Struktur nach dem Patch der Scheduler-Struktur

#define YASA_SCHED_CPU_STRUCT \ /* static member functions */ \ YASA_LOGFILE logfile; /* yasa internal log file */ \ YASA_TIME tick; /* tick value of scheduler */ \ int yasa_version; /* yasa version */ \ int cpu; /* number of cpu */ \ int calcpreemptiontime; /* calculate preemption time */ \ /* dynamic members */ \ YASA_TIME schedulerstart; /* start time of scheduler */ \ YASA_TIME schedulerend; /* end time of scheduler */ \ YASA_TIME nextschedulingtime; /* next calling time of scheduler */ \ const struct yasa_scheduler_attr \

*yasa_schedulerattr; /* ptr to structure of scheduler */ \ YASA_THREAD* (*schedule)(struct rtl_sched_cpu_struct *scheduler, \ const YASA_TIME *now, YASA_TIME *ptime); /* scheduling function */ \ YASA_TIME yasa_startofthread; /* When did the current thread get the cpu? */ \ YASA_TIME yasa_startofthreadtick; /* start of current time tick. */ \ void *yasa_schedulerdata; /* can be used by scheduler, default=0 */

Abbildung A-5: Definition des Makros YASA_SCHED_CPU_STRUCT

Anhang A.7 - Patchvorgang unter RT-Linux

101

Während der Kompilierung wird das Makro ausgewertet und entsprechend eingesetzt. Für den Anwender unsichtbar entsteht intern die folgende Scheduler-Struktur. struct rtl_sched_cpu_struct { struct rtl_thread_struct *rtl_current; struct rtl_thread_struct rtl_linux_task; struct rtl_thread_struct *rtl_task_fpu_owner; struct rtl_thread_struct *rtl_tasks; // the queue of RT tasks struct rtl_thread_struct *rtl_new_tasks; clockid_t clock; spinlock_t rtl_tasks_lock; int sched_flags; int sched_user[4]; /* YASA extensions --> */ /* static member functions */ YASA_LOGFILE logfile; /* yasa internal log file */ YASA_TIME tick; /* tick value of scheduler */ int yasa_version; /* yasa version */ int cpu; /* number of cpu */ int calcpreemptiontime; /* calculate preemption time */ /* dynamic members */ YASA_TIME schedulerstart; /* start time of scheduler */ YASA_TIME schedulerend; /* end time of scheduler */ YASA_TIME nextschedulingtime; /* next calling time of scheduler */ const struct yasa_scheduler_attr

*yasa_schedulerattr; /* ptr to structure of scheduler */ YASA_THREAD* (*schedule)(struct rtl_sched_cpu_struct *scheduler, const YASA_TIME *now, YASA_TIME *ptime); /* scheduling function */ YASA_TIME yasa_startofthread; /* When did the current thread get the cpu? */ YASA_TIME yasa_startofthreadtick; /* start of current time tick. */ void *yasa_schedulerdata; /* can be used by scheduler, default=0 */ /* <-- YASA extensions */ };

Abbildung A-6: Scheduler-Struktur während des Kompilierens

Anhang A.8 - Generierte Quelltexte

102

A.8 Generierte Quelltexte

Der folgende Quelltext wurde von YASA für die Verwendung mit dem Executive „Simula-tor“ generiert und erzeugte das Timingverhalten, dass in Abbildung 2.4-2 dargestellt ist. //////////////////////////////////////////////////////////////////////////////////////////////// // // YASA taskset declarations. Do not edit! This file was created by YASA 2 automatically. // // Project : Priority_Inversion // Author : Jan Blumenthal // Filename : $(YASA_PROJECT)/Simulator (Prio)/yasa_projecttaskset.h // Creation date : Wed Jun 5 00:00:00 2002 // Last modified : Wed Jun 5 00:00:00 2002 // //////////////////////////////////////////////////////////////////////////////////////////////// // Sammlung von Beispielen, die Probleme bei verschiedenen Synchronisationsprotokollen aufzeigen // // Example taken from lectiure "EBys7-Schedulinganalyse", F. Golatowski, University of Rostock // #ifndef YASA_PROJECT_TASKSET_INCLUDE #define YASA_PROJECT_TASKSET_INCLUDE //////////////////////////////////////////////////////////////////////////////////////////////// // project settings #define YP_SYNCHRONIZATION_OFFSET 0 #define YP_ENDTIME 30000 //////////////////////////////////////////////////////////////////////////////////////////////// // Mapping of attribut structures #define YP_ENVIRONMENT_ATTR environmentattr #define YP_SCHEDULING_ATTR schedulerattr #define YP_THREAD_ATTR threadattr1 #define YP_MUTEX_ATTR mutexattr1 //////////////////////////////////////////////////////////////////////////////////////////////// // mutex settings #define MUTEXID_MUTEX_1 1 #endif // ifndef YASA_PROJECT_TASKSET_INCLUDE

Abbildung A-7: Beispiel einer generierten Header-Datei

//////////////////////////////////////////////////////////////////////////////////////////////// // // YASA taskset definitions. Do not edit! This file was created by YASA 2 automatically. // // Project : Priority_Inversion // Author : Jan Blumenthal // Filename : $(YASA_PROJECT)/Simulator_(Prio)/yasa_projecttaskset.c // Creation date : Wed Jun 5 00:00:00 2002 // Last modified : Wed Jun 5 00:00:00 2002 // //////////////////////////////////////////////////////////////////////////////////////////////// // Sammlung von Beispielen, die Probleme bei verschiedenen Synchronisationsprotokollen aufzeigen // // Example taken from lecture "EBys7-Schedulinganalyse", F. Golatowski, University of Rostock ////////////////////////////////////////////////////////////////////////////////////////////////


103

// project settings #include <yasa/yasa.h> const extern YASA_SCHEDULER_ATTR prio_attr; //////////////////////////////////////////////////////////////////////////////////////////////// // Creation array of mutex "Mutex_1" YASA_MUTEX_ATTR mutexattr1= { 0, // Next mutex {

MUTEXID_MUTEX_1, // Id of mutex "Mutex_1" // Name of mutex }, YASASP_NOTHING, // Synchronization protocol: No synchronization protocol used 2, // Priority ceiling { 0 // Preempt ceiling } }; //////////////////////////////////////////////////////////////////////////////////////////////// // Resource actions of thread "P2(Low)" YASA_RESOURCEVECTOR threadattr2resourceactions[]= { { (void*)MUTEXID_MUTEX_1, YASAA_MUTEX_LOCK , 1000 }, { (void*)MUTEXID_MUTEX_1, YASAA_MUTEX_UNLOCK , 4000 }, { 0 , 0 , YASA_TIME_INFINITY } }; //////////////////////////////////////////////////////////////////////////////////////////////// // Creation array of thread "P2(Low)" YASA_THREAD_ATTR threadattr2= { 0, // Next thread { 2, // Id of thread "P2(Low)" // Name of thread }, YASA_THREAD_PERIODIC, // Type of thread 1, // Priority 10000, // Period 5000, // Required time 10000, // Deadline 0, // Deadline tolerance 0, // Offset 0, // Resume vector threadattr2resourceactions, // Resource vector 0, // CPU YASA_DL_IGNORE, // Deadline behaviour 0, // Emergency thread 0, // Init function 0, // Execute function 0 // Cleanup function }; //////////////////////////////////////////////////////////////////////////////////////////////// // Resource actions of thread "P1(High)" YASA_RESOURCEVECTOR threadattr1resourceactions[]= { { (void*)MUTEXID_MUTEX_1, YASAA_MUTEX_LOCK , 1000 }, { (void*)MUTEXID_MUTEX_1, YASAA_MUTEX_UNLOCK , 2000 }, { 0 , 0 , YASA_TIME_INFINITY } }; //////////////////////////////////////////////////////////////////////////////////////////////// // Creation array of thread "P1(High)" YASA_THREAD_ATTR threadattr1= { &threadattr2, // Next thread


104

{ 1, // Id of thread "P1(High)" // Name of thread }, YASA_THREAD_PERIODIC, // Type of thread 2, // Priority 10000, // Period 3000, // Required time 10000, // Deadline 0, // Deadline tolerance 2000, // Offset 0, // Resume vector threadattr1resourceactions, // Resource vector 0, // CPU YASA_DL_IGNORE, // Deadline behaviour 0, // Emergency thread 0, // Init function 0, // Execute function 0 // Cleanup function }; //////////////////////////////////////////////////////////////////////////////////////////////// // Scheduler attributes const YASA_SCHEDULING_ATTR schedulerattr[YP_MAX_CPU]= { { &prio_attr , YP_ENDTIME, 1000 , 0 }, }; //////////////////////////////////////////////////////////////////////////////////////////////// // Environment attributes YASA_ENVIRONMENT_ATTR environmentattr= { YP_SCHEDULING_ATTR, // Scheduling attributs #ifdef YP_THREAD_ATTR &YP_THREAD_ATTR, // Thread attributes #else 0, #endif #ifdef YP_MUTEX_ATTR &YP_MUTEX_ATTR, // Mutex attributes #else 0, #endif YP_SYNCHRONIZATION_OFFSET, // Synchronization offset };

Abbildung A-8: Beispiel einer generierten Quelltext-Datei

Anhang A.9 - Logfile der Prioritäteninversion

105

A.9 Logfile der Prioritäteninversion

Das folgende Logfile zeigt die gekürzten Protokollinformationen aus der Simulation der Prioritäteninversion aus Abbildung 2.4-2. Yasa version : 1.0 Executive name : simulator Executive version : 1.2 CPU number : 0 Scheduler called : 30 Max. logfile size : 100000 Logfile position : 3324 Scheduler start : 0 Scheduled end time : 30000 Current end time : 30000 Duration : 30000 Scheduler tick : 1000 Scheduling time : 0 Calculate preemption time : no Name of scheduler : ys_prio Version of scheduler : 1.0 YL: 0 thread: -2, 33: Synchronized start YL: 0 thread: -1, 33: Synchronized start YL: 0 thread: -3, 1: Thread_created , thread id : 1, name:"P1(High)" YL: 0 thread: 1, 33: Synchronized start YL: 0 thread: -3, 1: Thread_created , thread id : 2, name:"P2(Low)" YL: 0 thread: 2, 33: Synchronized start YL: 0 thread: -3, 18: Mutex_created , mutex id : 1, name:"Mutex_1",no protocol YL: 0 thread: -2, 30: Scheduler_called , scheduled start: 0 YL: 0 thread: 2, 2: Thread_activate , sch. activation: 0 YL: 0 thread: -2, 31: Scheduler_finished , next scheduling: 1000 YL: 0 thread: -2, 32: Thread_switch YL: 0 thread: 2, 4: Thread_started , activation time: 0 YL: 1000 thread: 2, 20: Mutex_locked , mutex id : 1 YL: 1000 thread: -2, 30: Scheduler_called , scheduled start: 1000 YL: 1000 thread: -2, 31: Scheduler_finished , next scheduling: 2000 YL: 1000 thread: 2, 5: Thread_continues , activation time: 0 YL: 2000 thread: -2, 30: Scheduler_called , scheduled start: 2000 YL: 2000 thread: 1, 2: Thread_activate , sch. activation: 2000 YL: 2000 thread: -2, 31: Scheduler_finished , next scheduling: 3000 YL: 2000 thread: -2, 32: Thread_switch YL: 2000 thread: 1, 4: Thread_started , activation time: 2000 YL: 3000 thread: 1, 21: Mutex_try_n_blocked , mutex id : 1 YL: 3000 thread: -2, 30: Scheduler_called , scheduled start: 3000 YL: 3000 thread: -2, 31: Scheduler_finished , next scheduling: 4000 YL: 3000 thread: -2, 32: Thread_switch YL: 3000 thread: 2, 5: Thread_continues , activation time: 0 YL: 4000 thread: -2, 30: Scheduler_called , scheduled start: 4000 YL: 4000 thread: -2, 31: Scheduler_finished , next scheduling: 5000 YL: 4000 thread: 2, 5: Thread_continues , activation time: 0 YL: 5000 thread: 2, 22: Mutex_unlocked , mutex id : 1 YL: 5000 thread: -2, 30: Scheduler_called , scheduled start: 5000 YL: 5000 thread: -2, 31: Scheduler_finished , next scheduling: 6000 YL: 5000 thread: -2, 32: Thread_switch YL: 5000 thread: 1, 5: Thread_continues , activation time: 2000 YL: 5000 thread: 1, 20: Mutex_locked , mutex id : 1 YL: 6000 thread: 1, 22: Mutex_unlocked , mutex id : 1 YL: 6000 thread: -2, 30: Scheduler_called , scheduled start: 6000 YL: 6000 thread: -2, 31: Scheduler_finished , next scheduling: 7000 YL: 6000 thread: 1, 5: Thread_continues , activation time: 2000 YL: 7000 thread: 1, 13: Deadline_match , deadline : 12000 YL: 7000 thread: 1, 6: Thread_suspended , activation time: 2000 YL: 7000 thread: -2, 30: Scheduler_called , scheduled start: 7000 YL: 7000 thread: -2, 31: Scheduler_finished , next scheduling: 8000 YL: 7000 thread: -2, 32: Thread_switch YL: 7000 thread: 2, 5: Thread_continues , activation time: 0 YL: 8000 thread: 2, 13: Deadline_match , deadline : 10000 YL: 8000 thread: 2, 6: Thread_suspended , activation time: 0 YL: 8000 thread: -2, 30: Scheduler_called , scheduled start: 8000 YL: 8000 thread: -2, 31: Scheduler_finished , next scheduling: 9000 YL: 8000 thread: -1, 34: Idle_thread , param : YL: 9000 thread: -2, 30: Scheduler_called , scheduled start: 9000 YL: 9000 thread: -2, 31: Scheduler_finished , next scheduling: 10000 YL: 9000 thread: -1, 34: Idle_thread , param : YL: 10000 thread: -2, 30: Scheduler_called , scheduled start: 10000 YL: 10000 thread: 2, 2: Thread_activate , sch. activation: 10000 YL: 10000 thread: -2, 31: Scheduler_finished , next scheduling: 11000

Anhang A.9 - Logfile der Prioritäteninversion

106

YL: 10000 thread: -2, 32: Thread_switch YL: 10000 thread: 2, 4: Thread_started , activation time: 10000 YL: 11000 thread: 2, 20: Mutex_locked , mutex id : 1 YL: 11000 thread: -2, 30: Scheduler_called , scheduled start: 11000 YL: 11000 thread: -2, 31: Scheduler_finished , next scheduling: 12000 YL: 11000 thread: 2, 5: Thread_continues , activation time: 10000 YL: 12000 thread: -2, 30: Scheduler_called , scheduled start: 12000 YL: 12000 thread: 1, 2: Thread_activate , sch. activation: 12000 YL: 12000 thread: -2, 31: Scheduler_finished , next scheduling: 13000 YL: 12000 thread: -2, 32: Thread_switch YL: 12000 thread: 1, 4: Thread_started , activation time: 12000 YL: 13000 thread: 1, 21: Mutex_try_n_blocked , mutex id : 1 YL: 13000 thread: -2, 30: Scheduler_called , scheduled start: 13000 YL: 13000 thread: -2, 31: Scheduler_finished , next scheduling: 14000 YL: 13000 thread: -2, 32: Thread_switch YL: 13000 thread: 2, 5: Thread_continues , activation time: 10000 YL: 14000 thread: -2, 30: Scheduler_called , scheduled start: 14000 YL: 14000 thread: -2, 31: Scheduler_finished , next scheduling: 15000 YL: 14000 thread: 2, 5: Thread_continues , activation time: 10000 YL: 15000 thread: 2, 22: Mutex_unlocked , mutex id : 1 YL: 15000 thread: -2, 30: Scheduler_called , scheduled start: 15000 YL: 15000 thread: -2, 31: Scheduler_finished , next scheduling: 16000 YL: 15000 thread: -2, 32: Thread_switch YL: 15000 thread: 1, 5: Thread_continues , activation time: 12000 YL: 15000 thread: 1, 20: Mutex_locked , mutex id : 1 YL: 16000 thread: 1, 22: Mutex_unlocked , mutex id : 1 YL: 16000 thread: -2, 30: Scheduler_called , scheduled start: 16000 YL: 16000 thread: -2, 31: Scheduler_finished , next scheduling: 17000 YL: 16000 thread: 1, 5: Thread_continues , activation time: 12000 YL: 17000 thread: 1, 13: Deadline_match , deadline : 22000 YL: 17000 thread: 1, 6: Thread_suspended , activation time: 12000 YL: 17000 thread: -2, 30: Scheduler_called , scheduled start: 17000 YL: 17000 thread: -2, 31: Scheduler_finished , next scheduling: 18000 YL: 17000 thread: -2, 32: Thread_switch YL: 17000 thread: 2, 5: Thread_continues , activation time: 10000 YL: 18000 thread: 2, 13: Deadline_match , deadline : 20000 YL: 18000 thread: 2, 6: Thread_suspended , activation time: 10000 YL: 18000 thread: -2, 30: Scheduler_called , scheduled start: 18000 YL: 18000 thread: -2, 31: Scheduler_finished , next scheduling: 19000 YL: 18000 thread: -1, 34: Idle_thread , param : YL: 19000 thread: -2, 30: Scheduler_called , scheduled start: 19000 YL: 19000 thread: -2, 31: Scheduler_finished , next scheduling: 20000 YL: 19000 thread: -1, 34: Idle_thread , param : YL: 20000 thread: -2, 30: Scheduler_called , scheduled start: 20000 YL: 20000 thread: 2, 2: Thread_activate , sch. activation: 20000 YL: 20000 thread: -2, 31: Scheduler_finished , next scheduling: 21000 YL: 20000 thread: -2, 32: Thread_switch …. YL: 25000 thread: 1, 5: Thread_continues , activation time: 22000 YL: 25000 thread: 1, 20: Mutex_locked , mutex id : 1 YL: 26000 thread: 1, 22: Mutex_unlocked , mutex id : 1 YL: 26000 thread: -2, 30: Scheduler_called , scheduled start: 26000 YL: 26000 thread: -2, 31: Scheduler_finished , next scheduling: 27000 YL: 26000 thread: 1, 5: Thread_continues , activation time: 22000 YL: 27000 thread: 1, 13: Deadline_match , deadline : 32000 YL: 27000 thread: 1, 6: Thread_suspended , activation time: 22000 YL: 27000 thread: -2, 30: Scheduler_called , scheduled start: 27000 YL: 27000 thread: -2, 31: Scheduler_finished , next scheduling: 28000 YL: 27000 thread: -2, 32: Thread_switch YL: 27000 thread: 2, 5: Thread_continues , activation time: 20000 YL: 28000 thread: 2, 13: Deadline_match , deadline : 30000 YL: 28000 thread: 2, 6: Thread_suspended , activation time: 20000 YL: 28000 thread: -2, 30: Scheduler_called , scheduled start: 28000 YL: 28000 thread: -2, 31: Scheduler_finished , next scheduling: 29000 YL: 28000 thread: -1, 34: Idle_thread , param : YL: 29000 thread: -2, 30: Scheduler_called , scheduled start: 29000 YL: 29000 thread: -2, 31: Scheduler_finished , next scheduling: 30000 YL: 29000 thread: -1, 34: Idle_thread , param : YL: 30000 thread: 1, 3: Thread_exiting , retvalue : 0x1 YL: 30000 thread: 2, 3: Thread_exiting , retvalue : 0x1

Abbildung A-9: Logfile aus Abbildung 2.4-2

Anhang A.10 - Konfiguration der Schedulingumgebung

107

A.10 Konfiguration der Schedulingumgebung

Die Abbildung A-10 zeigt den Ablauf der Konfiguration für eine erbbare Eigenschaft, die global im Projekt definiert werden kann, letztendlich aber von den Gegebenheiten des Exe-cutives bzw. des Schedulers maßgeblich beeinflusst wird.

Verwendung der Grundeinstellungdes Executives

Verwendung derGrundeinstellung des Schedulers

Konfiguration durch Executivezugelassen?

Konfiguration durch Schedulerzugelassen?

Überprüfung auf Executive-Grenzwerte und Korrektur

Konfiguration der Eigenschaft imProjekt

Überprüfung auf Scheduler-Grenzwerte und Korrektur

Individuelle Konfiguration

Nächster Scheduler

Abbildung A-10: Konfiguration der vererbbarer Projekteigenschaften

Anhang A.11 - Darstellung von Zeitdiagrammen in YASA

108

A.11 Darstellung von Zeitdiagrammen in YASA

Die folgenden Zeitdiagramme zeigen die unterschiedlichsten Darstellungsformen von Pro-jekten in YASA. Das zugrunde liegende Projekt ist in Beispiel 4 beschrieben. Die Sema-phoren nutzen das KPP als Synchronisationsprotokoll. In Abbildung A-11 ist das Zeitdiagramm dargestellt, das unter Verwendung des prioritätsbasierten Schedulers entsteht. Das Diagramm in Abbildung A-12 zeigt den gering-fügig anderen Verlauf unter ELLF.

Abbildung A-11: Beispiel 4 in Thread-Ordnung (Prioritätsbasierter Scheduler)

Abbildung A-12: Beispiel 4 in Thread Ordnung (ELLF-Scheduler)


109

Abbildung A-13: Beispiel 4, Threads einzeln in Environment-Ordnung

Das Beispiel 4 wurde insgesamt mit vier verschiedenen Environments ausgeführt, die als Executive den Simulator nutzen und alle verschiedene Scheduler (den prioritätsbasierten Scheduler, Earliest Deadline First, Enhanced Least Laxity First und Least Laxity First) ein-setzten. Die Betrachtung in Environment-Ordnung eignet sich besonders gut, um feine Un-terschiede zwischen den Umgebungen zu ermitteln. In Abbildung A-13 ist für jeden Thread ein Zeitdiagramm gezeigt, das das Verhalten dieses Threads in den vier Environments dar-stellt. Die Verwendung des Kernel Priority Protocols führt hier zu sehr ähnlichen Ergebnissen, da die Scheduler kaum nach ihren Schedulingkriterien entscheiden dürfen. Besonders beach-


110

tenswert ist der Jitter der Prozesse P0 und P1 zum Zeitpunkt t=2000 bzw. t=4000. Er tritt auf, weil sich P2 in einem kritischen Abschnitt befindet und nicht unterbrochen werden darf. In Abbildung A-14 ist für jedes Mutex ein Zeitdiagramm dargestellt, das die Möglichkeit bietet, die durchschnittlichen Belegungszeiten in den verschiedenen Environments zu ana-lysieren.

Abbildung A-14: Beispiel 4, Mutexe einzeln in Environment-Ordnung

Das Zeitdiagramm in Abbildung A-15 zeigt die CPU-Informationen in Environment-Ordnung an. Auf diese Weise kann sehr einfach die durchschnittliche Belegung der CPU und das Verhältnis zwischen Leerlauf-, System- und Nutzzeit in den unterschiedlichen En-vironments ermittelt werden.

Abbildung A-15: Beispiel 4, CPU einzeln in Environment-Ordnung

Anhang A.12 - Ausgewählte Klassendiagramme

111

A.12 Ausgewählte Klassendiagramme

YObject

YCPULogFile

YDerivedObject

YEnvironment

YFilePath

YLogFileMutex

YLogFileTask

YMutex

YPlugIn

YProject

YProjectLogFile

YResourceAction

YResult

YResults

YResumeTime

YScheduler

YSet

YTask

YWorkSpace

YWorkSpaceManager

YSet


YEnvironmentSet

YFilePathSet

YLogFileMutexSet

YLogFileTaskSet

YMutexSet

YPlugInList

YProjectSet

YResourceActionSet

YResumeTimeSet

YSchedulerSet

YTaskSet

YObject

Abbildung A-16: Vererbungsdiagramm der Klasse YObject

Abbildung A-17: Vererbungsdiagramm der Klasse YSet

Das YObject (Abbildung A-16) ist die Basisklasse aller wichtigen Klassen in YASA. Sie ist vom QObject abgeleitet und bietet vordefinierte Mechanismen zur Benachrichtigung über Datenänderungen. Die Klasse YSet (Abbildung A-17) ist die Basisklasse zur Verwaltung von Listen in YASA. Sie bietet neben den geerbten auch zusätzliche Benachrichtigungs-mechanismen, die z.B. über das Hinzufügen bzw. Entfernen eines Items informieren.

$classYCPULogFile.html

$classYDerivedObject.html

$classYEnvironment.html

$classYFilePath.html

$classYLogFileMutex.html

$classYLogFileTask.html

$classYMutex.html

$classYPlugIn.html

$classYProject.html

$classYProjectLogFile.html

$classYResourceAction.html

$classYResult.html

$classYResults.html

$classYResumeTime.html

$classYScheduler.html

$classYSet.html

$classYTask.html

$classYWorkSpace.html

$classYWorkSpaceManager.html


$classYEnvironmentSet.html

$classYFilePathSet.html

$classYLogFileMutexSet.html

$classYLogFileTaskSet.html

$classYMutexSet.html

$classYPlugInList.html

$classYProjectSet.html

$classYResourceActionSet.html

$classYResumeTimeSet.html

$classYSchedulerSet.html

$classYTaskSet.html

$classYObject.html


112

YProject (Abbildung A-18) repräsentiert ein Projekt innerhalb eines Arbeitsbereiches in YASA. Die Klasse bildet eine Komposition mit weiteren Klassen, die der detaillierten Kon-figuration der Projektattribute dienen. Alle Klassen sind untereinander durch Assoziationen verbunden, um die Datenkonsistenz zu bewahren.

YProject

YProjectLogFile

project

YObject

YResults

parent

YHeaderSet headerset

YASA_TICKtimertick

YTIME

endtime

YASA_MAXCPUmaxcpu

YASA_CALCPREEMPTIONTIME

calcpreemptiontime

YSourceSet

sourceset

YMutexSet

mutexset

YTaskSet

taskset

YString

projectdir

YEnvironmentSet

environmentset

results

projectlogfile

Abbildung A-18: Kompositionsdiagramm der Klasse YProject

Ein Projekt besteht neben den Projektattributen aus einer Liste der definierten Environ-ments (YEnvironment). Diese Environments (Abbildung A-19) enthalten die Konfiguration für die Ausführung des Projekts in einer Systemumgebung. Zur automatischen Übernahme der Projekteinstellungen sind einige Attribute wie YASA_CALCPREEMPTIONTIME und YASA_TIMERTICK mit den korrespondierenden Attributen in YProject assoziiert. Alle Environments enthalten zur Verwaltung der Scheduler eine Liste der definierten Y-Scheduler (Abbildung A-20). Diese enthalten ebenfalls Attribute für CPT und Timer-Tick, die mit dem YEnvironment assoziiert sind.

$classYProjectLogFile.html

$classYObject.html

$classYResults.html

$classYHeaderSet.html


$classYTIME.html

$classYASA__MAXCPU.html

$classYASA__CALCPREEMPTIONTIME.html

$classYSourceSet.html

$classYMutexSet.html

$classYTaskSet.html

$classYString.html

$classYEnvironmentSet.html


113

YEnvironment

YObject

YFilePath

YResultsparent

YASA_TICKtimertick

YASA_SCHEDULINGTIME schedulingtime

YASA_MAXCPU maxcpu

YExecutivePlugIn

executiveYString

logfilenamegcccompileroptions

idlenamegcccompileroptions

YASA_TIMERTICK

support_timertick


logfile


calcpreemptiontime

logfilepath

YOutput

output

YSchedulerSet

schedulerset

results

YASA_SYNCHRONIZATIONOFFSET

synchronizationoffset

Abbildung A-19: Kompositionsdiagramm der Klasse YEnvironment

YScheduler

YObject

YSet

parent

YPlugIn

YActions

actions

set

YASA_TICK

timertick

min_timertick

YTIME

YASA_TIMERTICK

support_timertick

YDerivedType< bool > derivedparent


calcpreemptiontime

YSchedulerPlugIn

scheduler

YASA_SCHEDULERTYPE

type

Abbildung A-20: Kompositionsdiagramm der Klasse YScheduler

$classYObject.html

$classYFilePath.html

$classYResults.html


$classYASA__SCHEDULINGTIME.html

$classYASA__MAXCPU.html

$classYExecutivePlugIn.html

$classYString.html

$classYASA__TIMERTICK.html



$classYOutput.html

$classYSchedulerSet.html

$classYASA__SYNCHRONIZATIONOFFSET.html

$classYObject.html

$classYSet.html

$classYPlugIn.html

$classYActions.html


$classYTIME.html

$classYASA__TIMERTICK.html



$classYSchedulerPlugIn.html

$classYASA__SCHEDULERTYPE.html


114

YTask YTaskSet

parenttask

YObject

YResourceActionSetresourceactionset

YASA_OFFSET offset

YASA_SERVERTYPEservertype

YASA_LAXITYlaxity

YASA_PERIODperiod

YASA_TASKTYPEtasktype

subtasksetparenttaskset

YASA_DLBEHAVIOURdeadlinebehaviour

YASA_PRIORITY

priority

YString

function_cleanupfunction_execute

function_init

YResumeTimeSet

resumetimeset

YASA_CPU

cpu

YASA_DEADLINE

deadline

YASA_DEADLINETOLERANCE

deadlinetolerance

YASA_REQUIREDTIME

requiredtime

Abbildung A-21: Kompositionsdiagramm der Klasse YTask

$classYTaskSet.html

$classYObject.html

$classYResourceActionSet.html

$classYASA__OFFSET.html

$classYASA__SERVERTYPE.html

$classYASA__LAXITY.html

$classYASA__PERIOD.html

$classYASA__TASKTYPE.html

$classYASA__DLBEHAVIOUR.html

$classYASA__PRIORITY.html

$classYString.html

$classYResumeTimeSet.html

$classYASA__CPU.html

$classYASA__DEADLINE.html

$classYASA__DEADLINETOLERANCE.html

$classYASA__REQUIREDTIME.html

Thesen zur Diplomarbeit

1. Echtzeitsysteme sind zeitkritische Anwendungen, deren Zeitschranken eingehalten wer-den müssen. Es werden harte Echtzeitsysteme mit festen Zeitschranken und weiche Echtzeitsysteme mit fließenden Zeitschranken unterschieden.

2. Die Verteilung der einzelnen Prozesse auf die Prozessoren übernimmt ein Scheduler. Es werden zyklische, statische und dynamische Scheduler unterschieden. In modernen Echtzeitbetriebssystemen werden zumeist prioritätsbasierte statische Scheduler einge-setzt.

3. Scheduler sind Bestandteil des Betriebssystems und mit ihm fest verwoben. Sie können in der Regel nicht ausgewechselt werden.

4. Synchronisationsprotokolle werden eingesetzt, um negative Effekte wie die Prioritäten-inversion und Deadlocks zu vermeiden.

5. Für die Optimierung des Schedulingverhaltens sind Kenntnisse über die Scheduling-umgebung des Betriebssystems notwendig. Für die korrekte Auswertung ist eine Proto-kollierung und Analyse des Schedulingverhaltens der Prozesse notwendig.

6. Das Framework YASA stellt eine umfangreiche Entwicklungsumgebung für Echtzeit-anwendungen mit dem Ziel der Optimierung des Schedulingverhaltens zur Verfügung.

7. Der Einbau neuer Scheduler und Synchronisationsprotokolle erfordert den Zugriff auf die Quelltexte des Systems. Die Änderung der Betriebssysteme geht einher mit der Er-weiterung der systemeigenen Schnittstellen, um die zusätzlichen Eigenschaften zu im-plementieren.

8. Die Kapselung und Erweiterung der originalen Schedulingumgebung eines Betriebssys-tems erfolgt durch Executives. Sie müssen zusätzliche Funktionen wie einen Logging-Mechanismus zur Evaluierung von Projekten enthalten.

9. Die Einführung plattformunabhängiger Scheduler verlangt eine klare Schnittstellen-definition zur Schedulingumgebung. Sie muss durch die Executives gewährleistet wer-den.

10. In YASA 2 ist die Konfiguration umfangreicher Projekte möglich. Die Definition der Prozesse umfasst Eigenschaften wie Priorität, Deadline, Offset und die Angabe von Startfunktionen. Ferner können Mutexe mit entsprechenden Synchronisationsprotokol-len angelegt werden. Das Festlegen einer Systemumgebung mit der Wahl des Executi-ves und der Scheduler rundet die Konfiguration ab.

11. Vor der Ausführung von Projekten werden Arbeitsverzeichnisse mit generierten Quell-texten und Startskripten in Abhängigkeit vom gewählten Executive erzeugt.

12. Der Start von Projekten wird von den Startup-Codes der Executives übernommen, um die neuen Schedulingumgebungen korrekt zu initialisieren. Nach dem Projektdurchlauf wird ein Logfile geschrieben.

13. Die Auswertung erfolgt in dem grafischen Front-End durch das Analysieren des Log-files. Umfangreiche Darstellungen können in grafischer und tabellarischer Form vorge-nommen werden. Bei unzureichenden Ergebnissen besteht die Möglichkeit, die Projekt-einstellungen zu optimieren und den Projektlauf zu wiederholen.

14. Die Verwendung der Klassenbibliothek Qt gestattet die Programmierung plattform-unabhängiger Anwendungen für Windows, UNIX, Mac sowie eingebetteten Systemen.

Erklärung

Ich erkläre, diese Diplomarbeit selbstständig und ohne fremde Hilfe angefertigt und die benutzten Unterlagen vollständig angegeben zu haben.

Ort, Datum: Rostock, 8. Juli 2002 Jan Blumenthal

diplomarbeit - uni-rostock.de

Documents