Betriebssysteme Kap. 2: Nebenläufigkeit und Parallelität

Größe: px
Ab Seite anzeigen:

Download "Betriebssysteme Kap. 2: Nebenläufigkeit und Parallelität"

Transkript

1 Betriebssysteme, WS 2013/14 wk Betriebssysteme Kap. 2: Nebenläufigkeit und Parallelität Winfried E. Kühnhauser Wintersemester 2013/14 Winfried E. Kühnhauser CSI Technische Universität Ilmenau

2 Roadmap Anwendungsebene GUI MatLab Office ABS Google Earth Firefox Anwendungsschnittstelle (Application Programmer s Interface, API) Betriebssystem Betriebssystem-Dienste Prozessmanagement Dateimanagement Netzwerkmanagement Ressourcenmanagement Prozessor- Ressourcen Speicher- Ressourcen E/A Ressourcen E/A Ressourcen Kommunikations- Ressourcen Betriebssysteme, WS 2013/14 wk Nebenläufigkeit und Parallelität

3 Grundsätzliches Computer bearbeiten Aufgaben in wohldefinierten Arbeitsabläufen beschrieben durch Programme: Algorithmen, präzise definiert mittels formaler Programmiersprachen (C, C++, Java...) beim Ablauf von Programmen entstehen oft Wartesituationen Powerpoint wartet auf Tastatureingaben Mailserver wartet auf eintreffende s Wartezeiten sind relativ zur Prozessorgeschwindigkeit gigantisch (1 Sek Prozessorzyklen) statt schlicht zu warten, lässt sich besseres tun parallele Ausführung mehrerer Aufgaben tskmgr Betriebssysteme, WS 2013/14 wk Nebenläufigkeit und Parallelität

4 Parallelität geht nicht immer (duschen und abtrocknen ) Voraussetzung dazu: Nebenläufigkeit Begriffe 1. Aktivitäten heißen nebenläufig, wenn zwischen ihnen keine kausalen Abhängigkeiten bestehen 2. Aktivitäten heißen parallel, wenn sie zeitlich überlappend durchgeführt werden Nebenläufigkeit ist Voraussetzung für Parallelität Powerpoint und -Klient Powerpoint und Fileserver Betriebssysteme, WS 2013/14 wk Nebenläufigkeit und Parallelität

5 2.1 Prozesse ? ? ? ? Trotz kausaler Unabhängigkeit der Aufgaben: Paralleles Arbeiten auf kognitiver Ebene ist (für Menschen) schwierig Unser Umgang damit Wir sequenzialisieren Zerlegung der Aufgabe in 4 (eigentlich parallel ausführbare) Aktivitäten sequenzielle Abarbeitung dieser Aktivitäten Idee der Prozessmodelle von BSen Betriebssysteme, WS 2013/14 wk Prozesse

6 Definition Prozess (vorläufig, bis wir wissen, was Threads sind) Ein Prozess ist eine BS-Abstraktion zur vollständigen Beschreibung einer sequenziell ablaufenden Aktivität. Dazu gehört insbesondere das Arbeitsprogramm und dessen Bearbeitungszustand zugeordnete Betriebsmittel (Prozessor/Speicher/Kommunikationsressourcen) Rechte (Zugriff auf Dateien, Nutzung von Kommunikationsports) Parallele Aktivitäten werden repräsentiert durch parallele Prozesse ? ? ? ? Betriebssysteme, WS 2013/14 wk Prozesse

7 2.1.1 Prozessmodelle In a Nutshell Prozess = BS-Abstraktion zur Ausführung von Programmen Prozessmodelle definieren konkrete Prozesseigenschaften ( BS-spezifisch) Prozessmanager BS-Komponente, die Prozessmodelle implementiert Betriebssysteme, WS 2013/14 wk Prozessmodelle

8 Prozessmodelle Aufgabe präzise Definition der BS-Abstraktion Prozess definiert durch Semantik der Operationen auf Prozessen Erzeugen, Beenden, Anhalten, Fortsetzen, nichtfunktionale Eigenschaften von Prozessen Isolation Ressourcenmanagement (Speicher, Rechenzeit) Rechtemanagement implementiert durch Datenstrukturen Algorithmen des Prozessmanagements Betriebssysteme, WS 2013/14 wk Prozessmodelle

9 Prozessmanagement Anwendungsebene GUI MatLab Office ABS Google Earth Firefox Anwendungschnittstelle (Application Programmer s Interface, API) Betriebssystem-Dienste Betriebssystem Prozessmanagement Speichermanagement Kommunikationsmanagement Prozessor- Ressourcen Speicher- Ressourcen Ressourcenmanagement Kommunikations- Ressourcen div. E/A Ressourcen Betriebssysteme, WS 2013/14 wk Prozessmodelle

10 Prozessmanager seziert class ProcessManager { public: CreateProcess(Program) {... } Prozessmanagement TerminateProcess(Process) {... }... private: ProcessDescriptorTable... } Betriebssysteme, WS 2013/14 wk Prozessmodelle

11 2.1.2 Prozesserzeugung Prozesserzeugung: Erzeugen einer Programmablaufumgebung Anwen- GUI dungsebene CreateProcess() Google Earth Anwendungsschnittstelle (Application Programmer s Interface, API) Betriebssystem-Dienste Betriebssystem Prozessmanagement Speichermanagement Kommunikationsmanagement Prozessor- Ressourcen Speicher- Ressourcen Ressourcenmanagement Kommunikations- Ressourcen div. E/A Ressourcen Betriebssysteme, WS 2013/14 wk Prozesserzeugung

12 Anwendersicht mittels GUIs: Mausklick auf ein Symbol Google Earth mittels Kommandointerpreter/Shells kandooma> googleearth was letztendlich geschieht: per Systemaufruf aus ablaufendem Programm if (fork() == 0) execve( /usr/local/bin/googleearth, ) Betriebssysteme, WS 2013/14 wk Prozesserzeugung

13 Resultierende Aktionen des Prozessmanagements Prüfen notwendiger Voraussetzungen Rechte, Ressourcenverfügbarkeit (Speicher, Prozessorzeit) Namensvergabe Stammbaum Allokation von Ressourcen (dabei helfen andere BS-Komponenten); i.w. Arbeitsspeicher (Speichermanagement), Prozessorzeit (Scheduler) Anlegen von Managementdatenstrukturen ( Prozessdeskriptor ) Ressourcenmanagement; u.a. Speicher- und Prozessorbelegung Rechtemanagement; u.a. Eigentümer, Zugriffsrechte Laufzeitmanagement; u.a. Ablaufzustand, eingetretene Ereignisse Betriebssysteme, WS 2013/14 wk Prozesserzeugung

14 Notwendige Voraussetzungen (prozessmodellspezifisch) Sicherheit Authentizität des auszuführenden Programms Prüfung digitaler Signaturen Echtzeit Erfüllbarkeit von Ressourcenanforderungen Einhaltung gegebener Garantien Basis: Lastbeschreibungen Fairness Quoten Robustheit/Überlastvermeidung Lastsituation Betriebssysteme, WS 2013/14 wk Prozesserzeugung

15 (prozessmodellspezifisch) z.b. Unix/Windows Systemfamilien: Prozessidentifikation ist positive ganze Zahl Namensvergabe Vergabealgorithmus variiert; z.b. zyklisch [0, 32000], zufällig kann nach Terminierung eines Prozesses erneut vergeben werden eindeutig zu einem Zeitpunkt bzgl. aller existierenden Prozesse nicht unbedingt eindeutig für zeitlich nicht überlappende Prozesse erst recht nicht eindeutig über Systemgrenzen hinweg tskmgr Betriebssysteme, WS 2013/14 wk Prozesserzeugung

16 Stammbaum Abstammungsbeziehungen definieren Eltern/Kind-Hierarchie Prozess erzeugt weitere Prozesse: seine Kinder diese wiederum erzeugen weitere Prozesse usw. baumartige Abstammungshierarchie Nutzung: Rechte und Verantwortlichkeiten Ur- Prozess (erzeugt beim Systemstart ( launchd, init ) Betriebssysteme, WS 2013/14 wk Prozesserzeugung

17 Verwaiste Prozesse Adoption; Unix-Technik: durch Urprozess Ur- Prozess Ur- Prozess Betriebssysteme, WS 2013/14 wk Prozesserzeugung

18 Prozessmodellcharakteristika Allokation von Ressourcen Adressraum: wie viel Arbeitsspeicher erhält der neue Prozess? Größe Zeitpunkt: zu welchem Zeitpunkt erhält er ihn? Echtzeiteigenschaften (Planbarkeit) Performanz (Proaktivität) Isolation: wie ist er (vor anderen Prozessen) geschützt? Robustheit, Sicherheit, Korrektheit Speichermanagement, Kap. 3 High-End Betriebssysteme, Kap Arbeitsspeicher Betriebssysteme, WS 2013/14 wk Prozesserzeugung

19 Betriebssysteme, WS 2013/14 wk Arbeitsspeicherstruktur Arbeitsspeicher enthält mindestens ausführbaren Code des ausgeführten Programms Text Segment Werte der Programmvariablen (Integers, Strings, Klasseninstanzen ) Datensegment dynamisch erzeugte Datenstrukturen zur Organisation des Programmablaufs Heap Segment Stack Segment Arbeitsspeicher komplexer Prozesse (e.g. mit Threads, shared libraries) können solche Segmente vielfach enthalten Textsegment(e) Daten-(Heap-) Segment(e) Stacksegment(e)

20 Repräsentation ausführbarer Programme (.out/.exe -Files) Quellcode: C/C++/Java- Programm Textdatei Compiler Objekt- Code Bibliothek Linker ausführbares Programm z.b. im ELF-Format * ) Dateien auf persistentem Speicher (z.b. Festplatte) Magie (Formathinweise) Programmcode initialisierte Daten uninitialisierte Daten Startadresse (IP) Symboltabellen, z.b. firstint: #0 secondint: #4 grusstext: # h e l l o Kopf Infos zum Binden, Debuggen vom Compiler/ Linker erzeugter Programmcode vom Compiler initialisierte Daten * ) Executable und Link Format Betriebssysteme, WS 2013/14 wk Prozesserzeugung

21 Arbeitsspeicher-Initialisierung ausführbare Programmdatei Magie Programcode initialisierte Daten uninitialisierte Daten Startadresse Symboltabellen, z.b. firstint: #0 secondint: #4 grusstext: # h e l l o Speicherlayout Textsegment(e) Daten-(Heap-) Segment(e) Stacksegment(e) Betriebssysteme, WS 2013/14 wk Dabei hilft das VMM Kap Prozesserzeugung

22 Damit dies korrekt funktioniert: präzise Formatvereinbarungen zwischen dem Linker (Programmdatei-Produzent) dem Prozessmanagement (Programmdatei-Lader) Das a.out-format ursprüngliches Unix-Format veraltet, z.b. keine dynamisch gebundenen Bibliotheken (DLLs) Das Common Object File Format (COFF) Nachfolger des a.out-formats verbreitet vor allem in der Windows Welt Das Executable and Link(age/able) Format (ELF) heutiger Linux-Standard siehe Übungen Betriebssysteme, WS 2013/14 wk erkennbar an magic number Prozesserzeugung

23 Das a.out-format Kopf Textsegment Datensegment magic number text segment size data segment size bss segment size symbol table size program entry point text reloc table size data text reloc table size struct exec { } unsigned long a_midmag; unsigned long a_text; unsigned long a_data; unsigned long a_bss; unsigned long a_syms; unsigned long a_entry; unsigned long a_trsize; unsigned long a_drsize; Text-Relokationsinfo Daten-Relokationsinfo Symboltabelle Betriebssysteme, WS 2013/14 wk Prozesserzeugung

24 Allokation des Arbeitsspeichers schematisch /* read header Header=FileSystem.ReadHeader(ProgramFile); if (Header.midmag==ELFmag) then { ELFHeader=Header; /* create and init text segment TextSegmentAddr=VMM.CreateTextSegment(ELFHeader.TextSize); FileSystem.Read( ProgramFile, ELFHeader.TextSegmentOffset, ELFHeader.TextSize, TextSegmentAddr); /* create and init data segment /* create stack segment PCB.TextSegmentAddr=ELFHeader.TextSize; } elsif (Header.midmag==COFFmag) then { Betriebssysteme, WS 2013/14 wk Prozesserzeugung

25 Aufgabe Allokation elementarer Ressourcen in Prozessmodellen echtzeitfähiger Systeme (planbar) Planung und Bereitstellung von Prozessorzeit für einen Prozess 2. Prozessorzeit Parameter: Größe: wie viel Prozessorzeit benötigt der neue Prozess? Zeitpunkt: zu welchem Zeitpunkt wird Prozessorzeit benötigt? Autonomie: in wie weit darf dies durch andere Prozesse beeinflusst werden? in Prozessmodellen ohne diese Eigenschaften (kaum planbar) dynamisches ad-hoc-scheduling Strategien beeinflussen massiv die NFEs Scheduling-Algorithmen in Kap. 2.3 Betriebssysteme, WS 2013/14 wk Prozesserzeugung

26 Zwischenstand Aktionen des Prozessmanagements Prüfen notwendiger Voraussetzungen Rechte, Ressourcenverfügbarkeit (Speicher, Prozessorzeit) Namensvergabe Stammbaum Allokation von Ressourcen (dabei helfen andere BS-Komponenten); i.w. Arbeitsspeicher (Speichermanagement) Prozessorzeit (Scheduler) Irgendwo müssen wir uns all dies merken : Anlegen von Managementdatenstrukturen ( Prozessdeskriptor ) Ressourcenmanagement; u.a. Speicher, CPU Rechtemanagement; u.a. Eigentümer, Zugriffsrechte Laufzeitmanagement; u.a. Ablaufzustand, eingetretene Ereignisse Betriebssysteme, WS 2013/14 wk Prozesserzeugung

27 Management-Datenstrukturen Aufgabe Buchführung über sämtliche zum Management eines Prozesses notwendigen Informationen - Prozessidentifikation - Rechtemanagement - Speichermanagement (z.b. über Lage der Text/Daten/Stacksegmente) - Prozessormanagement (z.b. Lastprofil, Priorität, Ablaufzustand) Prozessdeskriptor (process control block, PCB) Prozessdeskriptortabelle: Prozessdeskriptoren sämtlicher Prozesse Man kann Prozessdeskriptoren ansehen Mac: Aktivitätsanzeige, ps -axl Linux/Gnome GUI: Systemüberwachung, ps -axl Windows: Task Manager Betriebssysteme, WS 2013/14 wk Prozesserzeugung

28 Ein typischer Prozessdeskriptor Prozessormanagement Identifikationen Prozessidentifikation Prozessidentifikation des Erzeugers Scheduling Prozesszustand Priorität, Lastbeschreibung,... Prozessorkontext Programmzähler ( IP ) Stack Pointer ( SP ) Prozessorstatusregister ( PSR ) allgemeine Prozessorregister Ereignismanagement anstehende Ereignisse eingeplante Reaktionen Handler-Vektor Aufweckzeit Accounting Startzeit verbrauchte Prozessorzeit Ein/Ausgabevolumen eindeutige Prozessbezeichnung, Einordnung in Hierarchie Informationen für Schedulingalgorithmen gesichert bei Verdrängung des Prozesses, restauriert bei Reaktivierung z.b. die Privilegierungsebene relevant auch bei schlafenden Prozessen zur Prioritätenbestimmung, Statistik, Kostenberechnung oder Quotenbestimmung Betriebssysteme, WS 2013/14 wk Prozesserzeugung

29 Speichermanagement Virtueller Adressraum Programm(Text-)segment(e) Datensegment(e) Stacksegment(e) Shared Memory Segment(e) Seitentabelle Kernel Stack Rechtemanagement User-Id des Eigentümers Gruppen-Id des Eigentümers Security Contex (Capabilities, Attribute) Allgemeines Ressourcenmanagement Arbeitsdirectory Root-Directory Filedeskriptoren E/A-Parameter, Schutzbit-Masken, etc. Beschreibung des Speicherlayouts Prozedurmanagement innerhalb des BS Filedeskriptoren, Socketdeskriptoren,... mit Zustandsinformationen je Ressource: erworbene Rechte, Dateipositionspointer,... Betriebssysteme, WS 2013/14 wk Prozesserzeugung

30 Ein typischer Prozessdeskriptor ist sehr groß (mit Seitentabellen (s.u.) mehrere Megabyte) ist daher oft physisch zweigeteilt (damit in Passivphasen weniger Arbeitsspeicher belegt wird) Informationen, die während der gesamten Existenz benötigt werden, z.b. Ablaufzustand (rechenbereit, blockiert) Priorität zugesandte Ereignisse und eingeplante Reaktionen hierauf Informationen, die nur während einer Aktivphase benötigt werden, z.b. Rechte (Teile des) Speicherlayout(s) Betriebssysteme, WS 2013/14 wk Prozesserzeugung

31 Zusammenfassung Prozesserzeugung Prüfen notwendiger Voraussetzungen Rechte, Ressourcenverfügbarkeit Namensvergabe Stammbaum Allokation von Ressourcen Arbeitsspeicher, Prozessorzeit Strategien bestimmen NFEs: Robustheit, Sicherheit, Performanz, Echtzeitanforderungen Managementdatenstrukturen Betriebssysteme, WS 2013/14 wk Prozesserzeugung

32 2.1.3 Prozessterminierung Ursachen Selbstmord Aufgabe erledigt GUI: Logout Compiler: Übersetzung eines Programms abgeschlossen Fehler aufgetreten und Weitermachen sinnlos logischer Fehler (z.b. Compiler: Quellcodedatei nicht gefunden) arithmetischer Fehler (z.b. Division durch 0) Betriebsmittelmangel (z.b. virtueller Speicher (s.u.) erschöpft) Mord und Totschlag nicht mehr gebraucht (z.b. Fenster schließen alle Prozesse im Fenster) Todesstrafe wegen schlimmer Vergehen (z.b. Speicherschutzverletzungen) Verklemmungsauflösung Betriebssysteme, WS 2013/14 wk Prozessterminierung

33 Techniken Selbstmord: Systemaufruf ans Prozessmanagement z.b. Unix: exit() explizit an beliebiger Stelle in einem Programm implizit nach Beenden des Programms (durch Laufzeitsystem) Mord und Totschlag: durch Eigentümer: per GUI: Fenster schließen _ per Admin-Software (z.b. Windows Task Manager) per Kommandointerpreter (z.b. Unix: kill -9 <eine PID> ) per Systemaufruf aus einem ablaufenden Programm (z.b. Unix: kill(<pid>,sigkill) ; kill(getpid(),9) exit() ) durch Betriebssystem: Nachricht an das Prozessmanagement, z.b. durch Speichermanagement ALU/Arithmetik-Koprozessor (FPU) Verklemmungsüberwachung Betriebssysteme, WS 2013/14 wk Prozessterminierung

34 Was geschieht bei einer Prozessbeendigung? Freigabe der Ressourcen Name, Speicher- und Prozessorreservierungen, geöffnete Dateien, Kommunikationsverbindungen Benachrichtigung der Eltern Techniken: Signale (IPC), rückkehrende Systemaufrufe (z.b. wait()) Adoption der Kinder Ur- Prozess Ur- Prozess Betriebssysteme, WS 2013/14 wk Prozessterminierung

35 2.1.4 Zusammenfassung Elementares Prozessmanagement Prozessmodelle Definition der BS-Abstraktion Prozess durch Semantik der Operationen auf Prozessen nichtfunktionale Eigenschaften von Prozessen implementiert durch Operationen, Datenstrukturen, Algorithmen des Prozessmanagements Prozesserzeugung Allokation von Ressourcen Prozessterminierung Freigabe der Ressourcen und dazwischen Ablaufmanagement: Management-Datenstrukturen Betriebssysteme, WS 2013/14 wk Zusammenfassung

36 2.2 Threads Motivation Viele Anwendungssysteme enthalten nebenläufige Aktivitäten Server (Web-, Mail-, Datenbank-) bedienen gleichzeitig viele Klienten Netzwerk Algorithmen zur Lösung komplexer Probleme Lösung von Differentialgleichungen (Wetter) Multiplikation großer Matrizen (Computergrafik) Simulationen (Simulacron 3) Betriebssysteme, WS 2013/14 wk Threads

37 Naive Lösung für jede nebenläufige Aktivität spendieren wir einen Prozess Jedoch Prozesse sind dafür uncool Kosten des Managements (Ressourcenallokation) Kosten der Isolation (virtuelle private Adressräume, s.u.) Kosten der Kommunikation (IPC, s.u.) Parallelität mittels vieler Prozesse ist teuer revidiertes Prozessmodell Gesucht also: kostengünstigeres Modell zur Parallelisierung nebenläufiger Aktivitäten Betriebssysteme, WS 2013/14 wk Threads

38 2.2.1 Das Threadmodell Ursachenforschung Das bisherige Prozessmodell ist kostspielig, weil zwei sachlich unabhängige Konzepte zusammengefasst sind: Prozesse sind hier gleichzeitig die elementare Einheit der Parallelität die elementare Einheit des Ressourcenmanagements und Schutzes Modell historisch, nicht sachlich begründet Korrektur Entflechtung dieser Funktionen; wir möchten eine Abstraktion zum Management von Ressourcen (teuer) eine Abstraktion zum Management von Parallelität (preiswert) enter Threads Betriebssysteme, WS 2013/14 wk Das Threadmodell

39 Anwendungsbeispiel Multi-threaded Webserver Prozess mit vielen parallelen Aktivitäten, die alle die gleichen Rechte haben (z.b. Zugriff auf Datenbank mit Webseiten) alle die gleichen Ressourcen besitzen und sich teilen (z.b. Arbeitsspeicher, Webseitencache, Kommunikationswege zu Dateisystem/Datenbank) jede einzeln für sich z.b. einen individuellen Klienten betreut Klient Web-Server Klient Betriebssysteme, WS 2013/14 wk Das Threadmodell

40 Revision des bisherigen Prozessmodells Definition Prozess Ein (multi-threaded) Prozess ist eine vollständige Beschreibung einer ablaufenden Aktivität. Dazu gehört insbesondere das Arbeitsprogramm zugeordnete Betriebsmittel (Prozessor/Speicher/Kommunikationsressourcen) Rechte prozessinterne parallele Aktivitäten (Threads) und ihre Bearbeitungszustände. Definition Thread Ein Thread ist eine sequenzielle Aktivität im Kontext eines Prozesses. Parallele Aktivitäten innerhalb eines Prozesses werden durch parallele Threads repräsentiert. Betriebssysteme, WS 2013/14 wk Das Threadmodell

41 Anmerkungen Eigentümer von Ressourcen und Rechten sind nach wie vor Prozesse das Programm eines Prozesses kann nun Code für mehr als nur eine einzige sequenzielle Aktivität enthalten Gegenstand der Prozessorzuteilung sind nun Threads das ursprüngliche Prozessmodell ist eine Spezialisierung dieses Modells: ein Prozess mit genau einem Thread ( single-threaded ) Web-Server Betriebssysteme, WS 2013/14 wk Das Threadmodell

42 Anmerkungen cont d ein Prozessdeskriptor eines multi-threaded-prozessmodells enthält alle Informationen des PCBs eines single-threaded-prozessmodells plus Informationen über alle seine Threads (je Thread ein Threaddeskriptor (TCB, thread control block )) ein TCB enthält lediglich Ablaufkontext (Programmzähler, Stackpointer, Prozessorregister) Threadzustand (aktiv, bereit, blockiert,...) insbesondere keine Beschreibung der Ressourcen (Speicherlayout, Rechte) Threads werden daher oft auch als Leichtgewichtsprozesse bezeichnet Betriebssysteme, WS 2013/14 wk Das Threadmodell

43 Varianten komfortabel: integriert in Programmiersprachen zu Fuß: Thread-Bibliotheken / Betriebssystem-API Integriert in Programmiersprachen, z.b. Ada: TASK BODY AServerThread IS BEGIN LOOP AwaitClientRequest(...); HandleClientRequest(...); ReplyToClient(...); UNTIL client disconnects; END; Programmieren mit Threads Wie treten Threads gegenüber Programmierern auf? Aufgabe des Ada-Compilers Abbildung der TASKs auf das multi-threaded Prozessmodell des BS (KLTs, s.u.) alternativ hinzufügen eines Laufzeitsystems mit eigenem Thread-Management (ULTs, s.u.) Betriebssysteme, WS 2013/14 wk Das Threadmodell

44 Zu Fuß, z.b. in einem C-Programm, eine Thread-Bibliothek nutzend #include <pthread.h> void AServerThread() { repeat { AwaitClientRequest(...); HandleClientRequest(...); ReplyToClient(...); } until client disconnects; } durch Thread ausgeführtes Programm, syntaktisch als Prozedur formuliert main() {... whenever new client connects: ThreadCreate(...,AServerThread,...);... } Aufgabe der Thread-Bibliothek (dieselbe wie die des Compilers) Abbildung des Prozedurkonstrukts auf das Prozessmodell des BS (KLTs, s.u.) alternativ hinzufügen eines Laufzeitsystems mit einem Thread-Management (ULTs, s.u.) Betriebssysteme, WS 2013/14 wk Das Threadmodell

45 2.2.2 Thread-Implementierungen Alternativen Prozessmodell des Betriebssystems ist single-threaded Realisierung auf Anwendungsebene (User Level Threads, ULTs) Web-Server Thread- Bibliothek DB-Server Thread- Bibliothek TCB-Tabelle TCB-Tabelle API Prozessmgmt PCB-Tabelle Betriebssysteme, WS 2013/14 wk Thread-Implementierungen

46 Prozessmodell des Betriebssystems ist multi-threaded Realisierung durch Betriebssystem (Kernel Level Threads, KLTs) Web-Server DB-Server API Prozessmgmt PCB- und TCB-Tabellen Betriebssysteme, WS 2013/14 wk Thread-Implementierungen

47 Pros und Kontras der beiden Implementierungsformen Pro ULT Web-Server Thread- Bibliothek DB-Server Thread- Bibliothek TCB-Tabelle TCB-Tabelle API Prozessmgmt PCB-Tabelle Performanz Thread-Management ohne Systemaufrufe Thread-Umschaltung ohne BS-Mitwirkung keine Kosten durch Systemaufruf-Overhead Individualität anwendungsindividuelle Thread-Schedulingstrategien möglich Portabilität Betriebssysteme, WS 2013/14 wk Thread-Implementierungen

48 Pro KLT Web-Server DB-Server API Prozessmgmt PCB- und TCB-Tabellen Performanz: Parallelität Nutzung von Mehrprozessor/Multicorearchitekturen keine Blockade der gesamten Anwendung durch blockierende Systemaufrufe Betriebssysteme, WS 2013/14 wk Thread-Implementierungen

49 Problematisch: ein blockierender Systemaufruf (z.b. E/A-Operation) legt den Aufrufer still bei ULTs ist dies ein Prozess, und damit alle seine Threads Web-Server Thread- Bibliothek (mit Scheduler) DB-Server Thread- Bibliothek (mit Scheduler) TCB-Tabelle TCB-Tabelle API Prozesse PCB-Tabelle Betriebssysteme, WS 2013/14 wk Thread-Implementierungen

50 Es gibt Work-Arounds Alle gefährlichen (=potenziell blockierenden) Systemaufrufe einpacken; Paket: Test, ob sie blockieren würden, riefe man sie auf nein: tatsächlicher Aufruf ja: Eintrag des Aufrufer-Threads in Warteliste, Threadwechsel, später Neuversuch Folge rewriting sämtlicher derartiger Systemaufrufe sehr ineffizient sehr plump es gibt aber keine Alternativen Betriebssysteme, WS 2013/14 wk Thread-Implementierungen

51 Fazit: Wer die Wahl hat... Wahl des ULT- vs. KLT-Modells hängt ab von Voraussetzungen: Prozessmodell des BS multi-threaded? Anwendungsprofil: E/A-Profil, Parallelität, Portabilität, Individualität Betriebssysteme, WS 2013/14 wk Thread-Implementierungen

52 Anwendungsprofile Typische Thread-Szenarien (Server mit vielen Klienten) benutzen blockierende E/A-Operationen sehr häufig spricht gegen ULTs relativiert den Management-Overhead (Systemaufrufe) der KLTs: Threads warten oft auf die Fertigstellung von E/A-Operationen dies tun sie innerhalb des Betriebssystems ( kernel level ) also fallen zusätzliche Kosten für einen eigens zum Thread-Scheduling notwendigen Systemaufruf oft gar nicht an die bei KLTs höheren Kosten für eine Threaderzeugung können durch Thread-Pools eliminiert werden nutzen die Parallelität von Multicore-Prozessoren Fazit Es spricht vieles für multi-threaded Prozessmodelle und KLTs Betriebssysteme, WS 2013/14 wk Thread-Implementierungen

53 2.2.3 Zusammenfassung Sie kennen nun den Grund für die Existenz von Threads multi-threaded Prozessmodelle deren Pros und Kons Performanz Robustheit Sicherheit Implementierungsebenen für Threads user level Threads kernel level Threads Pros und Kons dieser Varianten Betriebssysteme, WS 2013/14 wk Zusammenfassung

54 2.3 Scheduling Das Problem Anzahl der Aktivitäten >> Anzahl der Prozessoren nicht alle können gleichzeitig arbeiten eine Auswahl muss getroffen werden Auswahlstrategie: Schedulingstrategie, ~algorithmus die Betriebssystemkomponente: Scheduler Welche Threads erhalten wann wie lange einen Prozessor zugeteilt Betriebssysteme, WS 2013/14 wk Scheduling

55 2.3.1 Zustandsmodelle Ziel Effizientes Ressourcenmanagement Threads können z.b. aktiv sein besitzen einen Prozessor rechenbereit sein hätten gerne einen Prozessor kurzfristig warten (z.b. auf Daten von Speichermedien) benötigen keinen Prozessor, aber in Kürze Arbeitsspeicher langfristig warten (z.b. Klientenauftrag, Timerablauf) benötigen keinen Prozessor / Arbeitsspeicher Folge Ressourcenmanagement benötigt präzise Informationen über derartige Threadzustände Betriebssysteme, WS 2013/14 wk Zustandsmodelle

56 Aufgabe der Zustandsmodelle Beschreibung des Ablaufzustands von Threads (aktiv, bereit, kurz wartend,...) der möglichen Zustandsübergänge (z.b. bereit aktiv, aktiv kurz wartend,...) Nutzung jeder Thread ist zu jedem Zeitpunkt in genau einem dieser Zustände jeder Thread wechselt seinen Zustand gemäß der im Modell definierten Zustandsübergänge, hervorgerufen z.b. durch Zuteilung eines Prozessors (bereit aktiv) Eintritt von Wartegründen (aktiv wartend) Ressourcenmanagement nutzt Zustände als Informationsquelle für strategische Entscheidungen Betriebssysteme, WS 2013/14 wk Zustandsmodelle

57 Beschreibungsmittel Endliche deterministische Automaten a got a a q 0 a b q t a, b b got b b Implementierung Threadzustand ist Teil des Threaddeskriptors Zustandsübergangsfunktion ( -Funktion) ist Teil des Prozessmanagements Betriebssysteme, WS 2013/14 wk Zustandsmodelle

58 Threadzustände im 3/5-Zustandsmodell bereit: kann aktiv werden, sobald Prozessor frei wird aktiv: besitzt einen Prozessor, arbeitet blockiert: wartet auf Ereignis (E/A, Timer-Ablauf,...) frisch: erzeugt, Betriebsmittel/Rechte zum Ablauf fehlen noch beendet: Betriebsmittel in der Freigabephase frisch Zulassung bereit Scheduler: - Zuteilung - Entzug aktiv Beendigung beendet Ereignis Warten blockiert Beendigung Betriebssysteme, WS 2013/14 wk Zustandsmodelle

59 Verfeinerung: 7-Zustandsmodell Differenzierung (prozessexterner) Wartegründe Prozess ausgelagert (besitzt temporär keinen Arbeitsspeicher) Prozess (z.b. durch Benutzer) temporär stillgelegt (benötigt keinen Prozessor) (längerfristige) Suspendierung Zuteilung/Entzug Zulassung Beendigung frisch bereit aktiv beendet Suspendierung/ Desuspendierung Ereignis Warten bereit/ suspendiert blockiert Ereignis Suspendierung/ Desuspendierung blockiert/ suspendiert Betriebssysteme, WS 2013/14 wk Zustandsmodelle

60 Reale Modelle: Varianten dieser Grundmodelle Beispiel: Unix System 5, Release 4 9-Zustandsmodell ps created genug Speicher ready Scheduler kernel running exit() zoombi zu wenig Speicher swap out/in wakeup() sleep() Systemaufruf ready/ swapped asleep/ in memory user running wakeup() swap out preempt continue asleep/ swapped preempted Betriebssysteme, WS 2013/14 wk Zustandsmodelle

61 Messages Zustandsmodelle Präzise Informationen über Threadzustand befördern Effizienz und Ökonomie des Prozessormanagements welche Threads wollen rechnen (Kandidatenvorrat für Zuteilung) wie viele Threads wollen rechnen (Last) wie kurzfristig werden für einen gegebenen Thread Prozessorressourcen benötigt... Effizienz und Ökonomie des Speichermanagements welche Informationen müssen wo im Speicher liegen (Zuteilungskandidaten) wie groß ist der Gesamtspeicherbedarf aller rechenbereiten Prozesse (Last) wie kurzfristig werden welche Speicherressourcen benötigt... Betriebssysteme, WS 2013/14 wk Zustandsmodelle

62 2.3.2 Scheduler Welche Threads erhalten wann wie lange einen Prozessor zugeteilt Scheduler strategiegesteuerte(r) - Zuteilung - Entzug eines Prozessors bereit aktiv Ereignis Warten blockiert Betriebssysteme, WS 2013/14 wk Scheduler

63 Arbeitsweise eines Schedulers Scheduler- Aktivierung z.b. Blockierung eines aktiven Threads Bereitwerden eines blockierten/ suspendierten Threads wakeup! asleep Auswahlstrategie: m aus n Threads (bei m Prozessoren) Zuteilung und Entzug Sichern des Threadkontexts in TCB MMU-Kontext (Speicher-Layout) Stackkontext Registerkontext Privilegierungsebene Restaurieren des neuen Threadkontexts aus TCB (Implementierung architekturabhängig) bereit aktiv Ereignis Warten blockiert Betriebssysteme, WS 2013/14 wk Scheduler

64 2.3.3 Scheduleraktivierungen Wann wird die letzte Schedulingentscheidung überprüft? Prozess/Threaderzeugung neuer, rechenbereiter Thread Threadterminierung, Threadblockierung ein Prozessor wird frei Ereigniseintritt Thread wird rechenbereit (Wegfall von Wartegründen) Wechsel von Prioritäten in prioritätenbasierten Schedulingalgorithmen periodisch in zeitscheibenbasierten Schedulingalgorithmen Scheduler- Aktivierung asleep Auswahlstrategie: m aus n Threads (bei m Prozessoren) Zuteilung und Entzug bereit aktiv Ereignis Warten blockiert Betriebssysteme, WS 2013/14 wk Scheduleraktivierungen

65 Ein Kontextwechsel umfasst Zuteilung und Entzug: Kontextwechsel bei Wechsel zwischen Threads desselben Prozesses Software meets Hardware Stackkontext; enthält u.a. IP und PSR (ALU-Flags, Privilegierungsebene) Prozessorregister floating point unit (FPU)-Kontext; sehr groß hohe Kosten zusätzlich bei Wechsel zwischen Threads verschiedener Prozesse Privilegierungsebene Speicherlayout Sofortkosten: Herstellen des Speicherlayouts Sekundärkosten: TLB- und Cache-refill sehr (!) hohe Kosten; s. nachfolgendes Kapitel Kosten der Kontextwechsel auswirkungsreich auf Gesamtperformanz Reaktivität Echtzeiteigenschaften Scheduler- Aktivierung bereit Ereignis asleep Auswahlstrategie: m aus n Threads (bei m Prozessoren) Zuteilung und Entzug blockiert aktiv Warten Betriebssysteme, WS 2013/14 wk Kontextwechsel

66 Kostenfaktor FPU Kopieren des FPU-Kontexts: sehr viele Register (IA-64: 2KByte) in TCB- Datenstrukturen (im Arbeitsspeicher!) Sofortkosten: Kopieroperationen Sekundärkosten: durch Cacheverschmutzung Realisierung: (da nicht jeder Thread die FPU benutzt:) faul, Hardware hilft: FPU-Protection besitzt / benutzt Thread A (aktiv) FPU Kontext A Thread A (passiv) besitzt FPU save Kontext A B Thread B (aktiv) benutzt restore Betriebssysteme, WS 2013/14 wk Kontextwechsel

67 Kostenfaktor FPU Kopieren des FPU-Kontexts: sehr viele Register (IA-64: 2KByte) in TCB- Datenstrukturen (im Arbeitsspeicher!) Sofortkosten: Kopieroperationen Sekundärkosten: durch Cacheverschmutzung Realisierung: (da nicht jeder Thread die FPU benutzt:) faul Hardware hilft: FPU-Protection Thread A (aktiv) Thread A (passiv) Thread B (aktiv) Auswirkung besitzt / benutzt FPU Kontext A FPU Kontext A B besitzt / benutzt nur ein Thread benutzt FPU: tatsächliches Sichern erfolgt nie wenige Threads benutzen FPU: tatsächliches Sichern minimiert Betriebssysteme, WS 2013/14 wk Kontextwechsel

68 Implementierung eines Threadwechsels Im Maschinenraum Für die Profis Z.B. in Linux auf einer Intel IA-64-Architektur (deren Intel-Implementierung: Itanium ) ia64_switch_to(struct task_struct *next) Sichern des Ablaufkontexts des abzulösenden Threads in dessen TCB Restaurieren des Kontexts des neuen Threads aus dessen TCB hochperformante Implementierung: HW-architekturspezifisch, in Maschinencode Zum Nachlesen Mosberger, Eranian: IA-64 Linux Kernel Code: /usr/src/linux-<version>/arch/ia64/kernel/entry.s Betriebssysteme, WS 2013/14 wk Kontextwechsel

69 2.3.5 Schedulingstrategien Das Problem asleep Auswahlstrategie: m aus n Threads (bei m Prozessoren) Zuteilung und Entzug bereit aktiv Ereignis Warten blockiert Betriebssysteme, WS 2013/14 wk Schedulingstrategien

70 Strategische Ziele abhängig vom Einsatzumfeld eines Betriebssystems Echtzeitsysteme: Einhaltung von Fristen interaktive Systeme: Reaktivität Serversysteme: Reaktivität, E/A-Performanz Batch-Verarbeitungssysteme: Durchsatz ergänzt durch allgemeine Ziele Fairness: rechenbereite Threads bekommen ein faires Maß an Rechenzeit Lastbalancierung: alle Systemkomponenten (CPUs, Speicher, E/A- Peripherie) sind gleichmäßig ausgelastet Ausbalancierung mehrerer Ziele multikriterielle Optimierungsaufgabe, i.d.r. NP-vollständig heuristische Scheduling-Algorithmen Betriebssysteme, WS 2013/14 wk Schedulingstrategien

71 Lastmuster Typische Muster aktiver Threadphasen CPU-lastiger Thread z.b. mathematische Berechnungen, Bildcodierung, Verschlüsselung E/A - lastiger Thread z.b. interaktive Prozesse, Klienten, (wenig belastete) Serverthreads periodische Last P P P P z.b. Anlagensteuerung, Echtzeitverarbeitung von (Audio-, Video-, Sensor-) Datenströmen chaotische Last Server mit inhomogenen Diensten : Aktivphase Betriebssysteme, WS 2013/14 wk Schedulingstrategien

72 Differenzierte Schedulingstrategien nutzen Wissen über Lastmuster zur Optimierung; z.b. Minimierung der Thread/Prozesswechsel Frist Frist Frist Frist periodische Last (wichtig) periodische Last (weniger wichtig) prio-basierter Schedule multikriterieller Schedule 18 Pw. 13 Pw. Betriebssysteme, WS 2013/14 wk Schedulingstrategien

73 Schedulingstrategien für Batch-Systeme Ziele Auslastung teurer Betriebsmittel - i.d.r. Maximierung der CPU- Auslastung Minimierung der Scheduling-Kosten wenig Prozesswechsel kurze Laufzeit des Scheduling-Algorithmus Maximierung des Durchsatzes (erledigte Arbeit / Zeit) Algorithmen... gibt es sehr viele; zwei der bekannteren: First Come, First Served (FCFS) Shortest Remaining Time Next (SRTN) Betriebssysteme, WS 2013/14 wk Schedulingstrategien

74 First Come, First Served (FCFS, FIFO) Prozessorzuteilung in Reihenfolge, in der Threads rechenbereit werden Threads arbeiten, bis sie (auf ein Ereignis) warten müssen (z.b. E/A- Operation) extrem einfache Strategie einfach zu implementieren (1 Warteschlange) geringe Algorithmuskosten (O(1): FIFO-Warteschlange) schnelle Entscheidungen (O(1): Nr. 1 aus Warteschlange) nicht immer sehr klug; Beispiel: 1 periodischer Thread, Aktivphasendauer 1 Sekunde (CPU-intensiv) n E/A-intensive Threads Betriebssysteme, WS 2013/14 wk Schedulingstrategien

75 Wertung guter Durchsatz: minimale Zahl an Threadwechseln minimaler Scheduling-Overhead E/A-intensive Threads können durch CPU-intensive Threads extrem verzögert werden hohe Varianz der Bearbeitungszeiten für Threads mit unterschiedlichen Lastmerkmalen Betriebssysteme, WS 2013/14 wk Schedulingstrategien

76 Shortest Remaining Time Next (SRTN) Thread mit voraussichtlich kürzester Restrechenzeit erhält Prozessor preemptiv* ), d.h. Threads können von konkurrierenden Threads verdrängt werden (Schätzwert über) Restlaufzeit muss vorliegen einfache Strategie einfach zu implementieren (1 Warteschlange) geringe Algorithmuskosten (O(n): sortierte Warteschlange) schnelle Entscheidungen (O(1): Nr. 1 aus Warteschlange) * ) i. Ggs. zu kooperativ Betriebssysteme, WS 2013/14 wk Schedulingstrategien

77 Wertung bevorzugt kurze Prozesse Gefahr, dass längere Prozesse verhungern vergleichsweise mehr Threadwechsel größerer Scheduling-Overhead Betriebssysteme, WS 2013/14 wk Schedulingstrategien

78 Schedulingstrategien für interaktive Systeme Ziel Minimierung von Reaktionszeiten (subjektiver Eindruck von Performanz) Fairness (mehrere Benutzer/Klienten) Algorithmen... gibt es auch hier viele; oft verwendet: Round-Robin-Varianten einfacher Round Robin Round Robin plus Prioritäten Betriebssysteme, WS 2013/14 wk Schedulingstrategien

79 Round Robin Idee Jeder Thread bekommt ein gleich großes Teil des Kuchens: die Zeitscheibe rechenbereite Threads aktiver Thread tick einfach und effizient zu realisieren einfach zu implementieren (1 Warteschlange) geringe Algorithmuskosten (O(1): FIFO-Warteschlange) schnelle Entscheidungen (O(1): Nr. 1 aus Warteschlange) notwendiges Wissen gering (CPU-Nutzungsdauer des aktiven Threads) Betriebssysteme, WS 2013/14 wk Schedulingstrategien

80 Round Robin Idee Jeder Thread bekommt ein gleich großes Teil des Kuchens: die Zeitscheibe rechenbereite Threads aktiver Thread tick Tuning-Rädchen: Größe einer Zeitscheibe große Zeitscheibe wenig Threadwechsel geringer Schedulingoverhead Reaktivität: 10 Server-Klienten erteilen gleichzeitig einen Auftrag... kleine Zeitscheibe hohe Reaktivität Overhead z.b. bei Zeitscheibe 4msek, Threadwechselzeit 1msek: 20% typischer Wert heute: 20-50msek Betriebssysteme, WS 2013/14 wk Schedulingstrategien

81 Einbeziehung von Prioritäten Ziel Ausdrucksmöglichkeit der Wichtigkeit von Threads niedrig: z.b. Dämonen (die z.b. im Hintergrund s verschicken) Putzarbeiten (Index-Erstellung, Defragmentierung) hoch: z.b. Idee auf Aufträge reagierende Threads (z.b. in Servern) auf Benutzereingaben reagierende Threads (z.b. aktives Fenster einer GUI) unter Echtzeitbedingungen arbeitende Threads (z.b. Motormanagement, DVD-Spieler) jeder Thread erhält individuelle Priorität Threads der höchsten Prioritäten erhalten einen Prozessor zwischen Threads gleicher Priorität: Round-Robin Betriebssysteme, WS 2013/14 wk Schedulingstrategien

82 Realisierung Warteschlange Prio Warteschlange Prio 1 Warteschlange Prio Es gibt sehr viele Varianten dieses Schemas statische Prioritäten, z.b. in planbaren Echtzeitsystemen (Autoradio: Reaktion auf Stationswechseltaste hat Vorrang vor Senderfeldstärkenüberwachung) kommerziellen Rechenzentren (wer mehr zahlt, ist eher an der Reihe) dynamische Prioritäten, abhängig z.b. von verbrauchter CPU-Zeit (Verhinderung der Dominanz) E/A-Intensität Wartegrund Betriebssysteme, WS 2013/14 wk Schedulingstrategien

83 Realisierung Warteschlange Prio Warteschlange Prio 1 Warteschlange Prio Beispiel aktueller Linux O(1) Scheduler Prios 1-140, je Core eine Warteschlangengruppe mit einer Warteschlange je Prio ( 8 Cores: bis zu 1120 Warteschlangen) Betriebssysteme, WS 2013/14 wk Schedulingstrategien

84 Schedulingstrategien in Echtzeitsystemen Beispielszenario 1: PC MPEG-Videostrom mplayer Bildfolge 25 Bilder/Sek Lastmuster: z.b. alle 40 msek für 15 msek msek Erzeugte Prozessorbelegung ohne Konkurrenz msek Frist für Bild 1 Bild 2 Bild 3 Bild 4 Betriebssysteme, WS 2013/14 wk Schedulingstrategien

85 Beispielszenario 2: Digitales Mischpult MPEG-Videostrom Bildfolge 30 Bilder/Sek MPEG-Videostrom Bildfolge 25 Bilder/Sek Lastmuster: z.b. alle 40 msek für 15 msek + alle 33 1 / 3 msek für 10 msek msek Erzeugte Prozessorbelegung mit Konkurrenz z.b. Frist für.. Bild 1 Bild 2 Bild 3 Bild 4 Bild msek Frist für Bild 1 Bild 2 Bild 3 Bild 4 Betriebssysteme, WS 2013/14 wk Schedulingstrategien

86 Schedulingziele in Echtzeitsystemen Finden einer ausführbaren Bearbeitungsreihenfolge (ein Schedule ) die Fristen einhält deren Berechnung ökonomisch ist (Algorithmuskosten) die selbst ökonomisch ist (z.b. Minimierung der Threadwechsel) die sich (evtl.) an wechselnde Lastmuster anpasst Verbreitete Algorithmen EDF: früheste Frist zuerst (earliest deadline first) RMS: Raten-monotones Scheduling (rate monotonic scheduling) für periodische Lasten (z.b. Mischpult, DVD-Spieler, technische Prozesse) Betriebssysteme, WS 2013/14 wk Schedulingstrategien

87 Earliest Deadline First (EDF) Methode wird ein Thread rechenbereit, so nennt er seine nächste Deadline (Frist) von allen bereiten Threads ist immer derjenige mit der frühesten Deadline aktiv (dringend=wichtig) Folglich... arbeitet der Algorithmus mit dynamischen Prioritäten adaptiv ist die Priorität um so höher, je näher seine Frist liegt ist er preemptiv Voraussetzung kausale zeitliche Unabhängigkeit der Threads (keine wechselseitige Blockierung) Betriebssysteme, WS 2013/14 wk Schedulingstrategien

88 The Works Beispiellast (hier periodisch) Thread A: Periodendauer 30 msek, Aktivphase 10 msek Thread B: Periodendauer 40 msek, Aktivphase 15 msek Thread C: Periodendauer 50 msek, Aktivphase 5 msek Frist: Jeweils der Beginn der folgenden Aktivphase A B C C A B A A A A B B B C C EDF A B? C A? B C? A? B A? C? A B msek Anmerkungen bei Bereitwerden eines Threads müssen Prioritäten neu berechnet werden bis zu einer Prozessorauslastung von 100% wird ein Schedule gefunden kausale oder zeitliche Abhängigkeiten? Betriebssysteme, WS 2013/14 wk Schedulingstrategien

89 2.3.6 Zusammenfassung Das Problem Anzahl der Threads >> Anzahl der Prozessoren nicht alle können gleichzeitig rechnen eine Auswahl muss getroffen werden Auswahlstrategie: Schedulingalgorithmen Welche Threads erhalten wann wie lange einen Prozessor zugeteilt Zulassung Scheduling Beendigung frisch bereit aktiv beendet Ereignis Warten blockiert Betriebssysteme, WS 2013/14 wk Zusammenfassung

90 Schedulingalgorithmen haben großen Einfluss auf Reaktivität, E/A-Performanz, Echtzeitverhalten, sind daher spezialisiert auf konkrete Einsatzszenarien, z.b. interaktive Systeme, Serversysteme, Echtzeitsysteme, Batch-Systeme sind weiter differenziert bzgl. Annahmen über typische Lastmuster (Periodizität, Fristen) gegebene Garantien z.b. bzgl. der Fairness, Fristeneinhaltung, erzielbare Prozessorauslastung... Threadwechsel erfolgen zu wohldefinierten Zeitpunkten durch Sichern und Restaurieren von Thread/Prozesskontexten können mit erheblichen Kosten verbunden sein (Adressraumwechsel, FPU-Kontextwechsel) Betriebssysteme, WS 2013/14 wk Zusammenfassung

91 2.4 Privilegierungsebenen Situation Anwendungsprozesse und BS nutzen gemeinsame Ressourcen Raum BS AP AP BS AP AP Zeit Problem Schutz vor fehlerbedingten oder bösartigen Wechselwirkungen Lösung Isolation durch Arbeitsspeicherbelegung Speicherzugriffsschutzmechanismen Privilegierungsebenen Betriebssysteme, WS 2013/14 wk Prozessorbelegung 2.4 Privilegierungsebenen

92 Schutz von Arbeitsspeicherbereichen Isolation (Code, Datenstrukturen) von Betriebssystem und Anwendungsprozessen Isolation von Anwendungsprozessen untereinander Schutzmechanismen des VMM, implementiert durch MMU ( Kap. 3) Schutz kritischer (privilegierter) Prozessorinstruktionen Anhalten des Prozessors, Setzen von Interruptsperren Definition des Arbeitsspeicher-Layouts (Zugriff auf MMU) Verändern kritischer Prozessorregister Zugriff auf E/A-Controller Schutzmechanismen implementiert durch Privilegierungsebenen Betriebssysteme, WS 2013/14 wk Privilegierungsebenen

93 Privilegierungsebenen der Intel x86-architektur Ring 0: höchste Privilegien, sämtliche Prozessorinstruktionen erlaubt Ebene der BS-Software (je nach BS-Architektur mehr oder weniger umfangreich) Mikrokernarchitekturen: nur Mikrokern monolithische Architekturen: gesamte BS-Software Ring 3: keine privilegierten Prozessorinstruktionen erlaubt Ebene der Anwendungsprozesse Ring 1, 2: Auswahl privilegierter Prozessorinstruktionen erlaubt Mikrokernarchitekturen: E/A-Subsysteme: Zugriff auf E/A-Controller Speichermanagement: Zugriff auf MMU monolithische Architekturen: selten genutzt Betriebssysteme, WS 2013/14 wk Privilegierungsebenen

94 Verwendungsbeispiele Linux, Windows Ring 3 Ring 2 Ring 1 Anwendungsprozesse unbenutzt unbenutzt Ring 0 BS Betriebssysteme, WS 2013/14 wk Privilegierungsebenen

95 Verwendungsbeispiele Virtualisierungen Ring 3 Ring 2 Ring 1 Ring 0 Anwendungsprozesse unbenutzt BS Hypervisor Betriebssysteme, WS 2013/14 wk Privilegierungsebenen

96 Verwendungsbeispiele Mikrokernarchitekturen Ring 3 Ring 2 Ring 1 Ring 0 BS-Komponenten, Anwendungsprozesse E/A-System vertrauenswürdige BS-Komponenten Mikrokern Betriebssysteme, WS 2013/14 wk Privilegierungsebenen

97 HW-Unterstützung aktuelle Privilegierungsebene ist Teil des Prozessor-Statusregisters: Current Privilege Level (CPL) Grundlage der HW-Schutzmechanismen; permanente Überwachung der ausgeführten Instruktionen der Speicherzugriffe Modifikation des CPLs durch privilegierte Instruktionen bei Beginn und Abschluss des Aufrufs eines Systemdienstes ( 2.5.6) einer Unterbrechungsbehandlung ( 2.5.7) Betriebssysteme, WS 2013/14 wk Privilegierungsebenen

98 MSGs jeder auf Privilegierungsebene < 3 ablaufende Prozess hat Zugriff auf kritische Ressourcen jeder mit Ring-0-Privilegien ablaufende Prozess hat Zugriff auf sämtliche Ressourcen eines Prozessors sämtliche Instruktionen (z.b. HALT) sämtliche Prozessorregister (z.b. PSR) sämtliche Register der E/A-Peripherie (s. Kap. 6) MMU-Register zur Adressraum-Konfiguration (s. Kap. 3) Betriebssysteme, WS 2013/14 wk Privilegierungsebenen

99 Sämtliche Isolation von Anwendungsprozessen und Betriebssystem Anwendungsprozessen untereinander beruht elementar auf hardwareimplementierten Prozessor-Privilegierungsebenen hardwareimplementierten Speicherzugriffsschutzmechanismen Die Korrektheit der Implementierung und Nutzung dieser Mechanismen ist das Fundament! jeglicher Sicherheitseigenschaften von Betriebssystemen! Betriebssysteme, WS 2013/14 wk Privilegierungsebenen

100 Betriebssysteme, WS 2013/14 wk Kommunikation und Synchronisation 2.5 Kommunikation und Synchronisation Beispiel 1: Interaktionen zwischen BS-Komponenten GUI Office Google Earth MatLab ABS Firefox Anwendungsschnittstelle (Application Programmer s Interface, API) Betriebssystem-Dienste Prozessmanagement Dateimanagement Netzwerkmanagement Ressourcenmanagement Prozessor- Ressourcen Speicher- Ressourcen E/A Ressourcen E/A Ressourcen Kommunikations- Ressourcen

101 Betriebssysteme, WS 2013/14 wk Kommunikation und Synchronisation Dateimanagement Dateimanagement Dateimanagement VMM HDD.putJob( ) Gerätemanager-Interface HDD- Gerätemanager ( Treiber )

102 Betriebssysteme, WS 2013/14 wk Kommunikation und Synchronisation Beispiel 2: Interaktionen zwischen Anwendungsprozessen Codec, z.b. H.264 LiveStream Server API z.b. IEEE 1394 Firewire FWDD HDD NWDD z.b. WLAN FW-Karte Netzwerkkarte

103 Das Problem Codec forever do { sende(bild) } LiveStream Server forever do { empfange(bild) } Austausch von Daten zwischen Prozessen Kommunikation (Inter-Prozess-, IPC; z.b. sende/empfange ) Abweichende Geschwindigkeiten von Sender und Empfänger Synchronisation Betriebssysteme, WS 2013/14 wk Kommunikation und Synchronisation

104 Naiver Versuch Codec LiveStream Server forever do { pufferq.hinten:=bild } forever do { Bild:=pufferQ.vorne; } Codec- Thread Server- Thread Ganz so einfach geht es leider nicht Puffer voll Puffer leer Pufferelement in Benutzung Betriebssysteme, WS 2013/14 wk Kommunikation und Synchronisation

105 Betriebssysteme, WS 2013/14 wk Kommunikation und Synchronisation Problemfelder gleichzeitiges Lesen und Schreiben des selben Pufferelements: Konsistenz des gelesenen Bildes? Codec- Thread Server- Thread Operationen auf gemeinsamen Variablen (Pufferelemente) sind kritische Abschnitte erfordern wechselseitigen Ausschluss

106 Betriebssysteme, WS 2013/14 wk Kommunikation und Synchronisation unterschiedliche Geschwindigkeiten von Erzeuger und Verbraucher: Pufferüberlauf, Leere Codec- Thread Server- Thread Synchronisation relativer Geschwindigkeiten

107 Betriebssysteme, WS 2013/14 wk Kommunikation und Synchronisation Kritische Abschnitte und wechselseitiger Ausschluss Definition Es gibt Ressourcen, die als ganzes oder bzgl. einzelner Operationen nur exklusiv, d.h. zu einem Zeitpunkt nur durch einen einzigen Thread nutzbar sind. Eine Phase, in der ein Thread eine exklusive Operation auf einer Ressource ausführt, heißt kritischer Abschnitt. Kritische Abschnitte erfordern den wechselseitigen Ausschluss konkurrierender Threads.

108 Betriebssysteme, WS 2013/14 wk Kommunikation und Synchronisation Problemdefinition Annahmen konkurrierende Threads arbeiten asynchron, z.b. in einer unendlichen Schleife dabei betreten und verlassen sie irgendwann einen kritischen Abschnitt Betreten und Verlassen dieses Abschnitts wird durch Algorithmen organisiert, die den kritischen Abschnitt einklammern (Entry/Exit-Code) beliebiger beliebiger Code Code beliebiger Code Entry-Code Entry-Code Entry-Code kritischer Abschnitt Exit-Code Exit-Code Exit-Code beliebiger beliebiger Code Code beliebiger Code

109 Betriebssysteme, WS 2013/14 wk Kommunikation und Synchronisation Algorithmen zum wechselseitigen Ausschluss Allgemeine Anforderungen Korrektheit: In einem kritischen Abschnitt befindet sich zu jedem Zeitpunkt höchstens ein Thread (wechselseitiger Ausschluss) Lebendigkeit: Falls ein Thread einen kritischen Abschnitt betreten möchte, dann betritt (irgendwann) (irgend)ein Thread diesen Abschnitt Verhungerungsfreiheit: Kein Thread wartet für immer vor einem kritischen Abschnitt

110 Betriebssysteme, WS 2013/14 wk Kommunikation und Synchronisation Wechselseitiger Ausschluss - ein erster (naiver) Versuch Szenario Codec- Thread Server- Thread (Vereinfachung: Pufferkapazität = 1 Bild) 2 parallele Aktivitäten 1 exklusiv nutzbare Ressource kritische Abschnitte: schreiben und lesen Idee während Benutzung des Puffers wird dieser als busy markiert bei Vorfinden eines benutzten Puffers wird gewartet

111 Wechselseitiger Ausschluss - ein erster (naiver) Versuch Szenario Codec- Thread Server- Thread (Vereinfachung: Pufferkapazität = 1 Bild) also: Entry Code (Belegen des kritischen Abschnitts): if bufferbusy then await(not bufferbusy) *) ; bufferbusy := true; Exit-Code (Freigeben des kritischen Abschnitts): bufferbusy := false; beliebiger Code Entry-Code kritischer Abschnitt Exit-Code *) await(condition) z.b. implementiert durch busy waiting : loop until condition Betriebssysteme, WS 2013/14 wk beliebiger Code 2.5 Kommunikation und Synchronisation

112 Writer- Thread bufferbusy Reader- Thread Writer-Thread (Codec): Reader-Thread (Server): forever do { forever do { if bufferbusy then await(not bufferbusy); codepicfromcamerastream(pic); bufferbusy := true; if bufferbusy then await(not bufferbusy); read(buffer, pic); bufferbusy := true; bufferbusy := false; write(buffer, pic); sendtosomeclient(pic); bufferbusy := false; } } Korrektheit: parallele Ausführung der Threads bei ; Ursache: Race Conditions Lebendigkeit: viel zu sehr... Verhungern: z.b. bei Pseudoparallelität lediglich Problemverlagerung: kritischer Zugriff nun auf bufferbusy Betriebssysteme, WS 2013/14 wk Kommunikation und Synchronisation

113 Betriebssysteme, WS 2013/14 wk Kommunikation und Synchronisation Was tun? 2 Probleme dieses naiven Synchronisationsversuchs Korrektheit (wechselseitiger Ausschluss) Problemursache: zwischen Testen der Bedingung und Reaktion auf Ergebnis ändert paralleler Thread die Bedingung (race) Lösungsidee: Atomarität (Ununterbrechbarkeit) von Codesequenzen herstellen: if not bufferbusy then bufferbusy:=true Verhungern Problemursache: (mindestens) einer der beteiligten Threads kommt nicht zum Zuge Lösungsidee: explizit für Abwechslung sorgen Lösungen: Synchronisations- und Kommunikationsmechanismen

114 Betriebssysteme, WS 2013/14 wk Kommunikation und Synchronisation Synchronisations- und Kommunikationsmechanismen Semaphore Operationen zur Einleitung und Beendigung kritischer Abschnitte KBegin; buffer:=pic; KEnd; Hoare sche Monitore abstrakte Datentypen mit wechselseitigem Ausschluss bei der Ausführung ihrer Operationen write(buffer,pic) { KBegin; buffer:=pic; KEnd; } Transaktionaler Speicher lockfreie Datenstrukturen transactionbegin; buffer:=pic; transactionend; Botschaften send(pic); Fernaufrufe write(pic);

115 Betriebssysteme, WS 2013/14 wk Semaphore (Binäre) Semaphore Dijkstra 1965 Idee: Flagge mit 2 Zuständen frei belegt mit 2 atomaren Operationen belegen: P(Semaphorname) ( Passeren ) freigeben: V(Semaphorname) ( Vriegeven ) Beispiel

116 Betriebssysteme, WS 2013/14 wk Semaphore (Binärer) Semaphor Abstrakter Datentyp mit 2 atomaren Operationen P, V belegen: P(Semaphorname) freigeben: V(Semaphorname) Zustand Anwendungsschnittstelle (Application Programmer s Interface, API) Betriebssystem-Dienste Prozessmanagement Dateimanagement Netzwerkmanagement Ressourcenmanagement Prozessor- Ressourcen Speicher- Ressourcen E/A Ressourcen E/A Ressourcen Kommunikations- Ressourcen Abstrakte Semantik P(semaphore s) wait until s.zustand = frei; s.zustand := belegt; V(semaphore s) s.zustand := frei;

117 Betriebssysteme, WS 2013/14 wk Semaphore Benutzung semaphore s; s=new(semaphore); P(s); <kritischer Abschnitt> V(s); } Regel dabei: sämtliche Nutzer des kritischen Abschnitts müssen dies tun

118 Nicht ganz einfach: Implementierung z.b. als Klasse, die Operationen P und V exportierend mit einer internen Aufrufer-Warteschlange waitq zwei Operationen atomicbegin und atomicend, die Ununterbrechbarkeit herstellen (s.u.) P(semaphore s) { } atomicbegin(); if (s.state==busy) { s.waitq.enter(caller); suspend(caller); } s.state=busy; atomicend(); V(semaphore s) { } atomicbegin(); s.state=not busy; continue(s.waitq.leave()); atomicend(); Betriebssysteme, WS 2013/14 wk Semaphore

119 Nutzung auf Anwendungsebene genutzt von multi-threaded Anwendungen (Webserver, PowerPoint, etc.) implementiert durch Systemaufrufe und (Thread)Bibliotheken Quelle Senke Nutzung auf BS-Ebene genutzt von allen nebenläufigen Komponenten Dateimanagement implementiert durch BS selbst im Maschinenraum: atomicbegin(), atomicend() HDD- Gerätemanager VMM Betriebssysteme, WS 2013/14 wk Semaphore

120 Unterstützung durch Hardware: die TSL-Operation Ununterbrechbarkeit Ausschluss paralleler Ausführung Betriebssysteme, WS 2013/14 wk Implementierung von atomicbegin/end TestAndSetLock ( TSL ) im Instruktionssatz eines Prozessors Im Maschinenraum testen des Inhalts einer Speicherzelle, ergebnisabhängig Wert hineinschreiben TSL busy, int if (busy==0) busy=int atomicbegin(s): TSL s.state, callingthread.id CMP s.state, callingthread.id JZE gotit CALL scheduler.yield JMP atomicbegin gotit: RET try to get lock did I get it? yes optional, mandatory in monocores: give up processor try again got it, may enter critical region Multicorearchitekturen Synchronisation von Threads mit gemeinsamen Adressraum Synchronisation von Threads ohne gemeinsamen Adressraum (Prozesse, MParchitekturen mit individuellem Speicher je Prozessor) cave: allen Aufrufern gemeinsamer Speicher notwendig Semaphore

121 1. Problem: Konsistenz des gelesenen Bildes Benutzung von Semaphoren Zurück zu unserem Synchronisationsproblem Codec- Thread Semaphor bufferbusy Server- Thread Writer-Thread: forever do { codepicfromcamerastream(pic); P(bufferBusy); write(buffer,pic); V(bufferBusy); } Reader-Thread forever do { P(bufferBusy); read(buffer,pic); V(bufferBusy); sendtosomeclient(pic); } wechselseitiger Ausschluss ungelöst: Geschwindigkeitsdifferenz bei endlichem Puffer schneller Writer-Thread findet vollen Puffer vor schneller Reader-Thread liest aus noch leerem Puffer Betriebssysteme, WS 2013/14 wk Semaphore

122 2. Problem: Geschwindigkeitsdifferenz (bei einelementigem Puffer) Codec- Thread bufferbusy bufferfull buffermt Server- Thread wechselseitiger Ausschluss Writer-Thread: forever do { codepicfromcamerastream(pic); } P(bufferMt); P(bufferBusy); write(buffer,pic); V(bufferBusy); V(bufferFull); Reader-Thread forever do { } P(bufferFull); P(bufferBusy); read(buffer,pic); V(bufferBusy); V(bufferMt); sendtosomeclient(pic); Schutz vor Puffer- Über/Unterlauf Betriebssysteme, WS 2013/14 wk Semaphore

123 2. Problem: Geschwindigkeitsdifferenz (bei mehrelementigem Puffer) Codec- Thread bufferbusy bufferfull = 0 buffermt = 4 Server- Thread Writer-Thread: forever do { codepicfromcamerastream(pic); } Down(bufferMt); P(bufferBusy); write(buffer,pic); V(bufferBusy); Up(bufferFull); Reader-Thread forever do { } Down(bufferFull); P(bufferBusy); read(buffer,pic); V(bufferBusy); Up(bufferMt); sendtosomeclient(pic); Betriebssysteme, WS 2013/14 wk Semaphore

124 Betriebssysteme, WS 2013/14 wk Semaphore Wertung Semaphore lösen 2 elementare Probleme wechselseitiger Ausschluss Synchronisation unterschiedlicher Geschwindigkeiten Synchronisation durch aktives Warten oder Suspendierung i.v mit Thread-Warteschlangen sind softwaretechnisch problematisch in größeren Systemen: Synchronisationsoperationen (P und V) stehen im Code dort, wo Zugriffsoperationen (read/write) stehen also verteilt im Programmtext sämtlicher zugreifender Threads insbesondere also getrennt von den synchronisierten Daten Korrektheitsproblem: die unabdingbare Vollständigkeit Symmetrie der P- und V-Operationen ist schwierig erreichbar und nachweisbar

125 Betriebssysteme, WS 2013/14 wk Hoare sche Monitore Hoare sche Monitore Charles Antony Richard Hoare Die Idee Nutzung des Prinzips der Datenabstraktion Sie kennen dies bereits aus der Mathematik: Algebren; Assoziationen von Grundmengen und Operationen als Konzept in Programmiersprachen: z.b. C++ - Klassen: Zusammenfassung und Kapselung von Daten darauf definierten Operationen/Methoden

126 Betriebssysteme, WS 2013/14 wk Hoare sche Monitore Hoare sche Monitore legen noch eins drauf: Zusammenfassung von Daten darauf definierten Operationen/Methoden Synchronisation zu einem abstrakten Datentyp, dessen Operationen jeweils kritische Abschnitte darstellen wechselseitiger Ausschluss der Operationen eines Datentyps Zugriff auf Daten ausschließlich über automatisch synchronisierende Operationen

127 Betriebssysteme, WS 2013/14 wk Hoare sche Monitore Also statt so... Writer-Thread P(bufferBusy); write(buffer,pic); V(bufferBusy); Reader-Thread P(bufferBusy); read(buffer,pic); V(bufferBusy); buffer

128 Betriebssysteme, WS 2013/14 wk Hoare sche Monitore... so: Writer-Thread Reader-Thread Puffer.write(buffer,pic); Puffer.read(buffer,pic); Monitor class Puffer { } buffer public: void write(buffer,pic) void read(buffer,pic) Aufrufer will und muss nicht wissen ob Synchronisation nötig ist mit welchen Mechanismen dies erfolgen muss welche Regeln dabei gelten

129 Betriebssysteme, WS 2013/14 wk Hoare sche Monitore Ziel der Regeln Monitor-Synchronisationsregeln Wechselseitiger Ausschlusses der Monitoroperationen: zu jedem Zeitpunkt ist höchstens ein Thread in einem Monitor aktiv Teil 1 1. jede Monitoroperation ist am Eingang und an den Ausgängen durch einen Türsteher gesichert 2. das Betreten des Monitors erfolgt nur mit dessen Zustimmung ( Anklopfen ) 3. falls bereits ein anderer Thread im Monitor aktiv ist, wird die Zustimmung verweigert und der anklopfende Thread suspendiert ( P-Operation) 4. wenn ein Thread den Monitor verlässt, wird ein wartender Thread eingelassen (fortgesetzt, V-Operation)

130 Betriebssysteme, WS 2013/14 wk Hoare sche Monitore Implementierung der Regeln je Monitor ein Semaphor jede Operation eines Monitors enthält am Eingang eine P-Operation an jedem Ausgang eine V-Operation auf diesen Semaphor

131 Betriebssysteme, WS 2013/14 wk Hoare sche Monitore Benutzung von Monitoren Manchmal integriert in Programmiersprache Programmiersprache kennt den Typ Monitor Modula-3, Concurrent Pascal Monitor-Klassenoperation werden automatisch durch P- und V- Operationen geklammert (Compiler) Vollständigkeit und Symmetrie der Synchronisationsoperationen durch Compiler garantiert CLASS Puffer = Monitor { } VAR buffer; PROCEDURE ENTRY write( ) BEGIN END;

132 Betriebssysteme, WS 2013/14 wk Hoare sche Monitore Benutzung von Monitoren Oft aber auch schwache Integration: Java, class Monitor aus dem thread-package class Puffer extends Monitor { } manuelle Integration von enter()/leave()-operationen, fehleranfällig verwandt: synchronized-methoden (wechselseitiger Ausschluss) synchronized write(pic) { }

133 Betriebssysteme, WS 2013/14 wk Hoare sche Monitore Bedingungsvariable (Conditions) Geschwindigkeitsdifferenz bei endlichem Puffer Quelle (Writer): forever do { if Puffer voll warte auf (Puffer nicht voll); if Puffer leer signalisiere (Puffer nicht leer); schreibe Bild; } Senke (Reader): forever do { if Puffer leer warte auf (Puffer nicht leer); if Puffer voll signalisiere (Puffer nicht voll); lese Bild; } Bedingungsvariable Puffer nicht voll, Puffer nicht leer mit 2 Operationen: Warten auf das Vorliegen von Bedingungen ( Puffer nicht voll ) Signalisieren des Vorliegens von Bedingungen Monitore mit Bedingungsvariablen (vgl. Semaphore: buffermt, bufferfull)

134 Betriebssysteme, WS 2013/14 wk Hoare sche Monitore Ziel Monitor-Synchronisationsregeln Wechselseitiger Ausschluss und Geschwindigkeitsanpassung 1. jede Monitoroperation ist am Eingang und den Ausgängen durch einen Türsteher gesichert 2. das Betreten des Monitors erfolgt nur mit dessen Zustimmung ( Anklopfen ) 3. falls bereits ein anderer Thread im Monitor aktiv ist, wird die Zustimmung verweigert und der anklopfende Thread suspendiert ( P-Operation) 4. wenn ein Thread den Monitor verlässt, wird ein wartender Thread eingelassen (fortgesetzt, V-Operation) 5. gerät ein Thread innerhalb einer Monitoroperation in eine Wartesituation (warten auf Bedingungsvariable), so verlässt er den Monitor 6. bevor ein auf eine Bedingung wartender Thread fortgesetzt wird, muss er den Monitor wieder betreten Teil 2

135 Betriebssysteme, WS 2013/14 wk Hoare sche Monitore Implementierung der Bedingungsvariablen je Bedingungsvariable ein Semaphor (mit seiner Warteschlange) wait-operation eines Monitors P-Operation des Semaphores signal-operation eines Monitors V-Operation des Semaphores

136 Betriebssysteme, WS 2013/14 wk Hoare sche Monitore Benutzung von Bedingungsvariablen Oft integriert in Programmiersprache Programmiersprache kennt den Typ Monitor den Typ Bedingungsvariable die Operationen wait und signal Datenstrukturen für Bedingungsvariablen durch Compiler automatisch generiert wait und signal im Laufzeitsystem der Sprache implementiert z.b. Java: class Condition mit Methoden await() und signal() class Puffer extends Monitor { } Condition nonfull= new Condition(); nonfull.await();

137 Betriebssysteme, WS 2013/14 wk Hoare sche Monitore Das allgemeine Erzeuger/Verbraucher-Problem Producer/Consumer, Reader/Writer, Bounded Buffer Erzeuger: forever do { erzeuge(i); buffer.write(i); }; Codec monitor class buffer { int count=0, n=10, buffer[1..n]; condition nonfull, nonmt; Server Verbraucher: forever do { i=buffer.read(); verbrauche(i); }; } void write(int i) { if (count == n) then wait(nonfull); if (count == 0) then signal(nonmt); count = count +1; buffer[count]=i; }; int read() { if (count == 0) then wait(nonmt); if (count == n) then signal(nonfull); count = count-1; return(buffer[count+1]); }

138 Betriebssysteme, WS 2013/14 wk Hoare sche Monitore Beispiel zeigt Lösung 2er Aspekte der Synchronisation wechselseitiger Ausschluss der Zugriffe auf gemeinsame Daten ( buffer ) durch wechselseitigen Ausschluss von Monitoroperationen kurzzeitiges Ausbremsen Anpassung unterschiedlicher Geschwindigkeiten von Erzeuger und Verbraucher durch Warten auf und Signalisieren von Bedingungen (nonfull, nonmt) längerfristiges Ausbremsen

139 Betriebssysteme, WS 2013/14 wk Hoare sche Monitore Anmerkungen zu Semaphoren und Hoare schen Monitoren Methoden und Techniken gelten allgemein, d.h. für Threads und Prozesse innerhalb eines BS Threads innerhalb eines Anwendungsprozesses Anwendungsprozesse untereinander (cave! Gemeinsamer Speicher!) BSe implementieren derartige Synchronisationsmechanismen selber Anwendungsprozesse nutzen Bibliotheken oder BS-Dienste, z.b. Semaphore über Systemdienste (z.b. Unix): semop, semctl, semget Threadbibliotheken: pthread_cond_wait, pthread_cond_signal, pthread_mutex_lock, pthread_mutex_unlock Monitore Java-Klassenbibliotheken (thread-package) Systemimplementierungssprachen wie Concurrent Pascal, Modula-3

140 Betriebssysteme, WS 2013/14 wk Transaktionaler Speicher Transaktionaler Speicher Im Grunde ein alter Bekannter Codec- Thread Server- Thread Kommunikation mittels gemeinsamen Speicher Synchronisation zwecks wechselseitigem Ausschluss Geschwindigkeitsanpassung Damit haben wir heute vermehrt ein Problem: Performanz

141 Betriebssysteme, WS 2013/14 wk Transaktionaler Speicher Performanz Lange Zeit war Performanz sehr bequem wachsende Systemleistung durch wachsende CPU-Geschwindigkeit und interne Parallelität Erhöhung der Taktfrequenz Pipelining: Zerlegung und parallele Abarbeitung einzelner Maschineninstruktionen Hyperthreading: parallele Maschineninstruktions- und Datenstromverarbeitung spekulative Ausführung auf Maschineninstruktionsebene für Anwendungs- und BS-Software weitgehend unsichtbar sequenzielle Programmierparadigmen ausreichend

142 Betriebssysteme, WS 2013/14 wk Transaktionaler Speicher Ära ist beendet physikalische Aspekte der Energieverteilung/Wärmeableitung auf Chip Limitierung der Steigerung der Taktfrequenz logische Aspekte der Instruktionsausführung Limitierung spekulativer Ausführung und Instruktionsparallelität Leistungssteigerung durch Paradigmenwechsel der Prozessorarchitektur: Multicores Paradigmenwechsel der Software: parallele/verteilte Algorithmen + Parallelität + Kommunikation + Synchronisation Kommunikations- und Synchronisationsmodelle erhalten Schlüsselpositionen

143 Betriebssysteme, WS 2013/14 wk Transaktionaler Speicher Unglücklicherweise Kommunikation mittels gemeinsamen Speicher zwar sehr schnell Synchronisation mittels wechselseitigem Ausschluss jedoch stark Parallelität limitierend Alternatives K&S-Paradigma: Transaktionaler Speicher Kommunikation mittels gemeinsamen Speicher Synchronisationskonzept transaktionaler Systeme Programmierparadigma hier Modellierung Kommunikationsmodelle Realisierung Kommunikationsmodelle

144 Betriebssysteme, WS 2013/14 wk Transaktionaler Speicher Die Idee Semaphore, Monitore blockierende Synchronisationsmechanismen Jobs der Programmierer Identifikation kritischer Abschnitte Korrektheit: race conditions (zu wenig Synchronisation) Verklemmungen (zu viel Synchronisation) Fairness Grad der Parallelität (z.b. Zugriffsmuster (lesen/schreiben), lang/kurz ) Transaktionaler Speicher sperrenfreier Synchronisationsmechanismus Job der Programmierer Identifikation kritischer Abschnitte Synchronisationsmechanismus erledigt den Rest: Korrektheit, Verklemmungen, Fairness, Grad der Parallelität

145 Betriebssysteme, WS 2013/14 wk Transaktionaler Speicher Plakativ Transaktionaler Speicher Leichtgewichtstransaktionen (ACID) für parallele Aktivitäten (Threads) mit gemeinsamen Adressraum Programmierparadigma Parallele Aktivitäten (Threads/Prozesse), die gemeinsame Speicherobjekte mit transaktionaler Zugriffssemantik nutzen ACID = atomicity, consistency, isolation, durability

146 Transaktionale Operationssemantik Atomarität Durch Operationsfolgen in Transaktionen bewirkte Zustandsänderungen sind aus Sicht paralleler Transaktionen unteilbar und konsistent alles oder nichts Konsistenz Unbeobachtbarkeit von Zwischenergebnissen halb gefüllte Puffer, inkonsistente Listenverzeigerung Isolation Parallele Transaktionen beeinflussen sich gegenseitig nicht wechselseitiger Ausschluss Betriebssysteme, WS 2013/14 wk Transaktionaler Speicher

147 Betriebssysteme, WS 2013/14 wk Transaktionaler Speicher Benutzung von Transaktionen Writer-Thread: forever do { readcamerastream(pic); begintransaction(); count := count +1; buffer[count] := pic; endtransaction(); } Reader-Thread forever do { begintransaction(); count := count-1; pic := buffer[count+1]; endtransaction(); sendtosomeclient(pic); } Entry-Code kritischer Abschnitt Exit-Code ohne Sperren maximale Parallelität keine races: Korrektheit keine Verklemmungen: Lebendigkeit konsistente Sichten keine Zwischenzustände

148 Betriebssysteme, WS 2013/14 wk Transaktionaler Speicher Messages Kommunikation und Synchronisation in parallelen Algorithmen sperrende Synchronisationsmechanismen erweisen sich bei wachsender Parallelität als Performanzengpass transaktionaler Speicher Kommunikation über gemeinsamen Speicher sperrenfreie (c.g.s.) Synchronisation Automatisierung der Synchronisation maximale Parallelität, Korrektheit und Lebendigkeit Implementierung: Hardware (begintransaction, endtransaction) Programmierparadigma mit kräftigen Erleichterungen für Programmierer paralleler Algorithmen Beseitigung von Performanzengpässen

149 Allerdings TS ist kein universelles Synchronisationsparadigma zwar wechselseitiger Ausschluss aber keine Synchronisation unterschiedlicher Geschwindigkeiten Signalisierung aus Transaktion per def. nicht außerhalb sichtbar Stand der Kunst: frisch Vorschläge zur Programmiermodellbildung zahlreiche experimentelle HW (+ SW) -Implementierungen mehr im Sommer (Kommunikationsmodelle) Betriebssysteme, WS 2013/14 wk Transaktionaler Speicher

150 Betriebssysteme, WS 2013/14 wk Botschaften Botschaften Wir haben bisher kennen gelernt Kommunikation paralleler Aktivitäten über gemeinsamen Speicher Synchronisation dabei durch Semaphore, Monitore, transaktionalen Speicher Alle Mechanismen setzen voraus gemeinsamen Speicher für den Datenaustausch die Implementierung der Synchronisationsmechanismen K&S zwischen unterschiedlichen Rechnern lose gekoppelten MP-Architekturen Threads mit disjunkten Adressräumen ein hierfür geeignetes Kommunikationsparadigma muss her

151 Betriebssysteme, WS 2013/14 wk Botschaften Die Idee Codec- Prozess Fileserver Betriebssystem

152 Die Idee Codec- Prozess Fileserver Betriebssystem Betriebssystem Codec-Prozess: forever do { codepicfromcamerastream(pic); send(fileserver, pic); } Fileserver: forever do { receive(pic); SomeFile.write(pic); } Betriebssysteme, WS 2013/14 wk Botschaften

153 Betriebssysteme, WS 2013/14 wk Botschaften 2 elementare Operationen Senden einer Botschaft an einen Empfänger Botschaftenbasierte Kommunikation send(in Empfänger, IN Botschaft) Empfangen einer Botschaft von einem Absender receive(out Absender, OUT Botschaft)

154 Betriebssysteme, WS 2013/14 wk Botschaften Eigenschaften zahlreiche Varianten ( Kommunikationsmodelle, send/receive-modell), z.b. bzgl. Verlässlichkeit garantielos gelbe Post: reguläre Briefe UDP/IP-Pakete mit Zustellungsgarantien gelbe Post: Einschreiben mit Rückschein TCP/IP-Botschaften Synchronität synchrones Senden/Empfangen; z.b. Klient/Server-Kommunikation asynchrones Senden/Empfangen; z.b. gelbe Post

155 Betriebssysteme, WS 2013/14 wk Botschaften Synchrone (blockierende) Sende-Operationen Sender wartet, bis Empfänger die Botschaft annimmt Sender Empfänger synchrones Senden, Empfänger wartet bereits receive Empfangsquittung synchrones Senden, Empfänger wartet noch nicht Empfangsquittung receive Zeit Ankunft einer Botschaft ist garantiert einfache Programmierung synchroner Aktivitäten (z.b. codec-prozess, Serveraufruf) unbekannte Verzögerungszeit, während der der Sender nicht weiterkommt

156 Asynchrone Sende-Operationen Sender wartet nicht, bis Empfänger die Botschaft annimmt Sender Empfänger asynchrones Senden, Empfänger wartet bereits receive keine Verzögerung asynchrones Senden, Empfänger wartet noch nicht receive keine Verzögerung, keine Quittung geringere Kosten einfache Programmierung von Nebenläufigkeit programmiertechnische Ebene: unklar, wann Botschaftenpuffer wiederverwendbar logische Ebene: unklar, ob und wann Botschaft zugestellt ist Betriebssysteme, WS 2013/14 wk Botschaften

157 Betriebssysteme, WS 2013/14 wk Botschaften Synchrone (blockierende) Empfangs-Operationen Empfänger wird aufgehalten, bis Botschaft eintrifft Sender Empfänger send synchrones Empfangen, noch keine Botschaft eingetroffen send synchrones Empfangen, Botschaft bereits eingetroffen Botschaftenankunft präzise feststellbar einfache Programmierung synchroner Aktivitäten (z.b. in (File)Server) unbekannte Verzögerungszeit, während der der Empfänger nicht weiterkommt

158 Asynchrone (nicht blockierende) Empfangs-Operationen Empfänger macht weiter, falls keine Botschaft eingetroffen ist Sender Empfänger send asynchrones Empfangen, noch keine Botschaft eingetroffen send asynchrones Empfangen, Botschaft bereits eingetroffen einfache Programmierung von Nebenläufigkeit unklar, wann Botschaft da ist Benachrichtigungstechniken: explizite Warteoperation öfters nachfragen (Polling), asynchrone Unterbrechung durch Ereignismeldung, s.u. eintreffende Botschaft erzeugt Thread Betriebssysteme, WS 2013/14 wk Botschaften

159 Betriebssysteme, WS 2013/14 wk Botschaften Implementierung für Anwendungsebene: durch BS sockets (universell), message queues (Linux) für BS selbst hocheffiziente IPC-Mechanismen im Maschinenraum (Mikrokernarchitekturen) nicht-lokal: Kommunikationsprotokolle nutzend (verteilte Betriebssysteme)

160 Betriebssysteme, WS 2013/14 wk Botschaften Messages send/receive-operationen Kommunikation und Synchronisation ohne gemeinsamen Speicher BSe implementieren diese Mechanismen benutzt von Betriebssystemen selbst Rechnergrenzen überschreitende Kommunikation mikrokernbasierte (multi-adressraum-) BSe Anwendungsprozessen über BS-Dienstaufrufe ( Übungen) Linux: die msg -Gruppe für lokale IPC: msgget, msgsnd, msgrcv sockets, standardisierter globaler Kommunikationsmechanismus zahlreiche Varianten synchron/asynchron verlässlich/unverlässlich Grundlage der Implementierung vieler anwendungsnaher Kommunikationsmechanismen

161 Betriebssysteme, WS 2013/14 wk Fernaufrufe Fernaufrufe (Remote Procedure Calls, RPCs) Ziel wie Botschaften: K&S ohne Voraussetzung gemeinsamen Speichers aber: problemorientiert, weniger systemnah Weg Adaption eines anwendungsnahen, unkomplizierten und vertrauten Kommunikationsmodells an die Eigenschaften verteilter Systeme Idee Verallgemeinerung des Prozeduraufrufs: Prozedurfernaufrufe (Remote Procedure Call, RPC) Methodenaufrufs: Methodenfernaufrufe (Remote Method Invocation, RMI)

162 Betriebssysteme, WS 2013/14 wk Fernaufrufe Wo finden wir RPCs/RMIs? Kommunikation zwischen Computern mit Netzwerk-Betriebssystemen verteilte Dateisysteme (Sun Network File System (NFS)) Zeitserver (NTP) Namendienste (DNS) Kommunikation zwischen Betriebssystemkomponenten in Mikrokernarchitekturen Interaktionen von Prozess- und Dateisystem aber auch: Kommunikation zwischen Komponenten verteilter Anwendungssysteme (CORBA, Java-VM) Finanz- und Versicherungswirtschaft (Sicherheitsinfrastrukturen) Telemetriesysteme (Raumfahrt) Telekommunikationssysteme (Vermittlungssysteme) Echtzeitsysteme (Produktionsanlagensteuerung) eingebettete Systeme (Fahrzeugsteuerung)

163 Betriebssysteme, WS 2013/14 wk Fernaufrufe Szenario Beispiel 1 Kommunikation zwischen Computern mit Netzwerk-Betriebssystemen Unix-Systemfamilie vernetzt mittels LAN verteiltes Dateisystem: Sun Network File System (NFS) Kommunikationsmechanismus: Sun RPC Das Szenario physisch Fileserver

164 Betriebssysteme, WS 2013/14 wk Fernaufrufe Das Szenario logisch Zusammenkleben zunächst unabhängiger Filesysteme Klebestellen : mount-punkte was geschieht an einem Klebepunkt?

165 Softwarekomponenten des Szenarios Arbeitsplatzrechner- Betriebssystem Fileserver- Betriebssystem lokales NFS- RPC NFS- Dateisystem Klient Server Umlenkung mount blauserver.prakinf.tu-ilmenau.de:/home/blau /home Betriebssysteme, WS 2013/14 wk Fernaufrufe

166 Betriebssysteme, WS 2013/14 wk Fernaufrufe Beispiel 2 Betriebssysteme mit Kern-Architektur Grundidee dieser Architekturform elementare Betriebssystem-Funktionalität in sehr kleinem Betriebssystemkern ( Kern) typisch: Threads, Adressräume, IPC weniger elementare Aufgaben schwächer privilegiert ( reguläre Anwendungssysteme) API - Implementierung Prozess-Server Fileserver Prozessmanagement Netzwerkprotokolle VMM NetzwerkSvr Gerätetreiber Dateisystem VMM Kern: elementares PM, SM und IPC Hardware monolithische Schichtenarchitektur Hardware Kern-Architektur

167 Betriebssysteme, WS 2013/14 wk Fernaufrufe Folgen Isolation der BS-Komponenten Adaptivität (Auf- und Abskalierung der Systemfunktionalität) Robustheit (Fehlerisolation) IT-Sicherheit (TCB-Größe) Korrektheit (Verifizierbarkeit) Kommunikationskosten API - Implementierung Prozess-Server Fileserver Prozessmanagement Netzwerkprotokolle VMM NetzwerkSvr Gerätetreiber Dateisystem VMM Kern: elementares PM, SM und IPC Hardware monolithische Schichtenarchitektur Hardware Kern-Architektur

168 Betriebssysteme, WS 2013/14 wk Fernaufrufe Kommunikationskosten Prozeduraufruf monolithische Architektur: innerhalb eines Adressraums Prozedurfernaufruf Kern-Architektur: über Adressraumgrenzen hinweg API - Implementierung Prozess- Server Fileserver Prozessmanagement Netzwerkprotokolle VMM Netzwerk- Server Gerätetreiber Dateisystem VMM Kern Hardware Hardware

169 Betriebssysteme, WS 2013/14 wk Fernaufrufe Der Fernaufruf Idee also Verallgemeinerung des (lokalen) Prozeduraufrufs: Aufruf und Ausführung in unterschiedlichen Kontexten mindestens: Adressraumkontext aber auch Betriebssystemkontext, Programmiersprachenkontext, Hardwarekontext Prozess- Server Fileserver Aufrufer Ausführer VMM Netzwerk- Server Gerätetreiber Middleware Middleware Kern Betriebssystem Betriebssystem Hardware Kommunikationsmedium (LAN, MAN, WAN)

170 Betriebssysteme, WS 2013/14 wk Fernaufrufe Kommunikationsmuster des Fernaufrufs... Kontext des Aufrufers Kontext des Ausführers Aufrufer Ausführer Aufruf Kontextwechsel Kontextwechsel Rückkehr

171 Betriebssysteme, WS 2013/14 wk Fernaufrufe... und seine Implementierung durch ein botschaftenbasiertes Kommunikationsmodell RPC-Beschreibung Aufrufer Ausführer send(ausführer,call-msg) Aufruf Kontextwechsel receive(aufrufer,call-msg) receive(ausführer,reply-msg) Kontextwechsel Rückkehr send(aufrufer,reply-msg) receive(aufrufer,call-msg)

172 Betriebssysteme, WS 2013/14 wk Fernaufrufe Idealvorstellung Aufruf und Wirkung gleich der eines regulären Prozeduraufrufs insbesondere (gegenüber botschaftenbasierten Kommunikationsmodellen) Aufruftransparenz Typprüfung der Signatur beim Aufruf (Parameter, Funktionswert) Parameterübergabemanagement (z.b. Verpacken in Botschaft) Programmablaufsteuerung (z.b. synchrone receive-operation) Ortstransparenz Adressierung der ausführenden Instanz (z.b. DNS-Nutzung) Fehlertransparenz Fehlerbehandlung Kommunikation per Fernaufruf sehr viel bequemer weniger fehleranfällig Mechanismen nicht gerade billig

173 Betriebssysteme, WS 2013/14 wk Fernaufrufe Die 7 Plagen verteilter Systeme bei der Herstellung dieses Ideals unterschiedliche Programmiersprachen: Datentyprepräsentation, Stack- Layout separate Adressräume: Parameterübergabe, globale Variablen separate Prozesse: keine gemeinsame Ablaufsteuerung separate Hardware: kein gemeinsames Ausfallverhalten unterschiedliche Hardware: keine gemeinsame Datentyprepräsentation offene Kommunikationswege: IT-Sicherheit lange Kommunikationswege: Performanz, Rechtzeitigkeit

174 Betriebssysteme, WS 2013/14 wk Fernaufrufe Zahltag Das kostet! RPCs gibt es nicht umsonst: Lokalisierung, Parameter-Marshalling, Kontrollflusssteuerung, Fehlerbehandlung, Kontextumschaltung; Middleware, im Sommer Laufzeiten Zyklen PC Accent (1981) Mach (1986) V-Kernel (1986) Amoeba (1986) Taos (1990) Taos LRPC (1990) L4 (1997) leichtgewichtige RPC-Modelle, z.b. in Kern-Architekturen

175 Betriebssysteme, WS 2013/14 wk Systemaufrufe Systemaufrufe Problem BS stellt zahlreiche Dienste bereit (Linux 250); z.b. Prozesserzeugung (fork) Programmausführung (exec ) Dateimanagement (open, close, read, write) Kommunikation (msg, socket, shm ) In diesem Abschnitt: Aufrufmethoden und -mechanismen Ring 3 - Privilegien Prozeduraufruf++ Anwendungsprozess fork(),... Ring 0 - Privilegien BS-Dienste Betriebssystem-Schnittstelle (Application Programmer s Interface (API)) Prozessmgmt Dateisysteme Sockets...

176 Betriebssysteme, WS 2013/14 wk Systemaufrufe Methodische Überlegungen: geeignetes Aufrufmodell? Wunsch des Anwendungsentwicklers Bequemlichkeit Vertrautheit Performanz (hohe Aufruffrequenz, tausende pro Sekunde) Wunsch des BS-Entwicklers Sicherheit Robustheit reguläre Prozeduraufrufe erfüllen Kriterien nicht (unterschiedliche Addressräume, Privilegien, Programmiersprachen) Prozedurfernaufruf: bequem, vertraut, performant, sicher, robust viel zu teuer leichtgewichtiges RPC-Modell

177 Betriebssysteme, WS 2013/14 wk Systemaufrufe Ablauf eines Systemaufrufs Anwendungsebene Anwendungsprozess:... write(fd,buffer,nbytes);... libc: write(fd,buffer,nbytes) { push(nbytes); push(buffer); push(fd); push(write_c); TRAP; } Datensegment Codesegment write_c fd buffer nbytes User-SP Stacksegment Betriebssystem-Schnittstelle (Application Programmer s Interface (API)) Sys_write() { ParamArea=User-SP+4; fd=paramarea->fd; buffer=paramarea->buffer; nbytes=paramarea->nbytes; Betriebssystem struct { int fd; char* buffer; int nbytes } ParamArea; TRAP-Interruptbehandlung: switch User-SP-> case read_c: Sys_read() case write_c: Sys_write()

178 Betriebssysteme, WS 2013/14 wk Systemaufrufe Umgang mit den ersten 3 Plagen in diesem Szenario Unterschiedliche Programmiersprachen kein einheitliches Format der Aufrufparameter (Reihenfolge, Format) Lösung: normierte Parameterstruktur und Datentyprepräsentation zwischen Anwendungsprogramm und Betriebssystem definiert durch API-Spezifikation implementiert durch zwischengeschaltete Bibliothek (z.b. libc; Stellvertreter-Prozeduren, Urform heutiger Middleware-Stubs) libc: write(fd,buffer,nbytes) { push(nbytes); push(buffer); push(fd); push(write_c); TRAP; } write_c fd buffer nbytes

179 Betriebssysteme, WS 2013/14 wk Systemaufrufe Separate Namensräume Sys_write liegt nicht im Namensraum des Anwendungsprozesses Einigung auf Namenskonventionen ( push(write_c) ) Anwendungsprozess:... write(fd,buffer,nbytes)... libc, Code für write: push(nbytes); push(buffer); push(fd); push(write_c); TRAP; write_c fd buffer nbytes Sys_write() { ParamArea=User-SP+4; fd=paramarea->fd; buffer=paramarea->buffer; nbytes=paramarea->nbytes; TRAP-Interruptbehandlung: PAR=User-SP+4; switch PAR-> case read_c: Sys_read() case write_c: Sys_write()

180 Betriebssysteme, WS 2013/14 wk Systemaufrufe Separate Adressräume kein direkter Zugriff auf Parameter seitens der aufgerufenen Prozedur Parameter-Datenstruktur; Alternativen dabei: in Registern, in gemeinsamen Speicherbereich (Stack) write_c fd buffer nbytes Sys_write() { ParamArea=User-SP+4; fd=paramarea->fd; buffer=paramarea->buffer; nbytes=paramarea->nbytes; TRAP-Interruptbehandlung: PAR=User-SP+4; switch PAR-> case read_c: Sys_read() case write_c: Sys_write()

181 Betriebssysteme, WS 2013/14 wk Systemaufrufe Privilegienwechsel TRAP/RTT-Mechanismus (ReTurn from Trap): Interrupt Descriptor Table Anwendungsprozess:... write(fd,buffer,nbytes)... libc, Code für write: push(nbytes); push(buffer); push(fd); push(write_c); TRAP; write_c fd buffer nbytes Sys_write() { ParamArea=User-SP+4; fd=paramarea->fd; buffer=paramarea->buffer; nbytes=paramarea->nbytes; TRAP-Interruptbehandlung: PAR=User-SP+4; switch PAR-> case read_c: Sys_read() case write_c: Sys_write() RTT;

182 Betriebssysteme, WS 2013/14 wk Systemaufrufe Anmerkungen zur Performanz Sicherheit und Robustheit Gegenüber einfachem Prozeduraufruf entstehen Kosten durch Privilegienwechsel gering Kosten durch Parameteraufbereitung und -übergabe gering bei Übergabe in Registern Kosten durch Interrupt (TRAP/RTT) je 100 Taktzyklen (Kontextsicherung) Verlust der Möglichkeit der Sprungziel-Vorausberechnung Verlust sämtlicher spekulativer Ausführungen Optimierung (seit Pentium 2): SysEnter/SysExit Kosten gegenüber regulärem Prozeduraufruf ca. Faktor 2

183 2.5.7 Ereignismanagement Das Problem in Betriebssystemen laufen sehr viele Aktivitäten parallel ab Ausführung von Anwendungsprogrammen Reaktion auf Benutzereingaben Management von Prozessor-, Speicher-, Kommunikationsressourcen Bedienung der E/A-Peripherie dabei entstehen immer wieder Situationen, in denen auf unterschiedlichste Ereignisse reagiert werden muss Timerablauf Benutzereingaben (Maus, Tastatur) Eintreffen von Daten vom Netzwerk, der Festplatte Einlegen/stecken von Datenträgern Ereignismanagement quantitativ: kleines WindowsXP-System (Laptop), gestartete GUI jederzeit können ca. 400 verschiedene Ereignissen auftreten Betriebssysteme, WS 2013/14 wk Ereignismanagement

184 Umgangsformen busy waiting : Threads prüfen andauernd den Ereigniseintritt, d.h. warten aktiv kurze Reaktionszeit ineffiziente Prozessornutzung hoher Energieverbrauch akzeptabel bei bekannt kurzen Wartezeiten Multiprozessormaschinen, falls ausreichend freie Prozessoren vorhanden sind ausreichend Energie vorhanden ist Betriebssysteme, WS 2013/14 wk Ereignismanagement

185 Umgangsformen periodic testing : Threads prüfen hin und wieder den Ereigniseintritt je nach Prüfintervall fragliche Reaktionszeit fragliche Effizienz der Prozessornutzung akzeptabel bei relaxten Reaktionszeitanforderungen Interrupts : asynchroner Benachrichtigungsmechanismus durch Unterbrechung (interruption) der laufenden Aktivität das Telefon klingelt Betriebssysteme, WS 2013/14 wk Ereignismanagement

186 (Asynchrone) Unterbrechungen (Interrupts) Beispiel: Gerätemanagement ( Gerätetreiber, Device Driver) Gerätetreiber Startkommando an E/A-Gerät Zeit aktiven Wartens Fertigmeldung des E/A-Geräts Betriebssysteme, WS 2013/14 wk Ereignismanagement

187 (Asynchrone) Unterbrechungen (Interrupts) Beispiel: Gerätemanagement ( Gerätetreiber, Device Driver) beliebiger Thread Gerätetreiber Treadwechsel (Scheduling) Startkommando an E/A-Gerät gewonnene Prozessorzeit Zeit passiven Wartens Treadwechsel (Interrupt) Fertigmeldung des E/A-Geräts Zur Wirksamkeit dieser Technik Verhältnis Anzahl Festplattenoperationen zu CPU-Operationen, Laptop: ca. 1: Betriebssysteme, WS 2013/14 wk Ereignismanagement

Betriebssysteme Kap. 2: Nebenläufigkeit und Parallelität

Betriebssysteme Kap. 2: Nebenläufigkeit und Parallelität Betriebssysteme, WS 2014/15 wk - 1 - Betriebssysteme Kap. 2: Nebenläufigkeit und Parallelität Winfried E. Kühnhauser Wintersemester 2014/15 Winfried E. Kühnhauser CSI Technische Universität Ilmenau www.tu-ilmenau.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

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

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

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

Mehr

Ü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

Dämon-Prozesse ( deamon )

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

Mehr

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

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

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

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

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

Mehr

6.Vorlesung Betriebssysteme Hochschule Mannheim

6.Vorlesung Betriebssysteme Hochschule Mannheim Christian Baun 6.Vorlesung Betriebssysteme Hochschule Mannheim SS2011 1/40 6.Vorlesung Betriebssysteme Hochschule Mannheim Christian Baun Karlsruher Institut für Technologie Steinbuch Centre for Computing

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

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

Betriebssysteme Kap A: Grundlagen

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

Mehr

Betriebssysteme (BTS)

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

Mehr

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

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

Mehr

5 Speicherverwaltung. bs-5.1 1

5 Speicherverwaltung. bs-5.1 1 5 Speicherverwaltung bs-5.1 1 Pufferspeicher (cache) realer Speicher Primärspeicher/Arbeitsspeicher (memory) Sekundärspeicher/Hintergrundspeicher (backing store) (Tertiärspeicher/Archivspeicher) versus

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

Rechnerarchitektur und Betriebssysteme (CS201): Semaphor, Monitor, Deadlocks, Re-Entrance

Rechnerarchitektur und Betriebssysteme (CS201): Semaphor, Monitor, Deadlocks, Re-Entrance Rechnerarchitektur und Betriebssysteme (CS201): Semaphor, Monitor, Deadlocks, Re-Entrance 5. November 2013 Prof. Dr. Christian Tschudin Departement Mathematik und Informatik, Universität Basel Repetition

Mehr

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

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

Mehr

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

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

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

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

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

Architektur Verteilter Systeme Teil 6: Interprozess-Kommunikation

Architektur Verteilter Systeme Teil 6: Interprozess-Kommunikation Architektur Verteilter Systeme Teil 6: Interprozess-Kommunikation 09.05.15 1 Literatur [6-1] http://php.net/manual/de/book.sockets.php [6-2] http://de.wikipedia.org/wiki/socket_(software) [6-3] http://php.net/manual/de/book.network.php

Mehr

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

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

Mehr

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

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

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

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

CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik)

CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik) Prof. Dr. Th. Letschert CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik) Vorlesung 7 Th Letschert FH Gießen-Friedberg Ressourcen Verwaltung passive Ressourcen aktive Ressourcen

Mehr

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

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

Mehr

Zur Erinnerung: Threads. Threadverwaltung. Threads: Prioritäten. Beispiel Flugbuchungsprogramm. Nichtdeterminismus

Zur Erinnerung: Threads. Threadverwaltung. Threads: Prioritäten. Beispiel Flugbuchungsprogramm. Nichtdeterminismus Zur Erinnerung: Threads Programmierung (fortgeschrittene Konzepte) Threads, Monitore, Semaphore und speisende en Wolf-Ulrich Raffel (uli@wuraffel.de) Möglichkeiten, Threads zu definieren Bildung einer

Mehr

Betriebssysteme. Dipl.-Ing.(FH) Volker Schepper

Betriebssysteme. Dipl.-Ing.(FH) Volker Schepper 1. Der Prozess beginnt im Zustand Erzeugt, nachdem sein Vaterprozess den Systemaufruf fork() (s.u.) abgesetzt hat. In diesem Zustand wird der Prozess-Kontext initialisiert. 2. Ist diese Aufbauphase abgeschlossen,

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

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

Prozeß P1 Prozeß P2. Zur Synchronisation stehen den beiden Prozessen binäre Semaphore und die beiden Funktionen

Prozeß P1 Prozeß P2. Zur Synchronisation stehen den beiden Prozessen binäre Semaphore und die beiden Funktionen Seite 8 A UFGABE 11 INTERP ROZEßKOMMUNIKATION Das folgende Petrinetz zeigt zwei verkoppelte Prozesse P1 und P2. Die Transitionen a und b beschreiben Aktionen von P1, die Transitionen c und d Aktionen von

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

DBUS Interprozess-Kommunikation für Embedded-Plattformen

DBUS Interprozess-Kommunikation für Embedded-Plattformen DBUS Interprozess-Kommunikation für Embedded-Plattformen Andreas Schwarz Neratec Solutions AG Firmenprofil Neratec Solutions AG Produkt-Entwicklungen für kundenspezifische elektronische Produkte Produkte

Mehr

Inhaltsverzeichnis XII

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

Mehr

8. Vorlesung Betriebssysteme

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

Mehr

Kapitel 2: Betriebssysteme

Kapitel 2: Betriebssysteme LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS Skript zur Vorlesung: Einführung in die Informatik: Systeme und Anwendungen Sommersemester 2009 Vorlesung: Dr. Peer Kröger Übungen:

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

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

Quantitative Methoden. Betriebssysteme

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

Mehr

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

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

Mehr

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

C. Betriebssystem-Strukturen C.1 Monolithische Betriebssysteme

C. Betriebssystem-Strukturen C.1 Monolithische Betriebssysteme C. Betriebssystem-Strukturen C.1 Monolithische Betriebssysteme Sammlung von Routinen, ohne Hierarchie, Kapselung und Schichtung. Jede Prozedur kann beliebige andere Prozeduren aufrufen und Datenstrukturen

Mehr

Prozesse und Threads. Peter Puschner Institut für Technische Informatik peter@vmars.tuwien.ac.at

Prozesse und Threads. Peter Puschner Institut für Technische Informatik peter@vmars.tuwien.ac.at Prozesse und Threads Peter Puschner Institut für Technische Informatik peter@vmars.tuwien.ac.at 1 Ziel: Gleichzeitiges, kontrolliertes Ausführen von Programmen auf einem Rechner Welche Mechanismen sind

Mehr

5. Threads, Serverprozesse und Benachrichtigungen

5. Threads, Serverprozesse und Benachrichtigungen 5. Threads, Serverprozesse und Benachrichtigungen Threads allgemein Threads in Android: Handler und Messages Services: Local, Remote, Binding Benachrichtigungen Entwicklung mobiler Anwendungen Europäische

Mehr

TIMI: Technische Informatik für Medieninformatiker

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

Mehr

POSIX Echtzeit: Kernel 2.6 und Preempt-RT

POSIX Echtzeit: Kernel 2.6 und Preempt-RT POSIX Echtzeit: Kernel 2.6 und Preempt-RT Slide 1 - http://www.pengutronix.de - 21.01.2007 Echtzeit-Systemplanung Wenn das zeitliche Verhalten spezifiziert ist, kann auch spezifiziert werden, welche Applikationsteile

Mehr

2 Echtzeitbetriebssysteme

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

Mehr

Grundkurs Betriebssysteme

Grundkurs Betriebssysteme Grundkurs Betriebssysteme Architekturen, Betriebsmittelverwaltung, Synchronisation, Prozesskommunikation von Peter Mandl 3., akt. und erw. Aufl. 2013 Springer Vieweg Wiesbaden 2012 Verlag C.H. Beck im

Mehr

Übung zu Grundlagen der Betriebssysteme. 8. Übung 04.12.2012

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

Mehr

6. Tutorium zu Softwaretechnik I

6. Tutorium zu Softwaretechnik I 6. Tutorium zu Softwaretechnik I Parallelität und Testen Michael Hoff 01.07.2014 INSTITUT FÜR PROGRAMMSTRUKTUREN UND DATENORGANISATION KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum

Mehr

Technische Informa/k II

Technische Informa/k II Technische Informa/k II Prof. Dr. Bernd Freisleben Sommersemester 2013 Vorlesung zur Klausurvorbereitung Folie 00-2 Organisatorisches Klausur: Dienstag, 16.07.13, 12:00-14:00 Uhr im Hörsaal 00/0070 Zugelassene

Mehr

3. Unix Prozesse. Betriebssysteme Harald Kosch Seite 57

3. Unix Prozesse. Betriebssysteme Harald Kosch Seite 57 3. Unix Prozesse Ein Prozeß ist die Umgebung eines laufenden Programms. Ein bißchen Analogie. Wer kocht gerne? Papa möchte mit Hilfe eines Rezeptes eine Torte für seine Tochter backen. Das Rezept ist das

Mehr

Vorl. 6: Single- und Multitasking

Vorl. 6: Single- und Multitasking Universität Bielefeld Technische Fakultät AG Rechnernetze und verteilte Systeme Vorl. 6: Single- und Multitasking Peter B. Ladkin Single Tasking Command Interpreter (ComInt) läuft wartet auf Tastatur-Eingabe

Mehr

Beschreiben Sie stichwortartig, was die folgenden Kommandos bewirken.

Beschreiben Sie stichwortartig, was die folgenden Kommandos bewirken. Betriebssysteme: Auswahl alter Klausuraufgaben Seite 1 Beschreiben Sie stichwortartig, was die folgenden Kommandos bewirken. a) sort < MeineDatei.txt > MeineDateiSort.txt b) find / -type d \( -name man

Mehr

OSEKtime - Time-Triggered OSEK/OS

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

Mehr

leave: mov flag, 0 ; 0 in flag speichern: Lock freigeben ret

leave: mov flag, 0 ; 0 in flag speichern: Lock freigeben ret Sep 19 14:20:18 amd64 sshd[20494]: Accepted rsa for esser from ::ffff:87.234.201.207 port 61557 Sep 19 14:27:41 amd64 syslog-ng[7653]: STATS: dropped 0 Sep 20 01:00:01 amd64 /usr/sbin/cron[29278]: (root)

Mehr

Dynamische Skalierbarkeit

Dynamische Skalierbarkeit Alexander Eichhorn Verteilte Systeme und Betriebssysteme Technische Universität Ilmenau Frühjahrstreffen der GI Fachgruppe Betriebssysteme 30. Juni 2005 Koblenz Vortragsüberblick Teil 1 Teil 2 Teil 3 Begriffsbestimmungen

Mehr

6.6 Persistenter virtueller Speicher

6.6 Persistenter virtueller Speicher 6.6 Persistenter virtueller Speicher Idee: alle Segmente sind persistent Datei -Begriff überflüssig! Aber: Segment hat erweiterten Deskriptor. bs-6.6 1 Segment überdauert Tod des erzeugenden Prozesses,

Mehr

Betriebssysteme Kap F: CPU-Steuerung CPU-Scheduling

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

Mehr

Grundlagen der Informatik. Prof. Dr. Stefan Enderle NTA Isny

Grundlagen der Informatik. Prof. Dr. Stefan Enderle NTA Isny Grundlagen der Informatik Prof. Dr. Stefan Enderle NTA Isny 2 Datenstrukturen 2.1 Einführung Syntax: Definition einer formalen Grammatik, um Regeln einer formalen Sprache (Programmiersprache) festzulegen.

Mehr

Rapid I/O Toolkit. http://projects.spamt.net/riot. Alexander Bernauer alex@copton.net 08.12.08

Rapid I/O Toolkit. http://projects.spamt.net/riot. Alexander Bernauer alex@copton.net 08.12.08 Rapid I/O Toolkit http://projects.spamt.net/riot Alexander Bernauer alex@copton.net 08.12.08 Inhalt Motivation Architektur Beispiel I/O Features Ausblick Motivation Problemstellung Vorgaben Datenverarbeitung

Mehr

Kap. 2. Prozesse. Version vom 05.10.2009. Kap. 2 - Inhalt. Definition Prozeßzustände Threads Scheduling Beispiele. Folie 2

Kap. 2. Prozesse. Version vom 05.10.2009. Kap. 2 - Inhalt. Definition Prozeßzustände Threads Scheduling Beispiele. Folie 2 Kap. 2 Prozesse Version vom 05.10.2009 Kap. 2 - Inhalt Definition Prozeßzustände Threads Scheduling Beispiele Folie 2 Definition I - Woraus bestehen Prozesse? Prozeß ist ein Programm in seiner Ausführung,

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

Projekt für Systemprogrammierung WS 06/07

Projekt für Systemprogrammierung WS 06/07 Dienstag 30.01.2007 Projekt für Systemprogrammierung WS 06/07 Von: Hassan Bellamin E-Mail: h_bellamin@web.de Gliederung: 1. Geschichte und Definition 2. Was ist Virtualisierung? 3. Welche Virtualisierungssoftware

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

COMPOSITA: Eine Studie über Laufzeit-Architekturen für massiv parallele Systeme

COMPOSITA: Eine Studie über Laufzeit-Architekturen für massiv parallele Systeme COMPOSITA: Eine Studie über Laufzeit-Architekturen für massiv parallele Systeme Luc Bläser HSR Hochschule für Technik Rapperswil Jürg Gutknecht ETH Zürich Vortrag KPS 2013 1 Oktober 2013 Motivation Heutige

Mehr

Steffen Heinzl Markus Mathes. Middleware in Java

Steffen Heinzl Markus Mathes. Middleware in Java Steffen Heinzl Markus Mathes Middleware in Java Leitfaden zum Entwurf verteilter Anwendungen - Implementierung von verteilten Systemen über JMS - Verteilte Objekte über RMI und CORBA Mit 50 Abbildungen

Mehr

Virtuelle Maschinen Konzept von VMWare

Virtuelle Maschinen Konzept von VMWare Virtuelle Maschinen Konzept von 11.12.2007 1 Einleitung 2 Software Virtualisierung 3 Software vs. Hardware 4 Fazit und Ausblick Motivation von Steigende Beliebtheit der x86-architektur Virtualizierung

Mehr

Hardware Virtualisierungs Support für PikeOS

Hardware Virtualisierungs Support für PikeOS Virtualisierungs Support für PikeOS Design eines Virtual Machine Monitors auf Basis eines Mikrokernels Tobias Stumpf SYSGO AG, Am Pfaenstein 14, 55270 Klein-Winternheim HS Furtwangen, Fakultät Computer

Mehr

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13 UNIVERSITÄT LEIPZIG Enterprise Computing Einführung in das Betriebssystem z/os Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13 Verarbeitungsgrundlagen Teil 3 Betriebssystem Überwacher

Mehr

Grundlagen der Parallelisierung

Grundlagen der Parallelisierung Grundlagen der Parallelisierung Philipp Kegel, Sergei Gorlatch AG Parallele und Verteilte Systeme Institut für Informatik Westfälische Wilhelms-Universität Münster 3. Juli 2009 Inhaltsverzeichnis 1 Einführung

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

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

Rechnerarchitektur. 11. Betriebssysteme und Prozesse. Inhalt. Ziele von Betriebssystemen. Betriebssystemkomponenten. Betriebssystemkomponenten

Rechnerarchitektur. 11. Betriebssysteme und Prozesse. Inhalt. Ziele von Betriebssystemen. Betriebssystemkomponenten. Betriebssystemkomponenten Inhalt Rechnerarchitektur 11. e und Soft- und eines Rechners Ziele von en komponenten dienste und -funktionen Mehrprogrammbetrieb Dateisysteme Ein-/Ausgabe architekturen Monolithische Systeme Geschichtete

Mehr

Programmierkurs: Delphi: Einstieg

Programmierkurs: Delphi: Einstieg Seite 1 von 6 Programmierkurs: Delphi: Einstieg Aus Wikibooks Inhaltsverzeichnis 1 Einstieg Einstieg Was ist Delphi Borland Delphi ist eine RAD-Programmierumgebung von Borland. Sie basiert auf der Programmiersprache

Mehr

Objektorientierte Programmierung. Kapitel 12: Interfaces

Objektorientierte Programmierung. Kapitel 12: Interfaces 12. Interfaces 1/14 Objektorientierte Programmierung Kapitel 12: Interfaces Stefan Brass Martin-Luther-Universität Halle-Wittenberg Wintersemester 2012/13 http://www.informatik.uni-halle.de/ brass/oop12/

Mehr

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

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

Mehr

VIRTUALISIERUNG IN MIKROKERN BASIERTEN SYSTEMEN

VIRTUALISIERUNG IN MIKROKERN BASIERTEN SYSTEMEN Fakultät Informatik Institut für Systemarchitektur, Professur Betriebssysteme VIRTUALISIERUNG IN MIKROKERN BASIERTEN SYSTEMEN Henning Schild Dresden, 5.2.2009 Definition Einführung von Abstraktionsschichten

Mehr

User Level Device Driver am Beispiel von TCP

User Level Device Driver am Beispiel von TCP September 17, 2004 Einleitung Motivation für Userlevel Device Driver Probleme von Userlevel Device Driver Motivation für Userlevel Device Driver Modularität, leichterer Austausch/Erneuerung von Komponenten.

Mehr

PIWIN 1 Übung Blatt 5

PIWIN 1 Übung Blatt 5 Fakultät für Informatik Wintersemester 2008 André Gronemeier, LS 2, OH 14 Raum 307, andre.gronemeier@cs.uni-dortmund.de PIWIN 1 Übung Blatt 5 Ausgabedatum: 19.12.2008 Übungen: 12.1.2009-22.1.2009 Abgabe:

Mehr

Einführung in die Echtzeitbetriebssysteme

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

Mehr

9 Verteilte Verklemmungserkennung

9 Verteilte Verklemmungserkennung 9 Verteilte Verklemmungserkennung 9.1 Grundlagen Für die Existenz einer Verklemmung notwendige Bedingungen Exklusive Betriebsmittelbelegung Betriebsmittel können nachgefordert werden Betriebsmittel können

Mehr

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

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

Mehr

Kapitel III. Prozesse. Prozessverwaltung. Was ist ein Prozess?

Kapitel III. Prozesse. Prozessverwaltung. Was ist ein Prozess? Kapitel III Prozessverwaltung 1 Was ist ein Prozess? Prozesse ein exekutierendes Programm (aktive Einheit) ein Prozess benötigt Ressourcen: CPU-Zeiten, Speicher, Files, I/O Systeme Betriebssystem ist verantwortlich

Mehr

Reaktive Systeme und synchrones Paradigma

Reaktive Systeme und synchrones Paradigma Sascha Kretzschmann Freie Universität Berlin Reaktive Systeme und synchrones Paradigma Einführung in das Seminar über synchrone Programmiersprachen Worum geht es? INHALT 2 Inhalt 1. Einleitung - Wo befinden

Mehr

Implementierung von Dateisystemen

Implementierung von Dateisystemen Implementierung von Dateisystemen Teil 2 Prof. Dr. Margarita Esponda WS 2011/2012 44 Effizienz und Leistungssteigerung Festplatten sind eine wichtige Komponente in jedem Rechnersystem und gleichzeitig

Mehr

Die Mikroprogrammebene eines Rechners

Die Mikroprogrammebene eines Rechners Die Mikroprogrammebene eines Rechners Das Abarbeiten eines Arbeitszyklus eines einzelnen Befehls besteht selbst wieder aus verschiedenen Schritten, z.b. Befehl holen Befehl dekodieren Operanden holen etc.

Mehr

Der Rechner. Grundbegriffe. Aufbau. Funktionsweise. Betriebssystem. Kategorisierung. PC-Komponenten. Prof. Dr. Aris Christidis

Der Rechner. Grundbegriffe. Aufbau. Funktionsweise. Betriebssystem. Kategorisierung. PC-Komponenten. Prof. Dr. Aris Christidis Der Rechner Grundbegriffe Aufbau Funktionsweise Betriebssystem Kategorisierung PC-Komponenten Auf der Grundlage eines Programms kann ein Computer Daten mit seiner Umgebung austauschen, mathematische und

Mehr

Java Batch Der Standard für's Stapeln

Java Batch Der Standard für's Stapeln Java Batch Der Standard für's Stapeln Berlin Expert Days 18.09.2015 Dirk Weil, GEDOPLAN GmbH Dirk Weil GEDOPLAN GmbH, Bielefeld GEDOPLAN IT Consulting Konzeption und Realisierung von IT-Lösungen GEDOPLAN

Mehr

Proseminar Technische Informatik A survey of virtualization technologies

Proseminar Technische Informatik A survey of virtualization technologies Proseminar Technische Informatik A survey of virtualization technologies Referent: Martin Weigelt Proseminar Technische Informatik - A survey of virtualization technologies 1 Übersicht 1. Definition 2.

Mehr

Parallelverarbeitung mit Ruby

Parallelverarbeitung mit Ruby Fachhochschule Wiesbaden - Fachbereich DCSM Parallelverarbeitung mit Ruby Prozess-Ebene Multithreading 04.12.2008 2003, 2008 H. Werntges, FB Design Informatik Medien (DCSM), FH Wiesbaden 1 Fachhochschule

Mehr

Parallele und funktionale Programmierung Wintersemester 2013/14. 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr

Parallele und funktionale Programmierung Wintersemester 2013/14. 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr Aufgabe 8.1: Zeigerverdopplung Ermitteln Sie an folgendem Beispiel den Rang für jedes Listenelement sequentiell und mit dem in der Vorlesung vorgestellten parallelen

Mehr

Effizientes Memory Debugging in C/C++

Effizientes Memory Debugging in C/C++ Effizientes Memory Debugging in C/C++ Adam Szalkowski Embedded Computing Conference 2014 Ursachen/ Symptome Debugging Tools Ursachen / Symptome Was habe ich falsch gemacht? Was kann denn passieren im schlimmsten

Mehr