Verteilte Echtzeit-Systeme

Transkript

1 - Verteilte Echtzeit-Systeme Hans-Albrecht Schindler Wintersemester 2018/19 Teil C: Echtzeit-Betriebssysteme Abschnitt 16: Primärspeicherverwaltung unter Echtzeitbedingungen CSI Technische Universität Ilmenau

2 Anmerkungen insb. zu Abschnitt 15 Einfacher Kernel (Executive DICK) nach Abschnitt 15: keine Speicherverwaltungskomponente Möglich wenn: keine neuen Prozesse dynamisch erzeugt 16.1 Einleitende Bemerkungen Dann: alle Prozesse: existieren bereits bei Systemstart diese: erhalten ebenfalls bei Systemstart statischen Speicherbereich unveränderlicher Größe im Hauptspeicher Sinnvoll: bei einfachen oft eingebetteten Systemen Dynamischere Systeme: benötigen natürlich Verwaltung für Primärspeicher im folgenden: Darstellung von Besonderheiten bei Echtzeit 16. Echtzeit-Primärspeicherverwaltung / 16.1 Einleitende Bemerkungen ws 2018/19 H.-A. Schindler Folie: 16-2

3 Einleitende Bemerkungen Grundlegendes für eine Echtzeit-Speicherverwaltung oberstes Gebot auch für Hauptspeicher-Management: Prozesse: müssen ihre zeitlichen Restriktionen (z.b. Fristen) einhalten können! insbesondere: zeitlicher Determinismus / Vorhersagbarkeit darf nicht zerstört werden Prozesse: dürfen durch Speicherverwaltungs-Operationen nicht unnötig vor allem nicht in unvorhersagbarer Weise verzögert werden 16. Echtzeit-Primärspeicherverwaltung / 16.1 Einleitende Bemerkungen ws 2018/19 H.-A. Schindler Folie: 16-3

4 Einleitende Bemerkungen Grundlegendes Echtzeit- Speicherverwaltung Statische Speicherzuordnung Verwaltung nach dynamischen Prinzipien virtuelle Speicherverwaltung Bild 16-1: Mögliche Herangehensweisen für die Speicherverwaltung von Echtzeit-Betriebssystemen 16. Echtzeit-Primärspeicherverwaltung / 16.1 Einleitende Bemerkungen ws 2018/19 H.-A. Schindler Folie: 16-4

5 16.2 Statische Speicherzuordnung Bemerkungen Einfachste Lösung der auf Folie 16-3 genannten Probleme: durch eine statische Zuordnung eines Speicherbereichs an jeden Prozess auch einfachste Echtzeitsysteme basieren auf Multiprocessing Herangehensweise Speicherzuordnungen a) im Voraus (Pre-Allokation) oft: schon zum Entwurfszeitpunkt spätestens jedoch: bevor Prozess erstmalig aktiv wird b) ohne Änderung bis zur Beendigung des Prozesses c) Bereiche maximaler jemals benötigter Größe 16. Echtzeit-Primärspeicherverwaltung / 16.2 Statische Speicherzuordnung ws 2018/19 H.-A. Schindler Folie: 16-5

6 Statische Speicherzuordnung Herangehensweise genauer a) einfachster Fall: alle Prozesse befinden sich ständig im Hauptspeicher hier nur notwendig: einmalige Speicheraufteilung zum Entwurfszeitpunkt b) Systeme mit zu kleinem Hauptspeicher: notwendig: Ein- u. Auslagerung von Prozessen rudimentäre Hauptspeicherverwaltung 16. Echtzeit-Primärspeicherverwaltung / 16.2 Statische Speicherzuordnung ws 2018/19 H.-A. Schindler Folie: 16-6

7 Statische Speicherzuordnung Vor- und Nachteile Vorteile: 1. einfache Implementierbarkeit 2. keine Beeinflussung der zeitbezogenen Prozessparameter (insb. Fristeinhaltung) durch Speicherverwaltungsoperationen kein zeitlicher Nichtdeterminismus Nachteile: 1. bei Anwendungs-Programmierung: 2. keine dynamischen Prinzipien anwendbar keine variablen Array-Dimensionen keine dynamische Variablenvereinbarung 16. Echtzeit-Primärspeicherverwaltung / 16.2 Statische Speicherzuordnung ws 2018/19 H.-A. Schindler Folie: 16-7

8 Statische Speicherzuordnung Vor- und Nachteile Nachteile: 2. Bezüglich Speichervergabe: diverse statische Eigenschaften a) nicht möglich: dynamische Anpassung besonders bei dynamisch sich änderndem Speicherbedarf (Zunahme und Abnahme) dadurch: Verschwendung von Speicherplatz, z.b. durch o Fragmentierung o verzögerte Freigabe nicht benutzten Speichers damit: o Out-of-memory-Situationen schneller möglich o höhere Kosten des realisierten Gesamtsystems b) nicht möglich: Ortsänderung des belegten Speichersegments 16. Echtzeit-Primärspeicherverwaltung / 16.2 Statische Speicherzuordnung ws 2018/19 H.-A. Schindler Folie: 16-8

9 Statische Speicherzuordnung Hardware-Gesichtspunkte Einfache Systeme (viele kleine eingebettete Systeme): verwenden: oft nur Minimalhardware (z.b. keine MMU) deshalb hier: virtuelle Speicherverwaltung: nicht sinnvoll Speicherschutz: meistens nicht realisiert von 5 aktuelleren Betriebssystemen für eingebettete Echtzeit- Systeme (RTLinux, RTAI, RTMS, QNX, VxWorks) hat nur ein (!) BS Speicherschutz implementiert (QNX) 16. Echtzeit-Primärspeicherverwaltung / 16.2 Statische Speicherzuordnung ws 2018/19 H.-A. Schindler Folie: 16-9

10 16.3 Behelfsmäßige Verwendung virtueller Speichertechnik virtuelle Speicherverwaltung in normalen (= Nicht-Echtzeit-)Betriebssystemen: heute allgemein eingesetzt in Echtzeit-Betriebssystemen heute noch oft: prinzipiell vorhanden in Varianten, die aus Nicht-Echtzeit- Betriebssystemen entstanden Vorteilhafte Eigenschaften: 1. Prozesse laufen innerhalb ihres eigenen virtuellen Adressraumes ( Speicherschutz) 2. sie können mehr Speicherplatz nutzen als physisch vorhanden ( dynamische Speicherzuordnung sehr einfach) 16. Echtzeit-Primärspeicherverw. / 16.3 Behelfsmäßige Verw. virtueller Speichertechnik ws 2018/19 H.-A. Schindler Folie: 16-10

11 ... Paging als Form virtueller Speicherverwaltung Hauptspeicher (Ausschnitt) Hintergrundspeicherspeicher (z.b. Festplatte) Prozess A im Hintergrundspeicher Prozess B im Hintergrundspeicher... Übertragung einzelner Teile eines Prozesses zur Ausführung (Platz vergabe an Prozesse muss auch auf Hintergrundspeicher nicht zusammenhängend sein) Bild 16-2: Paging-Prinzip Darstellung nach /Deitel90/ S Echtzeit-Primärspeicherverw. / 16.3 Behelfsmäßige Verw. virtueller Speichertechnik ws 2018/19 H.-A. Schindler Folie: 16-11

12 Paging für Echtzeit-Anwendungen Anwendung modifizierter Betriebssysteme Gefahr: Durch unkontrolliertes Ein-/Auslagern zeitkritischer Seiten unkontrollierbare Zeitverzögerungen möglich! einfache Lösung: Festnageln von Seiten im Hauptspeicher (bekannt als: Pinning, Memory Locking usw.) 16. Echtzeit-Primärspeicherverw. / 16.3 Behelfsmäßige Verw. virtueller Speichertechnik ws 2018/19 H.-A. Schindler Folie: 16-12

13 1. Systeme entsprechend Real-Time POSIX/RT-Mach: eine Applikation kann alle Seiten im Hauptspeicher fixieren Funktion mlockall() Beispielsysteme mit modifiziertem Paging bzw. bestimmte Adressbereiche Funktion mlock( <starting_address>, <length>) 2. Echtzeit-Versionen von Windows u. andere BS: beim create_thread()-systemaufruf spezifizierbar, dass alle Seiten des erzeugten Threads im Speicher fixiert werden 3. LynxOS: Fixieren von Seiten durch Priorität ( paging priority ) gesteuert falls: (Applikations-Priorität paging priority): Seiten der Applikation fixiert falls: (Applikations-Priorität < paging priority): Seiten nicht fixiert 16. Echtzeit-Primärspeicherverw. / 16.3 Behelfsmäßige Verw. virtueller Speichertechnik ws 2018/19 H.-A. Schindler Folie: 16-13

14 16.4 Probleme herkömmlicher virtueller Speicherverwaltung Bemerkungen Ein- u. Auslagerungsoperationen Zeitpunkt: finden immer zu unpassenden Zeiten statt bei Seiten-Fetch-Operation immer Abarbeitung der Befehlsfolge des laufenden Prozesses unterbrochen ( Verzögerung) Zeitdauer dafür: nicht definiert langwierige Untersuchung der Ursache des Page-Fault-Interrupts (z.b. Linux-Kernel) ggf. Reihe derartiger Operationen gebündelt ausgeführt Zeitdauer von Zustand außerhalb des betrachteten Prozesses abhängig (Zustand im Speicher, Bedürfnisse anderer Prozesse) FAZIT: keinerlei zeitlicher Determinismus 16. Echtz.-Primärspeicherverw. / 16.4 Probleme herkömml. virtueller Speicherverwaltung ws 2018/19 H.-A. Schindler Folie: 16-14

15 Probleme herkömmlicher virtueller Speicherverwaltung Bemerkungen Deshalb: wichtiges Problem: geeignete Algorithmen für echtzeitfähige dynamische, ggf. virtuelle Speicherverwaltung 16. Echtz.-Primärspeicherverw. / 16.4 Probleme herkömml. virtueller Speicherverwaltung ws 2018/19 H.-A. Schindler Folie: 16-15

16 Generelles 16.5 Neuere Arbeiten zur Echtzeitspeicherverwaltung In neueren Arbeiten: Verwendung nur statischer Speicherverwaltung für immer komplexer werdende Echtzeitsysteme als nicht mehr vertretbar bezeichnet siehe z.b.: [Borg+2006] [OCERA] weitergehende Darstellungen: versuchen geeignete Modelle zu entwickeln [Böhnert+2011]: diskutieren: Modell, basierend auf neuartigen Betriebssystem- Komponenten u. neuartiger Real-time virtual memory management unit (RTMMU) hierbei: volle Flexibilität von virtueller u. dynamischer Speicherverwaltung für Echtzeitsysteme 16. Echtz.-Primärspeicherverw. / 16.5 Neuere Arbeiten zur Echtzeitspeicherverwaltung ws 2018/19 H.-A. Schindler Folie: 16-16

17 Hauptspeicherverwaltung nach dynamischen Prinzipien Generelle Anmerkungen weitergehende Darstellungen: [Borg+2006]: diskutiert: Eignung verschiedener dynamischer Speichermodelle für Echtzeitsysteme 16. Echtz.-Primärspeicherverw. / 16.5 Neuere Arbeiten zur Echtzeitspeicherverwaltung ENDE Abschnitt 16 ws 2018/19 H.-A. Schindler Folie: 16-17