Vorlesung Echtzeitbetriebssysteme III. Entwurf von Echtzeitsystemen Dr.-Ing. Frank Golatowski

Ziele der Vorlesung Aufzeigen, welche Möglichkeiten es gibt, ein Echtzeitsystem zu konstruieren. Sowohl ohne Betriebssystem als auch mit Betriebssystem

Gliederung: Mögliche Wege, ein Echtzeit-System zu konstruieren Polling in einer Endlosschleife (Polled Loop Systems) Polled Loop ohne Interrupts Polled Loop mit Interrupts Phase/ State Driven Code Coroutine Kooperatives Multitasking Spezialfall: Zyklische Exekutive Interruptgesteuertes Systems Multitasksysteme Kooperatives Multitasking (non-preemptive Multitasking) Preemptives prioritätsbasiertes Multitasking

Gliederung Polling in einer Endlosschleife (Polled Loop Systems) Phase/ State Driven Code Coroutine Interrupt Driven Systems Foreground / Background Systems RTOS

Unendliche Pollingschleife Polled Loop Systems Einfachster RT-Kernel Schnelle Reaktion auf einzelne Ereignisse In einer einzelnen sich wiederholenden TEST-Operation wird auf das Vorhandensein bzw. Nichtvorhandensein eines Ereignisses getestet In Abhängigkeit vom Vorhandensein des Ereignisses wird eine bestimmte Funktion ausgeführt. (Hier: ProcessData()) Es ist keine IPC und kein Scheduling erforderlich, da nur eine einzelne Task existiert main() { FLAG flPacketFlag; for (;;){ if (flPacketHere == TRUE) { ProcessData(); // Daten verarbeiten flPacketHere=FALSE); // reset Flag } Max 1 Datenpaket erreicht im Abstand von 1s das System Ein Flag PacketHere wird durch das Netzwerk gesetzt, wenn ein Paket eintrifft. Daten werden per DMA in den Speicher der CPU geschrieben Daten sind verfügbar, wenn Packethere = 1

Unendliche Pollingschleife Anwendung Wenn ein einzelner Prozessor für die Behandlung weniger schneller Geräte vorgesehen ist. Wenn Ereignisse sich nicht überlappen bzw. wenn die Überlappung minimal ist oder minimal gehalten werden kann

Unendliche Pollingschleife ohne Interrupts Eine Hauptschleife bedient alle I/O-Anforderungen sequentiell 1. Zum Auffinden eintreffender Ereignisse werden alle I/O-Leitungen / Geräte getestet 2. Als Reaktion auf die eintreffende Ereignisse werden Funktionen ausgeführt Gut für sich regelmäßig (vorhersagbar) ändernde Eingaben z.B. 9600-Baud serieller Port Schlecht für sich unregelmäßig ändernde Eingaben, die schnelle Reaktionen erfordern Systeme mit einer großen Anzahl von Eingängen z.B. Alarm-Signale, asynchrone Eingaben z.B. von einer Tastatur

Unendliche Pollingschleife ohne Interrupts als zyklische Exekutive (ZE) Beispiel für Codeabschnitte main() { i =0; for (;;){ CheckInputs(); CheckDigitalInterfaces(); switch (i){ case 0 : application0();break; case 1 : application1();break; case 2 : application2();break; case 3 : i=0;break; } i++; main() { for (;;){ CheckInputs(); CheckDigitalInterfaces(); Application(); } <Existierender Code> <Aufgesplitteter Code>

Unendliche Pollingschleife ohne Interrupts mit zykl. Exekutive Das Problem der zyklischen Exekutive liegt im Code-Splitting I/O-Polling verschwendet CPU-Zeit Test auf Korrektheit des Algorithmus und des Zeitverhaltens nach der Aufsplittung Immer wenn der Code verändert wird, ist ein Neuaufsplitten mit nachfolgendem Test auf Korrektheit erforderlich Wartung und Pflege solcher Software sehr schwierig Code schwer lesbar Bei Wechsel der Hardware u.U. Neustrukturierung der Software erforderlich Tests der Algorithmen und des Timings

Unendliche Pollingschleife mit Interrupt Diese Variation der Pollingschleife nutzt einen festen Uhren-Interrupt Es wird eine bestimmte Zeitdauer abgewartet, zwischen dem Erkennen, dass das FLAG = TRUE ist und dem erneuten Rücksetzen auf FALSE Wird zum Schalter-Entprellen verwendet: Eine Verzögerungszeit kann z.B. mit programmierbaren Timer realisiert werden, der einen Interrupt auslöst nachdem ein Zählerwert heruntergezählt wurde.

Unendliche Pollingschleife mit Interrupt Schalterposition On Off Zeit main() { int FLAG; for (;;){ // Endlosschleife if (FLAG == TRUE){ // Ereignis erkannt counter = 0; while (counter < 3); // Warte FLAG = FALSE; ProcessEvent(); } Counter_ISR() // tickert alle 10 ms counter++; Pollingsystem verarbeitet ein Ereignis, das zufällig eintrifft. Jedoch erreicht max 1 Ereignis/s das System Ereignis prellt (Schalterprellen 20ms) Das Ereignis wird durch ein externes Gerät gesetzt, das ein Flag im Speicherbereich des Systems auf TRUE setzt genutzt wird ein 10ms fixed rate interrupt zur Synchronisation

Unendliche Pollingschleife mit Interrupts Beispiel Serial_ISR() { ReadCharFromPort(); PutCharIntoBuf(); if(CompleteLine){ SendBufToAppl(); GetNewBuf(); } digital_ISR() event = ReadDigitalInterface; time = ReadSystemClock; EnqueueEvent(event, time); main() { for (;;){ ServiceOperator(); UpdateTimeOnDisplay(); HandleQueuedEvents(); } ISR wird jedesmal aufgerufen, wenn ein Zeichen am Seriellen Port eintrifft ISR wird jedesmal aufgerufen, wenn eine Übertragung an einem der parallelen Schnittstellen festgestellt wurde

Unendliche Pollingschleife mit Interrupts Eine Hauptschleife bedient alle I/O-Anforderungen sequentiell, aber die Verarbeitung kritischer I/O wird nicht in der Schleife bedient Typische Herangehensweise, die verändert werden sollte. Z.B. häufig verwendet MS/DOS-basiertes System: Steuerschleife und mehrere Interruptserviceroutinen (TSR) häufig verwendet in Steuerungen, die Mikrocontroller nutzen Nutzung von MS/DOS-Betriebssystemfunktionen in einer ISR nicht möglich, wegen fehlender Wiedereintrittsfähigkeit

Unendliche Pollingschleife mit Interrupts Probleme Es treten die gleichen Probleme wie beim Endlos-Polling ohne Interrupts auf, wenn viele Ereignisse zu verarbeiten sind. Performanceanalyse schwierig. Muß Laufzeiten der ISR´s berücksichtigen und Häufigkeit des Auftretens der Ereignisse. Die Behandlung einiger Ereignisse kann sich unnötig verzögern. Funktionen der Hauptschleife werden in einer vorbestimmten Reihenfolge aufgerufen, die nicht übereinstimmt mit dem aktuellen Auftreten der Ereignisse

PLS Anwendung Einfach zu schreiben und zu debuggen Reaktionszeit einfach zu bestimmen (ohne Interrupts) Gut für die Behandlung von High-Speed Datenkanälen mit Arbeiten fehlerhaft, wenn das Eintreffen von Ereignissen im Burst nicht berücksichtigt wurde Nicht in komplexen und komplizierten Systemen Nutzen CPU-Zeit (aktives Warten) Insbesondere dann, wenn das Ereignis das abgefragt (gepollt) wird häufig auftritt.

Gliederung Polling in einer Endlosschleife (Polled Loop Systems) Phase/ State Driven Code Coroutine Interrupt Driven Systems Foreground / Background Systems RTOS

Phasen- und Zustandsgesteuerter Code Verwendet verschachtelte Statements Zustandsautomat (FSA) eine solche Unterteilung der Prozesse ermöglicht es, dass jeder Abschnitt vor dem Ende temporär suspendiert werden kann, ohne dabei kritische Daten zu verlieren Umsetzung des Multitasking mittels Coroutinen Es gibt einige Prozesse, die sehr gut mittels FSM implementiert werden können. FSA-Implementierung gut für Compilier-Prozess besteht aus mehreren Phasen: lexikalische Analyse, Parsing, Codegenerierung, Optimierung Kommunikationsprogramme, wie z.B. Netzwerkpakethandler sind meist unterteilt in mehrere Phasen If ... then case

Software Zustandsmaschine (FSM) Zustandsmaschinen speichern interne Zustände in einer Variablen. Zustandswechsel erfolgen, wenn Eingänge sich ändern. Verwendet in: control-dominated code; reactive systems.

Phasen- und Zustandsgesteuerter Code Beispiel: Einfacher Prozeß, der drei Zustände einnimmt. Am Ende jedes Prozesses wird der Zustand des Flags gesetzt Bei einem Neustart des Systems arbeitet das System an der Stelle weiter, an der es unterbrochen wurde Eine andere Möglichkeit eine FSM umzusetzen besteht in der Nutzung einer Tabelle main() { int flag =1; for (;;){ switch (flag){ case 1 : { PerformPart1();flag=2; break;} case 2 : { PerformPart2();flag=3; break;} case 3 : { PerformPart3();flag=1; break;} }

State machine specification in1=1/x=a A B r=0/out2=1 r=1/out1=0 in1=0/x=b C D s=0/out1=0 s=1/out1=1

Wie eine solche Struktur in C aussieht (C code structure) Aktueller Zustand wird in einer Variablen gespeichert Zustandstabelle als Switch implementiert Cases definieren die Zustände Zustände können Eingänge testen Switch wird in einer While-Schleife wiederholt

C state machine structure C state table while (TRUE) { switch (state) { case state1: ... } C state machine structure switch (state) { case A: if (in1==1) { x = a; state = B; } else { x = b; state = D; } break; case B: if (r==0) { out2 = 1; state = B; } else { out1 = 0; state = C; } case C: if (s==0) { out1 = 0; state = C; } else { out1 = 1; state = D; }

Phasen- und zustandsgesteuerter Code Zusammenfassung State-Driven Systems können in vielen Sprachen kodiert werden: Nutzung der IF-THEN bzw. CASE-Anweisungen. Für komplexe Systeme wird eine Umsetzung über Tabellen vorgezogen Können in Verbindung mit Polling-Schleife verwendet werden: Der erste Zustand testet Flags Der zweite Zustand verarbeitet die Daten, wenn das Flag gesetzt ist Nicht alle Applikationen sind geeignet, in mehrere Zustände aufgeteilt zu werden. Tabellen, die zur Implementierung dieser Technik erforderlich sind, können groß werden. Manuelle Translation von FSM  Tabelle fehlerbehaftet.

Gliederung Polling in einer Endlosschleife (Polled Loop Systems) Phase/ State Driven Code Coroutine Interrupt Driven Systems Foreground / Background Systems RTOS

Coroutine Die Coroutine ist eine Programmiertechnik, die in den Anfängen der Embedded Systeme häufig verwendet wurde, um Prozesse zu verarbeiten Wird heute kaum noch verwendet Ist jedoch ein gutes Beispiel, um Probleme aufzuzeigen, die sich ergeben, wenn versucht wird diverse komplexe Steuerungen zwischen mehreren Prozesse zu realisieren, ohne Prozesse zu verwenden Kombination mit phasen/zustandsgesteuertem Code

Coroutine: Eigenschaften Ähnlich wie Unterprogramm, jedoch bestimmt der aufrufende Programmabschnitt die Rücksprungadresse. Coroutinen geben die Steuerung freiwillig ab. Erfordert disziplinierte Programmierung

Zeitlicher Ablauf von zwei Coroutinen Wenn eine Routine die Steuerung übergeben möchte, dann lädt sie ihre Return- Adresse in ein entsprechende Register (ist vom Prozessortyp abhängig) und lädt den Befehlszähler mit dem Returnwert der anderen Co-Routine Vorsichtiges Verwenden von Registern, die evtl. von anderen Co-Routinen verwendet werden.

Steuerfluß von zwei Coroutinen ARM-Prozessor R15 ist Befehlszähler ADR r14,co2a co1a ADR r0, a LDR r1, [r0] ADD r1,#5 STR r1, [r0] ADR r13,c01b MOV r15,r14 co1b ADR r3, b LDR r4,[r3] BNE r4, #2 co1c . . co2a ADR r3, w LDR r4, [r3] STR r4, r0 ADR r13,c02b MOV r15,r13 co2b ADR r3, x LDR r4,[r3] BNE r5, y STR r4, r5 ADR r13,c02c co2c . . R14 enthält die Rücksprung- adresse der Coroutine2 R13 von Coroutine1 Coroutine 1 Coroutine 2

Zeitlicher Ablauf von zwei Coroutinen Es sind allgemeinere Steuerflüsse programmierbar, als nur mit Subroutinen. Minimale Vereinfachung des Softwareentwurfs, der Zeitforderungen erfüllen muß. Nicht geeignet, um komplexe Programme mit signifikanten Zeiteigenschaften zu konstruieren Kann auch ohne Zeitforderungen unangenehm zu programmieren sein. Schwer zu debuggen

Zyklische Exekutive Besteht nur aus einer Co-Routine

Coroutine mit Betriebssystemunterstützung: Kooperatives Multitasking Nach jeder Phase wird zentraler Dispatcher aufgerufen Dispatcher verwaltet die Befehlszähler für eine Liste von Prozessen, die entsprechend RR ausgeführt werden. Er wählt den nächsten Prozess aus, der ausgeführt werden soll. Kommunikation zwischen den Prozessen mittels globalen Variablen. Alle Daten, die zwischen den „Dispachtes“ benötigt werden, müssen in globalen Variablen gespeichert werden.

Kooperatives Multitasking Context-Switch von Tasks Wenn ein Multitasking-System sich entscheidet eine andere Task auszuführen, dann wird einfach der Kontext der aktuellen Task auf seinem Stack gesichert Der Kontext der neuen Task wird wiederhergestellt, indem die zuvor auf dem Stack gespeicherten Daten von dort geholt werden

Kooperatives Multitasking In einem kooperativen Multitaskingsystem gibt ein Prozeß die CPU freiwillig an einen anderen ab. Er ist kooperativ. Kann ähnlich wie in Unterprogrammen umgesetzt werden, enthält aber keinen Rücksprung Anstelle des Rücksprungs wird eine spezielle Kontextwechselfunktion aufgerufen. Ein Systemruf für Context-switch Ähnlich zur Coroutine: Hauptunterschied: hier wird ein Scheduler verwendet yield_CPU() cswitch

Zwei kooperative Multitaskingprozesse if (x>2) sub1(y); else sub2(y,z); proca(a,b,c) ProcData(r,s,t) if (val1==3) abc(val2); rst (val3); yield_CPU(); yield_CPU(); SaveState(current); p = ChooseProcess; LoadAndGO(p); Scheduler

Round-Robin Systeme Prozesse werden sequentiell, bis zu ihrem Ende ausgeführt RR mit fester Zeitscheibe (time slice) Systemuhr mit fester Rate Wenn Prozess Zeitscheibe überschreitet, wird er unterbrochen. Wenn er nicht beendet wurde muss sein Kontext gespeichert werden. Prozess wird am Ende der Warteschlange platziert.

Kooperatives Multitasking Zusammenfassung Andere Begriffe: non-preemptive, round-robin Windows 3.1, Windows 9x

Gliederung Polling in einer Endlosschleife (Polled Loop Systems) Phase/ State Driven Code Coroutine Interrupt Driven Systems Foreground / Background Systems RTOS

Interrupt gesteuerte Systeme Interrupt-driven MS/DOS, Mikrocontroller Das Hauptprogramm ist eine Endlosschleife

Contextwechsel Kontextwechsel hat maßgeblich Einfluss auf die Reaktionszeit Muss minimal sein Kontext eines Prozesses Inhalt der Register PC Inhalt der Coprozessorregister Memory page register Spezielle Variablen

Contextwechsel void main(void) { init(); /* Initialisierung des Systems, Laden d. Int.Handler*/ while (TRUE); } void int1(void) /* Inthandler 1 */ save(context); task1(); restore(context); void int2(void) /* Inthandler 2 */ task2(); RTS besteht aus einem einfachen Main-Programm und drei Interrupthandlern, die den Context auf dem Stack speichern void int3(void) /* Inthandler 3 */ { save(context); task3(); restore(context); }

Preemptives Multitasking Interrupts sind der ideale Mechanismus, um einen Kontextwechsel in einem preemptiven Multitasking-System umzusetzen. Timer-Driven preemption: Ein Timer generiert periodisch Interupts: Herzschlag eines Betriebssystems CPU TIMER

Preemptives Multitasking Ein Interrupt-gesteuerter (interrupt-driven) preemptiver Kontextwechsel erzeugt einen allgemeinen Programmfluß, der ähnlich dem Prozedur-gesteuerten (procedure-driven) kooperativen Taskwechsel ist Zur Implementierung können gleiche Techniken, wie beim kooperativen Multitasking eingesetzt werden. Unterschied liegt im auslösenden Ereignis des Kontextwechsels: freiwillige Abgabe der CPU bei kooperativem MT Timer-Interrupt beim preemptiven MT

Gliederung Polling in einer Endlosschleife (Polled Loop Systems) Phase/ State Driven Code Coroutine Interrupt Driven Systems Foreground / Background Systems RTOS

Foreground/Background- Systeme void main(void) { init(); while (TRUE); } void int1(void) /* Inthandler 1 */ save(context); task1(); restore(context); void int2(void) /* Inthandler 2 */ task2(); void int3(void) /* Inthandler 3 */ task3(); FG/BG-Systeme sind Erweiterungen zu reinem Interruptgesteuerten Systemen: PLS (s. main() ) = Dummy BG-Prozess ersetzen durch sinnvolle Prozessausführung FG/BG-Systeme sind die häufigste Lösung in embedded Systemen

FG/BG-Systeme sind die häufigste Lösung in embedded Systemen Enthalten einige interruptgesteuerte Prozesse oder Real-Time-Prozesse (FG) und einige nicht interruptgesteuerte Prozesse (BG) FG Tasks laufen als RR oder preemptive prioritätsbasierte Prozesse oder Kombinationen aus diesen. BG Tasks sind voll unterbrechbar durch FG-Prozesse =Task mit niedrigster Prio. Alle RT-Lösungen sind Spezialfälle der FG/BG-Systeme

Alle RT-Lösungen sind Spezialfälle der FG/BG-Systeme PLS = FG/BG ohne FG, Polling in BG Hinzufügen von Int.s zur Synchronisation vollständiges FG/BG-System Phasen gesteuerter Code = FG/BG ohne FG, PD in BG Coroutine = komplizierter BG-Prozess Nur interruptgesteuert = FG/BG System ohne BG

Background Processing F: Was sollte im Hintergrund ausgeführt werden? A: Alles was nicht zeitkritisch ist. BG-Prozess wird immer ausgeführt, außer das System ist überlastet. Überlast = Die Vordergrundprozesse lasten das System voll aus. Rate mit der BG ausgeführt wird, ist abhängig von Auslastung und kann sehr gering sein. Rechenzeit des BG-Prozesses 1 – Auslastung aller FG-Prozesse t= Beispiel1: 6 / 0,15 = 40 Beispiel2: 10 / 0,45 = 22,22

Background Processing F: Welche Prozesse sind nicht zeitkritisch und können im BG ausgeführt werden? Häufig: Zähler im BG inkrementieren. Zum Messen der Auslastung bzw. zum Detektieren, ob der FG sich aufgehängt hat. Z.B. für jeden FG-Prozess individuellen Zähler im BG-Prozess, die dekrementiert werden müssen durch FG. = Software-Watchdog

Berechnung der Periode des BG-Prozesses A: C=1, T=4, U=0,25 B: C=1, T=5, U=0,2 C: C=8, T=20, U=0,4 BG: C=6 A B C BG ... 2 4 6 8 10 12 14 16 18 20

Berechnung der Periode des BG-Prozesses A: C=1, T=4, U=0,25 B: C=1, T=5, U=0,2 BG: C=10 A B BG ... 2 4 6 8 10 12 14 16 18 20

Initialisierung Initialisierung ist erste Aufgabe des BG-Prozesses Disable Interrupts Setzen (des) der Interruptvektor(en) und Stack initialisieren Selbsttest ausführen Systeminitialisierung ausführen Enable Interrupts

Real-Time Operationen Werden i.A. im Vordergrund ausgeführt. Die real-time oder FG-Operationen sind die gleichen, wie in reinen Interrupt-Systemen. D.h. was im Vordergrund (FG) ausgeführt werden soll, ist identisch mit dem, was in Interruptsystemen ausgeführt wird.

Zusammenfassung FG/BG Beschriebene RT-Lösungen lassen sich in Modifikationen als FG/BG-Prozesse beschreiben. Häufig verwendet Entscheidender Nachteil: Interfaces zu komplizierten Geräten und Netzwerken müssen geschrieben werden. Am besten, wenn die Anzahl der FG-Prozesse apriori bekannt und fest. Anfällig gegenüber Zeitvariationen, Wettlaufbedingungen, Hardwarefehler... einige Firmen gestatten keine Designs, die Interruptgesteuert sind.

Entwurf von Echtzeitsystemen & Zyklische Exekutive (noch einmal)

Rate-Monotonic Systeme Rangmonoton (Rang=Priorität), Ratenmonoton (Rate=Periode) Liu/Layland 1973 Periodische Prozesse Periodische Prozesse erhalten entsprechend Ihrer Periode eine Priorität zugewiesen: Kleine Periode  große Priorität Wenn die Auslastung des Gesamtsystems bei einer ratenmonotonen Prioritätenzuweisung < 69 % ist, dann halten alle Prozesse ihre Deadlines ein. vorausgesetzt die Periode ist gleich der Deadline. Es gibt noch weitere Voraussetzungen (kommt später dran)

Die Entwicklung harter Echtzeit Drei Stufen der Entwicklung harter Echtzeit von der einfache zyklische Exekutive ... über major/minor zyklischen Scheduling ... zum pre-emptiven RTOS Scheduling dynamisches Scheduling (Forschungsgegenstand)

Einfache zyklische Exekutive void main (void) { init(); while (TRUE) { task_1(); task_2(); task_3(); task_4(); busy_wait_cycle(); } Interruptzeit Freie Zeit

ZE Einfach Aber nicht sehr effizient Worst-Case-Verhalten leicht zu bestimmen Leicht zu implementieren Aber nicht sehr effizient Worst Case Verhalten leicht abzuschätzen Sporadische Ereignisse können nur umständlich behandelt werden (Polling mit hoher Rate)

Major / Minor Cycle Häufige Terminologie, die in periodischen Systemen und in zyklischer Exekutive verwendet wird. In periodischen Systemen und in zyklischer Exekutive wiederholt sich die Ausführungsreihenfolge der Tasks nach einer bestimmten Periode. Diese Periode wird als Major Cycle (Hauptzyklus) bezeichnet. Falls sich innerhalb des Hauptzyklus kleinere Sequenzen wiederholen, werden diese als Minor Cycle (innerer Zyklus) bezeichnet.

ZE mit Minor und Major-Zyklus void main (void) { init(); while (TRUE) { task_1(); /**/ task_2(); /**/ busy_wait_minor(); task_1(); /**/ task_3(); /**/ task_4(); /**/ } Interruptzeit 1 2 3 Freie Zeit

ZE mit Minor und Major-Zyklus Einfach Worst-Case-Verhalten bleibt leicht bestimmbar Effizienter als einfache zyklische Exekutive Aber nicht sehr effizient Behandlung sporadische Ereignisse und Interrupts schwierig Zielt auf die Verwendung harmonische Frequenzen kompliziertes Arbeiten erfordert die Aufsplittung des Programm-Codes in Teilabschnitte

Pre-emptives Multitasking RTOS-Scheduling

Pre-emptives Multitasking RTOS-Scheduling Effiziente Verwendung der verfügbaren CPU-Zeit nicht nur harmonische Frequenzen schnelle und effiziente Behandlung sporadischer Ereignisse Leichte Entwicklung von Anwendungscode es ist nicht notwendig, den Code in Teilcodeabschnitte zu zerteilen und auch der Kommunikationsaufwand zwischen diesen Teilen mittels globaler Variablen

... aber Das wirkliche Echtzeitverhalten muß bestimmbar sein Der Overhead eines RTOS muß klein sein RTOS muß fehlerfrei sein Wenn ein RTOS Designfehler enthält, dann kann das Gesamtsystem nicht die Anforderungen an die Zuverlässigkeit erfüllen Systemverhalten zur Entwurfszeit untersuchen

Unterteilung in Tasks / Prozesse Multi-Tasking in einem Datenverarbeitungssystem Wait for I/O Event Event in DB eintragen Auf Kdo. warten DB DB durch- suchen Daten anzeigen AD-Wandler

Datenverarbeitungssystem ServiceOperator() { while(TRUE){ WaitForCmd(); SearchDatabase(); } HandleQueuedEvents() { while(TRUE){ WaitForEvent(); EnterEventInDatabase(); } Update TimeOnDisplay() { while(TRUE){ WaitOneSecond(); DisplayTime(); }

Was ist preemptives Scheduling Die Task mit der höchsten Priorität erhält die CPU Wenn eine höher priorisierte Task bereit wird, wird die aktuelle Task verdrängt (preempted) und die höher priorisierte Task erhält die Steuerung (CPU) Ein preemptiver Kern wird verwendet, wenn Reaktionszeit wichtig ist Wird in den meisten kommerziellen Betriebssystemen verwendet READY RUNNING ASLEEP

Vereinfachtes Prozeßmodell: Zustandsmodell eines Prozesses RUNNING READY ASLEEP

Multitasking

C=1, T=4, U=0,25 C=1, T=5, U=0,2 C=8, T=20, U=0,4 A B ... 2 4 6 8 10 12 14 16 18 20