Betriebssysteme Hard Real Time Systems

Größe: px
Ab Seite anzeigen:

Download "Betriebssysteme Hard Real Time Systems"

Transkript

1 Betriebssysteme Hard Real Time Systems Thomas Staub, Juni 2002 Zusammenfassung Im Hauptstudium Informatik an der Universität werden von den Studenten zusätzliche Efforts erwartet. In der Vorlesung Betriebssysteme von Professor Dr. Torsten Braun war eine Semesterarbeit zu einem in der Vorlesung angeschnittenen Thema verlangt. In meiner Arbeit werden Aspekte von harten Echtzeitbetriebssystemen besprochen. Im ersten Teil werden die Fragen, was ein Echtzeitsystem (Real-time system) ist, wie es sich mit harten und weichen (hard soft) Echtzeitsystemen verhält und was gewünschte Features eines solchen Systems wären, behandelt. Im folgenden Teil gehe ich detailierter auf die wichtigste Eigenschaft eines Real-Time Systems, die Vorhersagbarkeit, ein. Der dritte Teil ist Grundkonzepten und Scheduling Verfahren gewidmet. Als Ergänzung folgt eine Beschreibung von RT-linux als Beispiel eines auf einem Standard Betriebssystem basierenden Echtzeitbetriebssystem. Ich stütze mich hauptsächlich auf das Buch HARD REAL-TIME COMPUTING SYSTEMS, Predictable Scheduling, Algorithms and Applications von Giorgio C. Buttazzo [1] ab. 1

2 Inhaltsverzeichnis 1 Allgemeines Was versteht man unter einem Echtzeit-System (Real-Time System)? Harte und weiche Echtzeitsysteme (Hard & Soft Realtime Systems) Gewünschte Eigenschaften eines Echtzeit Betriebssystems Erreichen der Vorhersagbarkeit Direct Memory Access (DMA) Cache Interrupts Systemaufrufe Semaphoren Speicherverwaltung (Memory management) Programmiersprache Grundkonzepte Task Constraints Timing Constraints Precedence Constraints Resource Constraints Scheduling Problem Klassifikation von Scheduling Algorithmen Earliest Deadline First Rate Monotonic Scheduling (RMS) Garantiertes Scheduling RTLinux Allgemeines RT-Linux Aufbau Tasks Kommunikation zwischen RTTasks Kommunikation zwischen RT-Linux- und Linuxprozessen Zugriff auf Parameter von RTLinux unter dem Gastsystem Programmbeispiel RT Prozess Linux Prozess

3 1 Allgemeines 1.1 Was versteht man unter einem Echtzeit-System (Real-Time System)? Was versteht man unter einem Echtzeit-System? Intuitiv würde man sofort sagen, dass es sich um Systeme handelt, welche schnell reagieren müssen. Was bedeutet jedoch schnell? Wir können dies präziser fassen. Ein Echtzeit-System ist ein Computersystem, welches innerhalb von klaren Zeitvorgaben auf Ereignisse in seiner Umgebung reagieren muss. Das korrekte Verhalten eines Echtzeit-Systems hängt folglich nicht nur von der Korrektheit der berechneten Werte ab, sondern auch vom Zeitpunkt, an dem diese Resultate zur Verfügung stehen. Stellen wir uns einmal vor, wir haben eine Fertigungsstrasse für Autos. Ein Roboterarm montiert die Seitentüren und die Heckklappe an die Karrosserie. Es ist nicht nur die korrekte Durchführung des Montageablaufs wichtig. Der Roboter muss die Teile auch im richtigen Zeitpunkt und innerhalb eines maximalen Zeitraumes anbringen. Ist dies nicht der Fall, kann unter Umständen die Karrosserie noch nicht am richtigen Ort sein und der Roboter montiert die Türe ins Leere oder der Roboterarm kollidiert mit der Karrosserie oder mit anderen Montagearmen. Der Ablauf des Montierens wäre korrekt, der Roboter führt alle Schritte korrekt aus, jedoch zum falschen Zeitpunkt oder in einer längeren als der vorgesehenen Zeit. Das Resultat wäre ein Auto mit Totalschaden, bevor es jemals gefahren wäre. Hier ein paar Anwendungen, welche Echtzeitberechungen benötigen: Kontrolle von Kraftwerken Kontrolle von Fertigungsprozessen Flugkontrollsysteme Militärische Systeme Weltraummissionen Überwachungsaufgaben Telekommunikationssysteme 1.2 Harte und weiche Echtzeitsysteme (Hard & Soft Realtime Systems) Es gibt grundsätzlich zwei Arten von Echtzeit-Aufgaben: harte und weiche (hard & soft). Eine Real-time Aufgabe wird hart (hard real-time task) genannt, wenn das Verpassen der Zeitschranke (deadline) katastrophale Auswirkungen auf die kontrollierte Umgebung haben kann. Beispiele für harte Echtzeit Aufgaben: Auswertung von Sensordaten Flugkontrolle Monitoring bei Kernkraftwerken Entdecken von kritischen Situationen Eine Echtzeit Aufgabe wird als weich (soft real-time task) bezeichnet, falls das Erreichen der Deadline aus Leistungsgründen erwünscht ist, jedoch durch das Verpassen dieses Zeitlimit kein ernsthaften Schaden für das betroffene System entsteht und das korrekte Systemverhalten nicht gestört wird. Beispiel für solche Aufgaben sind: 3

4 Anzeigen von Meldungen am Bildschirm, zum Beispiel mittels Dialogfenstern Bewegung des Mauszeiger auf dem Bildschirm Kommmando-Interpreter in einer Konsole Behandlung der Eingaben durch das Keyboard Speichern von Report Daten Ein hartes Echtzeitbetriebssystem (hard real-time operation system) erlaubt die Behandlung von harten Echtzeit Aufgaben (hard real time tasks). In den meisten Fällen enthalten reale Anwendungen sowohl harte wie auch weiche Echtzeit Aufgaben, deshalb sollte ein hartes Real-time OS mit beiden Arten von Real-time Tasks umgehen können. Es sollte dabei 2 verschiedene Strategien verfolgen. Für die harten Task müssen die Zeitlimiten streng eingehalten werden, zudem sollte versucht werden die durchschnittliche Antwortzeit der soft Tasks zu minimieren. 1.3 Gewünschte Eigenschaften eines Echtzeit Betriebssystems Timeliness Die Resultate müssen nicht nur in ihrem Wert korrekt sein, sondern auch in der korrekten Zeit. Das Betriebssystem muss deshalb spezielle Kernel Mechanismen fürs Zeitsmanagement und für die Behandlung von Aktionen mit expliziten Zeitlimiten sowie verschiedenem kritischem Wert zur Verfügung stellen. Peak load Das System muss mit worst-case Szenarien umgehen können. Auch wenn alle möglichen ungünstigen Umstände eintreffen darf das Betriebssystem nicht abstürzen. Echtzeitsysteme sollten deshalb immer mit absolutem Pessismus entworfen werden. Es sollte immer Murphys [Captain Ed Murphy, Ingenieur US Air Force, 1949] Gesetz beachtet werden.[1] Murphys Gesetz Wenn etwas schiefgehen kann, dann wird es schiefgehen. Sodd s Zweites Gesetz Früher oder später wird die schlechtest mögliche Kombination von Umständen eintreffen. Vorhersagbarkeit Um das Leistungsminimum zu garantieren, muss das System alle Konsequenzen einer Scheduling Entscheidung vorhersehen können. Falls eine Aufgabe nicht innerhalb ihrer Zeitlimiten abgearbeitet werden kann, muss vom Betriebssystem dies erkannt werden, so dass alternative Aktionen geplannt werden können, um auf den Fehler zu reagieren. Wie man Vorhersehbarkeit erreicht, wird im nächsten Kapitel ausführlich behandelt. Fehlertoleranz Einfache Fehler in Hard- und Software sollten nicht zu einem Systemabsturz führen. Kritische Teile des Betriebssystems müssen deshalb fehlertolerant ausgelegt sein. Wartbarkeit Um eine gute Wartbarkeit sowie Erweiterbarkeit zu gewährleisten sollte das Realtime System modular aufgebaut sein. 4

5 2 Erreichen der Vorhersagbarkeit Eine der wichtigsten Eigenschaften, welche ein hartes Echtzeitbetriebssystem haben sollte ist Vorhersagbarkeit [4]. Das heisst das System sollte in der Lage sein, aufgrund der Kerneigenschaften und der Information, welche mit jedem Task verbunden ist, die Entwicklung der Tasks vorherzusagen und guarantieren können, dass alle kritischen Zeitbedingungen eingehalten werden können. Die Zuverlässigkeit dieser Garantie hängt von verschiedenen Faktoren ab. Beginnend mit archtektonischen Eigenschaften der Hardware führt dies über Mechanismen und Regeln des Betriebssystemskerns bis zur Programmiersprache, in welcher die Applikation entwickelt wurde.[1] Der Prozessor ist die erste Komponente, welche die Vorhersagbarkeit des Schedulings beeinflusst. Innere Eigenschaften des Prozessors wie Instruction prefetch, Caching, Pipelining und Direct Memory Access (DMA) sind Gründe für Nondetermismus. Alle diese Eigenschaften verbessern zwar die durchschnittliche Leistung des Prozessors, führen jedoch nicht deterministische Faktoren ein, welche eine genaue Analyse von Worst-Case-Situationen - was bei Echtzeitsystemen einer der wichtigsten Punkte ist - verhindern. Das Betriebssystem ist ein weiterer wichtiger Faktor. Die internen Eigenschaften wie Scheduling Algorithmen, Synchronisation Mechanismen, Typen von Semaphoren, Speichermanagement und Behandlung von Interrupts beeinflussen die Ausführung des Tasks. 2.1 Direct Memory Access (DMA) Direct Memory Access ist eine von vielen Peripheriegeräten benutzte Technik um Daten zwischen dem Gerät und dem Hauptspeicher zu transferieren. Das Ziel von DMA ist es die CPU (Central processing unit) von der Aufgabe der Kontrolle von Ein- und Ausgabe-Operationen (I/O) zu entlasten. Da hierbei die CPU und das DMA Device sich den gleichen Bus teilen, muss die CPU, bei Zugriff auf den Bus durch das DMA Gerät, abwarten bis der Zyklus beendet ist. Es existieren verschiedene Methoden: Cycle stealing ist die gebräuchlichste Methode. Hier stiehlt das DMA Gerät der CPU einen CPU Hauptspeicherzyklus (CPU memory cycle) um Daten zu transferieren. Während der Ausführung der DMA Operation laufen Ein-/Ausgabe-Operation und CPU Programmausführung parallel. Wenn immer CPU und DMA gleichzeitig einen Hauptspeicherzyklus brauchen, wird der Bus dem DMA Gerät zugewiesen und die CPU muss abwarten bis der Speicherzyklus des DMA Geräts beendet ist. Die Antwortzeit eines Prozesses kann nicht vorhergesagt werden, da bei der cycle stealing - Methode die Anzahl der Zyklen, welche die CPU während DMA Ausführung warten muss, nicht bekannt ist. Das Ganze verhält sich nicht deterministisch, somit ist es für Echtzeit- Situation wenig geeignet. Time-slice [3] ist eine Lösung für das Problem der Nichtdeterminiertheit bei cycle stealing. Bei dieser Methode wird jeder Memory cycle in zwei gleiche Teile gespalten: einer ist für die CPU reserviert, der andere für das DMA-Device (siehe Abbildung 1). Das jeweilige Gerät kann nur in der ihm zugeteilten Hälfte des Memory cycles auf den Bus zugreifen. Somit erhöhen häufige DMA Zugriffe die Antwortzeit von Prozessen nicht. Die CPU kann immer in den ihr zugeteilten Zeitschlitzen auf den Bus zugreifen. Natürlich ist die time-slice Methode deutlich teuerer als cycle stealing, aber das System kann mit grösserer Zuverlässigkeit vorhergesagt werden. Kosten für eine Operation sind in einem Echtzeitsystem deutlich weniger wichtig als die Vorhersagbarkeit und Worst-case Szenarien. 5

6 Memory time cycle reserviert für CPU reserviert für DMA Gerät Abbildung 1: Aufteilung eines Zeitschlitzes bei Time-slice Methode (DMA) 2.2 Cache Der Cache ist sehr schneller Speicher, der zwischen Prozessor und Hauptspeicher (RAM, random access memory) eingebaut wird, um die Prozessausführung zu beschleunigen. Er physisch nach der Memory Managment Unit (MMU) angordnet und von der Software aus nicht sichtbar. Sobald eine Addresse angefordert wird, überprüft die Hardware, ob sich die Information im Cache befindet. Falls ja, werden die Daten daraus gelesen, andernfalls wird auf den Hauptspeicher zugriffen und schliesslich der Inhalt des Caches angepasst. Diese Pufferungstechnik wird verwendet, da der grösste Teil der Speicherzugriffe auf die gleichen Adressen im Hauptspeicher erfolgt. Durch Caching lässt sich somit der Average-Case deutlich verbessern. In Echtzeitsystem wirkt sich dies jedoch negativ aus. Es fügt Nichtdeterminisums hinzu. Wenn sich in 80% der Fälle (hit ratio) die Daten im Cache befinden, erhöht dies zwar im Durchschnitt den Durchsatz, es lässt jedoch keine Aussage über den Worst-case zu. Die Konsequenz davon ist, dass man um präzise Worst-case Aussagen zu machen, Prozessoren ohne oder mit abgeschaltetem Cache verwendet. Eine andere Annäherung an das Cache Probleme wäre die Verwendung von multiplikativen Faktoren, welche von hit ratio abhängen. Eine genauere Schätzung des Verhaltens eines System erhält man durch Analyse des Prozess Codes und der Schätzung der Ausführung mithilfe von mathematischen Modellen von Caches.[1] 2.3 Interrupts Interrupts von Ein- und Ausgabegeräten stellen ein grosses Problem für die Vorhersagbarkeit eines Echtzeitsystems dar, weil sie, falls unsauber behandelt, zu unabhängigen Verzögerungen während der Ausführung führen. In fast allen Betriebssystemen führt die Ankunft eines Interrupt Signals zur Ausführung einer Service Routine (Treiber). Vorteil dieser Methode ist, dass alle Hardware spezifischen Details im Treiber gekapselt sind. In vielen Betriebssystemen haben Interrupts fixe Prioritäten, welche höher sind als jene von Prozessen. Grund ist, dass es sich vielfach um Ein-/Ausgabegeräte handelt, welche Echtzeitbedingungen haben. Im Zusammenhang mit einem Echtzeitsystem ist diese Annahme jedoch falsch, da durchaus ein Prozess dringender sein kann als ein Interrupt, das heisst, dass ein Prozess ausgeführt werden muss, damit er seine Zeitlimiten erreichen kann. Die durch die Interrupt Behandlung eingeführte Verzögerung bei der Ausführung eines Prozess lässt sich nicht vorhersagen. Im folgenden sind verschiedene Wege zur Lösung dieses Problems aufgezeigt. Alle externen Interrupts bis auf den Zeitgeber werden unterbunden. In diesem Fall müssen alle Peripheriegeräte durch die Applikationen direkt behandelt werden. Die Anwendungstasks haben direkten Registerzugriff auf den Schnittstellen. Der Datentransfer erfolgt durch Polling. Vorteile dieser Methode sind grosse Flexibilität beim Programmieren und Elimination der Verzögerungen. Somit können die Zeitkosten für einen Datentransfer präszis ausgewertet werden. Ein weiterer Vorteil ist, dass der Kernel beim Hinzufügen neuer Geräte oder bei Änderungen nicht abgeändert werden muss. Das Hauptproblem dieser Lösung liegt in der verminderten 6

7 Prozessor Effizienz bei E/A Operationen. Wie bei der vorhergehenden Lösung werden alle externen Interrupts exklusive dem Timer ausgeschaltet. Die Geräte werden jedoch jetzt nicht durch die Applikationen gehandhabt, sondern durch spezielle Kernel Routinen, welche periodisch aktiviert werden. Der Vorteil liegt in der Kapselung aller Hardware Details in Kernel Routinen, somit müssen sich die Anwendungen nicht darum kümmern. Das Hauptproblem liegt im Busy-Waiting der Kernel-E/A- Routinen, welche das System bei Ein-/Ausgaben bremsen. Zudem muss hier bei Änderungen der Peripherie-Geräten jeweils der Betriebssystemkern angepasst werden. Die externen Interrupts bleiben eingeschaltet. Es werden jedoch die Treiber soweit wie möglich verkleinert. Die einzige Aufgabe des Treibers besteht nun darin den richtigen Task zur Bearbeitung zu aktivieren. Einmal aufgerufen fällt der Task unter die Kontrolle des Betriebssystem, welches nun das Scheduling übernimmt. Somit wird Busy-Waiting bei E/A Operationen unterbunden, zudem werden die unabhängigen Verzögerungen bei Ausführung eines Tasks drastisch vermindert. 2.4 Systemaufrufe Die Vorhersagbarkeit eines Systems hängt in gewissem Mass auch von der Implementation der Kernel Primitiven ab. Um eine präzise Analyse des worst-case Falles zu erlauben, sollten Kernel Aufrufe eine fixe Ausführungsdauer haben. Weiter hilfreich ist, wenn alle Kernel Primitiven preemptiv sind. Nicht preemptiven können eine Verzögerung der Ausführung eines Prozesses zur Folge, da sie nicht unterbrochen werden können. 2.5 Semaphoren Typische in normalen Betriebssystemen verwendete Semaphore sind für Echtzeitumgebung nicht geeignet, da Prioritätsinversion auftreten kann. Ein Prozess mit höherer Priorität kann für unbestimmte Zeit durch einen Prozess mit niedriger Priotät aufgehalten werden. Dies ist in Real-time Systemen unbedingt zu vermeiden. Eine Lösung dieses Problems bieten spezielle Protokolle (zum Beispiel Basic Priority Inheritance, Priority Ceiling, Stack Resource Policy. Die Implementation solcher Protokolle zieht Anpassungen im Betriebssystemkern nach sich. Es werden nicht nur wait und signal Methoden gebraucht, sondern auch einige Datenstrukturen und Mechanismen zu Task Management. 2.6 Speicherverwaltung (Memory management) Wie bei anderen Betriebssystem Mechanismen sollten auch bei der Speicherverwaltung nicht deterministische Verzögerungen vermieden werden. Deshalb ist Demand paging nicht geeignet für Echtzeitanwendungen mit harten Zeitschranken, da es nichtvorhersehbare Verzögerungen bei Seitenfehlern (page faults) und Seitenersetzungen (page replacements) geben kann. Eine häufig angewandte Lösung ist die Einführung eines fixen Speicherverwaltungs-Schemas. Statische Aufteilung des Speichers ist effizient, solange die Anwendung gleiche Speichermengen braucht. Durch die Einführung von statischen Zuweisungsschemen für Resourcen und Speicher erhöhen zwar den Grad der Vorhersagbarkeit, vermindern jedoch drastisch die Flexibilität in dynamischen Umgebungen. 7

8 2.7 Programmiersprache Ein weiterer Faktor, welcher die Vorhersagbarkeit des Gesamtsystems beeinflusst, ist die verwendete Programmiersprache. Leider sind die meisten gebräuchlichen Programmiersprachen nicht zur Beschreibung des zeitlichen Verhaltens geeignet. Programmiersprachen, welche zur Entwicklung von Echtzeitssystemen verwendet werden unterliegen gewissen Einschränkungen: Keine dynamischen Datenstrukturen Keine Rekursion Jede Schleife muss eine maximale Anzahl von Iterationen aufweisen, d.h. keine unendlichen Schleifen oder Schleifen, welche sich eine unbestimmte Anzahl Iterationen ablaufen Als Beispiele für Echtzeit-Programmiersprachen sind Real-Time Euclid [5] und Real-Time Concurrent C [6] zu nennen. Währenddem Real-Time Euclid entworfen wurde um statische Systeme zu entwicklen, bei welchen die zeitlichen Garantien zur Kompilierzeit gemacht werden, orientiert sich Real-Time Concurrent C an dynamischen Systemen, bei welchen Tasks zur Laufzeit aktiviert werden können. Ein wichtiges Feature ist deshalb die Möglichkeit, zu jedem Statement eine Deadline hinzuzufügen: within deadline (d) statement-1 [else statement-2] Die Ausführung des Statement-1 beginnt zum Zeitpunkt t, falls nicht komplett ausgeführt bis zum Zeitpunkt (t+d), wird die Ausführung unterbrochen und Statement-2 ausgeführt.[1] Natürlich müssen alle Echtzeitkonstrukte einer Sprache durch das darunter liegende Betriebssystem unterstützt werden. 3 Grundkonzepte 3.1 Task Constraints Bei Real-Time Tasks können folgende drei Klassen von Bedingungen (Constraints) unterschieden werden: Zeitbedingungen (Timing Constraints) Ablaufsbedingungen (Precedence Constraints) Bedingung betreffend gemeinsamen Zugriff auf Ressourcen (Resource Constraints) Timing Constraints Echtzeitsysteme haben strikte Zeitbedingungen, welche eingehalten werden müssen um das gewünschte Verhalten zu erreichen. Die wichtigste solche Schranke nennen wir Deadline. Die Deadline representiert den Zeitpunkt vor dem ein Prozess komplett ausgeführt sein muss, so dass er keinen Schaden anrichten. Wie aus Kapitel 1.2 bereits beschrieben unterscheiden wir zwischen harten und weichen Echtzeitsystemen, je nachdem was das Verpassen der Deadline für Folgen hat. 8

9 X Prozess J C L<0 Rechzeitige Ausführung Prozess J a s f d X C Zuspäte Ausführung L>0 a s d f Abbildung 2: Typische Parameter eines Real-Time Tasks Wie in Abbildung 2 dargestellt kann man einen Echtzeit-Task J generell mit folgenden Parametern charakterisieren [1]: Ankunftszeit a: Zeitpunkt des Eintreffens des Tasks Berechnungszeit (Computation time) C: Vom Prozessor für die vollständige Ausführung des Tasks ohne Unterbrechung benötigte Zeit Deadline d: Zeit, bis zu welcher der Task komplett ausgeführt sein sollte, um Schaden am System zu vermeiden. Startzeit s: Beginn der Ausführung des Tasks Endzeit f: Task ist komplett ausgeführt Wert v: Relative Wichtigkeit des Tasks in Bezug zu den anderen Tasks Verspätung (Lateness) L: L = f - d beschreibt die Verspätung der Vollendung des Tasks in Bezug auf die Deadline. Wird ein Task rechtzeitig vollendet so ist seine Verspätung negativ. Tardiness: Zeit, welche ein Task nach seiner Deadline aktiv bleibt. Laxity X: X = d - a - C ist die maximale Zeit, welche ein Task verzögert werden kann, so dass er noch innerhalb seiner Deadline abgearbeitet werden kann. Eine weitere Zeitcharakteristik eines Real-Time Task betrifft die Regelmässigkeit seiner Aktivierung. Im Allgemeinen, können Task periodisch oder aperiodisch definiert sein. Periodische Tasks bestehen aus einer unendlichen Reihe von identischen Aktivitäten (Instances Jobs), welche regelmässig mit einer konstanten Rate aktiviert werden. Aperiodische Tasks bestehen auch aus einer unendlichen Reihe von identischen Jobs, aber die Aktivierungen sind nicht regelmässig. 9

10 3.1.2 Precedence Constraints In manchen Anwendungen spielt nicht nur der einzelne Task und seine rechtzeitige Abarbeitung eine Rolle, sondern auch die Reihenfolge wie die Tasks verarbeitet werden. Gewisse Tasks müssen vor der Verarbeitung von andern abgeschlossen sein. Einige Tasks erwarten Resultate eines anderen. Um alle solchen Abhängigkeiten darzustellen wird oft ein Azyklischer Graph wie in Abbildung 3 verwendet. Der Task A muss vor Task B und Task C ausgeführt werden. A ist hier jeweils direkter Vorgänger A B C E D Abbildung 3: Vorgängerabbhängigkeiten dargestellt als Azyklischer Graph von B respektive C (A B, A C ). A ist zudem Vorgänger von D und E (A D, A E). A ist jedoch nicht direkter Vorgänger von D (A D). Die Vorgängerbedingung gilt es in einem Scheduling zu beachten Resource Constraints Aus Sicht eines Prozess sind alle Software Strukturen, welche zum Fortlauf der Ausführung seinerselbst führen, Ressourcen.[1] Wenn eine Ressource einem Task fest zugeordnet ist, nennt sie private. Falls mehrere Tasks die selbe Ressource verwenden, heisst sie shared. Zur Gewährleistung der Datenintegrität erlauben viele Ressourcen keinen gleichzeitigen Zugriff durch mehrere Tasks. Sie erfordern gegenseitigen Ausschluss (mutual exclusion) unter den konkurierenden Tasks. Die Ressource heisst dann exclusive. Die Codezeilen, welche unter Mutual Exclusion ausgeführt werden, werden als kritische Sektionen bezeichnet. Um den sequentiellen Zugriff zu exklusiven Ressourcen zu gewährleisten, bieten die meisten Betriebssysteme Synchronisation-Mechanismen an. Wenn ein Tasks auf eine exklusive Ressource warten muss, dann nennt man ihn blockiert auf dieser Ressource. Die Abbildung 4 zeigt eine solche Situation. B A Normale Ausführung A ist blockiert auf Ressource R, da Ressource R von Task B belegt ist. t t Kritische Sektionen mit Zugriff auf Ressource R Abbildung 4: Blockiert auf exklusiver Ressource 10

11 3.2 Scheduling Problem Bei einem Scheduling Problem haben wir in der Regel 3 Mengen [1]: J = Menge von Tasks P = Menge der Prozessoren R = Menge von Ressourcen Weiter haben unter Umständen Precedence Constraints gegeben durch einen Azyklischen Graphen und für jeden Task Time Constraints. In diesem Zusammenhang bedeutet Scheduling, die Zuordnung von Prozessoren aus P und Ressourcen aus R zu Tasks aus J, so dass alle Task unter Einhaltung der gegebenen Constraints völlständig abgearbeitet werden können [7]. Dieses Problem gilt als NP vollständig [8] Klassifikation von Scheduling Algorithmen soft Realtime Scheduling offline preemptive hard dynamic online non preemptive preemptive static Abbildung 5: Unterteilung der Schedulingverfahren für harte Echtzeitsysteme non preemptive Aus der grossen Zahl von Scheduling Algorithmen erkennen wir folgende Klassen [1]: Preemptive. Bei preemptiven Algorithmen kann der laufende Task(Prozess) jederzeit unterbrochen werden, um den Prozessor einem anderen aktiven Task zuzuordnen. Dies erfolgt gemäss der durch den Algortihmus definierten Regeln. Non-preemptive. Hier wird der gestartete Task bis zur Vollendung ausgeführt. Die Scheduling Entscheidungen erfolgen hier jeweils sobald der Task beendet ist. Static. Scheduling Entscheidung basieren hier auf fixen Parametern, welche dem Task vor der Aktivierung zugewiesen werden. Dynamic. Entscheidungen basieren auf dynamischen Parametern, welche während der Ausführung ändern können. 11

12 Off-line. Algorithmen werden off-line genannt, falls sie auf alle Tasks vor der Ausführung angewendet werden. Scheduling erfolgt somit vor der eigentlichen Programmausführung zur Vermeidung von Scheduling-Overhead. Der vollständige Ausführungsplan liegt zur Laufzeit vorberechnet als Tabelle vor. On-line. Das Scheduling erfolgt jeweils zur Ausführungszeit, wenn ein neuer Task ankommt oder wenn der laufende Task beendet wird. Optimal. Der Algorithmus minimiert die Kosten. Falls keine Kostenfunktion definiert wurde, ist das einzige was zählt ein machbarer Schedule. Der Algorithmus heisst optimal, falls er nur keinen machbaren Schedule findet, wenn alle anderen Algorithmen dieser Klasse auch keinen finden. Heuristic. Ein Algorithmus wird heuristic genannt, falls er zu einem optimalen Schedule tendiert, aber diesen nicht garantieren kann Earliest Deadline First Das Hauptkriterium dieses dynamischen preemptiven Algorithmus ist die früheste Deadline. Ihr wird die höchste Priorität gegeben, womit der dazugehörende Task in seiner Ausführung vorgezogen wird. Es wird jeweils der Task mit der nächsten Deadline ausgeführt. Voraussetzungen für diesen Algorithmus sind: alle Tasks sind unabhängig voneinander maximale Ausführungszeit ist bekannt und konstant vernachlässigbarer Zeitaufwand für Switches zwischen Tasks Der Least-Laxity Algorithmus ist dem Earliest-deadline-first ähnlich. Hier wird statt der reinen Deadline die Laxity, d.h. die Differenz zwischen Ausführungszeit und Deadline verwendet. Beide Algorithmen eignen sich für Einprozessorsysteme, für Mehrprozessorsysteme müssten sie angepasst werden. Ein Echtzeitsystem ist unter Earliest Deadline First planbar, falls gilt [1]: m i=1 C i P i 1 m: Anzahl periodischer Ereignisse P i : Periodendauer des Ereignisses i C i : Erforderliche CPU Zeit fuer Ereignis i Earliest Deadline first kann die gesamte CPU Zeit verwenden, es kann jedoch vorkommen, dass die Deadlines nicht erreicht werden. Wir betrachten folgendes Beispiel [9]: Prozess Ankunftszeit Ausführungszeit Frist P P P

13 P 1 Deadline P 2 Ankunftszeit Deadline P 3 Ankunftszeit Deadline Ankunftszeit Abbildung 6: Beispiel eines Scheduling mit Earliest Deadline First Rate Monotonic Scheduling (RMS) Das Rate Monotonic Scheduling ist eine einfache Regel, welche die Prioritäten gemäss den Anfrage Rate vergibt. Aktivitäten mit hoher Anfrage Rate, das heisst mit kleiner Periode, erhalten hohe Priorität. Aktivitäten mit niedriger Frequenz bekommen niedrige Priorität. Somit werden hochfrequente Aktivitäten nur minimal verzögert. Periode P2 P2 Periode P1 P1 P1 P1 Abbildung 7: Beispiel zu Rate Monotonic Scheduling Zeit t Rate Monotonic ist optimal in der Gruppe der Algorithmen mit fixen Prioritäten, das heisst, dass es keinen Algorithmus mit fixen Prioritäten gibt, welcher eine Task Menge planen kann und RM nicht. Eine Echtzeitssystem ist unter RMS planbar, falls die gesamte Prozessorauslastung den Wert von ln2 (0.69) nicht übersteigt. In diesem Fall garantiert RMS die korrekte Ausführung der Task Menge. 13

14 3.2.4 Garantiertes Scheduling Es wird die vorgesehene CPU-Zeit für jedes Prozess berechnet. aktuelle Zeit Erzeugungszeitpunkt vorgesehene Zeit = Anzahl P rozesse Berechnung des Verhältnis für jeden Prozess: verbrauchte CP U Zeit vorgesehene Zeit Es wird nun immer der Prozess ausgeführt, der das niedrigster Verhältnis aufweist. Sobald ein anderer Prozess das niedrigste Verhältnis besitzt, ist dieser Prozess an der Reihe. Diverse weitere Scheduling Algorithmen sowie deren Analyse sind im Buch von Buttazo [1] zu finden. 4 RTLinux RTLinux wurde als Forschungprojekt am New Mexiko Institute of Technology in Socorro, New Mexiko entwickelt. Das Design und die Methodik stammen von Victor Yodaiken, die erste Implementation von Michael Barabanov. RTLinux wird jetzt von der Firma FSMLabs, Inc. weiterentwickelt. Die Haupt-Kernel-Entwickler sind Victor Yodaiken, Michael Barabanov und Cort Dougan. 4.1 Allgemeines Echtzeitbetriebssysteme sollten klein, schnell und vorhersagbar sein. Wegen grossen Vielfalt von Anforderungen an das Real-Time Scheduling, sollte das Task Scheduling flexible, wiederprogrammierbare Richtlinien besitzen. Zu diesen schon schwierig zu erreichenden Requirements kommen noch Benutzer Requirements wie gute Entwicklungstools, graphische Benutzeroberflächen und Netzwerkunterstützung. Um alle diese Requirements so einfach wie möglich zu erreichen, wure eine einfache Version der Virtual Machine Technologie verwendet. Es wurde ein Standard Betriebssystem genommen, welches viele gewünschte Eigenschaften besitzt, und dies wurde so modifiziert, dass es die Kontrolle über das System mit einem kleinen Echtzeitkernel teilt.[12] RT-Linux Aufbau Linux ist wie die meisten anderen Betriebssysteme entworfen, um die durchschnittliche Leistung des Systems zu erhöhen und somit nicht für die Erfüllung von harten Echtzeitbedingungen geeignet. Neuere Versionen von Linux unterstützen zwar den POSIX.1b-1993 Standard für Echtzeitprozesse. Dies bietet zwar Möglichkeiten zum Blockieren von User Pages im Speicher und zum Ändern der Scheduling Richtlinien zu einer Prioritäten basierten, dies reicht jedoch nicht aus um harte Echtzeitbedingungen zu erfüllen, es können nur weiche Echtzeibedingungen erreicht werden. Hauptprobleme liegen in den folgenden Punkten: Linux Prozesse sind heavyweight Prozesse und haben deshalb einen grossen Overhead bei Prozesswechsel Linux hat nicht-preemptive Kern Prozesse. Ein Kern Prozess kann somit nicht unterbrochen werden. Falls zum Beispiel fork aufgerufen wird, wird dieses komplett ausgeführt, bevor ein anderer Prozess abläuft. Dies ist für harte Echtzeitprobleme nicht geeignet, da ein wichtiger Echtzeit-Prozess unter Umständen warten müsste bis die Kernprozesse ausgeführt sind. 14

15 Linux unterbindet in kritischen Bereichen des Kernels die Interrupte, dafür verwendet es häufig die cli-methode (Clear Interrupt) in diesen Bereichen. Linux wird als Task mit niedrigster Priorität ausgeführt Real Time Tasks User Process Gerätetreiber Systembibliotheken Linux Kernel Direkter Hardware Zugriff Real Time Scheduler I/O I/O RT Linux Software Interrupts Hardware Interrupts Hardware Abbildung 8: Architektur des Echtzeitsystems mit RTLinux- und Linux-Kernel Den kompletten Linux Kernel preemptiv und damit echtzeitfähig zu machen, würde deshalb zu grosse Anstrenungen benötigen und wahrscheinlich mit einem komplett neuen Kernel enden. Somit wäre man völlig von den Entwicklungen bei Standard Linux Kernel abgeschnitten. Aus diesen Gründen agiert Linux nur als Gastsystem [10]. Linux wird ein kleines, einfaches Real-Time OS untergeschoben. Dadurch wird Linux zu einem Task, welcher nur dann läuft, falls kein Real-Time Task läuft, und zudem immer unterbrochen (pre-emptive) wird, falls ein Real-Time Task den Prozessor benötigt. Es läuft als Task mit niedrigster Priorität unter RTLinux. Abbildung 8 zeigt die Anordnung der 2 Kernel im System. RTLinux besteht aus folgenden Modulen [13]: RTLinux Kern Modul Scheduling Modul Kommunikations-Modul Modul mit Synchronisations- und Interprozess-Kommunikations-Primitiven Modul, durch welches ausgewählte Parameter des Echtzeitsbetriebssystems aus dem Gastsystem heraus verändert werden können. Auf der Abbildung 9 lässt erkennen, dass Linux durch RTLinux kontrolliert wird. Beide Kerne werden in der jeweils nächsten Schale durch Module erweitert. Es existieren 2 Arten von dynamisch ladbaren Modulen. Die Kern Module des Gastbetriebssystems Linux und die RTLinux Module. Die Linux Module interagieren im Gegensatz zu den RTLinux Modulen nicht mit dem RTLinux Kern. In 15

16 Abbildung 9: Aufbau von RTLinux als Schalenmodell [13] der äussersten Schale befinden sich die Userprozesse, durch sie werden die nicht zeitkritischen Komponenten des Gesamtsystems realisiert. [13] Änderungen am Linux Kernel finden sich vor allem an 3 Stellen im Bereich des Interupt- Handlings.[12] Die cli Methode, welche Interrupts deaktiviert wurde so modifiziert, dass sie eine Globale Variable (Soft interrupt enable) zurücksetzt. Die sti Methode, welche Interrupts aktiviert, generiert nun emulierte Interrupts für alle Soft Interupts. Low-Level Wrapper Routinen, welche Zustände bei Aufrufen speichern und wiederherstellen, wurden so abgeändert, dass sie nun soft return from interrupt an Stelle von Maschineninstruktionen verwenden. Sobald jetzt ein Interrupt auftritt, geht die Kontrolle an einen Real-Time Handler. Der Handler führt die nötigen Schritte in Bereich des Echtzeitsystems aus und übergibt gegebenenfalls den Interrupt weiter an Linux Tasks Der RTKern von RTLinux unterstützt zwei Typen von Tasks [13]: sporadische Tasks. Sie werden durch externe Interrupts ausgelöst und entsprechen den herkömmlichen Interruptroutinen. Sie besitzen alle die selbe Priorität. Da die Behandlung der Interrupts innerhalb von Linux unverändert bleiben, müssen vorhandene Treiber im Gastsystem Linux nicht angepasst weren. Dies wird durch eine Emulation der Interruptvektor-Tabelle von Linux erreicht. Tritt ein Interrupt auf, wird geprüft ob er durch einen sporadischen Task bearbeitet werden kann. Wenn ja wird der Interrupt als ausstehend markiert und die Interrupt- Verarbeitung von Linux ausgelöst. Zyklische Tasks. Sie werden periodisch ausgeführt und haben eine zugeordnete Priorität. Sie werden mit dem Scheduling-Fifo Algorithmus ausgeführt. Ein solcher Task wird durch einen 16

17 Zeitgeber Interrupt ausgelöst. Das Gastbetriebssystem Linux wird als zyklischer Task mit niedrigster Priorität abgearbeitet. Attribute dieser periodischen Tasks sind: Priorität Startzeit Periode Stackgrösse Funktion, welche durch den Task ausgeführt wird Kommunikation zwischen RTTasks Für die Kommunikation zwischen RTTasks und die Synchronisation der RTTasks steht ein RTLinux Kernelmodul zur Verfügung Kommunikation zwischen RT-Linux- und Linuxprozessen Um zwischen RTLinux- und Linux-Prozessen zu kommunizieren, werden RT-Fifos verwendet. Für einen Linuxprozess wird ein RT-Fifo durch ein Character Device, zum Beispiel /dev/rtf0, erpräsentiert. Der Linux Prozess kann synchron und asynchron in die Fifo schreiben sowie synchron, asynchron und zeitgesteuert aus der Fifo lesen. RTLinux hingegen greift nur asynchron auf die Fifo zu, da zeitkritische Aufgaben nicht durch die Kommunikation mit dem Gastsystem blockiert werden darf. Prozess Data read write open close select Linux RTFifo rtf_create rtf_destroy rtf_resize rtf_create_handler rtf_put rtf_get RTLinux Data Data RTTask Handler Data Data Message Abbildung 10: Kommunikation zwischen RTLinux- und Linuxprozessen Wird durch einen Linuxprozess etwas in die RTFifo geschrieben, so wird auf RTLinux Seite ein Handler, welcher der RTFifo zugeordnet wurde, abgearbeitet, die nun im Handler gelesen werden. Es findet eine ereignisorientierte Benachrichtung über das Vorhandensein von neuen Daten statt, dass heisst es wird eine Message an den RTTask gesendet. Für den Linuxprozess stehen die Befehle read, write, open, close, select auf das Character Device /dev/rtfnummer der FIFO zur verfüdung. Auf der Seite von RTLinux gibt es die Befehle rtf create, rtf destroy, rtf resize, rtf create handler, rtf put, rtf get.[13] 4.2 Zugriff auf Parameter von RTLinux unter dem Gastsystem RTLinux ist ein eigenständiges System, deshalb können Parameter und Zustände nicht einfach im Benutzeradressraum angezeigt und verändert werden. Zur Verädnerung der Parameter wurde in RTLinux eine auf dem Proc-Dateisystem basierende Schnittstelle implemeniert. Somit können die Parameter aus Gastsystem Linux heraus über /proc/sys/rt linux... verändert werden. 17

18 4.3 Programmbeispiel Ein kleines Programmierbeispiel soll nun die Philosophie hinter RT-Linux erklären [10]. Echtzeitprogramme werden wie folgt aufgespalten: Kleine und einfache Teile mit harten Echtzeitbedingungen (RT Prozesse) Grössere Teile für die restlichen Berechnungen, jedoch ohne harte Echtezeitbedingungen (Linux Prozesse) RT Prozess #define MODULE #include <linux/module.h> /* always needed for real-time tasks */ #include <linux/rt_sched.h> #include <linux/rt_fifo.h> RT_TASK mytask; /* this is the main program */ void mainloop(int fifodesc) { int data; /* in this loop we obtain data from the device and put it */ /* into the FIFO number 1 */ while (1) { data = get_data(); rt_fifo_put(fifodesc, (char *) &data, sizeof(data)); /* give up the CPU till the next period */ rt_task_wait(); } } /* This function is needed in any module. It will be invoked when */ /* the module is loaded. */ int init_module(void) { #define RTFIFODESC 1 RTIME now = rt_get_time(); /* get the current time */ /* rt_task_init associates a function with the */ /* RT_TASK structure */ /* and sets several execution parameters: */ /* priority level = 4, stack size = 3000 bytes */ /* pass 1 to mainloop as an argument */ rt_task_init(&mytask, mainloop, RTFIFODESC, 3000, 4); /* Mark mytask as periodic. */ /* It could be interrupt-driven as well */ 18

19 /* mytask will have period of time units */ /* the first run is in 1000 time units from now */ } rt_task_make_periodic(&mytask, now , 25000); return 0; /* cleanup routine. It is invoked when the module is unloaded. */ void cleanup_module(void) { /* kill the real-time task */ rt_task_delete(&mytask); } Linux Prozess Wir schreiben jetzt noch ein Programm, welches als normaler Linux Prozess läuft. Es liest die Daten aus dem FIFO und schreibt sie auf stdout. #include <rt_fifo.h> #include <stdio.h> #define RTFIFODESC 1 #define BUFSIZE 10 int buf[bufsize]; int main() { int i; int n; /* create FIFO number 1 with size of 1000 bytes */ rt_fifo_create(1, 1000); for (n=0; n < 100; n++) { } /* read the data from the FIFO and print it */ rt_fifo_read(1, (char *) buf, BUFSIZE * sizeof(int)); for ( i = 0; i < BUFSIZE; i++) { printf( %d, buf[i]); } printf( \n ); } /* destroy FIFO number 1 */ rt_fifo_destroy(1); return 0; 19

20 Literatur [1] Giorgio C. Buttazzo, Hard real-time computing systems: predictable scheduling algorithms and applications, Kluwer Academic Publishers, 4. Printing 2002, ISBN [2] Silberschatz, Galvin, Gagne, Operating systems concepts, John Wiley & Sons, Inc., sixth edition, ISBN [3] J. Stankovic and K. Ramamritham, editors. Tutorial on Hard Real-Time Systems. IEEE Computer Society Press, [4] J. Stankovic and K. Ramamritham. What is predictability for real-time systems? Journal of Real-Time Systems, 2, [5] E.Kligerman and A. Stoyenko. Real-time euclid: A language for reliable real-time systems. IEEE Transactions on Software Engineering, 12(9), September [6] N. Gehani and K. Ramamritham. Real-time concurrent c: A language for programming dynamic real-time systems. Journal of Real-Time Systems, 3, [7] J.Blazewicz et al. Scheduling in Computer and Manufacturing Systems. Springer Verlag, [8] M.R. Garey and D.S. Johnson. Computers and Interactability: A Guide to the Theory of NP- Completeness, W.H. Freeman and Company, [9] T.Braun, Skript der Vorlesung Betriebssysteme, Universität Bern, [10] Michael Barabanov and Victor Yodaiken, Real-Time Linux, March (white paper), 2002). [11] Michael Barabanov, A Linux-based Real-Time Operating System, June , New Mexiko Institute of Mining and Technology, papers/ (Juni 2002). [12] Michael Barabanov and Victor Yodaiken, A Real-Time Linux, developers/white_papers/ (Juni 2002). [13] Patrick Bangerter, Semester- und Diplomarbeit 2000, Inverses Pendel, HTA Biel Maschinenbau. 20

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

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

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

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

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

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

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

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 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

Sebastian Witte 06.03.2013

Sebastian Witte 06.03.2013 06.03.2013 Inhalt kleine, leistungsfähige Systeme verfügbar (Smartphones) Resourcenverschwendung übermäßige Resourcenreservierung kleinste Systeme noch zu schnell zu restriktives Scheduling Vermischung

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

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

Klausur zur Vorlesung Grundlagen der Betriebssysteme WS 2011 / 2012

Klausur zur Vorlesung Grundlagen der Betriebssysteme WS 2011 / 2012 Name: Matrikelnummer: Studiengang: INF CV IM Lehramt BSc MSc BEd MEd Diplom Klausur zur Vorlesung Grundlagen der Betriebssysteme WS 0 / 0 Montag, den. Februar 0, 09: Uhr 0: Uhr Prof. Dr. D. Zöbel, Dipl.

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

Einführung in die technische Informatik

Einführung in die technische Informatik Einführung in die technische Informatik Christopher Kruegel chris@auto.tuwien.ac.at http://www.auto.tuwien.ac.at/~chris Betriebssysteme Aufgaben Management von Ressourcen Präsentation einer einheitlichen

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

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

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

Interrupts. Funktionsprinzip. Funktionsprinzip. Beispiel in C

Interrupts. Funktionsprinzip. Funktionsprinzip. Beispiel in C Interrupts Funktionsprinzip Interrupts bei ATmega128 Beispiel in C Funktionsprinzip 1 Was ist ein Interrupt? C muss auf Ereignisse reagieren können, z.b.: - jemand drückt eine Taste - USART hat Daten empfangen

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

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

Dipl.-Inf. J. Richling Wintersemester 2003/2004. Weiche Echtzeit

Dipl.-Inf. J. Richling Wintersemester 2003/2004. Weiche Echtzeit Dipl.-Inf. J. Richling Wintersemester 2003/2004 Weiche Echtzeit Wiederholung - Resultat/Wert-Funktion "harte" Echtzeit Wert Zeit Wert Zeit Wert Deadline Zeit "weiche" Echtzeit Wert Deadline Zeit Deadline

Mehr

Virtueller Speicher. SS 2012 Grundlagen der Rechnerarchitektur Speicher 44

Virtueller Speicher. SS 2012 Grundlagen der Rechnerarchitektur Speicher 44 Virtueller Speicher SS 2012 Grundlagen der Rechnerarchitektur Speicher 44 Die Idee Virtuelle Adressen Prozess 1 Speicherblock 0 Speicherblock 1 Speicherblock 2 Speicherblock 3 Speicherblock 4 Speicherblock

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

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

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Jörg Rödel Virtualization - Whats out there? Virtualisierung hat bereits längere Geschichte auf x86 Startete mit VMware Setzte

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

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

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

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

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

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

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

RealTime Linux. Paul Seidel Seminar Prozessteuerung und Robotik WS 08/09 Lehrstuhl BS und Middleware Prof. Polze Hasso-Plattner-Institut Potsdam

RealTime Linux. Paul Seidel Seminar Prozessteuerung und Robotik WS 08/09 Lehrstuhl BS und Middleware Prof. Polze Hasso-Plattner-Institut Potsdam RealTime Linux Paul Seidel Seminar Prozessteuerung und Robotik WS 08/09 Lehrstuhl BS und Middleware Prof. Polze Hasso-Plattner-Institut Potsdam Übersicht 2 Standard-Kernel Dual-Kernel RTAI/LXRT In-Kernel

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

Design and Implementation of a Soft-error Resilient OSEK Real-time Operating System

Design and Implementation of a Soft-error Resilient OSEK Real-time Operating System Design and Implementation of a Soft-error Resilient OSEK Real-time Operating System Florian Lukas Lehrstuhl für Informatik 4 Verteilte Systeme und Betriebssysteme Friedrich Alexander Universität Erlangen

Mehr

Übung zu Grundlagen der Betriebssysteme. 13. Übung 22.01.2012

Übung zu Grundlagen der Betriebssysteme. 13. Übung 22.01.2012 Übung zu Grundlagen der Betriebssysteme 13. Übung 22.01.2012 Aufgabe 1 Fragmentierung Erläutern Sie den Unterschied zwischen interner und externer Fragmentierung! Als interne Fragmentierung oder Verschnitt

Mehr

Moderne Betriebssysteme. Kapitel 8. Kapitel 8. Folie: 1. Multiprozessorsysteme. Autor: Andrew S. Tanenbaum

Moderne Betriebssysteme. Kapitel 8. Kapitel 8. Folie: 1. Multiprozessorsysteme. Autor: Andrew S. Tanenbaum Moderne Betriebssysteme Kapitel 8 Multiprozessorsysteme Kapitel 8 Folie: 1 Multiprozessorsysteme Autor: Andrew S. Tanenbaum Pearson Studium 2009 2 3 4 5 6 7 Betriebssystemarten für Multiprozessoren Jede

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

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

OSEK Deadline-Analyse

OSEK Deadline-Analyse OSEK Deadline-Analyse GmbH Erlangen Jürgen Scherg 8. Juni 2001 Ein Programmtest muß unter verschiedenen Gesichtspunkten durchgeführt werden. verschiedene Testmethoden sind notwendig. Blackbox : Es wird

Mehr

Vortrag zum Seminar Konzepte und Techniken virtueller Maschinen und Emulatoren. Bruno Kleinert fuddl@gmx.de. 20. Juni 2007

Vortrag zum Seminar Konzepte und Techniken virtueller Maschinen und Emulatoren. Bruno Kleinert fuddl@gmx.de. 20. Juni 2007 User Mode Linux (UML) Vortrag zum Seminar Konzepte und Techniken virtueller Maschinen und Emulatoren Friedrich-Alexander-Universität Erlangen-Nürnberg Bruno Kleinert fuddl@gmx.de 20. Juni 2007 Überblick

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

Inhaltsverzeichnis. 1.1 Der Begriff des Betriebssystems 1.2 Zur Geschichte der Betriebssysteme 1.3 Aufbau eines Rechners

Inhaltsverzeichnis. 1.1 Der Begriff des Betriebssystems 1.2 Zur Geschichte der Betriebssysteme 1.3 Aufbau eines Rechners Inhaltsverzeichnis Systemprogrammierung - Kapitel 1 Einführung 1/19 1.1 Der Begriff des Betriebssystems 1.2 Zur Geschichte der Betriebssysteme 1.3 Aufbau eines Rechners E/A-Operationen, Speicherstrukturen

Mehr

Prozessor (CPU, Central Processing Unit)

Prozessor (CPU, Central Processing Unit) G Verklemmungen G Verklemmungen Einordnung: Prozessor (CPU, Central Processing Unit) Hauptspeicher (Memory) Ein-, Ausgabegeräte/ Periphere Geräte (I/O Devices) externe Schnittstellen (Interfaces) Hintergrundspeicher

Mehr

Protected User-Level DMA in SCI Shared Memory Umgebungen

Protected User-Level DMA in SCI Shared Memory Umgebungen Protected User-Level DMA in SCI Shared Memory Umgebungen Mario Trams University of Technology Chemnitz, Chair of Computer Architecture 6. Halle Chemnitz Seminar zu Parallelverarbeitung und Programmiersprachen

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

Embedded-Linux-Seminare. Linux als Betriebssystem

Embedded-Linux-Seminare. Linux als Betriebssystem Embedded-Linux-Seminare Linux als Betriebssystem http://www.embedded-linux-seminare.de Diplom-Physiker Peter Börner Spandauer Weg 4 37085 Göttingen Tel.: 0551-7703465 Mail: info@embedded-linux-seminare.de

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

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

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

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

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

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

Softwarelösungen: Versuch 4

Softwarelösungen: Versuch 4 Softwarelösungen: Versuch 4 Nichtstun in Schleife wird ersetzt durch zeitweilige Zurücknahme der Anforderung, um es anderen Prozessen zu erlauben, die Ressource zu belegen: /* Prozess 0 */ wiederhole flag[0]

Mehr

Raytracing auf Desktop PCs Optimizing Cache Usage (Intel Corp.)

Raytracing auf Desktop PCs Optimizing Cache Usage (Intel Corp.) Raytracing auf Desktop PCs Optimizing Cache Usage (Intel Corp.) von Martin Stöcker Motivation Geschwindigkeit der Prozessoren verdoppelt sich alle 18 Monate (Moore s Law) Geschwindigkeit des Speichers

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

Grundlagen der Rechnerarchitektur. Ein und Ausgabe

Grundlagen der Rechnerarchitektur. Ein und Ausgabe Grundlagen der Rechnerarchitektur Ein und Ausgabe Übersicht Grundbegriffe Hard Disks und Flash RAM Zugriff auf IO Geräte RAID Systeme SS 2012 Grundlagen der Rechnerarchitektur Ein und Ausgabe 2 Grundbegriffe

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

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

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

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

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

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

Embedded Linux. Embedded Linux. Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de. Seminar "Eingebettete drahtlose Systeme"

Embedded Linux. Embedded Linux. Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de. Seminar Eingebettete drahtlose Systeme Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de Embedded Linux 30.01.2009 Daniel Buchheim Inhalt: Was ist Embedded Linux? Hardwareunterstützung in Eingebetteten Systemen Open Source Aspekte Aufbau

Mehr

Funktionskapselung in Steuergeräten

Funktionskapselung in Steuergeräten Funktionskapselung in Steuergeräten Mobilität und Echtzeit Boppard am Rhein, 07.12.2007 Stand: 07.12.2007 1 Funktionskapselung in Steuergeräten Inhalt Ausgangssituation und Motivation Begriff "Kapselung"

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Von der Platte zur Anwendung (Platte, Treiber, Dateisystem)

Von der Platte zur Anwendung (Platte, Treiber, Dateisystem) (Platte, Treiber, Dateisystem) 1. Einleitung 2. Dateisysteme 2.1. Logisches Dateisystem 2.2. Dateiorganisationsmodul 2.3. Basis Dateisystem 3. Festplattentreiber 3.1. Funktionsweise 3.2. Scheduling Verfahren

Mehr

Echtzeit mit Linux. Erweiterungen und deren Anwendung. Martin Krohn. 2. Februar 2006

Echtzeit mit Linux. Erweiterungen und deren Anwendung. Martin Krohn. 2. Februar 2006 Erweiterungen und deren Anwendung 2. Februar 2006 1 Einleitung Anwendungsgebiete 2 Linux als Echtzeitbetriebssystem Eignung von Linux 3 Erweiterungen für Linux RT-Linux RTAI- Real-Time Application Interface

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

Einfluss der Treatment Sets auf Ladezeiten und Datenvolumen am Beispiel von SharePoint Server 2010

Einfluss der Treatment Sets auf Ladezeiten und Datenvolumen am Beispiel von SharePoint Server 2010 : Einfluss der Treatment Sets auf Ladezeiten und Datenvolumen am Beispiel von SharePoint Server 2010 von Thomas Stensitzki, Senior Consultant icomcept GmbH Management Summary Der Aufbau von Webseiten kann

Mehr

Einführung in die C-Programmierung

Einführung in die C-Programmierung Einführung in die C-Programmierung Warum C? Sehr stark verbreitet (Praxisnähe) Höhere Programmiersprache Objektorientierte Erweiterung: C++ Aber auch hardwarenahe Programmierung möglich (z.b. Mikrokontroller).

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

Konzepte von Betriebssystem Komponenten. Aufbau eines Modernen Betriebssystems (Windows NT 5.0)

Konzepte von Betriebssystem Komponenten. Aufbau eines Modernen Betriebssystems (Windows NT 5.0) Konzepte von Betriebssystem Komponenten Aufbau eines rnen Betriebssystems (Windows NT 5.0) Moritz Mühlenthaler 14.6.2004 1.Das Designproblem a) Überblick b) Design Goals c) Möglichkeiten der Strukturierung

Mehr

One of the few resources increasing faster than the speed of computer hardware is the amount of data to be processed. Bin Hu

One of the few resources increasing faster than the speed of computer hardware is the amount of data to be processed. Bin Hu Bin Hu Algorithmen und Datenstrukturen 2 Arbeitsbereich fr Algorithmen und Datenstrukturen Institut fr Computergraphik und Algorithmen Technische Universität Wien One of the few resources increasing faster

Mehr

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis...

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis... 1 Einführung................................................ 1 1.1 Was ist ein Betriebssystem?............................... 1 1.1.1 Betriebssystemkern................................ 2 1.1.2 Systemmodule....................................

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

Ergänzungen zum Manual OS V 2.05/2.06

Ergänzungen zum Manual OS V 2.05/2.06 Ergänzungen zum Manual OS V 2.05/2.06 SYSTEMRESOURCEN - PROGRAMM DOWNLOAD - Ab der Betriebssystemversion 2.05 haben die C-Control Units M-2.0 und Station 2.0 die Möglichkeit das Anwenderprogramm von einem

Mehr

Für die Software-Entwicklung von

Für die Software-Entwicklung von Betriebssysteme Embedded Design Für die Software-Entwicklung von Embedded- und Echtzeit-Systemen stehen unterschiedliche Arten von Task-Schedulern zur Auswahl. Sie reichen von einfacher, periodischer Ausführung

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

Embedded- und RT-Betriebssysteme. Dipl.-Inf. J. Richling Wintersemester 2003/2004

Embedded- und RT-Betriebssysteme. Dipl.-Inf. J. Richling Wintersemester 2003/2004 Embedded- und RT-Betriebssysteme Dipl.-Inf. J. Richling Wintersemester 2003/2004 Überblick Fünfeinhalb Vorlesungen: Embedded- und RT-Betriebssysteme (heute) Beispiel: Windows CE (22.1.04) Beispiel: Windows

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

Die L4-Mikrokern. Mikrokern-Familie. Hauptseminar Ansätze für Betriebssysteme der Zukunft. Michael Steil. Michael Steil 18.04.2002

Die L4-Mikrokern. Mikrokern-Familie. Hauptseminar Ansätze für Betriebssysteme der Zukunft. Michael Steil. Michael Steil 18.04.2002 Die L4-Mikrokern Mikrokern-Familie Hauptseminar Ansätze für Betriebssysteme der Zukunft 18.04.2002 Folie 1 Aufbau des Vortrags 1. Mikrokerne: Idee und Geschichte 2. L4: ein schneller Mikrokern 3. L4Linux:

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

Programmiertechnik II

Programmiertechnik II Analyse von Algorithmen Algorithmenentwurf Algorithmen sind oft Teil einer größeren Anwendung operieren auf Daten der Anwendung, sollen aber unabhängig von konkreten Typen sein Darstellung der Algorithmen

Mehr

HW/SW CODESIGN. Echtzeitverhalten. Mehmet Ozgan 0526530. 17. November 2015

HW/SW CODESIGN. Echtzeitverhalten. Mehmet Ozgan 0526530. 17. November 2015 HW/SW CODESIGN Echtzeitverhalten 17. November 2015 Mehmet Ozgan 0526530 ÜBERBLICK 1. Echtzeitsysteme 2. Hardware im Zeitbereich 3. Software im Zeitbereich 2 ECHTZEITSYSTEME REAL-TIME SYSTEM Ein Echtzeitsystem

Mehr

Softwareschnittstellen

Softwareschnittstellen P4.1. Gliederung Rechnerpraktikum zu Kapitel 4 Softwareschnittstellen Einleitung, Component Object Model (COM) Zugriff auf Microsoft Excel Zugriff auf MATLAB Zugriff auf CATIA Folie 1 P4.2. Einleitung

Mehr

Echtzeitverhalten. Einleitung. Was bedeutet Echtzeit? Beispiele. Andere Faktoren. Echtzeitsystem und Echtzeitkomponenten

Echtzeitverhalten. Einleitung. Was bedeutet Echtzeit? Beispiele. Andere Faktoren. Echtzeitsystem und Echtzeitkomponenten Echtzeitverhalten Einleitung Was bedeutet Echtzeit? Die Interaktion mit der Außenwelt stellt in einem System den Zeitbezug her. Normalerweise will man ein korrektes Ergebnis so schnell wie möglich bekommen.

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

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

System Monitoring mit strace. Systemcall tracing

System Monitoring mit strace. Systemcall tracing System Monitoring mit strace Systemcall tracing 1 Gliederung Einleitung: Was ist strace Grundlagen zu strace Kernel Kernelspace vs. Userspace Systemcalls ptrace Simple strace (Demo) strace die wichtigsten

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

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen Albrecht Achilles 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Betriebssysteme Eine kompakte Einführung mit Linux

Mehr

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Prof. Dr. Wilhelm Schäfer Paderborn, 15. Dezember 2014 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Aufgabe 1 Codegenerierung

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

Jürg Gutknecht, SI und ETH Zürich, April 2015

Jürg Gutknecht, SI und ETH Zürich, April 2015 Jürg Gutknecht, SI und ETH Zürich, April 2015 Der Staubsauger könnte ein Mikrofon eingebaut haben, welches sämtliche Geräusche im Raum aufnimmt und via Stromkabel an einen Geheimdienst weiterleitet Die

Mehr

Nebenläufige Programmierung

Nebenläufige Programmierung Nebenläufige Programmierung Perspektiven der Informatik 27. Januar 2003 Gert Smolka Telefon-Szenario Eine Telefonzelle Mehrere Personen wollen telefonieren Immer nur eine Person kann telefonieren Ressource

Mehr

Musterlösung Prüfung SS 2002

Musterlösung Prüfung SS 2002 Musterlösung Prüfung SS 2002 Fach: I4neu (SEE, KOS, GRS, BTS) Teilprüfung: Betriebssystem Tag: 2.7.2002 8:15 12:15 Raum 1006 Bearbeitungszeit: 72 Minuten Name:... Matr.Nr.:... Punkte:... Note:... Hilfsmittel:

Mehr

Technische Informatik II Wintersemester 2002/03 Sommersemester 2001. Heiko Holtkamp Heiko@rvs.uni-bielefeld.de

Technische Informatik II Wintersemester 2002/03 Sommersemester 2001. Heiko Holtkamp Heiko@rvs.uni-bielefeld.de Technische Informatik II Wintersemester 2002/03 Sommersemester 2001 Heiko Holtkamp Heiko@rvs.uni-bielefeld.de Speicher ist eine wichtige Ressource, die sorgfältig verwaltet werden muss. In der Vorlesung

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