Vorlesung Echtzeitbetriebssysteme. Sommersemester FH-Isny

Transkript

1 Vorlesung Echtzeitbetriebssysteme Sommersemester 2006 FH-Isny Dipl. Inf. B. Gerum NTA Isny RTOS V2.11 1

2 1.0 Einführung Echtzeitsysteme - Echtzeitbetriebssysteme Definition eines Echtzeitsystems Arten des Vorgehens Technischer Prozess Prozesse und Threads Standardisierte Ansätze (POSIX) Aufgaben von Betriebssystemen Beispiel aus der Praxis (Liebherrsteuerung) Prozesse Prozessauswahl (Scheduling) Prozesszustand Prozess-ID Priorität Prozess-Kontrollblock Wichtige Zeiten (Planungsgrößen) - Zeitparameter Scheduling Strategien FIFO-Scheduling Kürzester Auftrag zuerst (Shortest Job First SJF) Reih - Um - Strategie (Round Robin RU) Static Offline Scheduling Earliest Deadline First (EDF) Rate Monotonic Scheduling RM (Liu, Layland) Least Laxity Strategie Kombination mehrerer Strategien Beispiele für Schedulingverfahren (QNX, RTXDOS) Bedingung für erfolgreiche Ablaufplanung (Schedulability) Beispiele Prozess - Synchronisation und Kommunikation Zeitkritische Abläufe Erzwingen des wechselseitigen Ausschlusses Das Semaphor - Konzept (Dijkstra 1965) Mutex Objekte Verklemmung (Deadlock) und Prioritäts - Inversion Priorität-Erhöhung/-Vererbung Priority Ceiling Protocol Events Nachrichtenaustausch Gemeinsamer Speicher Botschafts-Warteschlangen Spezialisierte Warteschlangen (Pipes) Interruptverarbeitung Systemuhren und Zeitgeber Speicherverwaltung Lösungsmöglichkeiten Klassische Echtzeit-BS Betriebssystemerweiterungen für WinNT/2k Aufbau eines Realtimesystems Auswahlhilfe für Echtzeitbetriebssysteme Anhang A) Literatur Anhang B) Echtzeitbetriebssyteme (Übersicht) NTA Isny RTOS V2.11 2

3 Änderungsindex: Datum Version Änderung verantwortlich V Entwurf Ge V1.1 Überarbeitung + Ergänzung Ge V1.12 Reihenfolge geändert Ge V1.14 Systemmodell angepasst Ge V Beispiel überarbeitet Ge V1.16 Überarbeitung POSIX Ge V1.17 Beispiel Seite 40 korrigiert Ge V2.0 Skript überarbeitet Ge Wichtige Änderungen 1.1 Grundlagen Echtzeitsysteme 1.2 Grundlagen und Definitionen Echtzeitbetriebssysteme 2.0 Schedulingverfahren ergänzen (Laxity) 3.0 Synchronisation vereinfachen 4.0 Einfaches Minibetriebssystem 5.0 Zusätzliche Eigenschaften (Modularer Aufbau, Netzwerkfunktionalität), Mögliche Realisierungen einfaches Echtzeitbetriebssystem bietet - Multitasking mit entsprechender Schedulingstrategie - Interrupt und Speicherverwaltung Weiterführende Möglichkeiten - Anbindung an diverse Netze - Treiber für spezielle HW 6.0 Auswahlhilfe 7.0 Literatur NTA Isny RTOS V2.11 3

4 1.0 Einführung Echtzeitsysteme - Echtzeitbetriebssysteme Lernziele: - Wissen wie ein Echtzeitsystem definiert ist - Forderungen bei der Echtzeitprogrammierung kennen - Zwischen harter und weicher Echtzeit unterscheiden können - Wissen was man unter synchroner und asynchronen Programmierung versteht - Unterscheiden können zwischen einem technischen Prozess, einem Rechenprozess und einem kognitiven Prozess - Den Unterschied zwischen Task (Prozess) und Thread kennen - Den Begriff Standardisierte Ansätze (POSIX) erklären können - Wissen welche Aufgaben Betriebssysteme im technischen Umfeld haben 1.1. Definition eines Echtzeitsystems - Echtzeitsysteme sind Systeme, die korrekte Reaktionen innerhalb eines definierten Zeitlimits (Deadline) produzieren müssen. Wenn die Reaktionen diese Zeitlimits überschreiten, dann resultieren daraus Leistungseinbußen und/oder Fehlfunktionen. - Korrektheit eines Echtzeitsystemen ist nicht nur von den logischen Ergebnissen der Berechnung abhängig, sondern auch von dem Zeitpunkt an dem die Ergebnisse produziert wurden. - zeitliche Korrektheit und Vorhersagbarkeit => zeitlich deterministisches System Definition Echtzeit nach DIN 44300: Ein Betrieb eines Rechensystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind, derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Die Daten können je nach Anwendungsfall nach einer zeitlich zufälligen Verteilung oder zu vorherbestimmten Zeitpunkten anfallen. Forderung nach Rechtzeitigkeit (siehe auch 1.2 Harte und weiche Echtzeit) - rechtzeitiges Abrufen der Eingabedaten - rechtzeitige Durchführung der Verarbeitung - rechtzeitige Ausgabe der Ausgabedaten Forderung nach Gleichzeitigkeit Vorgänge in der Umwelt laufen gleichzeitig ab Echtzeitsysteme müssen darauf gleichzeitig reagieren Mehrere Datenverarbeitungsaufgaben müssen gleichzeitig ausgeführt werden Beispiele: - Reaktion auf gleichzeitige Fahrt von Zügen - Verarbeitung mehrerer gleichzeitig anfallender Messwerte bei einer Heizung - Motorsteuerung und ABS-System gleichzeitig Realisierung von Gleichzeitigkeit - Jede Datenverarbeitungsaufgabe durch getrennte Rechner => echt parallel - Einen Rechner für alle Datenverarbeitungsaufgaben => quasiparallel / quasigleichzeitig Vorraussetzung: Vorgänge in der Umwelt langsam im Vergleich zum Ablauf der Programme im Rechner NTA Isny RTOS V2.11 4

5 Forderung nach Determiniertheit Determiniertheit = Vorhersehbarkeit des Systemverhaltens Parallele bzw. quasiparallele Abläufe sind i.a. nicht vorhersehbar, zeitliche Verschiebungen können zu unterschiedlichen Abläufen führen. - das zeitliche Verhalten ist nicht determiniert - keine absolute Garantie der Sicherheit von Automatisierungssystemen Determiniertheit von Echtzeitsystemen Ein Echtzeit-System heißt determiniert, wenn es für jeden möglichen Zustand und für jede Menge an Eingabeinformationen eine eindeutige Menge von Ausgabeinformationen und einen eindeutigen nächsten Zustand gibt. Vorraussetzung: Endliche Menge von Systemzuständen Zeitlich determiniertes System: Antwortzeit für alle Ausgabeinformationen ist bekannt. In einem determinierten System ist garantiert, dass das System zu jedem Zeitpunkt reagieren kann, in einem zeitlich determinierten System zusätzlich auch bis wann die Reaktion erfolgt sein wird. "Harte und weiche" Echtzeit Harte Echtzeitsysteme Echtzeitsysteme: Das Ergebnis (Antwort, Reaktion) muss innerhalb der spezifizierten Deadline vorliegen. Weiche Echtzeitsysteme Echtzeitsysteme: Die Reaktionszeit (Antwortzeit) ist wichtig, aber das System arbeitet trotzdem korrekt, falls die Deadlines gelegentlich verpasst werden. Die verschiedenen Zeitanforderungen und deren Nichteinhaltungen, lassen sich grafisch anhand der nachfolgenden Schaden- bzw. Kostenfunktion verdeutlichen: Deadline Deadline Schaden bzw. Kosten (SK) Harte Echtzeit Weiche Echtzeit t(min) t(max) Zeit(t) Schaden- bzw. Kostenfunktion von harter und weicher Echtzeit NTA Isny RTOS V2.11 5

6 Unterscheidung weicher Echtzeitsystemen von interaktiven Systemen dadurch, dass bei diesen keine expliziten Deadlines existieren Ob weiche oder harte Echtzeitbedingungen von einem Echtzeitbetriebssystem erfüllt werden müssen, hängt ganz alleine von der Forderung nach Rechtzeitigkeit beziehungsweise Pünktlichkeit ab, die je nach Anwendungsfall unterschiedlich stark ausgeprägt sein kann. Während bei der weichen Echtzeit das Einhalten der Zeitanforderungen nur statisch definiert ist, muss bei der harten Echtzeit das exakte Einhalten von Zeitpunkten ausnahmslos ausnahmslos garantiert werden können, ohne dass auch nur ein Zeitpunkt verpasst werden darf. Grundsätzlich kann allerdings nicht ausschließlich nur zwischen harter und weicher Echtzeit differenziert werden, sondern jegliche Abstufungen dazwischen sind denkbar. => abhängig von den jeweiligen Anforderungen Beispiele für harte Echtzeit: Flugsteuersystem => Verpassen einer Deadline => kann zur Katastrophe führen Airbag => Reaktion im ms-bereich notwendig => Gefährdung von Personen Beispiele weiche Echtzeit: Datensammelsystem für ein Prozesssteuerungssystem => Sammelt periodisch Daten ein und toleriert zeitweilige Verzögerungen Anzeige des momentanen Benzinverbrauchs => Verpassen der Deadline => nur Einschränkung des Komforts 1.2. Arten des Vorgehens - Synchrone Programmierung: Planung des zeitlichen Ablaufs vor der Ausführung der Programme Vgl. Planwirtschaft - Asynchrone Programmierung (Parallelprogrammierung): Organisation des zeitlichen Ablaufs während der Ausführung der Programme Vgl. Marktwirtschaft NTA Isny RTOS V2.11 6

7 Verfahren der synchronen Programmierung Synchrone Programmierung: Planung des zeitlichen Verhaltens zyklisch auszuführender Teilprogramme vor der Ausführung - Synchronisierung der zyklisch auszuführenden Teilprogramme mit einem Zeitraster - Zeitraster über Echtzeituhr, Unterbrechungssignal zum Aufruf über Teilprogramme => Time triggered - Fest vorgegebene Reihenfolge des Ablaufs der Teilprogramme Beispiel: Heizungsregelung u 1 (t) Regelstrecke 1 Heizkreis Wohnung Raumtemperatur Wohnung y 1 (t) u 2 (t) Regelstrecke 2 Heizkreis Büro Raumtemperatur Büro y 2 (t) u 2 (t) Regelstrecke 3 Heizkessel Vorlauftemperatur y 3 (t) Stellgröße Istwert Analog-Ausgabe Analog-Eingabe Prozesssignal-Ein-/Ausgabe Echtzeit-Uhr Automatisierungs- Computer Bedienterminal Bemerkung: Einfacher digitaler Regelalgorithmus u(t i ) = (Sollwert y(t i )) * K P mit K P = Proportionalverstärkung u(t i ) = Stellgröße zum Zeitpunkt T i y(t i ) = Istwert zum Zeitpunkt T i NTA Isny RTOS V2.11 7

8 Fachtechnische (regelungstechnische) Konzeption - Auslegung der Regelalgorithmen und Regelparameter - Festlegung der Abtastzeiten für die Regelkreise T = Echtzeituhr Taktdauer T i = T 1 = T 2 = T 3 = Abtastzeitpunkt für Regelkreis i T 2T 5T Zuordnung von Bezeichner und Abtastzeiten Ein Teilprogramm für jeden Regelkreis Teilprogramm Bezeichner (Name) Abtastzeit (Zykluszeit) Temperatur-Regelung für die REGELUNG 1 T 1 = T Regelstrecke Heizkreis Wohnung Temperatur-Regelung für die REGELUNG 2 T 2 = 2T Regelstrecke Heizkreis Büro Temperatur-Regelung für die Regelstrecke Heizkessel REGELUNG 3 T 3 = 5T Grobentwurf bei synchroner Programmierung Unterbrechungssignale Von der Echtzeituhr mit der Zykluszeit T Alle T 1 =T REGELUNG 1 aufrufen Alle T 2 =2T REGELUNG 2 aufrufen Alle T 3 =5T REGELUNG 3 aufrufen Warteschleife NTA Isny RTOS V2.11 8

9 Zeitlicher Ablauf der synchronen Programmierung Annahme: - Rechenzeit für alle Teilprogramme gleich groß - Summe der Rechenzeiten der drei Teilprogramme kleiner als Zykluszeit Eigenschaften de synchronen Programmierung - Forderung nach Rechtzeitigkeit wird näherungsweise erfüllt => leichte Verschiebung - Forderung nach Gleichzeitigkeit wird erfüllt, wenn Zykluszeit T klein gegenüber den Zeitabläufen im technischen Prozess - Synchrone Programmierung gut für Echtzeit-Systeme mit zyklischen Abläufen => vorhersehbares Verhalten - Synchrone Programmierung ungeeignet für Reaktionen auf zeitlich nicht vorhersehbare (asynchrone ) Ereignisse Erhöhung der Rechenzeit durch ständiges Abfragen (Polling) Verzögerung der Reaktion - im Normalfall deterministisches Verhalten - kein komplexes Organisationsprogramm (Betriebssystem) - etwas aufwändigere Planung (Entwicklung) Nachteil der synchronen Programmierung Änderung der Aufgabenstellung bedeutet Änderung der gesamten Programmstruktur Beispiel: SPS NTA Isny RTOS V2.11 9

10 Verfahren der asynchronen Programmierung (Parallelprogrammierung) Organisationsprogramm (Echtzeitbetriebssystem) steuert während des Ablaufs der Teilprogramme den zeitlichen Aufruf - Aufruf der Teilprogramme, wenn Zeitbedingungen erfüllt sind - Gleichzeitige Ausführung wird nach bestimmter Strategie sequenzialisiert Zuordnung von Prioritätsnummern Priorität umso höher, je niedriger die Prioritätsnummer Beispiel: Heizungsanlage u 1 (t) synchron (zyklisch) Regelstrecke 1 Heizkreis Wohnung Raumtemperatur Wohnung y 1 (t) asynchron (stochastisch) Warnlampe u 2 (t) Regelstrecke 2 Heizkreis Büro Raumtemperatur Büro y 2 (t) u 2 (t) Regelstrecke 3 Heizkessel Vorlauftemperatur y 3 (t) Brennerstörsignal Stellgröße Istwert Analog-Ausgabe Analog-Eingabe Digitale- Digitale- Ausgabe Eingabe Prozesseinheit Echtzeit-Uhr Automatisierungs- Computer Bedienterminal Zuordnung von Bezeichner, Abtastzeiten und Prioritäten Teilprogramm Reaktion auf Brennerstörung mit Alarmmeldung Temperatur-Regelung für die Regelstrecke Heizkreis Wohnung Temperatur-Regelung für die Regelstrecke Heizkreis Büro Temperatur-Regelung für die Regelstrecke Heizkessel Bezeichner Abtastzeit Prioritätsnummer Prioriät (Name) (Zykluszeit) ALARM - 1 höchste REGELUNG 1 T 1 = T 2 zweithöchste REGELUNG 2 T 1 = 2T 3 dritthöchste REGELUNG 3 T 1 = 5T 4 niedrigste NTA Isny RTOS V

11 Zeitlicher Verlauf der Teilprogramme Eigenschaften der asynchronen Programmierung Forderung nach Rechtzeitigkeit nur näherungsweise erfüllt schlecht für niederpriore Teilprogramme Zeitbedingungen um so besser erfüllt, je höher die Priorität des jeweiligen Teilprogramms Ist-Zeitablauf kann sich gegenüber Soll-Zeitablauf stark verschieben Teilprogramme können sich gegenseitig überholen Aufeinanderfolge der Teilprogramme ist nicht deterministisch, sondern stellt sich dynamisch ein Bei Programmerstellung lässt sich nicht im Voraus angeben, welches Teilprogramm zu welchem Zeitpunkt ablaufen wird o Komplexität im Verwaltungsprogramm (BS) o Programmablauf z.t. schwer durchschaubar NTA Isny RTOS V

12 Ereignisgesteuerte Architekturen asynchrone Programmierung - Alle Aktivitäten als Folge von Ereignissen Aktivierung von Tasks Senden von Nachrichten - Unterstützung durch Echtzeitbetriebssysteme - Nicht deterministisches Verhalten - Flexibel bezüglich Veränderungen Zeitgesteuerte Architekturen synchrone Programmierung - Periodische Durchführung aller Task und Kommunikationen - Abtastung von externen Zustandsgrößen zu festen Zeitpunkten - Wenig flexibel bei Änderungen - Einfach analysierbar 1.3. Technischer Prozess In erster Linie verarbeiten Echtzeitsysteme Eingangswerte und berechnen rechtzeitig die dazu gehörigen Ausgangsgrößen. Als Eingangswerte sind Zustandsgrößen technischer Prozesse und als Ausgangsgrößen Werte für Stellglieder zu verstehen. Prozess- Rechner Technischer Prozess z.b.steuerung Aktoren : Steller für Motoren, Ventile,... Sensoren: Erfassung von Temperatur, Bewegung,... Analoge Größen müssen ggf. in digitale Signale umgeformt werden. Architektur der Echtzeitsteuerung Applikationen Steuer- und Regelprogramm Visualisierun Echtzeitbetriebssystem Hardware Direkte Anbindung oder Feldbus Prozessperipherie (Aktoren, Sensoren) Diese Darstellung ist nur ein stark vereinfachtes und allgemeingültiges Grobkonzept einer Echtzeitsteuerung und kann je nach Anwendungsfall abweichen. NTA Isny RTOS V

13 Bei einer Multimediaanwendung, im Bereich der PC-Spiele beispielsweise, wird in den seltensten Fällen eine Prozessperipherie notwendig sein. Kategorien von Echtzeitsystemen Einteilung von Echtzeitsystemen nach Einsatzgebieten: Kategorien von Echtzeitsystemen Einsatzgebiete Beschreibung Beispielanwendungen Speicher Programmierbare Steuerung (SPS) embedded RT- Systeme (eingebettete Echtzeitsysteme) RT- Kommunikationssysteme Anwendungen mit weichem zeitlichen Verhalten klassische Realtime-Systeme insbesondere für harte Echtzeitanwendungen Programmierung mittels spezieller Programmiersprache und speziellen Tools arbeiten mit einer festen Zykluszeit Steuert einen technischen Prozess, bei dem der Benutzer mit der Steuerung nur indirekt in Verbindung kommt Systementwicklung erfolgt für eine spezifische Aufgabe Steuerung ist nur Teil eines Gesamtsystems System ist frei von beweglichen und anfälligen Komponenten und dadurch sehr robust eine Komponente eines verteilten Realtimesystems dient anderen Realtime-Komponenten zum Informationsaustausch mit deterministischem Zeitverhalten Echtzeit-Applikationen auf Standardarchitekturen wie PC preiswerte Hardware und gewohnte PC-Plattform im rauhen Umfeld, in dem Echtzeitsysteme eingesetzt werden, oft nur bedingt tauglich Realtime-Verhalten, ohne Erweiterung häufig nur eingeschränkt (falls Standard-Betriebssystem verwendet wird) nur für weiche Echtzeitbedingungen tauglich * CNC-Maschine * Fertigungsstrasse * ABS beim Fahrzeug * Mobiltelefon * Modem * Waschmaschine * Gameboy * Multimediaanwendungen * Netzwerkverkehr * Voice over IP * Multimediaanwendungen * Computerspiele Kategorien von Echtzeitsystemen 1.4. Prozesse und Threads Ein Prozess ist nach der Deutschen Industrie Norm (DIN) wie folgt definiert: Definition Prozess [DIN66201]: Ein Prozess ist eine Gesamtheit von aufeinander einwirkenden Vorgängen in einem System, durch die Materie, Energie oder Information umgeformt, transportiert oder gespeichert wird. Man spricht von technischen Prozessen, wenn Materie oder Energie umgeformt, transportiert beziehungsweise gespeichert wird, und von Rechenprozessen bei der Umformung, beim Transport beziehungsweise bei der Speicherung von Information. NTA Isny RTOS V

14 Technischer Prozess Der technische Prozess ist durch physikalische Zustandsgrößen gekennzeichnet, die in der Regel durch Messwertaufnehmer, sogenannte Sensoren (zum Beispiel PT100 als Temperaturmesser, Füllstandsmesser, Endlagenerkennungsschalter) erfasst und durch Stellglieder, sogenannte Aktoren (zum Beispiel Relais, Ventile, Motoren jeglicher Art) beeinflusst werden können. => Unterscheidung des technischen Prozesses von dem Rechenprozess Rechenprozess Der Rechenprozess berechnet in der Regel aus Eingabewerten die dazugehörigen Ausgabewerte und ist somit für die Umformung, Verarbeitung und den Transport von Informationen verantwortlich. Der Rechenprozess wird meist auch als Task (Prozess) bezeichnet. Multitasking mehrere Tasks werden quasiparallel vom Prozessor bearbeitet. (meist nur 1 Prozessor => der nur sequentiell arbeiten kann) Definition TASK Ein Task ist eine organisatorische Einheit, die aus ausführbarem Programmcode, eigenem Speicher und Variablen besteht und ist gekennzeichnet durch eine Priorität und einem Taskzustand. Kognitiver Prozess Als kognitiver Prozess wird die Verarbeitung, Umformung und der Transport von Informationen innerhalb des menschlichen Bedieners bezeichnet. Der Bediener kann durch entsprechende Mensch-Maschine-Schnittstellen, auch engl. als Human- Machine-Interface (HMI) bezeichnet, auf den Rechenprozess bzw. indirekt auf den technischen Prozess Einfluss nehmen. Technischer Prozess - Rechenprozess kognitiver Prozess Rechenprozess (Task) Visualisierung Sensoren Aktoren Usereingabe Technischer Prozess Kognitiver Prozess NTA Isny RTOS V

15 Threads Als Thread wird ein Untertask, also ein untergeordneter Rechenprozess, innerhalb eines Programms (Prozesses) bezeichnet. Im Gegensatz zu Prozessen haben Threads keinen eigenen Adressraum (+ evtl. weitere Resourcen), sondern teilen sich den einmal vorhandenen Adressraum mit weiteren Threads innerhalb eines Prozesses. Weitere Unterschiede: Task Besitzer von Betriebsmitteln Enthält einen oder mehrere Threads Kommunikation über die Taskgrenzen hinaus, bevorzugt über Botschaften Thread Kann außer Prozessor keine Betriebsmittel besitzen, verfügt über alle Betriebsmittel der Task, der er angehört Element einer Task Kommunikation zwischen den Threads, bevorzugt über gleiche Daten Genauso wie bei den Rechenprozessen von Multitasking gesprochen wird, kann bei den Threads der Begriff Multithreading verwendet werden, wenn man damit die quasi parallele Abarbeitung von mehreren Threads innerhalb eines Programms (Prozesses) ausdrücken möchte. Bemerkung zur Threadumschaltung: Threadumschaltung ist mit weniger Aufwand verbunden, also auch schneller als eine Prozessumschaltung (Taskwechsel), da hier weniger Verwaltungsaufwand betrieben wird Standardisierte Ansätze (POSIX) Idee : Einheitliche Betriebssystem-Aufrufe Programme werden portabel (unabhängig vom Betriebssystem) POSIX => Portable Operating System Inteface. Dieser auf UNIX basierende Standard, wurde von IEEE (Institut of Electrical and Electronic Engineering) entwickelt und von ANSI (American National Standards Institute) und ISO (International Standards Organisation) standardisiert. Aufgrund ständiger Weiterentwicklungen, versuchen immer mehr Betriebssystementwickler weitere Versionen für Linux- und Windows-Betriebssysteme (z.b. MS Windows NT) zu erzeugen, die sich diesen Standard anpassen und die Betriebssysteme somit POSIX- Kompatibel werden. Beabsichtigt wird, eine flexible Portierbarkeit von Software (-Applikationen) auf Quellcode-Ebene zu erreichen. Bei dem Ziel, portable Betriebssystemschnittstellen, sowie Betriebssystemkomponenten zu standardisieren, werden letztendlich eindeutige Schnittstellen in Form von Funktionen definiert, die ein Betriebssystem bereit stellen muss, um diesen POSIX-Standards zu genügen, so dass ein POSIX konform geschriebener Quellcode auf allen weiteren POSIX-Betriebssystemen flexibel kompilierbar und ausführbar ist. NTA Isny RTOS V

16 POSIX a (draft) Base POSIX (UNIX) POSIX Realtime POSIX Threads POSIX d (draft) Realtime Extensions POSIX selbst definiert mehrere, unterschiedliche Standards für verschiedene Teile eines Betriebssystems, unter anderem auch den für Echtzeitsysteme relevanten, ehemaligen Standard POSIX 4 für Echtzeiterweiterungen, der seit 1993 durch weitere Entwicklungen bedingt, in POSIX b umbenannt wurde. Allgemein dienen solche Erweiterungen des POSIX-Standards der besseren Kontrolle über die Verwaltung der Ressourcen eines Betriebssystems. POSIX b gestattet die Verwendung eines Betriebssystems in Echtzeitsituationen und bezieht sich in seinen definierten Erweiterungen hauptsächlich auf Prozessvorrechte, Zeitverwaltung, sowie Systemaufrufe um die Kommunikation der Prozesse untereinander zu erleichtern. Häufig sind bei einer Portierung auf ein anderes Betriebssystemen Änderungen im Sourcecode notwendig. Grund: hardwarespezifischen Unterschiede => die durch Einhaltung des POSIX-Standards allerdings extrem minimiert werden können. Beispiele für Betriebssystem-Aufrufe Herkömmliche Aufrufe Taskfunktionen - RT_TASK_INIT Task initialisieren - RT_TASK_DELETE Task löschen - RT_TASK_SUSPEND Task schlafen legen - RT_TASK_RESUME Task aufwecken Zeitfunktionen - START_RT_TIMER - STOP_RT_TIMER - RT_GET_TIME Intertaskkommunikation - RT_SEND - RT_RECEIVE Semaphor-Funktionen (Synchronisationsmechanismen) - RT_SEM_INI - RT_SEM_DELETE - RT_SEM_SIGNAL - RT_SEM_WAIT RTAI-POSIX-ähnliche Task-Funktionen - ptthread_create Thread starten - ptthread_exit Thread beenden - ptthread_self ID ermitteln - ptthread_attr_setschedparam Priorität festlegen - ptthread_attr_getschedparam Priorität abfragen - mq_send Nachricht senden - mq_receive Nachricht empfangen - mq_open Message Queue anlegen - mq_close Message Queue schließen - ptthread_mutex _int Mutex initialisieren - ptthread_mutex_destroy Mutex löschen - ptthread_mutex_lock Mutex belegen - ptthread_mutex_unlock Mutex freigeben NTA Isny RTOS V

17 1.6. Aufgaben von Betriebssystemen Wozu ein Betriebssystem? Abstraktion von Hardware Koordinierung gleichzeitiger Aktionen und Ereignisse Verwaltung von Ressourcen Gewährleistung von Sicherheit und Schutz Entwurfsziele konventioneller Betriebssysteme (mittlerer) Durchsatz (mittlere) Latenz Fairness Skalierbarkeit keine Garantie zeitlicher Forderungen Aufgaben von Betriebssystemen und Unterschied zu konventionellen Betriebssystemen Konventionelle Betriebssysteme => Optimierung des average case Echtzeitbetriebssysteme => Optimierung des worst case RT-OS full featured OS optimize worst case optimize average case predictable schedule efficient schedule simple executive wide range of services minimize latency maximize throughput NTA Isny RTOS V

18 1.7. Beispiel aus der Praxis (Liebherrsteuerung) Ein-Prozessor CNC-Steuerung für Werkzeugmaschine mit max. 12 Achsen Digitale Antriebe DDS DDS DDS KDV PC-HW (Pentium III) Handrad Positionierung der NC-Achsen im Handbetrieb Visualisierung Programmierung Technologie NC-Interpreter SERCOS-RING (LWL) Digit. Antriebsschnittstelle SERCOS Interpolation Elektr. Getriebe Ablaufsteuerung Profibus DP Profibus-Master Diagnose Soft-PLC I/O I/O I/O Watchdog RTOS + WIN xx Steuerung der Peripherie (z.b. Ventile, Förderbänder,...) Standard-Schnittstellen COM, LPT, Ethernet, Modem Anforderungen bezüglich der Echtzeit: Funktion Zeitbedingung Dauer * Abweichung Prioritä t SERCOS-Schnittstelle 1**/2 /4 ms 800 us zyklisch +/- 200us=> nahezu jitterfrei! NC-Satzwechsel 15 ms ~ 5 ms +/- 5 ms PLC 50 ms ~ 15 ms zyklisch +/- 15 ms Visualisierung + Bedienen Restzeit * Pentium I 233 MHz ** nicht realisiert (gefordertes Ziel) Idle- Loop Forderungen: - harte Echtzeitanforderungen (Tabelle) müssen erfüllt werden - Visualisierung mit Microsoft-Windows ( viele Applikationen verfügbar, eingeführtes Produkt, Austauschbarkeit der Dateien... ) Lösung 1 (Stand ) : Echtzeit Betriebssystem RMOS for Windows (Protected Mode) - Zyklische Task für SERCOS-Schnittstelle (Task mit höchster Priorität, nicht unterbrechbar) - Weitere Echtzeit-Task mit gestufter Priorität (siehe Tabelle oben) - Win 3.11 => Task mit geringster Priorität (Idle-Task) Hardware: Pentium I 233 MHz / 32 MB RAM Lösung 2 (ab 1999 ) : Echtzeiterweiterung für WinNT / Win2K (3S) Hardware: Pentium III 600 MHz / 128 MB RAM NTA Isny RTOS V

19 2.0. Prozesse Prozessauswahl (Scheduling) Lernziele: - Zwischen preemptiven und nicht preemptiven Prozessen unterscheiden können - Den Prozess-Zustandsgraphen interpretieren können - Wissen welche Instanz die Prozesszustandsübergänge veranlasst - Die Funktion des Prozess-Kontrollblocks kennen - Die Zeitparameter bei der Prozessplanung richtig zuordnen können - Verstanden haben, was Scheduling-Strategien sind - Die unterschiedlichen Scheduling-Strategien anwenden können unter besonderer Berücksichtigung des Echtzeitaspekts - Die Bedingung für erfolgreiche Ablaufplanung kennen (Schedulability-Test) Echtzeitplanung: Prozess => wird sequentiell abgearbeitet und endet nach endlich vielen Schritten Echtzeitplanung (real time scheduling) Prozessen wird Prozessor so zu geteilt, dass die von der Anwendung vorgegebenen Zeitbedingungen, erfüllt werden Echtzeitplanung geht von harten Zeitbedingungen aus. Abhängig von der Anwendung ist zwischen Prozessen zu unterscheiden, deren Ausführung zwischen Start und Abschluss nicht unterbrochen werden kann nicht verdrängbare Prozesse => non preemptive deren Ausführung es sei denn, es sind besondere Einschränkungen vorhanden nach jeder Anweisung unterbrochen werden kann verdrängbare Prozesse => (preemptive) Prozessumschaltung (context switching) => Prozessor wird an einen anderen Prozess vergeben Bemerkung: Context Switching sollte möglichst schnell erfolgen => Overhead (Verwaltungsaufwand) besonders bei schnellem Systemtakt wichtig wichtiger Parameter für Echtzeitbetriebssysteme Der Start eines Prozesses, wie auch Prozessumschaltungen, können vom Rechnersystem, aber auch vom technischen System ausgehen. <= kann jederzeit geschehen Bezogen auf den Prozessstart wird von einem periodischen Prozess gesprochen, falls er jeweils nach Ablauf einer festen Zeitspanne gestartet werden soll. Andernfalls heißt der Prozess aperiodisch oder sporadisch. NTA Isny RTOS V

20 2.1. Prozesszustand Jeder Prozess befindet sich in einem der vier Zustände: rechnend - bereit - wartend - suspendiert Laufend Warten Beenden Wartend Verdrängen Starten Suspendiert Freigeben Aktivieren Bereit Laufend (active): dem virt. Prozessor ist ein phys. Prozessor zugeordnet, d.h. das zugehörige Programm befindet sich in Ausführung. In einem Monoprozessorsystem kann sich immer nur ein Prozess in diesem Zustand befinden. Bereit (ready): alle rechenbereiten Prozesse sind in einer oder mehreren Warteschlangen eingereiht. Sie bewerben sich um einen phys. Prozessor und sind demnach sofort ausführbar. Wartend: blockierte Prozesse, die auf Ereignisse bzw. Verfügbarkeit von Systemmitteln warten, bevor sie weiter ausgeführt werden können, sind in einer oder mehreren Warteschlangen eingereiht. Suspendiert: Prozesse, die z. Zt. keine Zuteilung des phys. Prozessors erfordern. Die Übergänge zwischen den Zuständen werden vom Dispatcher durchgeführt, während der Scheduler die Arbeitsreihenfolge entsprechend einer bestimmten Verwaltungsstrategie einteilt. Für alle Übergänge gibt es einen Veranlasser und einen Ausführer. Veranlasser kann ein Prozess oder der Scheduler/Dispatcher sein. Der Ausführer ist immer der Scheduler/ Dispatcher Aktivieren: ein neuer Prozess wird in die Warteschlange der bereiten Prozesse eingereiht. Die Systemsoftware sorgt dafür, dass das Programm beim starten mit der ersten Instruktion beginnt. Bei Bedarf wird in eine Initialisierungsroutine verzweigt. NTA Isny RTOS V

21 Veranlasser: der gerade laufende Prozess Starten: ein rechenbereiter Prozess wird vom Dispatcher ausgewählt und ausgeführt. Veranlasser: Dispatcher Warten: der laufende Prozess muss auf ein Ereignis oder ein System-Ressource warten, um weiterarbeiten zu können. Veranlasser: der laufende Prozess Freigeben: ein Ereignis, auf das ein Prozess gewartet hat, hat stattgefunden, bzw. das gewünschte Systemmittel wurde frei. Veranlasser: Scheduler Verdrängen: aus wichtigen (übergeordneten) Gründen soll ein anderer Prozess statt des laufenden fortgeführt werden. Veranlasser: Scheduler Beenden: der laufende Prozess scheidet aus dem Wettbewerb um die Rechenzeit aus. Veranlasser: der laufende Prozess NTA Isny RTOS V

22 2.2. Prozess-ID Priorität Prozess-Kontrollblock Die Prozessverwaltung benötigt zur korrekten Abarbeitung der einzelnen Aufgaben einige Angaben über die entsprechenden Prozesse. Diese sind im Prozess (PCB) - oder Task-Kontrollblock (TCB) abgelegt. Prozess - Kontrollblock enthält sämtliche Merkmale und Daten von Tasks wie: ID, Zustand, Priorität, Kontextzeiger, Verkettungszeiger usw. Sie werden vom Betriebssystem verwaltet und entsprechend aktualisiert. Auszug aus TCB RTXDOS TCB Link Adresse Stack Pointer Status Priority Task ID Mailbox / Queue Nr. Timer Link Timer Increment MBX / Queue Message MS Stack Segment Wenn Prozesse sporadisch bzw. periodisch ausgeführt werden sollen, kann dies z.b. im Prozess - Kontrollblock gekennzeichnet sein, mit ggf. besonderen Zeitbedingungen, wie Bereitzeit, Periode, Phase, Ausführungsdauer und Fristen Prozess Identifikator Der Identifikator ist eine Konstante und wird im sog. Prozess -Kontrollblock (s. oben) eingetragen. Er wir immer als Referenz auf den Prozess herangezogen. Priorität Bei entsprechender Abarbeitungs-Strategie wird jedem Prozess eine Priorität zugeordnet, die statisch oder dynamisch sein kann. Ein gängiger Wertebereich ist 0-255, wobei der Wert 0 für die höchste Priorität stehen kann (wird per Definition festgelegt). Der Eintrag und ggf. Weiterführung findet im PCB statt. NTA Isny RTOS V

23 2.3 Wichtige Zeiten (Planungsgrößen) - Zeitparameter A: Arrival time (Ankunftszeitpunkt) R: Request time (Einplanungszeitpunkt) S: Start time (Startzeit, Zuteilung eines Betriebsmittels) C: Completion time (Beendigungszeitpunkt) D: Deadline (Maximalzeit) E: Execution time (maximale Ausführungsdauer) P: Period time (maximale Antwortzeit) L: Laxity (Spielraum) r: Remaining flow time (Restantwortzeit) f: Flow time (Antwortzeit) Auftreten der Zeitparameter eines Rechenprozesses A: Arrival time R: Request time S: Start time C: Completion time D: Deadline Zusammenhang zwischen den Zeitparametern A <= R <= S <= C - E <= D - E Maximale Ausführungsdauer (Rechenzeitdauer) E = Ealt (t) + Eneu (t) Ealt (t) Eneu (t) : bisherige Dauer bis zum Beobachtungszeitraum : verbleibende Ausführungsdauer Zeitlicher Spielraum (Laxity) für die Ausführung eines Rechenprozesses L = D - S - E NTA Isny RTOS V

24 Einem Prozess P i werden die folgenden Zeitpunkte bzw. Zeitspannen zugeordnet: Bereitzeit (request time): R i Dies ist der früheste Zeitpunkt, an dem der Prozessor dem Prozess P i zugeteilt werden darf. Rechenzeit oder Bedienzeit (execution time) delta E i Diese Zeitspanne entspricht der reinen Rechenzeit auf dem Prozessor. Dabei werden für die Prozessausführung diejenigen Daten zugrunde gelegt, die, die längste mögliche Rechenzeit verursachen. Ausführungszeit (turn around time) Die Zeitspanne von Jobbeginn bis Jobende => enthält alle Zeiten in Warteschlangen, Bedienzeit und Ein- Ausgabe => sollte min. sein Frist (deadline): D i Zu diesem Zeitpunkt muss die Ausführung des Prozesses P i beendet sein. Die eingeführten Größen werden für die Echtzeitplanung von sporadischen Prozessen benötigt. Die folgenden Größen beziehen sich auf die Ausführung von Pi: Startzeit (engl.: starting time): S i Zu diesem Zeitpunkt beginnt der Prozess seine Ausführung durch den Prozessor. Abschlusszeit (engl.: completion time): C i Zu diesem Zeitpunkt beendet der Prozess seine Ausführung durch den Prozessor. Während die allgemeine Beziehung zwischen Start- und Abschlusszeit durch die Ungleichung si + ei ci ausgedrückt wird, gilt für nicht unterbrechbare Prozesse die Beziehung: si + ei = ci Bei einem unterbrechbaren Prozess Pi ist die Ausführungszeit über das Zeitintervall verstreut. Deadline Startzeit Abschlusszeit Rechenzeit Bereitzeit NTA Isny RTOS V

25 2.4. Scheduling Strategien - FIFO-Scheduling - Kürzester Auftrag zuerst - Zeitscheibenverfahren - Prioritätengesteuertes Scheduling - 1/t Verfahren - Statisches Offline Scheduling - Earliest Deadline First (EDF) - Ratemonotonic Scheduling - Verfahren des kleinsten Spielraums FIFO-Scheduling Dieses Verfahren nach dem Prinzip wer zuerst kommt mahlt zuerst (First Come First Served, FCFS oder First In First Out FIFO) reiht alle neu aktivierten Prozesse in eine Warteschlange ein. Dabei wird ein Prozess normalerweise erst nach Beendigung des vorhergehenden bearbeitet. Kontextwechsel => nur wenn der rechnende Prozess eine blockierende Systemfunktion aufruft oder wenn er den physikal. Prozessor freiwillig abgibt Nach Beendigung der Blockierung wird sein PCB wieder an das Ende der Bereit - Schlange angehängt. Anwendung: Stapelverarbeitung (und Windows 3.1) Mit FCFS wird nur die Prozessor - Auslastung (2.) optimiert. Beispielsweise hängt die mittlere Verweilzeit der Prozesse in der Bereit - Schlange stark von der Reihenfolge ab: die Prozesse 1-4 in der Bereit - Schlange haben jeweils eine Länge von 10, 6, 5 und 4 Zeiteinheiten. Bereit-Warteschlange Job 1 (10) Job 2 (6) Job 3 (5) Job 4 (4) Mittlere Verweilzeit = ( ) / 4 = 18 Treten die Jobs in der Reihenfolge 4,10,6,5 auf, gilt: Job 4 (4) Job 1 (10) Job 2 (6) Job 3 (5) Mittlere Verweilzeit = ( ) / 4 = 15,75 Zusammenfassung - Nicht preemptives Scheduling - Task, deren Einplanung am längsten zurückliegt bekommt Prozessor - Einfache Realisierung => Ungeeignet für harte Echtzeit NTA Isny RTOS V

26 Kürzester Auftrag zuerst (Shortest Job First SJF) Bei dieser Strategie wird die Zuteilung des phys. Prozessors auf Basis der kürzesten Bindung an einen Prozess gewährt das ist die Zeit bis zur nächsten Blockierung oder freiwilligen Abgabe der Kontrolle. Wenn mehrere Prozesse gleichlange Zeiten benötigen wird nach der FCFS verfahren. Diese Strategie ist optimal in Hinsicht auf die Optimierung der Verweilzeit. Problem: Bestimmung der kürzesten Verweilzeit Ein mögliches Verfahren ist: => Schätzung notwendig!!! t geschätzt (n) = ß *t gemessen (n -1) + (1 - ß)*t geschätzt (n -1) Durch den Faktor ß mit Werten aus dem Intervall [0..1] wird bei einer neuen Schätzung das Gewicht früherer Bindungzeiten (gemessen und geschätzt) festgelegt. Die (reziproken) Bindungszeiten können wie Prioritäten behandelt werden. Wenn die geschätzte Bindungszeit eines bereit gewordenen Prozesses kleiner als die restliche Zeit des laufenden Prozesses ist, kann letzterer verdrängt werden (preemptiv). Im nicht-preemptiven Fall wird der laufende Prozess bis zum nächsten blockierenden Aufruf oder der freiwilligen Abgabe des Prozessors weiter ausgeführt. Beispiel: Job Reihenfolgen Job 1 Job 2 Job (a) FCFS Ausführungszeiten: Job 1 10 Job 2 14 Job 3 17 Mittl. Ausführungszeit : ( ) :3 =13,67 Job 3 Job 2 Job (b) SJF Ausführungszeiten: Job 1 3 Job 2 7 Job 3 17 Mittl. Ausführungszeit : (3+7+17) :3 = 9 Zusammenfassung - Nicht preemptives und preemptives Scheduling möglich - Kurze Prozesse werden bevorzugt - Einfache Realisierung für harte Echtzeit untauglich NTA Isny RTOS V

27 Reih - Um - Strategie (Round Robin RU) Dieses preemptive Verfahren basiert auf Zuteilung einer Zeitscheibe für jeden bereiten Prozess. Sie wird durch Unterbrechungen einer Echtzeituhr gewonnen (Interrupt). Nach Ablauf ihrer Zeitscheibe werden die Prozesse verdrängt und sofort am Ende der Warteschlange wieder eingereiht. Die Reihenfolge in der Bereit - Schlange wird entspr. FCFS festgelegt. Die Einstellung der Zeitscheibe ist kritisch, da ein zu kleiner Wert zu häufigen Kontextwechseln mit hohem Verwaltungsaufwand führt, ein zu großer Wert in FCFS endet. Ankunft Warteschlange Prozessor Abgang RR optimiert Punkt 1.) der Anforderungen: Fairness. Die meisten Multi - Tasking - Systeme verwenden es als Basis, mit speziellen Zusätzen, denn ein Nachteil von FCFS bleibt erhalten: => EA - intensive Prozesse werden benachteiligt. Zusammenfassung - Jede Task bekommt einen festgelegten Zeitschlitz, zu der sie den Prozessor bekommt - Reihenfolge wird statisch festgelegt - Abarbeitung einer Task Stück für Stück - Verwendung bei Dialogsystemen (Multi-Tasking-Systeme) => für harte Echtzeit untauglich NTA Isny RTOS V

28 Zuteilungsentscheidung auf Prioritätsbasis Jedem Prozess wird eine Priorität zugeordnet, welche die Abarbeitungsreihenfolge entscheidend beeinflusst. damit wird gewährleistet, das der höchstpriorisierte Prozess seinen Endtermin (deadline) einhält Annahme : Prozessor ist schnell genug, um diesen Prozess bis zur Deadline abzuarbeiten Dieses Verfahren wird bei Echtzeit-Betriebssystemen häufig eingesetzt Prozesse gleicher Priorität können jeweils in eine, für jede Prioritätsstufe eingerichtete Warteschlange eingereiht werden. Die Abarbeitung beginnt dann immer aus der Warteschlange mit der höchsten Priorität und schreitet abhängig vom Prozess-Status nach unten fort. Die Zuordnung der Priorität kann statisch oder dynamisch sein. Statisch bedeutet, sie erfolgt bei der Systemgenerierung oder bei der Erzeugung eines Prozesses und bleibt während der Laufzeit unverändert. Im dynamischen Fall kann die Priorität während der Laufzeit Änderungen erfahren, abhängig von der jeweiligen Strategie (s.u.). In der preemptiven Form kann ein aktuell rechenbereit werdender Prozess höherer Priorität den gerade laufenden Prozess verdrängen. In der nicht preemptiven Form kann seine Ausführung frühestens nach einem blockierenden Systemaufruf oder einer freiwilligen Abgabe der Kontrolle seitens des laufenden Prozesses beginnen. Bei einer reinen Prioritätsstrategie besteht die Gefahr des Aushungerns von Prozessen niederer Priorität. (Starvation) Der Extremfall ist die Monopolisierung des phys. Prozessors. Bei statischen Systemen ist aus dieser Situation nur ein Neustart möglich. NTA Isny RTOS V

29 Beispiel, bei dem prioritätsbasiertes Scheduling versagt: t P (Periode) e i (Rechenzeit) P 1 50 ms 10 ms P 2 10 ms 2 ms Annahme: Prio P1 > Prio P2, da P1 wichtiger Wenn beide Prozesse zur selben Zeit starten Obwohl CPU frei ist, ist es für P 2 schon zu spät (Deadline verpasst) P 2 P 1 P 1 hat höhere Priorität Scheduling periodischer Prozesse vgl RMS Erweiterung des Prioritäten-Scheduling: 1/t Verfahren Dynamische Systeme verwenden einen Alterungs-Algorithmus, der die Prioritäten der Prozesse entsprechend den erteilten Prozessorzeiten absenkt. Prio(t) = t zugeteilt / t gebraucht (t in System - Zeiteinheiten) Hierbei ist die Priorität aufsteigend. (je kleiner die Zahl, desto höher ist die Priorität) Beispiel: Prio(t1 ) = 100/1, Prio(t2 ) = 100/2, Prio(t100) = 1 Erhöhung der Priorität (Boosting) Nach Freigabe eines blockierten Prozesses kann die Priorität angehoben werden. (Windows NT) Zusammen mit dem 1/t - Verfahren fällt die Ähnlichkeit zum Differential - Anteil (mit Abklingzeit) in einem Regelalgorithmus auf. Zusammenfassung - Prioritäten werden statisch vergeben - Nicht preemptive und preemptive Strategie ist möglich - Task mit höchster Priorität bekommt Prozessor - Einfache Implementierung - Zusätzlich bei 1/t Verfahren => dynamische Prioritäten über der Zeit => für harte Echtzeit nur bedingt tauglich NTA Isny RTOS V

30 Static Offline Scheduling In ganz zeitkritischen Echtzeitanwendungen wird dieses Verfahren eingesetzt. Die Scheduling - Entscheidungen werden vor der Ausführung getroffen, die der Dispatcher zur Laufzeit z.b. aus einer Tabelle zeitgesteuert abarbeitet (Kontextwechsel). Voraussetzung sind i.d.r. Anzahl der Tasks (Prozesse) steht vor der Laufzeit fest nur periodische Prozesse, aufgrund periodischer Ereignisse (z.b. System zur periodischen Messwerterfassung) Perioden beginnen zum selben Zeitpunkt (keine Phasenverschiebung) => für harte Echtzeit gut geignet Nachteil: Starres System kompletter Ablauf vorab geplant Earliest Deadline First (EDF) Durch das Scheduling erfolgt eine Auswahl des Prozesses mit der nächsten in der Zukunft liegenden Frist. Fristen können als Prioritäten aufgefasst werden, siehe prioritätsbasiertes Scheduling. Es gibt die preemptive und die nicht preemptive Variante, wobei letztere nicht optimal ist, da dabei ggf. Fristen verletzt werden. Beispiel: Drei Prozesse haben folgende Zeitvorgaben (z.b. in Millisekunden): P1: {r 1 = 0, d 1 = 4, e 1 = 2} P2: {r 2 = 4, d 2 = 8, e 2 = 2} P3: {r 3 = 0, d 3 = 9, e 3 = 4} Gewünschter Ablauf P1 s 2 mit Monoprozessorsystem nicht realisierbar r 2 P2 d 2 P t NTA Isny RTOS V

31 Nicht preemptive EDF - Variante: P1 wird aufgrund der nächstliegenden Frist zuerst abgearbeitet, kann frühestens bei t = 0 ms beginnen und wird dann bei t = 2ms beendet. Die nächste Frist liegt bei t=8ms für P2, dieser kann aber frühestens bei t=4ms beginnen und dauert dann bis t=6ms. In der Zeitspanne von t=2ms bis t=4ms ist der Prozessor untätig. Bei = t=6ms beginnt die Abarbeitung von P3, die bis t=10 ms andauert, was eine Fristverletzung bedeutet. P1 P2 P t Wenn die Prozesse dagegen in der (nicht preemptiven) Reihenfolge P1, P3, P2 abgearbeitet werden, findet keine Fristverletzung statt. Dies stellt aber kein reines EDF dar und bedeutet, dass nicht nur die nächste Frist allein für die Scheduling - Entscheidung ausschlaggebend sein darf, sondern es muss eine Vorausplanung über einen größeren Zeitraum stattfinden. (Komplexität der Algorithmen!) Günstiger ist deswegen die preemptive Variante des EDF - Scheduling: dabei kann P3 während der ansonsten inaktiven Zeit des Prozessors ab t=2ms für 2ms laufen, wird dann bei t=4ms von P2 wegen dessen früherer Frist verdrängt. Nach Beendigung von P2 wird P3 weiter ausgeführt und terminiert fristgerecht. P1 EDF: preemptive P2 P t Zusammenfassung - Task mit kleinster Restantwortzeit bekommt den Prozessor - Nicht preemptive und preemptive Strategie ist möglich - Einhaltung von zeitlichen Anforderungen wird speziell unterstützt - hoher Rechenaufwand für das Scheduling => für harte Echtzeit geeignet NTA Isny RTOS V

32 Rate Monotonic Scheduling RM (Liu, Layland) - Zuweisung von Prioritäten entsprechend der Periode - je kleiner die Periode, desto größer die Priorität - preemptives Scheduling - jeder Prozesssatz kann zugeteilt (scheduled) werden, wenn Gesamtauslastung des Prozessors < 69% (siehe 2.6. Schedulability) => d.h. 30% der Prozessorleistung werden nicht genutzt (Reserve). - ist optimales statisches Schedulingschema für unabhängige periodische Prozesse - optimal heißt, wenn ein Prozess nach einem festen Prioritätenschema zugeteilt (scheduled) werden kann, dann kann er auch mit RM zugeteilt (scheduled) werden Prio P2 > Prio P P 2 P 1 hat höhere Priorität P 1 Die Wichtigkeit der Prozesse muss sich also beim Systementwurf in der Häufigkeit ihrer Aktivierung ausdrücken. Beispielsweise müssen in einer Flugzeugsteuerung Sensoren für kritische (schnell veränderliche) Messgrößen mit höherer Frequenz abgefragt werden als dies für Engineering - Daten notwendig ist. Generell gilt: hochpriore Prozesse sollten so kurz wie möglich sein! Hochfrequente Prozesse werden demnach bevorzugt, während niederfrequente mehr zerstückelt werden wobei die häufigen Kontextwechsel zur geringeren Ausnutzung der Prozessorzeit führen. Vorteil des Verfahrens ist, dass die Beurteilung, ob die Zeitvorgaben eingehalten werden können, relativ einfach ist. NTA Isny RTOS V

33 Zusammenfassung - Spezialfall des Verfahrens mit festen Prioritäten für zyklische Tasks - Priorität um so höher, je kürzer die Zykluszeit (Periode) ist - Preemptive Strategie - Relativ einfache Realisierung => Verfahren wird in Echtzeitsystemen häufig angewendet Least Laxity Strategie Verfahren des kleinsten Spielraums - Preemptives Verfahren - Task mit kleinstem Spielraum erhält Prozessor - Berücksichtigung von Deadlines und Ausführungsdauern - Sehr aufwändiges Verfahren - Bestimmung des Spielraums häufig nicht exakt möglich => statistische Größe - Mit festem Takt z.b. 10 ms findet Überprüfung des kleinsten Spielraumes statt Task mit kleinstem Spielraum erhält den Prozessor => für harte Echtzeit am besten geeignet Beispiel: Task Dauer Einplanung T D : Deadline P1 30 ms 0 ms 40 ms P2 10 ms 0 ms 30 ms P3 30 ms 30 ms 100 ms P4 40 ms 50 ms 200 ms P5 10 ms 70 ms 90 ms Graphische Darstellung: P5 P4 200 ms P3 P2 P1 P1 P2 P1 P3 P5 P t/ms NTA Isny RTOS V

34 Kombination mehrerer Strategien Häufig werden mehrere der genannten Strategien kombiniert, um dem konkreten Anwendungsfall gerecht zu werden. Dies wird als Mehr - Ebenen - Verwaltung bezeichnet. Viele Kriterien können entsprechend ihrer Wichtigkeit in ein Priorität - Schema abgebildet werden, so dass die Prioritäten - Strategie in Kombination mit dem Zeitscheiben- und Fristen- Verfahren eine tragfähige Basis, speziell für Echtzeitsysteme, bildet. Best Effort EDF und RMS werden hauptsächlich für strikte Echtzeitsysteme eingesetzt. Ihre Validierung und Worst Case Abschätzung ist schwierig, insbesondere wenn Programm- Modifikationen vorgenommen werden. Häufig werden deshalb in nicht sehr zeitkritischen Systemen preemptives, prioritätsbasiertes Scheduling, in Verbindung mit RR verwendet (Multilevel Scheduling). Man wählt dabei die Prozessorgeschwindigkeit entsprechend, so dass alle Zeitvorgaben mit hoher Wahrscheinlichkeit eingehalten werden können. Dazu sind entsprechende Simulationen und Tests unter realen Lastverhältnissen erforderlich Beispiele für Schedulingverfahren (QNX, RTXDOS) RTXDOS: Ein Verfahren ist fest implementiert: Task mit der höchsten Priorität erhält den Prozessor. Falls mehrere Tasks dieselbe Priorität besitzen wird ein Round Robin Algorithmus wirksam => Task die am längsten gewartet hat erhält den Prozessor => d.h. Tasks mit gleicher Priorität werden im Zeitscheibenverfahren bedient QNX: Grundsätzlich wird der Prozessor nach Prioritäten vergeben. Befinden sich mehrere Prozesse im Ready-Zustand wir nach einer der folgenden Methoden der Prozessor vergeben: FIFO-Scheduling Round-Robin-Scheduling adaptives Scheduling NTA Isny RTOS V

35 Jeder Prozess im System benutzt eine dieser drei Methoden. Das Scheduling-Verfahren bezieht sich immer auf einen Prozess und nicht auf alle Prozesse eines Knotens. Scheduling-Verfahren arbeiten also prozessbasierend. Ein Prozess erbt seine Scheduling-Methode von seinem Vaterprozess. Mit folgenden Funktionen kann die Scheduling-Methode Einfluss genommen werden: Abfrage auf aktuelle Methode : getscheduler() Scheduling-Methode ändern : setscheduler() Erläuterung zum adaptiven Scheduling Beim adaptiven Scheduling verhält sich ein Prozess wie folgt: Wenn ein Prozess seine Zeitscheibe aufgebraucht hat (und er bis dahin nicht blockiert), wird seine Priorität um 1 verringert. Diesen Vorgang bezeichnet man als priority decay (Prioritätsverfall). Wichtig hierbei ist, dass die Verringerung nur um eine Prioritätsstufe erfolgt, auch wenn der Prozess eine weitere Zeitscheibe verbraucht - die Priorität wird maximal um eins niedriger gesetzt, als die Ausgangspriorität. Blockiert ein Prozess, bekommt er umgehend seine Ausgangspriorität zurück. Ready Warteschlange aktiv Prozess A Prozess B Prozess C Adaptives Scheduling. Prozess A verbraucht seine Zeitscheibe; seine Priorität wird um eins verringert. Der nächste Prozess mit dem Zustand READY läuft (Prozess B). Vornehmlich wird das adaptive Scheduling in Umgebungen eingesetzt, bei denen sich rechenintensive Hintergrundprozesse die CPU mit interaktiven Anwendungen teilen müssen. Sie können beim adaptiven Scheduling erwarten, dass die rechenintensiven Prozesse genügend CPU-Leistung erhalten und die interaktiven Anwendungen gute Antwortzeiten haben. Adaptives Scheduling ist der Standard für Programme, die über die Shell gestartet werden. NTA Isny RTOS V

36 2.6. Bedingung für erfolgreiche Ablaufplanung (Schedulability) => Nachweis der Durchführbarkeit des Ablaufes, d.h. es muss überprüft werden, ob bei einer gegebenen Anzahl von Task sämtliche Deadlines eingehalten werden können. Es muss wie in der Mathematik üblich zwischen notwendiger und hinreichender Bedingung unterschieden werden Ausgangspunkt: => Systemmodell Für die Diskussion des System-Schedulings ist als eine Grundlage ein Systemmodell erforderlich. m Prozesse P i mit den charakteristischen Eigenschaften d i Endtermin, deadline T i Periode Rechenzeit, Execution Time e i Einfache Einschränkungen i) e i d i = T i (d.h. die Rechenzeiten der Prozesse sind kleiner als deren Deadline, und die Deadline ist gleich der Periode) ii) iii) iv) Rechenzeit für einen gegebenen Prozess ist konstant Alle Prozesse sind periodisch Es existieren keine Vorrangbeziehungen zwischen den Prozessen v) Es wird kein Ressourcenbedarf der Prozesse betrachtet vi) Kontextswitch ist 0 vii) Alle Prozesse sind einem einzelnen Prozessor zugewiesen Ein realistisches Modell erfordert, dass diese Beschränkungen abgeschwächt werden, z.b: durch die Einbeziehung von: sowohl periodischen als auch aperiodischen Prozessen. willkürliche Vorrangbeziehungen, die zwischen Prozessen im Prozesssatz T definiert sind; d.h. wenn τ i < τ j dann hat die Ausführung von Prozess τ i Vorrang vor τ j. geschützten Ressourcensharing zwischen Prozessen Zeiten, die zwischen einem Minimum (best-case) und einem Maximum (worst-case) variable sind. Multiprozessor- Systeme mit statischer ( oder dynamischer) Prozesszuteilung Kontextswitch ungleich 0 NTA Isny RTOS V

37 Theorem von Lui und Layland Eine Menge periodischer Tasks (Deadline = Periode) kann durch das preemptive Earliest-Deadline- First-Verfahren ausgeführt werden wenn gilt: m Σ e i /T i 1 (1) I=1 d i T i e i m Endtermin, deadline Periode Rechenzeit, Execution Time Anzahl der Tasks Bezüglich des EDF-Verfahrens ist dieser Test notwendig und hinreichend Für beliebige Schedulingverfahren ist dieses nur eine notwendige Bedingung D.h. - notwendige Bedingung besagt, dass Prozessmenge nicht korrekt verplant werden kann, wenn sie verletzt ist - wenn sie erfüllt ist, bietet sie keine Garantie dafür, dass ein Ablaufplan eingehalten werden kann Eine Menge periodischer Tasks (Deadline = Periode) kann durch das Rate-Monotonic-Verfahren ausgeführt werden wenn gilt: U * 1 = 1,0 U * 2 = 0,828 U * 3 = 0,779 Grenzwert : 69,3% Beispiele: m Σ e i /T i U * m = m(2 1/m -1) für m = 1,2, (2) I=1 d i T i e i m U * m U m U m = e i /T i Endtermin, deadline Periode Rechenzeit, Execution Time Anzahl der Tasks Gesamt-Prozessorauslastung bei m Tasks Teilauslastung des Prozessors durch Task m m = 2 R A = 20 ms T A = 40 ms R B = 30 ms T B = 60 ms RA/TA + RB/TB = ½ + ½ > 2( 2 1) = 0,828 Falls Bedingung (2) nicht erfüllt => Verplanung mit Rate-Monotonic-Verfahren nicht möglich Falls nur Bedingung (1) erfüllt => Verplanung mit EDF Bemerkung: Die obigen Formeln dienen nur einer Abschätzung (worst case). Die Praxis zeigt, dass auch mit höheren Auslastungen (2) noch korrekte Abläufe möglich sind. Der Nachweis muss hier allerdings empirisch erfolgen durch Langzeittest mit statistisch verteilten Belastungen. (Realität soll möglichst gut angenähert werden, auch mit extremen Belastungen) Problem: a) geeignetes Aufzeichnungsverfahren für den Nachweis b) realitätsnahe Auslastung (Wie gut ist die Testumgebung?) Hinweis: Für ISO 9000 ist Nachweis erforderlich NTA Isny RTOS V

38 2.7. Beispiele Übung 1: - 2 periodisch auftretende Ereignisse, - Prozesse sind unterbrechbar, - hohe Systemauslastung (100 %) Ist dieses System mit prioritätsgesteuertem bzw. EDF-Scheduling verplanbar, d.h. werden Deadlines eingehalten? Prozess Periode T i Rechenzeit e i Auslastung P A P B Gesamtauslastung = e1/t1 + e2/t2 = 20/ /60 1 erfüllt Betrachtung im Zeitintervall 120 ms (kgv der Periode 40*3 und 60*2) => nach dieser Zeit wiederholt sich der komplette Ablauf, d.h. wenn hier keine Konflikte auftreten, dann wird auch der weitere Verlauf konfliktfrei sein. a) Auswahl für Priorität P B < P A P A P B b) Auswahl für Priorität P B > P A P A P B NTA Isny RTOS V

39 c) Auswahl nach dem kleinsten Spielraum oder der nach der kleinsten Restfrist P A P B Mit statischer Prioritätsvergabe werden die Endtermine nicht eingehalten Auswahl mit kleinstem Schlupf (EDF) ist erfolgreich Übung 2: - 2 periodisch auftretende Ereignisse, - Prozesse sind unterbrechbar, - geringere Systemauslastung (ca. < 80 %) Ist dieses System mit prioritätsgesteuertem Scheduling verplanbar, d.h. werden Deadlines eingehalten? Prozess Periode T i Rechenzeit e i Auslastung P A P B Gesamtauslastung = e1/t1 + e2/t2 = 15/ /20 = 0,8 1 erfüllt Betrachtung im Zeitintervall 60 ms (kgv der Periode 30*2 und 20*3) => nach dieser Zeit wiederholt sich der komplette Ablauf, d.h. wenn hier keine Konflikte auftreten, dann wird auch der weitere Verlauf konfliktfrei sein. RM: Prozess mit kürzerer Periodendauer erhält höhere Priorität => Prio P B >P A P A P B NTA Isny RTOS V

40 3.0. Prozess - Synchronisation und Kommunikation Probleme bei Multitasking Betriebssystemen: Abhängigkeiten zwischen Prozessen Informationsaustausch zwischen Tasks Synchronisation (zeitliche Koordination) Intertask-Kommunikation Synchronisation: Wenn mehrere parallele Prozesse auf gemeinsamen - Speicher, - Peripherie oder allgemein auf - System - Ressourcen zugreifen müssen, ist eine Synchronisation nötig, um inkonsistente Zustände zu vermeiden. Grundgedanke bei allen Synchronisierungsverfahren Rechenprozess muss warten, bis ein bestimmtes Signal bzw. Ereignis eintrifft Einfügen von Wartebedingungen an den kritischen Stellen Hauptformen der Synchronisierung Logische Synchronisierung (aufgaben-/oder prozessorientierte Synchronisierung) - Anpassung des Ablaufs der Rechenprozesse an den Ablauf der Vorgänge im technischen Prozess - Synchronisierung bedeutet: Erfüllung von Anforderungen bezüglich der Reihenfolge von Aktionen Berücksichtigung vorgegebener Zeitpunkte bzw. Zeitabstände Reaktionen auf Unterbrechungsmeldungen aus dem technischen Prozess Betriebsmittelorientierte Synchronisierung - Einhaltung von Bedingungen bezüglich der Verwendung gemeinsam benutzter Betriebsmittel (Ressourcen) NTA Isny RTOS V

41 Intertask-Kommunikation - Daten die von einer Task zur anderen fließen - Mechanismen zur Mitteilung, dass Information bereit ist, gelesen oder geschrieben zu werden - Mechanismen, die den gemeinsamen Zugriff auf Datenaustausch-Ressourcen regeln Hierzu sind grundsätzlich zwei Methoden möglich Gemeinsam benutzter Speicher Botschaftsaustausch (Message passing) 3.1. Zeitkritische Abläufe Zusammenarbeitende Prozesse benutzen häufig in irgendeiner Form einen gemeinsamen Teil eines Speichers, sei es Hauptspeicher oder Plattenspeicher (evtl. auch Peripherie-Elemente). Beispiel: Postausgang für Nachrichten über CAN Gegeben: Pufferspeicher (unbegrenzter Länge) in welchen die Prozesse P1 und P2 die zu sendenden Nachrichten eintragen können. Der Sendeprozess (P3) überprüft periodisch, ob Nachrichten vorhanden sind, entnimmt sie aus dem Puffer, packt sie in das CAN- Protokoll ein und versendet sie über das Netz. Vorraussetzung für einen geordneten Ablauf: Pufferspeicher muss immer zusammengehörende Nachricht enthalten. basis_adr Prozess P1 Prozess P lese_zeiger Prozess P3 schreib_zeiger CAN- Controller Zur Adressierung der einzelnen Nachrichten im Puffer werden Schreib- und Lesezeiger verwendet. Diese werden von den CAN-relevanten Prozessen entsprechend der Länge der Nachrichten (s.can - Feld DLC) inkrementiert. NTA Isny RTOS V

42 Zu einem beliebigen Zeitpunkt sei: lese_zeiger == basis_adr+3 schreib_zeiger == basis_adr+8 Die Prozesse P1 und P2 versuchen nun praktisch gleichzeitig jeweils eine neue Nachricht einzutragen. P1 liest schreib_zeiger == basis_adr+8 und speichert diesen Wert in einer lok. Variablen ab. In diesem Augenblick entscheidet der Scheduler dass P1 lange genug gerechnet hat und dass nun P2 den Prozessor bekommen soll. P2 liest ebenfalls schreib_zeiger == basis_adr+8, fügt seine Nachricht ein, führt schreib_zeiger = basis_adr+18 (ein Block habe die Länge 10) aus und rechnet bis zum Ende seiner Zeitscheibe oder bis zur nächsten Blockierung weiter. Irgendwann kommt P1 wieder zum Zuge und setzt seine Aktion fort, indem er seine Nachricht, unter der Annahme, dass schreib_zeiger == basis_adr+8 sei, einfügt und schreib_zeiger entsprechend der Nachrichtenlänge erhöht. Damit ist die Nachricht von P2 überschrieben worden, d.h. sie wird nicht gesendet und ist verloren. Der unkontrollierte Zugriff auf gemeinsamen Speicher (schreib_zeiger) hat also zu einem inkonsistenten Zustand geführt. Das kann in o.g. Fall katastrophale Folgen haben und ist deshalb keinesfalls tolerierbar. Fazit: Situationen in denen zwei oder mehr Prozesse auf gemeinsam benutzte Daten lesend und schreibend zugreifen und die Endergebnisse von der zeitl. Reihenfolge der Lese- und Schreiboperationen abhängen, heißen zeitkritische Abläufe. Die Fehlersuche ist dabei sehr schwierig, weil die Reproduzierbarkeit aufgrund ständig wechselnder Situationen und unerwarteter Nebeneffekte nicht gegeben ist. Für den Zugriff auf gemeinsame Ressourcen ist ein wechselseitiger Ausschluss der Prozesse (mutual exclusion) erforderlich. NTA Isny RTOS V

43 3.2. Erzwingen des wechselseitigen Ausschlusses a) Software - Lösungen: Hinweis: Dies sind Implementierungsbeispiele, bei der die wesentlichen Aspekte herausgehoben werden sollen. Im praktischen Einsatz wird es z. B. nicht sinnvoll sein, für jede Sperrvariable separate Funktionen zur Verfügung zu stellen, sondern (durch Parametrierung) nur eine Funktion für sperren und eine für freigeben. 1. Lösungsversuch: Einführung einer Sperrvariablen enum sperrvar {frei,belegt} puffer = frei; void sperren(void) { while(puffer==belegt); /* aktiv warten */ puffer=belegt; } void freigeben(void) { puffer=frei; } In P1 und P2 wären die Einträge der Nachricht damit folgendermaßen realisiert:.. sperren(); strcpy(schreib_zeiger, &nachricht); /* kritischer */ schreib_zeiger+=dlc+2; /* Abschnitt */ freigeben();.. Die Sperrvariable puffer repräsentiert das Systemmittel, hier den Speicherbereich des Sendepuffers. Damit ist das Problem der Überwachung eines evtl. komplexen Systemmittels auf die Überwachung einer Variablen abgebildet (verschoben) worden. Hier besteht wieder die Möglichkeit, dass zwei oder mehrere Prozesse die Sperrvariable (puffer) praktisch gleichzeitig lesen, als frei erkennen und deshalb gleichzeitig in den kritischen Abschnitt eintreten. Sie würden dann im obigen Beispiel auf den Schreibzeiger zugreifen, mit der gleichen Problematik. Übrigens muss nicht der gesamte Vorgang des Kopierens gesperrt werden, es genügt:. sperren(); mein_zeiger=schreib_zeiger; /* kritischer */ schreib_zeiger+=dlc+2; /* Abschnitt */ freigeben(); strcpy(mein_zeiger, &nachricht); b) Hardware - unterstützte Lösungen für die Durchsetzung des wechselseitigen Ausschlusses: Dazu kann wieder auf den 1. Lösungsversuch für die Software-Variante zurückgegriffen werden: NTA Isny RTOS V

44 1. Sperren und Freigabe der Interrupts des Prozessors enum sperrvar {frei,belegt} puffer=frei; void sperren(void) { _disable(); while(puffer==belegt) /* aktives warten */ { _enable(); if(puffer); /* NOP um Interrupts */ else ; /* zuzulassen */ ; _disable(); } puffer=belegt; _enable(); } void freigeben(void) { puffer=frei; } Mit der Funktion _disable() wird (bei den Intel - Prozessoren) der Maschinenbefehl CLI erzeugt der das Interrupt - Enable Bit im Statusregister löscht und damit sämtliche Unterbrechungen verhindert. Damit kann der Scheduler während der Bearbeitung der Sperrvariablen puffer nicht zum Zuge kommen, infolge dessen hat kein anderer Prozess gleichzeitig Zugriff auf puffer, d.h. der wechselseitige Ausschluss ist garantiert Danach werden die Unterbrechungen wieder zugelassen (_enable() ---> STI). Da es sich wieder um aktives Warten handelt, müssen die Unterbrechungen innerhalb der while - Schleife für kurze Zeit freigegeben werden, sonst könnte kein anderer Prozess die Freigabe durchführen und ein Deadlock wäre die Folge. Gravierender Nachteil dieser Lösung: Anwendungs-Prozesse führen privilegierte Operation durch Nämlich Sperren und Freigeben von Interrupts Bei fehlerhafter Programmierung kann dadurch das Gesamtsystem außer Funktion gesetzt werden, was in den meisten Fällen nur durch Rücksetzen (Reset) aufgehoben werden kann. 2. Atomare Operationen auf die Sperrvariable enum sperrvar {frei,belegt} puffer=frei; void sperren(void) { _asm { mov ax,belegt; warten: lock xchg ax,puffer; /* xchg ist atomar, mit lock */ cmp ax,belegt; /* Spinlock für Multiprozessor */ je warten; } } void freigeben(void) { puffer=frei; } Hier muss auf die Assemblersprache (80x86) zurückgegriffen werden. NTA Isny RTOS V

45 Für Monoprozessor-Scheduling genügt XCHG als atomare Operation, für Multiprozessoranwendungen muss der Bus durch das Lock-Prefix für andere Prozessoren gesperrt werden (gilt bis 80286). Nachdem das Problem des wechselseitigen Ausschlusses gelöst ist, gilt es den Nachteil des aktiven Wartens abzuschaffen. Dazu wird die Unterstützung eines Betriebssystems (in Form von speziellen Funktionen) benötigt, die Prozesse in einen Wartestatus versetzen kann und den phys. Prozessor anderen rechenbereiten Prozessen zuordnen kann. Nach Wegfallen des Grundes für den Wartezustand, sollen die entsprechenden Prozesse wieder aktiviert werden. Insgesamt sollten alle privilegierten und Hardware - unterstützten Operationen von der Systemsoftware ausgeführt werden, so dass die Anwendungsprozesse nur Standard- Funktionsschnittstellen "sehen (API). Unterstützung durch die System-Software Vermeidung des aktiven Wartens durch Systemfunktionen schlafen() und aufwecken(). Beispiel: Postausgang für Nachrichten über CAN Erzeuger Verbraucher Problem extern void einfuegen(char *pc); extern void schlafen(void); extern void wecken(int PID); extern void senden(char *pc); /* z. B. via CAN */ #define IDerzeuger 4711 #define IDverbraucher 815 #define maxzahl 100 /* Puffergröße */ int anzahl=0; void erzeuger(void) { char *nachricht; while(1) { if(anzahl==maxzahl) /* c */ schlafen(); einfuegen(nachricht); anzahl+=1; if(anzahl==1) /* b) */ wecken(idverbraucher); } } void verbraucher(void) { char *nachricht; while(1) { if(anzahl==0) /* a) */ schlafen(); senden(nachricht); /* d.h. entfernen aus dem Puffer */ anzahl-=1; if(anzahl==maxzahl-1) wecken(iderzeuger); } } NTA Isny RTOS V

46 Diese Lösung ist fehlerhaft, da die Variable anzahl nicht gesperrt wird. Folgendes kann passieren: der Verbraucher liest bei a) anzahl==0, d.h. der Sendepuffer ist leer. Daraufhin sollte er sich schlafen legen, aber der Scheduler entzieht ihm vorher den Prozessor. Wenn dann der Erzeuger aktiv wird, fügt er seinen Eintrag ein und stellt bei b) anzahl==1 fest und weckt den Verbraucher, in der Annahme dass dieser sich schlafen gelegt hat. Anzahl muss ja vorher 0 gewesen sein. Der Verbraucher schläft aber noch nicht, deswegen geht dieses Wecksignal verloren. Wenn der Verbraucher später wieder den Prozessor bekommt, legt er sich schlafen, da er vor der Verdrängung den leeren Puffer festgestellt hat. Der Erzeuger füllt im weiteren Verlauf den Puffer vollständig und legt sich in c) schlafen. Beide schlafen dann für immer, da keine Wecksignale mehr gezählt werden. Daraus folgt: Wecksignale sollten gezählt werden oder der Zugriff auf die Variable anzahl sollte gesperrt werden. Die Funktionen sperren() und freigeben() bieten hier keine Lösung wie man sieht: sperren(); if(anzahl==0) /* a) */ schlafen(); freigeben(); // endet im Dauerschlaf und sperren(); if(anzahl==0) { freigeben(); /* a) */ schlafen(); } bringt keinen Vorteil, da der Scheduler in a) wieder den Prozessor entziehen kann. Gefragt ist demnach ein Verfahren, welches folgendes liefert: wechselseitigen Ausschluss Vermeidung von aktivem Warten Zählen von Wecksignalen Entlastung der Anwendung (ein Systemobjekt) NTA Isny RTOS V

47 3.3. Das Semaphor - Konzept (Dijkstra 1965) Grundgedanke bei allen Synchronisierungsverfahren Rechenprozess muss warten, bis ein bestimmtes Signal bzw. Ereignis eintrifft Einfügen von Wartebedingungen an den kritischen Stellen Semaphore sind typische Elemente von Echtzeitsystemen zur Steuerung des Systemverhaltens. Sie sind systemweit bekannte Objekte, die zur Synchronisation der im System vorhandenen Tasks dienen. Was wird synchronisiert? eine Task wartet auf Daten einer zweiten Task zwei oder mehr Tasks teilen sich eine Resource Eintritt eines bestimmten Ereignisses (im Gegensatz zum Polling) Im allgemeinen unterscheidet man 3 verschiedene Typen von Semaphoren Binäre (zweiwertige) Semaphoren Gegenseitige Ausschlusssemaphoren (Mutual Exclusion) Zählsemaphore (Counting Semaphore) Semaphore => systemglobale Variable P - Operation (Passieren) => Semaphor (Zähler) wird dekrementiert Falls Zähler 0 => aufrufender Prozess kann in den kritischen Pfad eintreten Falls Zähler < 0 => aufrufender Prozess wird blockiert V - Operation (Verlassen) => ältester Prozess wird aus (FIFO) der Semaphor-Warteschlange entfernt (falls diese nicht leer ist) und in die Bereit - Schlange eingereiht. Der Zähler wird dabei inkrementiert. NTA Isny RTOS V

48 Beispiel 1: Zugverkehr über eine eingleisige Strecke Beispiel 2: Zugverkehr über eine eingleisige Strecke Mit Ablaufreihenfolge ABAB NTA Isny RTOS V

49 Beispiel 2: Parkhaus mit N Parkplätzen Bei positivem Zählerstand (freie Plätze) zeigt die Ampel an der Einfahrt grün und mit jedem einfahrenden Fahrzeug wird der Zähler dekrementiert ( P - Operation). Wenn kein Platz mehr verfügbar ist, zeigt die Ampel rot. Jedes weitere ankommende Fahrzeug dekrementiert den Zähler weiter und wird in eine Warteschlange eingereiht. Ein negativer Zählerstand repräsentiert also die Zahl der Fahrzeuge in der Schlange. Jedes Fahrzeug, welches das Parkhaus verlässt (V - Operation), inkrementiert den Zähler und ein Fahrzeug aus der Schlange darf einfahren. Pseudo - Code für die P- und V - Operation: void P ( Semaphor S) { Zähler(S)--; if( Zähler(S) < 0) { Kontext_sichern(get(PID)); blockierien(pid); starten(next(b-schlange)); Kontext_laden(next(B-Schlange)); } } // Bereit-Warteschlange void V (Semaphor S) { if(zähler(s)<0) deblockieren(next(s_schlange)); Zähler(S)++; } // Semaphor-Warteschlange NTA Isny RTOS V

50 Beispiel: Zwei Rechenprozesse sollen stets abwechselnd laufen Logische Synchronisierung NTA Isny RTOS V