Vorlesung Echtzeitbetriebssysteme. Sommersemester FH-Isny

Größe: px
Ab Seite anzeigen:

Download "Vorlesung Echtzeitbetriebssysteme. Sommersemester 2006. 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

Roboter- und Automatisierungstechnik

Roboter- und Automatisierungstechnik Roboter- und Automatisierungstechnik Teil 4: Grundlagen der Echtzeitprogrammierung Hochschule Bremerhaven SS 2007 Prof. Dr. Oliver Zielinski Inhalt 4.1 Problemstellung 4.2 Echtzeitprogrammierverfahren

Mehr

Systeme 1. Kapitel 5. Scheduling

Systeme 1. Kapitel 5. Scheduling Systeme 1 Kapitel 5 Scheduling Scheduling Verteilung und Zuweisung von begrenzten Ressourcen an konkurrierende Prozesse Beispiel: -> Zeitablaufsteuerung Zwei Prozesse zur gleichen Zeit rechenbereit auf

Mehr

CPU-Scheduling - Grundkonzepte

CPU-Scheduling - Grundkonzepte CPU-Scheduling - Grundkonzepte Sommersemester 2015 Seite 1 Gesamtüberblick 1. Einführung in Computersysteme 2. Entwicklung von Betriebssystemen 3. Architekturansätze 4. Interruptverarbeitung in Betriebssystemen

Mehr

Datentechnik. => Das Rechenergebnis ist nur dann sinnvoll, wenn es rechtzeitig vorliegt. Die Zeit muß daher beim Programmdesign berücksichtigt werden.

Datentechnik. => Das Rechenergebnis ist nur dann sinnvoll, wenn es rechtzeitig vorliegt. Die Zeit muß daher beim Programmdesign berücksichtigt werden. 5. Steuerung technischer Prozesse 5.1 Echtzeit (real time) Im Gegensatz zu Aufgabenstellungen aus der Büroumgebung, wo der Anwender mehr oder weniger geduldig wartet, bis der Computer ein Ergebnis liefert

Mehr

Vorbereitung zur Prüfung Echtzeitbetriebssysteme

Vorbereitung zur Prüfung Echtzeitbetriebssysteme Vorbereitung zur Prüfung Echtzeitbetriebssysteme Zugelassene Hilfsmittel: Taschenrechner Bitte verwenden Sie keinen roten Farbstift! 1. Echtzeitbetriebssysteme - Allgemein (15 Punkte) 1.1. Warum setzen

Mehr

Prozesse und Prozessmanagement des BS. 1 Unterschied Prozess, Threads. 1.1 Prozess. 1.2 Threads

Prozesse und Prozessmanagement des BS. 1 Unterschied Prozess, Threads. 1.1 Prozess. 1.2 Threads Prozesse und Prozessmanagement des BS 1 Unterschied Prozess, Threads 1.1 Prozess Bei jedem Programm muss gespeichert werden, welche Betriebsmittel (Speicherplatz, CPU- Zeit, CPU-Inhalt,...) es benötigt.

Mehr

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Friedrich-Alexander-Universität Erlangen-Nürnberg Ausgewählte Kapitel eingebetteter Systeme Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Sven Kerschbaum 1. Einführung Bei einem eingebetteten

Mehr

Scheduling in Echtzeitbetriebssystemen. Prof. Dr. Margarita Esponda Freie Universität Berlin

Scheduling in Echtzeitbetriebssystemen. Prof. Dr. Margarita Esponda Freie Universität Berlin Scheduling in Echtzeitbetriebssystemen Prof. Dr. Margarita Esponda Freie Universität Berlin Echtzeitsysteme Korrekte Ergebnisse zum richtigen Zeitpunkt Hart Echtzeitsysteme Eine verspätete Antwort ist

Mehr

Echtzeitscheduling (1)

Echtzeitscheduling (1) Echtzeitscheduling (1) Scheduling in Betriebssystemen Ressourcenausteilung (CPU, Speicher, Kommunikation) Faire Ressourcenvergabe, insbesondere CPU Hohe Interaktivität / kurze Reaktionszeit für interaktive

Mehr

OSEK / OSEKtime Ausgewählte Kapitel eingebetteter Systeme

OSEK / OSEKtime Ausgewählte Kapitel eingebetteter Systeme OSEK / OSEKtime Ausgewählte Kapitel eingebetteter Systeme Wilhelm Haas Wilhelm.Haas@informatik.stud.uni-erlangen.de Friedrich-Alexander-Universität Erlangen-Nürnberg Institut für Informatik Lehrstuhl 4

Mehr

Systeme I: Betriebssysteme Kapitel 7 Scheduling. Maren Bennewitz

Systeme I: Betriebssysteme Kapitel 7 Scheduling. Maren Bennewitz Systeme I: Betriebssysteme Kapitel 7 Scheduling Maren Bennewitz Version 23.01.2013 1 Inhalt Vorlesung Aufbau einfacher Rechner Überblick: Aufgabe, Historische Entwicklung, unterschiedliche Arten von Betriebssystemen

Mehr

Echtzeitprogrammierung und Echtzeitverhalten von Keil RTX. Frank Erdrich Semester AI 7

Echtzeitprogrammierung und Echtzeitverhalten von Keil RTX. Frank Erdrich Semester AI 7 Echtzeitprogrammierung und Echtzeitverhalten von Frank Erdrich Semester AI 7 Inhalt Einleitung Echtzeit und Echtzeitsysteme Echtzeitprogrammierung Real-Time Operating System Keil RTOS RTX Zusammenfassung

Mehr

4 Echtzeit-Programmierung

4 Echtzeit-Programmierung 4 Echtzeit-Programmierung 4.1 Problemstellung 4.2 Echtzeit-Programmierverfahren 4.3 Rechenprozesse 4.4 Zeitliche Koordinierung von Rechenprozessen 4.5 Kommunikation zwischen Rechenprozessen 4.6 Scheduling-Verfahren

Mehr

Prozessautomatisierungstechnik

Prozessautomatisierungstechnik Mohieddine Jelali Prozessautomatisierungstechnik 4. Echtzeitsysteme und Echtzeitprogrammierung WS 2013/14 Vorlesung: Prozessautomatisierung, Prof. Dr.-Ing. Mohieddine Jelali 1 Inhaltsangaben zu Kapitel

Mehr

Übung zu Grundlagen der Betriebssysteme. 7. Übung 27.11.2012

Übung zu Grundlagen der Betriebssysteme. 7. Übung 27.11.2012 Übung zu Grundlagen der Betriebssysteme 7. Übung 27.11.2012 Threads Thread (Faden des (Kontrollflusses)): ist ein sequentieller Abarbeitungsablauf (Kontrollfluss) innerhalb eines Prozesses. Umfasst ein

Mehr

5) Realzeitscheduling

5) Realzeitscheduling Inhalte Anforderungen Klassifizierungen Verschiedene Verfahren: FIFO, Round Robin, Least Laxity, EDF, fixed/dyn. Prio. Beispiele und Aufgaben Seite 1 Motivation Gegeben: Ein Einprozessorsystem, das Multiprogrammierung

Mehr

Verteilte Echtzeit-Systeme

Verteilte Echtzeit-Systeme - Verteilte Echtzeit-Systeme Hans-Albrecht Schindler Wintersemester 2015/16 Teil B: Echtzeit-Betriebssysteme Abschnitt 9: Scheduling gemischter Prozessmengen CSI Technische Universität Ilmenau www.tu-ilmenau.de

Mehr

Betriebssysteme (BTS)

Betriebssysteme (BTS) 9.Vorlesung Betriebssysteme (BTS) Christian Baun cray@unix-ag.uni-kl.de Hochschule Mannheim Fakultät für Informatik Institut für Betriebssysteme 10.5.2007 Exkursion Die Exkursion wird am Freitag, den 18.5.2007

Mehr

Betriebssysteme I WS 2013/2014. Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404

Betriebssysteme I WS 2013/2014. Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Betriebssysteme I WS 2013/2014 Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 16. Januar 2014 Betriebssysteme / verteilte Systeme Betriebssysteme

Mehr

Round-Robin Scheduling (RR)

Round-Robin Scheduling (RR) RR - Scheduling Reigen-Modell: einfachster, ältester, fairster, am weitesten verbreiteter Algorithmus Entworfen für interaktive Systeme (preemptives Scheduling) Idee: Den Prozessen in der Bereitschaftsschlange

Mehr

Begriff: Scheduling Planung, Schedule Plan. Verplanung der CPU-Zeit an die Threads (bzw. Prozesse)

Begriff: Scheduling Planung, Schedule Plan. Verplanung der CPU-Zeit an die Threads (bzw. Prozesse) 5 CPU-Scheduling Im folgenden wird von Threads gesprochen. Bei Systemen, die keine Threads unterstützen, ist der einzige "Thread" eines Prozesses gemeint. Früher wurde dieser Thread synonym mit dem Begriff

Mehr

2 Echtzeitbetriebssysteme

2 Echtzeitbetriebssysteme 35 2 Echtzeitbetriebssysteme In den letzten Jahren hat sich die Automobilindustrie zu einem der wesentlichen Anwender von Echtzeitbetriebssystemen für eingebettete Systeme entwickelt. Relativ zeitig erkannten

Mehr

Technische Informatik II

Technische Informatik II Institut für Technische Informatik und Kommunikationsnetze Technische Informatik II Übung 1: Prozesse und Threads Aufgabe 1: Prozesse und Threads a) Wie verhält sich eine Applikation die aus mehreren Prozessen

Mehr

Systeme I: Betriebssysteme Kapitel 4 Prozesse. Maren Bennewitz

Systeme I: Betriebssysteme Kapitel 4 Prozesse. Maren Bennewitz Systeme I: Betriebssysteme Kapitel 4 Prozesse Maren Bennewitz Version 20.11.2013 1 Begrüßung Heute ist Tag der offenen Tür Willkommen allen Schülerinnen und Schülern! 2 Wdhlg.: Attributinformationen in

Mehr

Aufbau eines Echtzeit-Betriebssystems für Embedded Systems

Aufbau eines Echtzeit-Betriebssystems für Embedded Systems Aufbau eines Echtzeit-Betriebssystems für Embedded Systems I. Begriffsdefinition II. Anforderungen III. Struktur und Komponenten Dr.-Ing. Ludwig Eckert, Seite 1 I. Begriffsdefinition: Embedded System Bsp.:

Mehr

Der Scheduler von Windows Konzepte und Strategien

Der Scheduler von Windows Konzepte und Strategien Gliederung Der Scheduler von Windows Konzepte und Strategien Daniel Lohmann 1 Grundbegriffe 2 Eigenschaften des Schedulers Grundlegende Eigenschaften Prioritätenmodell Dynamische Prioritätenanpassungen

Mehr

Dämon-Prozesse ( deamon )

Dämon-Prozesse ( deamon ) Prozesse unter UNIX - Prozessarten Interaktive Prozesse Shell-Prozesse arbeiten mit stdin ( Tastatur ) und stdout ( Bildschirm ) Dämon-Prozesse ( deamon ) arbeiten im Hintergrund ohne stdin und stdout

Mehr

Real-Time Operating Systems Ein Überblick

Real-Time Operating Systems Ein Überblick Real-Time Operating Systems Ein Überblick Stefan Tittel Universität Dortmund Proseminar: Werkzeuge und Techniken zur Spezifikation, Simulation und Implementierung von eingebetteten Systemen, 2004 1 Einführung

Mehr

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003 Task! evt. parallel zu bearbeitende Ausführungseinheit! Beispiel: Task A Zündung Task B Einspritzung Task C Erfassung Pedalwert Zeit t J. Schäuffele, Th. Zurawka:, Vieweg, 2003 Echtzeitbetriebssysteme

Mehr

OSEK / OSEKtime - ein Vergleich

OSEK / OSEKtime - ein Vergleich OSEK / OSEKtime - ein Vergleich Hauptseminar WS 07/08 André Puschmann andre.puschmann@stud.tu-ilmenau.de Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Fachgebiet Rechnerarchitektur

Mehr

RTEMS- Echtzeitbetriebssystem

RTEMS- Echtzeitbetriebssystem RTEMS- Echtzeitbetriebssystem Name: Hussein Hammoud Matrikel- Nr.: 230768 Studiengang: Technische Informatik Fach: Projekt Eingebettete Kommunikation Technische Universität Berlin Sommersemester 2006 RTEMS-

Mehr

Scheduler. Optimierung des Schedulings. Gliederung. Allgemeine Ziele. Synchronisationsprotokolle

Scheduler. Optimierung des Schedulings. Gliederung. Allgemeine Ziele. Synchronisationsprotokolle Aufgabe: Zuteilung der auf die CPU Automatisches Entwurfs- und Entwicklungssystem für harte Echtzeitsysteme Zuteilungsstrategien: Satz Jan Blumenthal 20.02.2003 Zyklisch 4 Gliederung Optimierung des Schedulings

Mehr

Betriebssysteme Kap F: CPU-Steuerung CPU-Scheduling

Betriebssysteme Kap F: CPU-Steuerung CPU-Scheduling Betriebssysteme Kap F: CPU-Steuerung CPU-Scheduling 1 termini technici Der englische Fachausdruck scheduler wurde eingedeutscht : Der Scheduler Für scheduling ist im Deutschen auch zu verwenden: Ablaufplanung

Mehr

Ein Scheduler für alle Fälle Robert Kaiser, SYSGO AG

Ein Scheduler für alle Fälle Robert Kaiser, SYSGO AG Ein Scheduler für alle Fälle Robert Kaiser, SYSGO AG Am Pfaffenstein 14 D-55270 Klein-Winternheim Tel. +49 (0) 6136 9948-0 Fax. +49 (0) 6136 9948-10 PikeOS: multiple VM Umgebung VM #0 VM #1 VM #2... PikeOS

Mehr

Rechnernutzung in der Physik. Betriebssysteme

Rechnernutzung in der Physik. Betriebssysteme Rechnernutzung in der Physik Betriebssysteme 1 Betriebssysteme Anwendungsprogramme Betriebssystem Treiber BIOS Direkter Zugriff von Anwenderprogrammen auf Hardware nur in Ausnahmefällen sinnvoll / möglich:

Mehr

Systemsoftware (SYS) Fakultät für Informatik WS 2008/2009 Christian Baun. Übungsklausur

Systemsoftware (SYS) Fakultät für Informatik WS 2008/2009 Christian Baun. Übungsklausur Hochschule Mannheim Systemsoftware (SYS) Fakultät für Informatik WS 2008/2009 Christian Baun Übungsklausur Aufgabe 1: Definieren Sie den Begriff der Systemsoftware. Nennen Sie die Aufgaben und Komponenten

Mehr

Betriebssystembau (BSB)

Betriebssystembau (BSB) Betriebssystembau (BSB) 6. Übung http://ess.cs.tu-.de/de/teaching/ws2013/bsb/ Olaf Spinczyk olaf.spinczyk@tu-.de http://ess.cs.tu-.de/~os AG Eingebettete System Informatik 12, TU Dortmund Agenda Vorstellung

Mehr

Prozesse und Scheduling

Prozesse und Scheduling Betriebssysteme für Wirtschaftsinformatiker SS04 KLAUSUR Vorbereitung mit Lösungen / Blatt 1 Prozesse und Scheduling Aufgabe 1 : Scheduling Gegeben seien die folgenden Prozesse und die Längen des jeweiligen

Mehr

Operating System Kernels

Operating System Kernels Operating System Kernels von Patrick Bitterling 1 Themenübersicht -Eine Einleitung über Kernel -Begriffserklärung, Architekturen -Kernel Subsysteme -Prozess-Scheduling, Speichermanagement,... -Der Networking

Mehr

Scheduling. Prozess-Ablaufplanung. Prof. Dr. Margarita Esponda Freie Universität Berlin WS 2011/2012

Scheduling. Prozess-Ablaufplanung. Prof. Dr. Margarita Esponda Freie Universität Berlin WS 2011/2012 Scheduling Prozess-Ablaufplanung Prof. Dr. Margarita Esponda Freie Universität Berlin WS 2011/2012 Scheduler Der Scheduler ist ein besonders wichtiges Programmteil jedes Betriebssystems. Prozesse P 1 P

Mehr

Zeit- und ereignisgesteuerte Echtzeitsysteme

Zeit- und ereignisgesteuerte Echtzeitsysteme Zeit- und ereignisgesteuerte Echtzeitsysteme Stephan Braun Stephan.Braun.Hagen@t-online.de PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Echtzeitsystemmodell Einführung Ereignis- und zeitgesteuerte

Mehr

(b) Worin besteht der Unterschied zwischen online und offline Scheduling?

(b) Worin besteht der Unterschied zwischen online und offline Scheduling? Universität Paderborn Fachgebiet Rechnernetze SoSe 2013 Konzepte und Methoden der Systemsoftware Präsenzübung 3 2013-05-06 bis 2013-05-10 Aufgabe 1: Scheduling - Grundbegriffe Bekanntlich gibt es für das

Mehr

Übung I Echtzeitbetriebssysteme

Übung I Echtzeitbetriebssysteme Übung I Echtzeitbetriebssysteme a) Von welchen drei Faktoren hängt bei der Echtzeitverarbeitung das korrekte Ergebnis ab? b) Wann ist ein System echtzeitfähig? c) Was versteht man unter Harter und Weicher

Mehr

Lösungsskizzen zur Abschlussklausur Betriebssysteme

Lösungsskizzen zur Abschlussklausur Betriebssysteme Lösungsskizzen zur Abschlussklausur Betriebssysteme 24. Januar 2013 Name: Vorname: Matrikelnummer: Studiengang: Hinweise: Tragen Sie zuerst auf allen Blättern (einschlieÿlich des Deckblattes) Ihren Namen,

Mehr

Seminar: Mobile Geräte QNX Einführung

Seminar: Mobile Geräte QNX Einführung Seminar: Mobile Geräte QNX Einführung Vortragender: Alex Maurer 2010/2011 Philipps Universität Marburg Echtzeitbetriebssystem QNX QNX ist ein RTOS (Real Time OS) vorhersagbares Zeitverhalten niedrige Latenz

Mehr

Schedulingalgorithmen Rechenzeitverteilung auf Betriebssystemebene. Andi Drebes Fachbereich Informatik Universität Hamburg

Schedulingalgorithmen Rechenzeitverteilung auf Betriebssystemebene. Andi Drebes Fachbereich Informatik Universität Hamburg Schedulingalgorithmen Rechenzeitverteilung auf Betriebssystemebene Andi Drebes Fachbereich Informatik Universität Hamburg Gliederung Notwendigkeit des Schedulings Einführung: Begriff des Multitaskings

Mehr

20 Eingebettete Software

20 Eingebettete Software 20 Eingebettete Software 20.0 Einführung Lernziele Echtzeitsysteme Eingebettete Systeme 20.1 Entwurf eingebetteter Systeme Modellierung von Echtzeitsystemen Programmierung von Echtzeitsystemen 20.2 Architekturmuster

Mehr

Programme werden durch den Ablauf eines oder mehrerer Prozesse (engl.: process, task) von einem Rechner abgearbeitet.

Programme werden durch den Ablauf eines oder mehrerer Prozesse (engl.: process, task) von einem Rechner abgearbeitet. Prozessverwaltung Prozesse Programme werden durch den Ablauf eines oder mehrerer Prozesse (engl.: process, task) von einem Rechner abgearbeitet. Prozesse sind Abfolgen von Aktionen, die unter Kontrolle

Mehr

Architektur Verteilter Systeme Teil 2: Prozesse und Threads

Architektur Verteilter Systeme Teil 2: Prozesse und Threads Architektur Verteilter Systeme Teil 2: Prozesse und Threads 21.10.15 1 Übersicht Prozess Thread Scheduler Time Sharing 2 Begriff Prozess und Thread I Prozess = Sequentiell ablaufendes Programm Thread =

Mehr

Welche der folgenden Aussagen gelten? a) Im allgemeinen gilt: ein Deadlock tritt auf gdw. der Resource-Allocation Graph einen Zykel

Welche der folgenden Aussagen gelten? a) Im allgemeinen gilt: ein Deadlock tritt auf gdw. der Resource-Allocation Graph einen Zykel Aufgabe 1 (5 Punkte) (Multiple Choice) Beantworten Sie folgende Fragen durch Ankreuzen der richtigen Antwort. Für jede falsche Antwort wird ein Punkt abgezogen (es werden minimal 0 Punkte vergeben). Welche

Mehr

SurefireKernel ÜBERSICHT SPEZIFIKATION. www.triadem.ch. Sicherheitskernel DATASHEET

SurefireKernel ÜBERSICHT SPEZIFIKATION. www.triadem.ch. Sicherheitskernel DATASHEET Sicherheitskernel ÜBERSICHT SurefireKernel ist ein schlanker skalierbarer nicht preemptiver Echtzeit-Kernel der für den Einsatz auf Kontrollersysteme optimiert ist. Er verfügt über eine Realtime-Überwachung

Mehr

Inhaltsverzeichnis. 2.4 Thread-Systeme. 2.1 Was ist ein Prozess? 2.2 Scheduling. 2.3 Interprozesskommunikation

Inhaltsverzeichnis. 2.4 Thread-Systeme. 2.1 Was ist ein Prozess? 2.2 Scheduling. 2.3 Interprozesskommunikation Inhaltsverzeichnis Systemprogrammierung - Kapitel 2 Prozessverwaltung 1/21 2.1 Was ist ein Prozess? Definition Prozesszustände Prozesskontrollblöcke 2.4 Thread-Systeme Sinn und Zweck Thread-Arten Thread-Management

Mehr

Echtzeitanforderung und Linux

Echtzeitanforderung und Linux Echtzeitanforderung und Linux Slide 1 - http://www.pengutronix.de - 21.01.2007 Definition Harte Echtzeit I Was zeichnet ein Echtzeitsystem aus? Zeitverhalten ist Teil der System-Spezifikation! Bei Embedded-Systemen

Mehr

Systemprogramme bezeichnen alle Programme, die bestimmte Aufgaben unterstützen, die unabhängig von einer konkreten Anwendung sind

Systemprogramme bezeichnen alle Programme, die bestimmte Aufgaben unterstützen, die unabhängig von einer konkreten Anwendung sind Betriebssysteme Systemprogramme bezeichnen alle Programme, die bestimmte Aufgaben unterstützen, die unabhängig von einer konkreten Anwendung sind Umfaßt z.b. auch Compiler, Interpreter und Dienstprogramme

Mehr

Betriebssysteme Kap A: Grundlagen

Betriebssysteme Kap A: Grundlagen Betriebssysteme Kap A: Grundlagen 1 Betriebssystem Definition DIN 44300 Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten

Mehr

OSEK-OS. Oliver Botschkowski. oliver.botschkowski@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab

OSEK-OS. Oliver Botschkowski. oliver.botschkowski@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab OSEK-OS Oliver Botschkowski oliver.botschkowski@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Einleitung Motivation Ziele Vorteile Einführung in OSEK-OS Architektur Task Management Interrupt

Mehr

Einführung in die Echtzeitbetriebssysteme

Einführung in die Echtzeitbetriebssysteme Einführung in die Echtzeitbetriebssysteme Hauptseminararbeit in dem Studiengang B.Sc. Informatik von Maximilian von Piechowski Technische Hochschule Mittelhessen Inhaltsverzeichnis 1 Was versteht man unter

Mehr

Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS. geschrieben von Oliver Botschkowski

Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS. geschrieben von Oliver Botschkowski Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS geschrieben von Oliver Botschkowski 1 Offene Systeme und deren Schnittstelle für die Elektronik im Kraftfahrzeug 1 Oliver Botschkowski - OSEK-OS

Mehr

3. Scheduler und Schedulingstrategien

3. Scheduler und Schedulingstrategien 5 3 Scheduler und Schedulingstrategien Unter Scheduling versteht man einen Ablaufplan, einen Fahrplan oder eine Auswahlstrategie, nach der ein knappes Betriebsmittel im Wettbewerb befindlichen Prozessen

Mehr

B.5 Prozessverwaltung B.5. Prozessverwaltung. 2002 Prof. Dr. Rainer Manthey Informatik II 1

B.5 Prozessverwaltung B.5. Prozessverwaltung. 2002 Prof. Dr. Rainer Manthey Informatik II 1 Prozessverwaltung Prozessverwaltung 2002 Prof. Dr. Rainer Manthey Informatik II 1 Prozesse Programme werden durch den Ablauf eines oder mehrerer Prozesse (engl.: process, task) ) von einem Rechner abgearbeitet.

Mehr

Quantitative Methoden. Betriebssysteme

Quantitative Methoden. Betriebssysteme Quantitative Methoden Betriebssysteme Problem und Gegenstand Problem Erfüllen von QoS-Anforderungen mit zeit- bzw. größenbeschränkten Ressourcen Gegenstand Scheduling basierend auf deterministischen Modellen

Mehr

8. Vorlesung Betriebssysteme

8. Vorlesung Betriebssysteme Dr. Christian Baun 8. Vorlesung Betriebssysteme Hochschule Mannheim WS1213 1/69 8. Vorlesung Betriebssysteme Dr. Christian Baun Hochschule Mannheim Fakultät für Informatik wolkenrechnen@gmail.com Dr. Christian

Mehr

Simple Scope. ecos-vertiefung. Florian Franzmann Tobias Klaus Peter Wägemann

Simple Scope. ecos-vertiefung. Florian Franzmann Tobias Klaus Peter Wägemann Simple Scope ecos-vertiefung Florian Franzmann Tobias Klaus Peter Wägemann Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl Informatik 4 (Verteilte Systeme und Betriebssysteme) http://www4.cs.fau.de

Mehr

Hausübung 2(Musterlösung)

Hausübung 2(Musterlösung) SoSe 2014 Konzepte und Methoden der Systemsoftware Universität Paderborn Fachgebiet Rechnernetze Hausübung 2(Musterlösung) 2014-05-12 bis 2014-05-23 Hausübungsabgabe: Format: Lösungen in schriftlicher

Mehr

5 CPU Scheduling. FH Regensburg BT/SS04 Betriebssysteme Wirtschaftsinformatik. 5.1 Grundlagen - 54 - 5.1.1 CPU Burst / I/O Burst

5 CPU Scheduling. FH Regensburg BT/SS04 Betriebssysteme Wirtschaftsinformatik. 5.1 Grundlagen - 54 - 5.1.1 CPU Burst / I/O Burst FH Regensburg BT/SS04 5 CPU Scheduling 5.1 Grundlagen 5.1.1 CPU Burst / I/O Burst Beobachtung: Programme rechnen typischerweise etwas, dann tätigen sie Ein/Ausgabe: CPU-Burst: das Programm rechnet eine

Mehr

Hausübung 2. Konzepte und Methoden der Systemsoftware. Aufgabe 1: Einfache Schedulingstrategien. SoSe bis

Hausübung 2. Konzepte und Methoden der Systemsoftware. Aufgabe 1: Einfache Schedulingstrategien. SoSe bis Universität Paderborn Fachgebiet Rechnernetze SoSe 2014 Konzepte und Methoden der Systemsoftware Hausübung 2 2014-05-12 bis 2014-05-23 Hausübungsabgabe: Format: Lösungen in schriftlicher oder gedruckter

Mehr

Was machen wir heute? Betriebssysteme Tutorium 2. Organisatorisches. Frage 2.1.a. Theorieblätter Abgabe. Antwort. Probleme mit OS/161?

Was machen wir heute? Betriebssysteme Tutorium 2. Organisatorisches. Frage 2.1.a. Theorieblätter Abgabe. Antwort. Probleme mit OS/161? Was machen wir heute? Betriebssysteme Tutorium 2 Philipp Kirchhofer philipp.kirchhofer@student.kit.edu http://www.stud.uni-karlsruhe.de/~uxbtt/ Lehrstuhl Systemarchitektur Universität Karlsruhe (TH) 1

Mehr

*DE102007042999A120090312*

*DE102007042999A120090312* *DE102007042999A120090312* (19) Bundesrepublik Deutschland Deutsches Patent- und Markenamt (10) DE 10 2007 042 999 A1 2009.03.12 (12) Offenlegungsschrift (21) Aktenzeichen: 10 2007 042 999.3 (22) Anmeldetag:

Mehr

TIMI: Technische Informatik für Medieninformatiker

TIMI: Technische Informatik für Medieninformatiker TIMI: Technische Informatik für Medieninformatiker Bachelor-Studiengang Digitale Medien Medieninformatik SS 2004 Niels Pollem Arbeitsgruppe Rechnernetze (Prof. Dr.-Ing. Ute Bormann) Scheduling:

Mehr

Domänenmodell: Fadenkommunikation und -synchronisation

Domänenmodell: Fadenkommunikation und -synchronisation Domänenmodell: Fadenkommunikation und -synchronisation Alexander Humphreys, Reinhard Rösch, Fabian Scheler 15. Mai 2003 Inhaltsverzeichnis 1 Domänendefinition 1 2 Domänenlexikon 1 3 Konzeptmodelle 4 4

Mehr

Übungen zum Fach Betriebssysteme Kapitel 3

Übungen zum Fach Betriebssysteme Kapitel 3 Übungen zum Fach Betriebssysteme Kapitel 3 Prof. Dr. Kern & Prof. Dr. Wienkop Prozessverwaltung 1 Prozeßauslagerung Ein Betriebssystem, das die Zustände "rechnend", "bereit" und "wartend" sowie den künstlichen

Mehr

DIPLOMHAUPTPRÜFUNG FÜR ELEKTROINGENIEURE PROZESSAUTOMATISIERUNG I Sommersemester 2006 - Musterlösung

DIPLOMHAUPTPRÜFUNG FÜR ELEKTROINGENIEURE PROZESSAUTOMATISIERUNG I Sommersemester 2006 - Musterlösung Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Mr, Mb 30.08.06 DIPLOMHAUPTPRÜFUNG FÜR ELEKTROINGENIEURE PROZESSAUTOMATISIERUNG I Sommersemester

Mehr

Übersicht. Nebenläufige Programmierung. Praxis und Semantik. Einleitung. Sequentielle und nebenläufige Programmierung. Warum ist. interessant?

Übersicht. Nebenläufige Programmierung. Praxis und Semantik. Einleitung. Sequentielle und nebenläufige Programmierung. Warum ist. interessant? Übersicht Aktuelle Themen zu Informatik der Systeme: Nebenläufige Programmierung: Praxis und Semantik Einleitung 1 2 der nebenläufigen Programmierung WS 2011/12 Stand der Folien: 18. Oktober 2011 1 TIDS

Mehr

DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Sep 2012. 4) Task-Verwaltung

DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Sep 2012. 4) Task-Verwaltung Inhalte Eigenschaften von Rechenprozessen (Tasks) Taskübergänge (process control block) Multitasking (kooperativ und präemptiv) Scheduler Erzeugen, Starten und Beenden von Tasks Taskzustände (running,

Mehr

ARM Cortex-M Prozessoren. Referat von Peter Voser Embedded Development GmbH

ARM Cortex-M Prozessoren. Referat von Peter Voser Embedded Development GmbH ARM Cortex-M Prozessoren Referat von Peter Voser Embedded Development GmbH SoC (System-on-Chip) www.embedded-development.ch 2 Instruction Sets ARM, Thumb, Thumb-2 32-bit ARM - verbesserte Rechenleistung

Mehr

13. Übung mit Musterlösung

13. Übung mit Musterlösung 13. Übung mit Musterlösung 1 Lösung 1 Teil 1.Multiple Choice) Bewertung: Ein Punkt für richtige Antwort, für jede falsche Antwort ein Punktabzug. a) Für die Exponentialverteilung ist die Zeit bis zum nächsten

Mehr

Betriebssysteme. Teil 13: Scheduling

Betriebssysteme. Teil 13: Scheduling Betriebssysteme Teil 13: Scheduling Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 15.01.16 1 Literatur [13-1] Quade, Jürgen; Mächtel, Michael: Moderne Realzeitsysteme kompakt. dpunkt, 2012 [13-2] Quade,

Mehr

Betriebssysteme und Systemsoftware

Betriebssysteme und Systemsoftware Merlin Denker Version 2 1 / 18 Vorwort Dieses Dokument soll einen Überblick über verschiedene Strategien aus der an der RWTH Aachen gehaltenen Vorlesung bieten. Die vorliegende Version dieses Dokuments

Mehr

Slothful Linux: An Efficient Hybrid Real-Time System by Hardware-Based Task Dispatching. Rainer Müller

Slothful Linux: An Efficient Hybrid Real-Time System by Hardware-Based Task Dispatching. Rainer Müller Slothful Linux: An Efficient Hybrid Real-Time System by Hardware-Based Task Dispatching Rainer Müller 21. November 2013 Spezialisierung von Betriebssystemen Vielzweckbetriebssysteme (General Purpose OS,

Mehr

OSEK/OSEKtime OS. Friedrich Alexander Universität Erlangen-Nürnberg. Wilhelm Haas 15. Juli 2006

OSEK/OSEKtime OS. Friedrich Alexander Universität Erlangen-Nürnberg. Wilhelm Haas 15. Juli 2006 OSEK/OSEKtime OS Ausgewählte Kapitel eingebetteter Systeme Friedrich Alexander Universität Erlangen-Nürnberg 1 Einführung Die Abkürzung OSEK steht für ein im Jahre 1993 gegründetes industrielles Standardisierungsgremium,

Mehr

OSEKtime - Time-Triggered OSEK/OS

OSEKtime - Time-Triggered OSEK/OS OSEKtime - Time-Triggered OSEK/OS Gregor Kaleta gregor.kaleta@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Einleitung OSEKtime Task-Zustandsmodell, Scheduling-Verfahren Interrupt-Verarbeitung

Mehr

183.579, SS2012 Übungsgruppen: Do., 14.6. Mi., 20.6.2012

183.579, SS2012 Übungsgruppen: Do., 14.6. Mi., 20.6.2012 VU Technische Grundlagen der Informatik Übung 8: Systemsoftware und Netzwerke 183.579, SS2012 Übungsgruppen: o., 14.6. Mi., 20.6.2012 ufgabe 1: Virtual Memory Zeichnen Sie ein System das Paging zur Speicherverwaltung

Mehr

Seminar. PG AutoLab. Verteilte Echtzeitsysteme. Sabrina Hecke. PG 522 Fachbereich Informatik Technische Universität Dortmund Lehrstuhl XII

Seminar. PG AutoLab. Verteilte Echtzeitsysteme. Sabrina Hecke. PG 522 Fachbereich Informatik Technische Universität Dortmund Lehrstuhl XII PG AutoLab Seminar Verteilte Echtzeitsysteme Sabrina Hecke PG 522 Fachbereich Informatik Technische Universität Dortmund Lehrstuhl XII 21. bis 23. Oktober 2007 Inhaltsverzeichnis 1 Was sind Echtzeitsysteme?

Mehr

Real Time Operating Systems (RTOS) = Echtzeit-Betriebssysteme. Eine Einführung. Klaus Kusche, Okt. 2011

Real Time Operating Systems (RTOS) = Echtzeit-Betriebssysteme. Eine Einführung. Klaus Kusche, Okt. 2011 Real Time Operating Systems (RTOS) = Echtzeit-Betriebssysteme Eine Einführung Klaus Kusche, Okt. 2011 Ziele des Vortrags Überblick über das Thema Praktisches Verständnis von Anforderungen Problembereichen

Mehr

Scheduling. Gliederung. Was ist Scheduling? Scheduling. Übersicht: 1. Einführung und Übersicht. 2. Prozesse und Threads. 3. Interrupts. 4.

Scheduling. Gliederung. Was ist Scheduling? Scheduling. Übersicht: 1. Einführung und Übersicht. 2. Prozesse und Threads. 3. Interrupts. 4. Gliederung 1. Einführung und Übersicht 2. Prozesse und Threads 3. Interrupts 4. 5. Synchronisation 6. Interprozesskommunikation 7. Speicherverwaltung Cl. Schnörr / HM 1 Gliederung Cl. Schnörr / HM 2 Was

Mehr

Effiziente Ankopplung eines zeitgesteuerten Feldbusses an ein Echtzeitbetriebssystem

Effiziente Ankopplung eines zeitgesteuerten Feldbusses an ein Echtzeitbetriebssystem Effiziente Ankopplung eines zeitgesteuerten Feldbusses an ein Echtzeitbetriebssystem Björn Pietsch Universität Hannover Amos Albert Robert Bosch GmbH 1 Gliederung Zeitgesteuerte Bussysteme Bisherige Lösungen

Mehr

1 Einleitung. 1.1 Aufgaben und Grobstruktur. Was ist ein Betriebssystem?

1 Einleitung. 1.1 Aufgaben und Grobstruktur. Was ist ein Betriebssystem? 1 Einleitung 1.1 Aufgaben und Grobstruktur Was ist ein Betriebssystem? Betriebssystem (Definition nach DIN 44300) Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften der Rechenanlage

Mehr

Embedded Linux. Arthur Baran

Embedded Linux. Arthur Baran Arthur Baran Inhalt Embedded System Aufbau von Embedded Linux Systemen Echtzeit Einige Beispiele Arthur Baran 2 Was ist Embedded System? klein verborgen im Gerät soll eine bestimmte Aufgabe erledigen Arthur

Mehr

B.4. B.4 Betriebssysteme. 2002 Prof. Dr. Rainer Manthey Informatik II 1

B.4. B.4 Betriebssysteme. 2002 Prof. Dr. Rainer Manthey Informatik II 1 Betriebssysteme Betriebssysteme 2002 Prof. Dr. Rainer Manthey Informatik II 1 Bekannte Betriebssysteme Windows 2000 CMS UNIX MS-DOS OS/2 VM/SP BS 2000 MVS Windows NT Solaris Linux 2002 Prof. Dr. Rainer

Mehr

Verbessertes Konzept: Monitore

Verbessertes Konzept: Monitore Verbessertes Konzept: Monitore Ein Nachteil von Semaphoren ist die Notwendigkeit zur expliziten Anforderung P und Freigabe V des kritischen Bereiches durch den Programmierer Vergißt der Entwickler z.b.

Mehr

Embedded OS für ARM Cortex Microcontroller

Embedded OS für ARM Cortex Microcontroller Embedded OS für ARM Cortex Microcontroller RTOS Design, Timinganalyse und Test mit Core Simulation und Hardware Debugger Entscheidende Fragen für oder gegen RTOS Lohnt sich der Einsatz eines RTOS auch

Mehr

Systeme 1. Kapitel 6. Nebenläufigkeit und wechselseitiger Ausschluss

Systeme 1. Kapitel 6. Nebenläufigkeit und wechselseitiger Ausschluss Systeme 1 Kapitel 6 Nebenläufigkeit und wechselseitiger Ausschluss Threads Die Adressräume verschiedener Prozesse sind getrennt und geschützt gegen den Zugriff anderer Prozesse. Threads sind leichtgewichtige

Mehr

Technische Grundlagen. Betriebssystem, Mac, GoLive

Technische Grundlagen. Betriebssystem, Mac, GoLive Technische Grundlagen Betriebssystem, Mac, GoLive Betriebssystem Nutzer Anwendungsprogramme Systemprogramme Hardware U1...Un Textverarbeitungssysteme Buchungssysteme Verwaltungsprogramme Spiele Kommandointerpreter

Mehr

Zusammenfassung Modul 223

Zusammenfassung Modul 223 Zusammenfassung Modul 223 von Christian Roth Powered by Schuschu Bison Schweiz AG, Surentalstrasse 10, CH-6210 Sursee, www.bison-group.com Inhaltsverzeichnis 1 Entwurfmuster... 3 1.1 Singleton... 3 1.1.1

Mehr

AN025. Application Note 025 zu MODULAR-4 (ML3 und ML5) Messen der CPU-Auslastung im Echtzeitbetrieb

AN025. Application Note 025 zu MODULAR-4 (ML3 und ML5) Messen der CPU-Auslastung im Echtzeitbetrieb AN025 Application Note 025 zu MODULAR-4 (ML3 und ML5) Messen der Autor: HB AN025.DOC (6 Seiten) 1. Definition Im folgenden wie auch in allen anderen Sorcus Schriften werden folgende Kurzbezeichnungen verwendet:

Mehr

Musterlösung 3. Mikroprozessor & Eingebettete Systeme 1

Musterlösung 3. Mikroprozessor & Eingebettete Systeme 1 Musterlösung 3 Mikroprozessor & Eingebettete Systeme 1 WS214/215 Hinweis: Die folgenden Aufgaben erheben nicht den Anspruch, eine tief ergehende Kenntnis zu vermitteln; sie sollen lediglich den Einstieg

Mehr

Domänenanalyse Threadverwaltung/Scheduling

Domänenanalyse Threadverwaltung/Scheduling Domänenanalyse Threadverwaltung/Scheduling Johannes Handl, Marc Rößler, Christian Strengert 15. Mai 2003 Domänenanalyse Threadverwaltung/Scheduling [1] Domänendefinition Die Erzeugung, Verwaltung, Umschaltung/Wechsel,

Mehr

Inhaltsverzeichnis XII

Inhaltsverzeichnis XII 1 Einführung... 1 1.1 Computersysteme... 1 1.1.1 Einführung... 2 1.1.2 Aufgabe von Betriebssystemen... 3 1.1.3 Grundlegende Hardwaremodelle... 3 1.1.4 CPU-Registersatz... 7 1.1.5 Multicore-Prozessoren

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Name: Matrikel-Nr: Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Bitte schreiben Sie leserlich und antworten Sie kurz und präzise. 1. Zeichnen Sie das Schichten-Modell eines Computersystems und markieren

Mehr

^ Springer Vi eweg. Grundkurs Betriebssysteme. Synchronisation, Prozesskommunikation, Virtualisierung. Architekturen, Betriebsmittelverwaltung,

^ Springer Vi eweg. Grundkurs Betriebssysteme. Synchronisation, Prozesskommunikation, Virtualisierung. Architekturen, Betriebsmittelverwaltung, Peter Mandl Grundkurs Betriebssysteme Architekturen, Betriebsmittelverwaltung, Synchronisation, Prozesskommunikation, Virtualisierung 4. Auflage ^ Springer Vi eweg 1 Einführung 1 1.1 Computersysteme 1

Mehr