Betriebssysteme.pdf

Betriebssysteme Dipl.-Ing. (FH) Michael Herzog  start Dipl.-Ing. (FH) Michael Herzog  Dipl.-Ing. (FH) Michael Herzog [email protected] Sprechstunde nach Vereinbarung Unterlagen: https://tinyurl.com/muyybaf8 (Google-...

Betriebssysteme Dipl.-Ing. (FH) Michael Herzog  start Dipl.-Ing. (FH) Michael Herzog  Dipl.-Ing. (FH) Michael Herzog [email protected] Sprechstunde nach Vereinbarung Unterlagen: https://tinyurl.com/muyybaf8 (Google-Drive) Bitte melden Sie sich umgehend bei: Verständnisproblemen Problemen mit Praktika … Dipl.-Ing. (FH) Michael Herzog  Praktikum: Vertiefung eigene Problemlösung Programmierung auf eigenem Rechner max. 2er Teams Testat: Wenn alle Aufgaben erfolgreich gelöst und erklärt wurden Voraussetzung: Linux auf eigenem Notebook/Laptop eigene Linux Distribution oder innerhalb einer VM Programmiersprache: C/C++ Man muss tatsächlich zwingend programmieren können! Dipl.-Ing. (FH) Michael Herzog Dipl.-Ing. (FH) Michael Herzog 01  Was ist ein Betriebssystem? Dipl.-Ing. (FH) Michael Herzog  Was ist ein Betriebssystem? Betriebssysteme haben zwei Hauptaufgaben: Sie stellen Dienste bereit, die die Aufgaben der Benutzer vereinfachen, und sie verwalten Betriebsmittel um wirkungsvollen Rechnerbetrieb sicherzustellen. Dipl.-Ing. (FH) Michael Herzog  Was ist ein Betriebssystem? Benutzer Software Dienste Betriebssystem Betriebsmittel Hardware Dipl.-Ing. (FH) Michael Herzog  Was ist ein Betriebssystem? Dienste (auch bekannt als Services oder Daemons) beschreiben allgemeine technische autarke Einheiten, welche zusammenhängende Funktiona- litäten zu einem Themenkomplex bündeln und über eine definierte Schnittstelle (API) zur Verfügung stellt: Verwaltung, Überwachung, Sicherheit, Treiber, GUI, etc. Betriebsmittel (auch als Ressourcen bezeichnet) sind Elemente, die zusammenarbeiten, um den reibungslosen Betrieb eines Computers zu gewährleisten: CPU, RAM, Peripherie, Netzwerk, etc. Dipl.-Ing. (FH) Michael Herzog  Was ist ein Betriebssystem? Bei Betriebssystemen handelt es sich ausschließlich um Software. Darum umfasst das Thema Betriebssysteme primär Inhalte aus der praktischen Informatik. Da eine der Hauptaufgaben von Betriebssystemen die Steuerung der jeweiligen Computer ist, gehören zum Thema Betriebssysteme auch immer Inhalte der technischen Informatik. Dipl.-Ing. (FH) Michael Herzog  Was ist ein Betriebssystem? Ziele Verständnis der Architektur, der Konzepte und der Funktionsweise moderner Betriebssysteme Verständnis für das Zusammenspiel von Hard- und Software Kennenlernen der Wirkungsweise der einzelnen Komponenten und zugrundeliegenden Mechanismen und Strategien Elementare Kenntnisse für die Entwicklung systemnaher Software Kompetenz: Beurteilung der Leistungsfähigkeit eines Betriebssystems Was tun bei Problemen? Dipl.-Ing. (FH) Michael Herzog Dipl.-Ing. (FH) Michael Herzog 02  Kleiner historischer Überblick Dipl.-Ing. (FH) Michael Herzog  Kleiner historischer Überblick ……… 1940. (Elektro-)mechanische Rechenmaschinen 1940–1955 Elektronenröhren, Relais, Steckfelder 1955–1965 Transistoren, Stapelverarbeitung 1965–1980 Integrierte Schaltungen, Dialogbetrieb 1980–2000 Hochintegrierte Schaltungen, PCs/Workstations 2000 ……… Verteilte Systeme, Mobile Systeme Dipl.-Ing. (FH) Michael Herzog  Kleiner historischer Überblick Zuse Z3 Die Z3 war der erste funktionsfähige Digitalrechner weltweit und wurde 1941 von Konrad Zuse in Zusammenarbeit mit Helmut Schreyer in Berlin gebaut. Die Programmierung erfolgte über Lochstreifen. Dipl.-Ing. (FH) Michael Herzog  Kleiner historischer Überblick ENIAC Im Auftrag der US-Armee wurde ENIAC ab 1942 von John Presper Eckert und John William Mauchly an der University of Pennsylvania entwickelt und am 14. Februar 1946 der Öffentlichkeit vorgestellt. Programmiert wurde er hauptsächlich von Frauen, den sogenannten „ENIAC- Frauen“. Die Programmierung erfolgte über Kabelsteckverbindungen. Dipl.-Ing. (FH) Michael Herzog  Kleiner historischer Überblick Mainframes In einem Großrechner sind aufeinander abgestimmte, robuste und hochgradig redundante Komponenten verbaut. Üblicherweise wird die Wartung dieser Rechner im laufenden Betrieb durch- geführt, auch Hardwareaustausch und Aufrüstungen führen zu keiner Beeinträchtigung oder gar Unter- brechung des Betriebs. Dipl.-Ing. (FH) Michael Herzog  Kleiner historischer Überblick Mainframes Stapelverarbeitung Die Idee der Stapelverarbeitung war, mehrere Aufgaben zu sammeln und sie nacheinander, ohne menschlichen Eingriff, abzuarbeiten. Dies führte zu einer höheren Effizienz, insbesondere in Umgebungen, in denen Computer teuer und Ressourcen begrenzt waren. Diese Entwicklung war ein wichtiger Schritt in der Evolution der Computernutzung. Dipl.-Ing. (FH) Michael Herzog  Kleiner historischer Überblick Mainframes Betriebssystem Das Betriebssystem eines Mainframes vereinfachte die Nutzung, indem der Stapelbetrieb vollständig automatisiert wurde. Die Funktionalität des Betriebsystems lag in der Ausführung des nächsten Programms, wenn ein vorheriges Programm beendet war. Probleme: Weiterentwicklungen: Sehr umfangreicher Code Interaktiver Betrieb durch mehrere Benutzer (Timesharing) und Speicherbedarf Echte Parallelität durch Aufkommen von E/A-Prozessoren Schwer zu warten Verzahnte Ausführung unabhängiger Programme Fehleranfällig Mehrbenutzersysteme Dipl.-Ing. (FH) Michael Herzog  Kleiner historischer Überblick Minicomputer Minicomputer sind eine Klasse von Computern, die in Bezug auf ihre Größe, Leistung und Anwendungsbereiche zwischen Mainframe-Computern und Mikrocomputern (heute als PC bekannt) liegen. Diese Bezeichnung wurde in den 1960er Jahren geprägt, als Computer begannen, kleiner zu werden, aber immer noch größer und leistungsfähiger waren als die aufkommenden Mikrocomputer. Dipl.-Ing. (FH) Michael Herzog  Kleiner historischer Überblick Minicomputer Betriebssystem Minicomputer verwendeten Betriebssysteme, die speziell für ihre Bedürfnisse entwickelt wurden. Einige der frühen Betriebssysteme für Minicomputer waren beispielsweise das DEC Operating System (DEC OS) der Digital Equipment Corporation (DEC)-Minicomputer. Vorteile: Gesucht: Keine Kühlung Neue Betriebsysteme … Geringerer Platzbedarf mit einfachen Strukturen Billiger mit einfacher Wartung mit Software Komponenten die geringere Komplexität aufweisen die eine Basis für Anwendungssoftware bereitstellen Dipl.-Ing. (FH) Michael Herzog  Kleiner historischer Überblick Minicomputer UNIX Unix ist ein Mehrbenutzer-Betriebs- system für Computer. Es wurde im August 1969 von den Bell Laboratories zur Unterstützung der Softwareentwicklung entwickelt. Heute steht Unix allgemein für Betriebssysteme, die entweder ihren Ursprung im Unix-System von AT&T (aka: Bell Laboratories) haben oder dessen Konzepte implementieren. Dipl.-Ing. (FH) Michael Herzog  Kleiner historischer Überblick Minicomputer UNIX Ken Thompson erstellte 1969 die erste Version in Assembler. 1972–1974 wurde das System komplett in C (Dennis Ritchie) implementiert und mit einem C- Compiler kostenfrei an verschiedene Universitäten verteilt. Daraus entwickelte sich an der Berkeley-Universität in Kalifornien die BSD-Linie (Berkeley Software Distribution). Ende der 1970er Jahre versuchte AT&T schließlich, Unix gewinnbringend zu vermarkten, woraus die System-V-Linie von Unix entstand. In den 1980er Jahren wurde Unix zum dominierenden Betriebssystem an den Universitäten, und es existierte eine Fülle verschiedenster UNIX-Derivate. Dipl.-Ing. (FH) Michael Herzog Dipl.-Ing. (FH) Michael Herzog 03  Betriebssysteme heute Dipl.-Ing. (FH) Michael Herzog  Betriebssysteme heute Einsatzgebiete Desktop / Laptop Heim- und Büroanwendungen Eingebettete Systeme Industrieautomation, Fahrzeuge, Consumer Electronics, etc. Mobilgeräte Smartphones, Tablets, etc. Server Datacenter, Großrechner, Cloud- und Grid-Computing Dipl.-Ing. (FH) Michael Herzog  Betriebssysteme heute Vielfältige Peripherie: WLAN, Bluetooth, 3G/4G/5G (EDGE, LTE) CD, DVD, HDD, SSD, Flash memory, USB storage LCD-/OLED-Displays, Touchscreens Keyboard, Mouse, Touchpad Drucker, Scanner GPS Gyroskop … Steigende Komplexität der Hardware. Häufig beschränkt durch CPU, Speicher, Akku. Dipl.-Ing. (FH) Michael Herzog  Betriebssysteme heute Beispiel: PC Multiuserfähig GUI Mehrere Programme laufen gleichzeitig Zugriff auf zahlreiche Peripheriegeräte Eine oder mehrere CPUs (oder CPU Kerne) Schnelle Reaktion auf Nutzereingabe Einfach bedienbar Micro­soft Windows, Apple MacOS, Google ChromeOS, Linux Dipl.-Ing. (FH) Michael Herzog  Betriebssysteme heute Beispiel: Server Multiuserfähig Mehrere Programme laufen gleichzeitig Dateisystem: hoher Durchsatz Netzwerk: hoher Durchsatz Eine oder mehrere CPUs (oder CPU Kerne) Stromsparend Gute Auslastung, hohe Rechenleistung Windows Server, Linux Dipl.-Ing. (FH) Michael Herzog  Betriebssysteme heute Beispiel: Smartphone Singleuser Mehrere Prozesse Dateisystem Touchscreen Stromsparend Vielfältige Peripherie: Kamera, GPS, mehrere Funknetze, Lautsprecher, Mikrofon,... Klein, sparsam, schnelle Reaktionszeiten, einfach bedienbar Google Android, Google Fuchsia, Apple iOS, Linux, LG WebOS, … Dipl.-Ing. (FH) Michael Herzog  Betriebssysteme heute Beispiel: Embeded-Systems Jeweils sehr spezieller Einsatzzweck Steuerung von Robotern, Kameras, Produktionsprozessen, etc. Monitoring von Prozessen, Maschinen, Produkten, etc. (z.B. QM) Geringer Speicherbedarf Schnelle, vorhersagbare Reaktionszeiten (Realzeitsysteme) Zuverlässig, einfach zu warten, fehlertolerant, sicher Dipl.-Ing. (FH) Michael Herzog  Betriebssysteme heute Beispiel: Realtime-Systems (RTOS) Manchmal reicht es nicht, dass Anwenderprogramme irgendwann abgearbeitet werden Aufgaben müssen in genau definierten Zeitfenstern abgearbeitet sein (z.B. ABS im Auto) Realzeit-Betriebssysteme garantieren Einhaltung von Deadlines Häufig kommerzielle OS QNX, VxWorks, PikeOS, FreeRTOS, Real-Time Linux, … Dipl.-Ing. (FH) Michael Herzog  Betriebssysteme heute Beispiel: Verteilte Betriebssysteme Verteilte oder vernetzte Computer-Systeme Cloud-Computing Grid-Computing Rechenzentren / Unternehmensnetzwerke Skalierbarkeit Transparenz Ressourcenverteilung Sicherheit Distributed System Environment (DSE) für IBM Mainframes, Linux Dipl.-Ing. (FH) Michael Herzog  Betriebssysteme heute Virtuelle Maschine Ein Betriebssystem kann auf einer virtuellen Maschine installiert werden, und dieser Ansatz wird als Virtualisierung bezeichnet. In einer virtualisierten Umgebung werden mehrere Betriebssysteminstanzen auf demselben physischen Server ausgeführt. Jede dieser Instanzen wird in einer eigenen virtuellen Maschine isoliert. Dipl.-Ing. (FH) Michael Herzog  Betriebssysteme heute Container Container sind eine Art von Virtualisierungstechnologie, die es ermöglicht, Anwendungen und ihre Abhängigkeiten in einer konsistenten und isolierten Umgebung auszuführen. Container laufen auf dem Betriebssystem des Host-Systems. Einige der bekanntesten Container-Technologien sind Docker, containerd, Podman etc. Dipl.-Ing. (FH) Michael Herzog  Betriebssysteme heute Embedded Operating Systems Embedded-Betriebssysteme sind meist genau auf die Maschinen oder Anlagen zugeschnitten, in die sie eingesetzt werden. Sie sollen nicht möglichst viele unterschiedliche Funktionen flexibel ausführen, sondern nur wenige, hoch spezialisierte. Diese aber möglichst fehlerfrei und sicher. Dipl.-Ing. (FH) Michael Herzog  Betriebssysteme heute Schnittstellen Zur Vereinfachung der Programmierung existieren spezielle vom Betriebssystem bereitgestellte Funktionen (System- aufrufe), z.B. für: Prozesse Dateisystem Ein-/Ausgabe... Standardisierung (POSIX) ermöglicht Portierung von Anwendungen über Plattformgrenzen hinweg! Dipl.-Ing. (FH) Michael Herzog Dipl.-Ing. (FH) Michael Herzog 04  Betriebssystemkerne Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Gute Architektur sagt uns, warum etwas getan wurde. Nicht wie und nicht wann und nicht wer. Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Der Betriebssystemkern Enthält die grundlegenden Funktionen des Betriebssystems: Systemaufrufe, Benutzerverwaltung, Prozessverwaltung inklusive Ausführungsreihenfolge (Scheduling), Interprozesskommunikation, Prozessumschalter (Dispatcher), Gerätetreiber, Speicherverwaltung, Dateisysteme zur Verwaltung von Dateien auf Speicherlaufwerken Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Der Betriebssystemkern Ist die Schnittstelle zur Hardware des Computers: Funktionalitäten im Betriebssystemkern haben vollen Hardwarezugriff Funktionalitäten laufen als Prozess im Adressraum des Kerns Funktionalitäten müssen nicht zwingend im Kern positioniert sein, sie können auch über Dienste bereitgestellt werden (Architektur) Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Der Betriebssystemkern Ein Schichtmodell ist eine strukturierte Darstellung eines Systems, bei dem die verschie- denen Funktionen oder Kompo- nenten in Schichten oder Ebenen organisiert sind. Jede Schicht erfüllt bestimmte Aufgaben und stellt Dienste für die darüber und darunter liegenden Schichten bereit. Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Der Betriebssystemkern Der Kernel-Bereich ist privilegiert stellt die Infrastruktur für die Prozesse und ihre Interaktionen bereit. Da der Kernel den direkten Zugriff auf die Hardware hat, ist von hier alles möglich. Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Die Anwendungsschicht Der User-Bereich ist nicht privilegiert, kann aber darauf aufbauende Funktionalitäten bereitstellen. Der Zugriff auf die Hardware erfolgt alleinig durch die im Kernel bereitgestellten Funktionalitäten (Sytem-Calls). Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Monolithische Kerne Ein Monolith enthällt alle Funktionalitäten eines Betriebssystems. Pro: Con: Die Ausführungsgeschwindigkeit ist besser Nachteilig ist, dass abgestürzte als mit anderen Architekturen da weniger Komponenten des Kerns nicht separat neu Prozesswechsel notwendig sind. Zudem ist gestartet werden können und eventuell durch jahrelange Entwicklungstätigkeit das gesamte Betriebssystem zum Absturz eine gewachsene Stabilität vorhanden. bringen. MS-DOS, FreeDOS, Windows 95/98/ME , Mac OS (bis Version 8.6), OS/2 … Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Minimale Kerne (Microkernel) Hier befinden sich nur die nötigsten Funktionen im Kernel. Pro: Con: Alle weiteren Funktionalitäten laufen als Nachteilig ist, dass abgestürzte Dienste bzw. Server im User-Modus. Die Komponenten des Kerns nicht separat neu ausgelagerten Funktionalitäten sind gestartet werden können und eventuell dadurch leichter austauschbar. das gesamte Betriebssystem zum Absturz Ein minimaler Kern bietet i.d.R eine bringen. bessere Stabilität und Sicherheit. AmigaOS, MorphOS, Tru64, QNX Neutrino, Symbian, Minix, Amoeba … Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Hybride Kerne Hier geht man einen Kompromiss ein. Diese enthalten Komponenten die, aus Geschwindigkeitsgründen, zusätzlich in den Kernel aufgenommen werden. Pro: Con: Theoretisch ergibt sich eine höhere Keine klare Definition was in den Kernel Geschwindigkeit als bei minimalen Kernen integriert wird. Daher differieren diese und eine höhere Stabilität als bei Systeme sehr stark und können zu einer monolithischen Kernen. fehlenden Unterstützung der Hardware- und Software-Hersteller führen. Windows seit NT 3.1, Apple Mac OS X, ReactOS, BeOS, ZETA … Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne / Vergleich Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne / Linux Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne / Android Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne / MacOS X Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Alternative Architekturen Der Flaschenhals aller bestehenden Systeme liegt in Ihren Schichtmodellen begründet. Eine Anwendung hat keinen direkten Zugriff auf die Hardware. Sämmtliche Kommunikation und Datenfluß wird über Bibliotheken und den Kernel abgewickelt. Um die Kommunikation und den Datenfluß zu erhöhen, wäre ein direkter Kontakt zwischen Anwendung und Hardware notwendig. Die Zugangskontrolle erfolgt weiterhin über Bibliotheken und Kernel. Ein solches Betriebsystem hätte einen geringeren Umfang (Sicherheit). Es könnte sogar selbst als Bibliothek fungieren und würde durch den Linker in eine Anwendung integriert werden. Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Programmierschnittstellen Ein Systemaufruf (System Call) ist eine Programmierschnittstelle (API), die es Anwendungsprogrammen ermöglicht, auf die Dienste und Ressourcen des Betriebssystems zuzugreifen. Wenn ein Programm eine Aktion ausführen will, die besondere Berechti- gungen erfordert oder die Kontrolle über die Hardware benötigt, verwendet es Systemaufrufe, um diese Dienste vom Betriebssystem anzufordern. Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Programmierschnittstellen Die Implementierung von Systemaufrufen hängt stark von der verwendeten Hardware, der Architektur und letztlich auch dem benutzten Betriebssystem ab. In der Regel wird heute ein Systemaufruf mit Softwareinterrupts oder anderen Spezialinstruktionen der CPU realisiert. Bei älteren Systemen findet meist einfach nur ein Sprung an eine fest definierte Adresse statt, an der der Systemaufruf oder ein Sprungbefehl zu diesem implementiert ist. Beim einem Moduswechsel gibt ein User-Prozess die Kontrolle über den Hauptprozessor an den Betriebssystemkern ab und ist für die benötigte Zeit unterbrochen. Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Programmierschnittstellen Wann werden Systemaufrufe genutzt? Software User-Mode Berechtigungen Ressourcenverwaltung System Call Kommunikation mit Hardware Prozesssteuerung Betriebssystem Kernel-Mode Netzwerkkommunikation Zeitverwaltung Hardware Dipl.-Ing. (FH) Michael Herzog  Betriebssystemkerne Programmierschnittstellen In der Praxis ist die Nutzung eines direkten Systemaufrufs nicht empfehlens- wert. Solche Software ist schlecht portierbar, da nicht alle Systemaufrufe bei den verschiedenen Betriebssystemfamilien identisch sind. Es ist nicht garantiert, dass neue Versionen eines Betriebssystemkerns nicht auch Veränderungen an Systemaufrufen enthält. Bei der Entwicklung von Software sollte auf die Funktionen von Bibliotheken zurückgegriffen werden. Diese befinden sich, mit entsprechenden Wrapper- Funktionen, logisch zwischen den Benutzerprozessen und dem Betriebssystemkern. Dipl.-Ing. (FH) Michael Herzog Dipl.-Ing. (FH) Michael Herzog 05  Prozessmanagement Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozessverwaltung Die Prozessverwaltung ist eine der grundlegenden Funktionalitäten eines Betriebssystems. Jeder Prozess im Betriebssystem ist eine Instanz eines Programms, das ausgeführt wird. Auf einem modernen Computersystem sind immer mehrere Prozesse in Ausführung. Der Hauptprozessor wird beim Mehrprogrammbetrieb im raschen Wechsel (ms) zwischen den Prozessen hin- und hergeschaltet. Jeder Prozess umfasst außer dem Programmcode noch seinen Prozesskontext, der von den Kontexten anderer Prozesse unabhängig ist. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Beispiel: Terminalbefehl – top Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozesskontext Der Kontext eines Prozesses bezieht sich auf den aktuellen Zustand und die Informationen, die benötigt werden, um einen bestimmten Prozess in einem Betriebssystem auszuführen. Jeder laufende Prozess hat seinen eigenen Kontext, der Informationen über den Zustand des Prozesses und seine Ausführungsumgebung enthält. Der Prozesskontext ist entscheidend für die Wiederaufnahme der Ausführung eines Prozesses nach einem Unterbrechungspunkt, beispielsweise nach einem Wechsel zu einem anderen Prozess oder nach einem Systemaufruf. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozesskontext Der Prozesskontext ist entscheidend, um die Multitasking-Fähigkeiten eines Betriebssystems zu unterstützen. Wenn ein Betriebssystem zwischen verschiedenen Prozessen wechselt, muss es den aktuellen Kontext speichern und den Kontext des nächsten auszuführenden Prozesses wiederherstellen. Der schnelle und effiziente Wechsel des Prozesskontexts trägt dazu bei, die Illusion zu schaffen, dass mehrere Prozesse gleichzeitig ausgeführt werden. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozessstatus Zugriffsrechte und Programmzähler Zustände Prozesskontext Dateien und Registerinhalte Ressourcen Stack und Stackzeiger Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Hardwarekontext Der Hardwarekontext eines Prozesses bezieht sich auf den Teil des Prozesskontexts, der Informationen über den Zustand der verwendeten Hardware enthält, die von einem bestimmten Prozess genutzt wird. Dieser Zustand umfasst Informationen über die CPU-Register, den Zustand des Hauptspeichers (RAM), den Zustand der CPU-Flags und andere hardwarenahe Daten. Der Hardwarekontext ist entscheidend für die Wiederaufnahme der Ausführung eines Prozesses nach einer Prozess-Unterbrechung. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Hardwarekontext Befehlszähler (Program Counter, Instruction Pointer) Stackpointer Basepointer Befehlsregister (Instruction Register) Akkumulator Page-Table Base Register Page-Table Length Register Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Systemkontext Der Systemkontext eines Prozesses bezieht sich auf den Teil des Prozesskontexts, der Informationen über alle Systemressourcen und den Zustand des Betriebssystems enthält, die von einem bestimmten Prozess genutzt werden. Dieser Kontext ist wichtig, um die Systemaufrufe und den Zugriff auf privilegierte Ressourcen zu verwalten. Der Systemkontext wird bei einem Wechsel von Benutzermodus zu Kernelmodus und zurück benötigt. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Systemkontext Eintrag in der Prozesstabelle Prozessnummer (PID) Prozesszustand Information über Eltern- oder Kindprozesse Priorität Zugriffsrechte auf Ressourcen Erlaubte Nutzungsmengen (Quotas) einzelner Ressourcen Laufzeit Geöffnete Dateien Zugeordnete Geräte Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozesstabelle / -kontrollblock Die Prozesstabelle und der Prozesskontrollblock (PCB) sind Konzepte in der Betriebssystem- architektur, die zur Verwaltung von Prozessen und ihren Zuständen verwendet werden. Diese sind in der Regel im Kontext von Multitasking-Betriebssystemen relevant. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozesstabelle Die Prozesstabelle ist eine Datenstruktur im Betriebssystem, die Informationen über alle aktiven Prozesse im System enthält. Jeder Prozess hat einen Eintrag in dieser Tabelle. Die Prozesstabelle dient als Index für alle laufenden Prozesse und bietet eine einfache Möglichkeit für das Betriebssystem, Informationen zu einem bestimmten Prozess schnell abzurufen. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozesstabelle Prozess-ID (PID): Eine eindeutige Kennung für jeden Prozess Zustand des Prozesses (laufend, bereit, blockiert usw.) Priorität des Prozesses für das Scheduling Zeiger auf den Prozesskontrollblock (PCB) des Prozesses Andere Ressourceninformationen Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozesskontrollblock (PCB) Der Prozesskontrollblock ist eine Datenstruktur, die alle Informationen enthält, die das Betriebssystem benötigt, um einen bestimmten Prozess zu verwalten. Jeder aktive Prozess hat seinen eigenen PCB, der vom Betriebssystem erstellt und aktualisiert wird. Der PCB wird im Speicher gehalten und enthält den Kontext des Prozesses. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozesskontrollblock (PCB) Zustand des Prozesses und Programmzähler Registerinhalte, einschließlich der CPU-Register Zeiger auf den Stack des Prozesses Informationen über geöffnete Dateien und andere Ressourcen Planungs- und Scheduling-Informationen wie Priorität und Wartezeit Informationen über den Prozesseigner, Zugriffsrechte und Sicherheitsinformationen Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Prozesszustände In einem Multitasking-Betriebssystem durchläuft ein Prozess verschiedene Zustände während seiner Lebensdauer. Diese Zustände werden als Prozesszustände bezeichnet, und sie geben den aktuellen Status eines Prozesses im System an. Gängige Zustände sind: Bereit (Ready) Laufend (Running) Blockiert (Blocked) Beendet (Terminated) Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 2-Zustands-Modell Das 2-Zustands-Modell ist einfach und bietet einen grundlegenden Rahmen für das Verständnis von Prozesszuständen. In der Praxis sind Betriebssysteme jedoch oft komplexer und verwenden erweiterte Modelle mit mehr Zuständen, um verschiedene Aspekte der Prozessverwaltung besser zu berücksichtigen. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 2-Zustands-Modell Prozesse im Zustand untätig werden in einer Warteschlange gespeichert, in der sie auf ihre Ausführung warten. Die Liste wird nach einem Algorithmus sortiert, der sinnvollerweise die Prozesspriorität und/oder die Wartezeit berücksichtigt. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 2-Zustands-Modell Das 2-Zustands-Modell hat den Vorteil, dass es sehr einfach realisierbar ist, es hat aber einen konzeptionellen Fehler. Dieser besteht in der Annahme, dass alle Prozesse jederzeit zur Ausführung bereit sind. In der Praxis ist das nicht der Fall, denn es gibt in einem Betriebssystem mit Mehrprogrammbetrieb auch immer Prozesse, die blockiert (blocked) sind. Mögliche Gründe: Prozess wartet auf die Ein-/Ausgabe eines Geräts Prozess wartet auf das Ergebnis eines anderen Prozesses Prozess wartet auf die Reaktion eines Benutzers Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 3-Zustands-Modell Daraus resultiert dann das 3-Zustands-Prozessmodell. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Ereignisbezogene Warteschlangen Für jedes Ereignis, auf das mindestens ein Prozess wartet, legt das Betriebssystem eine Warteschlange an. Tritt ein Ereignis ein, werden alle in der entsprechenden Warteschlange befindlichen Prozesse in die Warteschlange mit den Prozessen im Zustand bereit (ready) überführt. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 5-Zustands-Modell Bei Computern mit wenig Ressourcen kann es sinnvoll sein, die Anzahl der ausführbaren Prozesse zu limitieren, um Speicher zu sparen und den Grad des Mehrprogrammbetriebs festzulegen, ist es sinnvoll, das 3-Zustands- Prozessmodell um zwei weitere Prozesszustände zu erweitern. neu (new): beendet (exit): Prozesse, deren PCB das Betriebssystem beendet (exit): Abgearbeitete oder zwar bereits erzeugt hat, die aber noch abgebrochene Prozesse deren PCB und nicht in die Warteschlange für den Zustand Eintrag in der Prozesstabelle nicht entfernt bereit eingefügt sind. wurden. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 5-Zustands-Modell Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 6-Zustands-Modell Ist nicht genügend physischer Hauptspeicher für alle Prozesse verfügbar, müssen Teile von Prozessen auf den Auslagerungsspeicher (Swap) ausgelagert werden. Soll das Betriebssystem in der Lage sein, bei Bedarf Prozesse auszulagern, die im Zustand blockiert (blocked) sind, muss ein weiterer Prozesszustand suspendiert (suspended) eingeführt werden. Dadurch steht den Prozessen in den Zuständen rechnend und bereit mehr Hauptspeicher zur Verfügung. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 6-Zustands-Modell Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 7-Zustands-Modell Wurde ein Prozess suspendiert, ist es besser, den frei gewordenen Platz im Hauptspeicher zu verwenden, um einen ausgelagerten Prozess zu aktivieren, als ihm einen neuen Prozess zuzuweisen. Das ist aber nur dann sinnvoll, wenn der aktivierte Prozess nicht mehr blockiert ist. Im 6-Zustands-Modell fehlt die Möglichkeit, die ausgelagerten Prozesse in blockierte und nicht-blockierte ausgelagerte Prozesse zu unterscheiden. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das 7-Zustands-Modell Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das Zustands-Modell von Linux Das Prozessmodell von Linux kommt dem 7-Zustands-Prozessmodell schon sehr nahe. Der offensichtlichste Unterschied ist, dass der Zustand rechnend in der Praxis in die beiden Zustände benutzer rechnend (user running) für Prozesse im Benutzermodus und kernel rechnend (kernel running) für Prozesse im Kernelmodus unterteilt ist. Zudem heißt der Zustand beendet (exit) unter Linux Zombie. Ein Zombie- Prozess ist zwar fertig abgearbeitet (via Systemaufruf exit), aber sein Eintrag in der Prozesstabelle existiert noch so lange, bis der Elternprozess den Rückgabewert (via Systemaufruf wait) abgefragt hat. Dipl.-Ing. (FH) Michael Herzog  Prozessmanagement Das Zustands-Modell von Linux Dipl.-Ing. (FH) Michael Herzog Dipl.-Ing. (FH) Michael Herzog 06  Prozessstruktur Dipl.-Ing. (FH) Michael Herzog  Prozessstruktur Prozessdarstellung Die Darstellung eines Prozesses im Speicher umfasst die Zustände und die Struktur eines laufenden Programms. Hier sind die grundlegenden Komponenten, die in der Speicherrepräsentation eines Prozesses vorhanden sein können: Systemumgebung Stack Heap BSS (Block Started by Symbol) Datensegment Codesegment Dipl.-Ing. (FH) Michael Herzog  Prozessstruktur hohe Adressen Systembibliotheken (Kernel) und Systemumgebung externe Code-Bibliotheken. Stack Verwaltung von Funktionen und lokalen Variablen. Heap Dynamisch allokierte Daten. BSS Globale oder statische Variablen. Der Datenabschnitt enthält globale und statische Datensegment Variablen, die während der Laufzeit existieren. Dies ist der Maschinenbefehlscode, der vom Codesegment Prozessor ausgeführt wird. niedrige Adressen Dipl.-Ing. (FH) Michael Herzog  Prozessstruktur Beispiel: Terminalbefehl – size Dipl.-Ing. (FH) Michael Herzog  Prozessstruktur Prozesse im Speicher Die Ablage der Prozesse im physischen Speicher erfolgt durch den virtuellen Speicher nicht in fortlaufender Weise und auch nicht zwangsläufig ständig im Hauptspeicher. Dipl.-Ing. (FH) Michael Herzog  Prozessstruktur Erzeugung von Prozesskopien Der Systemaufruf fork ist unter Unix- / Linux-Betriebssystemen die üblicherweise verwendete Möglichkeit, einen neuen Prozess zu erzeugen. Es wird eine identische Kopie eines Prozesses erzeugt. Der aufrufende Prozess ist der Elternprozess (Parent Process). Der neu erzeugte Prozess heißt Kindprozess (Child Process). Er hat den gleichen Programmcode und Befehlszähler wie der Elternprozess, verweisen also auf die gleiche Zeile im Programmcode. Die Speicherbereiche von Kindprozess und Elternprozess sind streng voneinander getrennt. Dipl.-Ing. (FH) Michael Herzog  Prozessstruktur Erzeugung von Prozesskopien Dipl.-Ing. (FH) Michael Herzog  Prozessstruktur Erzeugung von neuen Prozessen Um einen ganz neuen Prozess zu erstellen, muss der Systemaufruf exec genutzt werden. Dieser ersetzt einen bestehenden Prozess durch einen anderen. In diesem Fall erbt der neue Prozess die PID des aufrufenden Prozesses. exec() Prozess A Prozess B PID: 4711 PID: 4711 Dipl.-Ing. (FH) Michael Herzog  Prozessstruktur Erzeugung von neuen Prozessen Soll aus einem Prozess wie beispielsweise aus einem Kommandozeilen- interpreter (Shell) heraus ein Programm gestartet werden, muss zuerst mit fork ein neuer Prozess erzeugt um diesen anschließend mit exec zu ersetzen. fork() exec() Shell Shell Prozess B PID: 4711 PID: 1234 PID: 1234 Dipl.-Ing. (FH) Michael Herzog  Prozessstruktur Prozessvergabelung Prozessverkettung Prozesserzeugung fork() exec() fork() + exec() Dipl.-Ing. (FH) Michael Herzog  Prozessstruktur Beenden von Prozessen Prozesse können auf unterschiedliche Art und Weise beendet werden: Normales Beenden (freiwillig, im Programmcode definiert) Beenden aufgrund eines Fehlers (freiwillig, im Programmcode definiert) Beenden aufgrund eines schwerwiegenden Fehlers (unfreiwillig, durch BS) Beenden durch einen anderen Prozess (unfreiwillig) Der Unix-Befehl kill stellt einen Wrapper um den Betriebssystemaufruf kill() dar. Es ist auf jedem Unix-Derivat als alleinstehende Anwendung vorhanden (üblicherweise unter: /bin/kill). Dipl.-Ing. (FH) Michael Herzog  Prozessstruktur Zeitliche Ausführung von Prozessen Der Scheduler ist eine wichtige Komponente des Betriebssystems, die für die Zuweisung von CPU-Ressourcen an laufende Prozesse verantwortlich ist. Die Hauptaufgabe besteht darin, die Reihenfolge festzulegen, in der Prozesse auf der CPU ausgeführt werden. Es gibt verschiedene Arten von Scheduling- Algorithmen, die der Scheduler implementieren kann, um diese Aufgabe zu erfüllen. In allen Betriebssystemen sind zumindest Teile der Prozessumschaltung in Assembler implementiert. Das liegt daran, dass z.B. das Sichern von Registern und des Stackzeigers nicht in Hochsprachen durchgeführt werden kann. Dipl.-Ing. (FH) Michael Herzog  Prozessstruktur Zeitliche Ausführung von Prozessen Der Dispatcher ist ebenfalls Bestandteil des Betriebssystems und für die Umsetzung der Scheduling-Entscheidungen des Schedulers verantwortlich. Während der Scheduler entscheidet, welcher Prozess als nächstes auf der CPU ausgeführt werden soll, implementiert der Dispatcher diese Entscheidung, indem er den Kontrollfluss von einem laufenden Prozess zu einem anderen wechselt. Das Einleiten des Umschaltvorgangs wird durch einen Timer-Interrupt ausgelöst. Der Interrupt wird periodisch ausgelöst und startet eine entsprechende Softwareroutine. Dipl.-Ing. (FH) Michael Herzog  Prozessstruktur Interrupt Interrupt Interrupt Prozess A Prozess B Umschalten Zeitscheibe Zeitscheibe Zeitscheibe Dipl.-Ing. (FH) Michael Herzog  Prozessstruktur Prozess Zustand … rechnend blockiert Zeit fopen bereit … rechnend Kernel Dipl.-Ing. (FH) Michael Herzog  Prozessstruktur POSIX-API Das “Portable Operating System Interface” (POSIX) ist ein Standard, der von der IEEE (Institute of Electrical and Electronics Engineers) für Betriebssysteme entwickelt wurde. POSIX definiert eine Schnittstelle zwischen Anwendungen und dem Betriebssystem, um die Portabilität von Software zwischen verschiedenen UNIX-ähnlichen Betriebssystemen zu erleichtern. fork execl, execv, execve, … wait, waitpid kill sleep … getpid, getppid, setpgid, … Dipl.-Ing. (FH) Michael Herzog Dipl.-Ing. (FH) Michael Herzog 07  Prozesssynchronisation Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Warum braucht man Synchronisation? Die Prozesssynchronisation bezieht sich auf den Mechanismus, der sicherstellt, dass mehrere Prozesse in einem System koordiniert und in einer bestimmten Reihenfolge oder zeitlichen Abfolge arbeiten. In einem Multitasking- oder Multiprozessor-System, in dem mehrere Prozesse gleichzeitig oder parallel ausgeführt werden, ist die Synchronisation entscheidend, um sicherzustellen, dass die Prozesse ordnungsgemäß miteinander interagieren und auf gemeinsame Ressourcen zugreifen können. Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Wann braucht man Synchronisation? Warten-Auf-Operationen (Wait and Signal) Kritischer Abschnitt (Critical Section) Rennbedingungen (Race Conditions) Mutex (Mutex Lock) Semaphore Deadlocks und Ressourcenkonflikte Interprozesskommunikation (IPC) Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Signale In Betriebssystemen dienen Signale als Mechanismus für die Kommunikation zwischen Prozessen oder zwischen dem Betriebssystem und Prozessen. Ein Signal ist eine Benachrichtigung an ein Programm oder einen Prozess, dass ein bestimmtes Ereignis aufgetreten ist. Signale können für verschiedene Zwecke verwendet werden, darunter die Behandlung von Ausnahmen, die Kommunikation von Ereignissen oder die Steuerung von Prozessen. Dies ermöglicht die Implementierung von asynchronen Benachrichtigungen und die Behandlung von außergewöhnlichen Ereignissen in einem Betriebssystem. Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Beispiel: Terminalbefehl – man signal Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Signalhandler Ein Signalhandler ist eine Funktion oder ein Codeabschnitt, der von einem Prozess ausgeführt wird, wenn dieser ein bestimmtes Signal empfängt. Signalhandler werden in der Regel verwendet, um auf bestimmte Ereignisse oder Bedingungen zu reagieren, die im Kontext eines Betriebssystems oder einer Anwendung auftreten können. Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Signalhandler Was passiert beim Aufruf eines Signalhandlers: Der Prozess wird bei Eintreffen eines Signals angehalten. Der Prozesszustand wird gesichert. Der Signalhandler wird aufgerufen. Diese Funktion darf selbst beliebige Systemaufrufe veranlassen (sollte sie aber nicht... ). Ist der Signalhandler beendet, läuft der Prozess an der Stelle weiter, wo er vorher unterbrochen wurde. Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Aktives Warten (Polling) Das aktive Warten, ist eine Methode in der Informatik, bei der ein Prozess wiederholt überprüft, ob eine bestimmte Bedingung erfüllt ist. Diese Technik wird häufig in Warteschleifen oder Schleifenstrukturen verwendet, um auf bestimmte Ereignisse oder Zustände zu reagieren. Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Passives Warten Im Gegensatz zum aktiven Warten, bei dem ein Prozess wiederholt überprüft, ob eine bestimmte Bedingung erfüllt ist, bezieht sich passives Warten auf eine Technik, bei der ein Prozess in den Wartezustand versetzt wird und nicht aktiv die Bedingung überprüft. Der Prozess wird erst dann aktiviert, wenn die Bedingung erfüllt ist. Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Sperren In der Systemprogrammierung bezieht sich der Begriff Sperren auf einen Mechanismus, der dazu dient, den Zugriff auf gemeinsame Ressourcen durch mehrere Prozesse oder Threads zu koordinieren. Das Ziel der Synchronisation durch Sperren besteht darin, sicherzustellen, dass nur ein Prozess oder Thread gleichzeitig auf eine bestimmte Ressource zugreifen kann, um mögliche Dateninkonsistenzen oder Rennbedingungen zu vermeiden. Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Mutex Ein Mutex (Mutual Exclusion) ist eine Art von Sperre, die dazu verwendet wird, den exklusiven Zugriff auf eine Ressource zu steuern. Ein Prozess oder Thread sperrt den Mutex, bevor er auf die Ressource zugreift, und entsperrt ihn nach Abschluss der Operation. Dateizugriffe Netzwerkkommunikation Zugriff auf gemeinsam genutzte Datenstrukturen Hardware Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Mutex POSIX API pthread_mutex_t Datentyp für Mutex pthread_mutex_init Erzeugen eines Mutexobjekts pthread_mutex_unlock Entsperren pthread_mutex_lock Sperren pthread_mutex_trylock Versuchendes Sperren pthread_mutex_destroy Löschen des Mutexobjekts Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Semaphore POSIX API sem_t Datentyp für Semaphor sem_init Initialisieren eines Semaphors (notwendig!) sem_post up Operation: Semaphor um 1 erhöhen sem_wait down Operation: Semaphor um 1 vermindern oder blockieren sem_trywait wie sem_wait, aber Aufruf kehrt sofort zurück falls sem_wait blockieren würde sem_timedwait wie sem_wait, aber mit time-out falls blockiert sem_getvalue Wert des Semaphors auslesen sem_destroy Löschen eines Semaphors Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Die Wahl zwischen Mutex oder Semaphore hängt von den Anforderungen und Charakteristiken des spezifischen Anwendungsfalls ab. Es ist wichtig, diese Synchronisationsmechanismen sorgfältig zu verwenden, um sicherzustellen, dass die kritischen Abschnitte effizient und sicher koordiniert werden. Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Deadlock Ein Deadlock (Stillstand / Blockade) ist eine Situation in einem System, bei der zwei oder mehr Prozesse oder Threads auf unbestimmte Weise blockiert sind, weil jeder auf die Freigabe von Ressourcen wartet, die von einem anderen gehalten werden. Ein Deadlock tritt auf, wenn es eine Zirkularität in den Wartebeziehungen gibt, sodass jeder Prozess auf die Freigabe einer Ressource wartet, die von einem anderen Prozess gehalten wird, und alle Prozesse im Kreis blockiert sind. Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Deadlock Die Entstehung von Deadlocks erfordert vier notwendige Bedingungen: Gegenseitiger Ausschluss Nicht-Preemption Mindestens eine Ressource im System muss Ressourcen können nicht zwangsweise von einem exklusiv für einen Prozess verfügbar sein und kann Prozess oder Thread entzogen werden. Sie können nicht gleichzeitig von anderen Prozessen oder nur freiwillig freigegeben werden. Threads verwendet werden. Zyklus in den Wartebeziehungen Warte-Zustand Es existiert eine Kette von Prozessen oder Threads, Ein Prozess hält mindestens eine Ressource und P1, P2,..., Pn, wobei P1 auf die Freigabe einer wartet darauf, dass ihm eine andere Ressource Ressource wartet, die von P2 gehalten wird, P2 freigegeben wird. wartet auf eine Ressource von P3, und so weiter, bis Pn auf die Freigabe einer Ressource von P1 wartet. Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Deadlock-Erkennung Ein Betriebsmittelgraph (Resource Allocation Graph) ist ein Konzept, das in der P1 besitzt R1 Betriebssystemtheorie verwendet wird, um uf t a die Zuteilung und Freigabe von Ressourcen arte w zwischen verschiedenen Prozessen zu w ar modellieren. P2 te t R2 au bes f itzt Betriebsmittelgraphen werden in Algorithmen zur Deadlock-Vermeidung und -Erkennung P3 R3 verwendet, um den Zustand des Systems zu analysieren und Maßnahmen zu ergreifen, Deadlock um Deadlocks zu verhindern oder aufzulösen. Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Deadlock-Erkennung (Matrizen) Gibt es mehrere Instanzen einer Ressource, sind Graphen zur Darstellung bzw. Erkennung von Deadlocks ungeeignet. Hier kann ein matrizen-basiertes Verfahren verwendet werden, das zwei Vektoren und zwei Matrizen benötigt: Resourcenvektor Belegungsmatrix Anforderungsmatrix Resourcenrestvektor Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Deadlock-Erkennung (Matrizen) R1 R2 R3 R4 Resourcenvektor ( 4, 2, 3, 1) Anzahl der Instanzen 0, 0, 1, 0 P1 Belegungsmatrix 2, 0, 0, 1 P2 0, 1, 2, 0 P3 Resourcenrestvektor ( 2, 1, 0, 0) Anzahl der noch verfügbaren Instanzen Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Deadlock-Erkennung (Matrizen) R1 R2 R3 R4 Resourcenvektor ( 2, 1, 0, 0) Anzahl der noch verfügbaren Instanzen 2, 0, 0, 1 P1 Belegungsmatrix 1, 0, 1, 0 P2 0, 1, 0, 0 P3 Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Livelock Ein Livelock bezeichnet eine Form der Blockierung zweier oder mehrerer Prozesse, die im Unterschied zum Deadlock nicht in einem Zustand verharren, sondern ständig zwischen mehreren Zuständen wechseln, aus denen sie nicht mehr entkommen können. Beispiel: Zwei Personen kommen sich in einem Gang entgegen und versuchen fortwährend, einander in der gleichen Richtung auszuweichen. Dadurch blockieren sie sich jedesmal gegenseitig. Bei einem Deadlock würden sich die zwei Personen nur gegenüberstehen und jeweils darauf warten, dass die andere beiseite geht, was nicht geschieht. Dipl.-Ing. (FH) Michael Herzog Dipl.-Ing. (FH) Michael Herzog 08  Threads Dipl.-Ing. (FH) Michael Herzog  Threads Was sind Threads? Threads sind die kleinste ausführbare Einheit innerhalb eines Prozesses. Insgesamt ermöglichen Threads eine flexiblere, reaktionsschnellere und effizientere Programmierung in einer Vielzahl von Anwendungsfällen. Es ist jedoch wichtig, Threads sorgfältig zu managen, um potenzielle Probleme wie Rennbedingungen und Deadlocks zu vermeiden. Es gilt zu beachten, dass die Wahl zwischen Threads und Prozessen von den Anforderungen der Anwendung abhängt, und es ist nicht ungewöhnlich, beide in einem System zu verwenden, um die Vorteile beider Modelle zu kombinieren. Dipl.-Ing. (FH) Michael Herzog  Threads Threads vs. Prozesse Merkmal Thread Prozess Kleinste ausführbare Einheit Unabhängiges Programm in Definition innerhalb eines Prozesses. Ausführung. Teilen denselben Adressraum und Haben eigenen Adressraum und Ressourcenzuweisung Ressourcen innerhalb eines separate Ressourcen. Prozesses. Erfordert aufwändige Direkter Zugriff auf gemeinsame Mechanismen wie IPC für die Kommunikation Daten, erfordert jedoch Kommunikation zwischen synchronisierte Mechanismen. Prozessen. Dipl.-Ing. (FH) Michael Herzog  Threads Threads vs. Prozesse Merkmal Thread Prozess Isoliert voneinander, weniger Benötigt Synchronisations- Rennbedingungen, aber schwerere Synchronisation mechanismen, um Rennbe- Synchronisation zwischen dingungen zu verhindern. Prozessen. Geringerer Overhead im Vergleich Höherer Overhead, da separate Overhead zu Prozessen. Adressräume und Ressourcen. Effiziente Nutzung von Ressourcen Höherer Ressourcenverbrauch Ressourcennutzung innerhalb desselben Prozesses. aufgrund separater Adressräume. Dipl.-Ing. (FH) Michael Herzog  Threads Threads vs. Prozesse Merkmal Thread Prozess Schnellere Erstellung und Langsamer bei der Erstellung und Terminierung. Terminierung Terminierung. Das Beenden eines Erstellung und Terminierung beeinflusst nur den spezifischen Prozesses beendet alle seine Thread. Threads. Isoliert, das Scheitern eines Scheitern eines Threads kann den Fehlerisolierung Prozesses beeinflusst andere gesamten Prozess beeinträchtigen. Prozesse nicht. Dipl.-Ing. (FH) Michael Herzog  Threads Threads vs. Prozesse Ein Thread wird auch als Aktivitätsträger oder leichtgewichtiger Prozess benannt. Ein Thread ist immer Teil eines Prozesses und wird im Adressraum des Prozesses ausgeführt. Ein Prozess kann viele Threads gleichzeitig enthalten. Diese Threads werden unabhängig voneinander (ähnlich Prozessen) abgearbeitet. Ein Prozess besteht bei seiner Erzeugung aus einem Thread. Der Thread wird implizit erzeugt wenn der Prozess erzeugt wird. Dipl.-Ing. (FH) Michael Herzog  Threads Threads vs. Prozesse Prozess Thread Programm in Ausführung Leichter Prozess Vollständig isoliert Gehört zu einem Prozess Speicher nicht gemeinsam genutzt Speicher wird gemeinsam genutzt Ressourcenverbrauch hoch Ressourcenverbrauch geringer Hoher Zeitbedarf bei Niedriger Zeitbedarf bei Kontextwechsel Kontextwechsel Dipl.-Ing. (FH) Michael Herzog  Threads Die Abarbeitung von Threads ist ca. 10-100 mal schneller im Vergleich zu der Verarbeitung von Prozessen. Threads nutzen den gleichen Adressraum und erleichtert so grundsätzlich die Kommunikation zwischen Threads. Dipl.-Ing. (FH) Michael Herzog  Threads Erzeugung von neuen Threads Threads können sehr einfach erstellt werden: Der Code eines Threads ist eine normal definierte Funktion, die auch wieder andere Funktionen aufrufen kann. Threads werden durch die Verwendung von Systemaufrufen gestartet. Der Systemaufruf bekommt die Threadfunktion als Parameter übergeben. Dipl.-Ing. (FH) Michael Herzog  Threads Threads implementieren Threads sind i.d.R. im Kern implementiert, ähnlich zu den Prozessen. Threads haben dieselben Zustände wie Prozesse, die Bedeutung der Zustände ist identisch. Können in vielen Programmiersprachen und Systemen realisiert werden: C, C++, C#, Java, Python, Swift … Dipl.-Ing. (FH) Michael Herzog  Prozesssynchronisation Threads POSIX API pthread_create Erzeugen eines Threads pthread_exit Beenden eines Threads pthread_join Warten auf Ende eines Threads pthread_yield Aufgeben der CPU Dipl.-Ing. (FH) Michael Herzog  Threads Fork-Join-Modell Das Fork-Join-Modell ist ein Paradigma für die parallele Programmierung, das das Erstellen von Threads (fork) und das Zusammenführen von Threads (join) beinhaltet. Dieses Vorgehen wird gerne in rekursiven Algorithmen angewendet, bei denen eine große Aufgabe in kleinere Teilaufgaben zerlegt werden kann. Jeder Thread oder Prozess kann sich auf eine Teil-Aufgabe konzentrieren, und am Ende werden die Ergebnisse kombiniert, um das Gesamtergebnis zu erhalten. Dipl.-Ing. (FH) Michael Herzog  Threads Fork-Join-Modell Dipl.-Ing. (FH) Michael Herzog  Threads Durch den Aufruf der Funktion fork() in einem Programm, werden Threads ebenso wie der gesamte Adressraum des Prozesses kopiert. Es entsteht eine exakte Kopie des aufrufenden Prozesses, einschließlich aller Threads und deren Zustände! Dipl.-Ing. (FH) Michael Herzog Dipl.-Ing. (FH) Michael Herzog 09  Interprozesskommunikation Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Was ist IPC? Die Interprozesskommunikation (IPC) bezieht sich auf Mechanismen und Techniken, die es Prozessen ermöglichen, miteinander zu kommunizieren, sei es auf demselben Computer oder über ein Netzwerk hinweg. IPC ist grundsätzlich wichtig, wenn verschiedene Prozesse zusammenarbeiten müssen, Daten austauschen oder miteinander interagieren sollen. Die Wahl der geeigneten Methodik hängt von den Anforderungen der Anwendung ab. Faktoren wie Effizienz, Datenvolumen, Sicherheit und Komplexität spielen dabei eine Rolle. Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Synchrone IPC Synchrone Interprozesskommunikation (IPC) bezieht sich auf den Prozess, bei dem der Absender eines Signals oder einer Nachricht auf eine Bestätigung oder eine Antwort vom Empfänger wartet, bevor er mit der Ausführung fortsetzt. Dies stellt sicher, dass der Absender und der Empfänger synchronisiert sind und dass bestimmte Ereignisse oder Aufgaben abgeschlossen sind, bevor andere beginnen. Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Asynchrone IPC Asynchrone Interprozesskommunikation (IPC) bezieht sich auf den Prozess, bei dem der Absender eines Signals, einer Nachricht oder einer Anforderung nicht auf eine sofortige Antwort vom Empfänger wartet. Der Absender setzt seine Ausführung fort, während der Empfänger die Anfrage verarbeitet und möglicherweise zu einem späteren Zeitpunkt antwortet. Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Synchone / Asynchrone IPC synchron asynchron Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Mechanismen Es gibt verschiedene Mechanismen der Interprozesskommunikation, die je nach Anforderungen und Kontext verwendet werden können. Shared Memory Sockets Dateien Semaphoren Message Queues Mutexe Pipes Condition Variables Promises (Futures) Remote Procedure Call (RPC) Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Shared Memory Shared Memory ermöglicht es mehreren Prozessen, auf denselben physischen Speicherbereich zuzugreifen. Dadurch können die Prozesse effizient und schnell Daten austauschen, ohne dass eine explizite Kommunikation über Nachrichten erforderlich ist. Der gemeinsame Speicherbereich wird im RAM des Systems erstellt und kann von den beteiligten Prozessen gelesen und beschrieben werden. Die beteiligten Prozesse müssen sich, bei diesem Vorgehen, selbst koordinieren. Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Shared Memory Linux-Systemaufrufe: shmget Ein Segment erzeugen oder auf ein bestehendes zugreifen shmat Ein Segment an einen Prozess anhängen shmdt Ein Segment von einem Prozess lösen/freigeben shmctl Den Status eines Segments abfragen, es ändern oder löschen Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Dateien Prozesse können auch auf gemeinsame Dateien zugreifen, um Daten auszutauschen. Der Zugriff auf Dateien kann im Vergleich zu anderen IPC- Mechanismen langsam sein. Es ist wichtig, die Zugriffsrechte auf Dateien korrekt zu setzen, um die Sicherheit zu gewährleisten. Geeignete Synchronisationsmechanismen (z. B. Semaphoren, Mutexes) sind erforderlich, wenn mehrere Prozesse auf gemeinsame Dateien zugreifen. Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Message Queues Warteschlangen ermöglichen den Datenaustausch zwischen Prozessen. Dieser Mechanismus ist besonders nützlich, wenn strukturierte Daten zwischen Prozessen ausgetauscht werden müssen. Die Struktur der ausgetauschten Nachrichten muss zwischen den Prozessen vereinbart werden, um eine korrekte Kommunikation zu gewährleisten. Die Verwendung von Semaphoren oder anderen Synchronisations- mechanismen kann erforderlich sein, um sicherzustellen, dass der Zugriff auf die Queue ordnungsgemäß funktioniert. Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Message Queues Linux-Systemaufrufe: msgget MQ erzeugen oder auf eine bestehende zugreifen msgsnd Eine Nachricht in eine MQ schreiben (schicken) msgrcv Eine Nachricht aus einer MQ lesen (empfangen) msgctl Den Status einer MQ abfragen, ändern oder löschen Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Pipes Pipes ermöglichen es, dass der Output (Standardausgabe) eines Prozesses direkt als Input (Standard­eingabe) für einen anderen Prozess dient. Pipes sind unidirektional. Es gibt jedoch Möglichkeiten, zwei Pipes zu erstellen, um eine bidirektionale Kommunikation zwischen zwei Prozessen zu ermöglichen. Pipes haben in der Regel eine begrenzte Puffergröße, was bedeutet, dass zu viele Daten in der Pipe zu einem Blockieren des Schreibprozesses führen können. Pipes arbeiten nach dem FIFO-Prinzip (First-In-First-Out). Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Pipes POSIX API pipe Pipe mit zwei Endpunkten erzeugen write In Pipe schreiben read Von Pipe lesen close Mit pipe geöffnete Pipe schließen popen Prozess starten (benutzt fork) und Pipe zum Prozess öffnen pclose Mit popen geöffnete Pipe schließen Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Pipes POSIX API mkfifo Named Pipe erzeugen open Named Pipe öffnen close Named Pipe schliessen read Aus Named Pipe lesen write In Named Pipe schreiben Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Pipes in der Shell Pipes in der Shell werden verwendet, um zwei oder mehr Befehle zu kombinieren. Dabei fungiert die Ausgabe eines Befehls als Eingabe für einen anderen Befehl, und die Ausgabe dieses Befehls kann als Eingabe für den nächsten Befehl fungieren … Es kann auch als temporäre Verbindung zwischen zwei oder mehr Befehlen / Programmen / Prozessen verstanden werden. Die Kommandozeilen- programme, die die weitere Verarbeitung übernehmen, werden oft als Filter bezeichnet. Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Pipes in der Shell "|" anonyme Pipe Bsp.: ps ax | less ">" benannte Pipe Bsp.: mkfifo mypipe ls > mypipe Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Promises (Futures) Promises oder Futures sind in der Regel Konzepte für die asynchrone Programmierung, bei der ein Programm auf ein Ergebnis oder eine Rückmeldung von einer asynchronen Operation wartet, ohne dabei den Haupt-Thread zu blockieren. Diese Konzepte werden oft in Sprachen wie JavaScript, Python (als Promise bzw. Future), oder in Frameworks wie Java's CompletableFuture verwendet. Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Promises (Futures) Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Sockets Die Verwendung von Sockets ist besonders geeignet, wenn die Kommunikation zwischen verschiedenen Rechnern erforderlich ist oder wenn eine verbindungsorientierte Kommunikation (wie bei TCP) gewünscht wird. Bei der Verwendung von Sockets über das Internet sollten Sicherheitsaspekte berücksichtigt werden, wie z. B. Verschlüsselung für die Vertraulichkeit der Daten. Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Sockets POSIX API socket Socket erzeugen socketpair Zwei Sockets erzeugen, ähnlich pipe read, recv Aus Socket lesen write, send In Socket schreiben close Socket schließen select warten auf Socketaktivität poll warten auf Socketaktivität Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Sockets Die Operationen send und recv können beliebig lange dauern. Dadurch können Prozesse / Threads auf unbestimmte Zeit blockieren! Um dem Problem des Blockierens entgegenzuwirken, wird der Systemaufruf select eingesetzt. Dieser Aufruf dient als Multiplexer für mehrere Sockets (File- Descriptors: fdts). Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) How one thread listens to many sockets with select in C. Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Condition Variables Condition Variables dienen der Synchronisation von Threads in einem Multithreading-Kontext. Threads werden darüber informiert, dass eine bestimmte Bedingung erfüllt wurde oder dass eine bestimmte Ressource verfügbar ist. Normalerweise sind diese Variablen auf Threads innerhalb desselben Prozesses beschränkt und nicht direkt für die Interprozesskommunikation zwischen verschiedenen Prozessen nutzbar. Dipl.-Ing. (FH) Michael Herzog  Interprozesskommunikation (IPC) Remote Procedure Call (RPC) Es wird einem Programm ermöglicht, eine Funktion (oder Prozedur) auf einem entfernten Rechner oder in einem anderen Adressraum auszuführen, als wäre sie lokal vorhanden. Es abstrahiert die Netzwerkkommunikation und ermöglicht Entwicklern, sich auf die Logik ihrer Anwendungen zu konzentrieren. Verschiedene Implemen- tierungen von RPC existieren für unterschiedliche Plattformen und Programmiersprachen. Dipl.-Ing. (FH) Michael Herzog Dipl.-Ing. (FH) Michael Herzog 10  Scheduling Dipl.-Ing. (FH) Michael Herzog  Scheduling Was ist Scheduling? Scheduling (Planung) bezieht sich auf den Prozess, wie das Betriebssystem die Ausführung von Aufgaben (Prozessen, Threads, …) auf einem Computer plant und verwaltet. Das Hauptziel des Schedulings ist es, die Ressourcen des Systems effizient zu nutzen, um die Anforderungen der Benutzer und des Systems selbst zu erfüllen. Scheduling ist ein kritisches Element im Betriebssystemdesign, da es direkten Einfluss auf die Leistung und die Benutzererfahrung hat. Die Auswahl der richtigen Scheduling-Strategie hängt von den spezifischen Anforderungen des Systems und der Art der ausgeführten Aufgaben ab. Dipl.-Ing. (FH) Michael Herzog  Scheduling Aufgaben eines Schedulers Prozessorzuweisung: Entscheidet, welcher Prozess als nächstes auf dem Prozessor ausgeführt werden soll. Prozesswechsel: Führt den Wechsel von einem laufenden Prozess zu einem anderen durch. Prioritätszuweisung: Bestimmt die Priorität von Prozessen, um sicherzustellen, dass wichtige Aufgaben bevorzugt behandelt werden. Warteschlangenmanagement: Verwaltet Warteschlangen von Prozessen, die darauf warten, auf dem Prozessor ausgeführt zu werden. Dipl.-Ing. (FH) Michael Herzog  Scheduling Entscheidungsfaktoren CPU-Auslastung: Maximierung der CPU-Auslastung, um den Prozessor effizient zu nutzen. Durchsatz: Anzahl der abgeschlossenen Aufgaben pro Zeiteinheit. Wartezeit: Minimierung der Wartezeit der Prozesse in der Warteschlange. Umlaufzeit: Gesamtzeit, die ein Prozess benötigt, um abgeschlossen zu werden. Antwortzeit: Zeit zwischen der Anforderung eines Benutzers und der ersten Reaktion des Systems. Dipl.-Ing. (FH) Michael Herzog  Scheduling Nicht präemptives Scheduling Nicht präemptives Scheduling ist eine Art von Prozessscheduling, bei dem der laufende Prozess nicht unterbrochen werden kann, bis er seine CPU- Zeitscheibe vollständig aufgebraucht hat oder eine andere Blockierungs- bedingung eintritt. Es wird häufig in einfachen Systemen oder in Batch-Verarbeitungs- umgebungen eingesetzt, in denen Vorhersagbarkeit und einfache Implementierung wichtiger sind als eine schnelle Reaktion auf Benutzerinteraktionen. Dipl.-Ing. (FH) Michael Herzog  Scheduling Präemptives Scheduling Präemptives Scheduling ist ein Scheduling-Algorithmus in Betriebssystemen, bei dem der Betriebssystemkern die Kontrolle über die CPU von einem laufenden Prozess übernehmen kann, um einem anderen Prozess die Ausführung zu ermöglichen. Im präemptiven Scheduling kann der Betriebssystemkern einen laufenden Prozess unterbrechen und einem anderen Prozess die CPU-Zeit zuweisen, wenn bestimmte Bedingungen erfüllt sind. Dipl.-Ing. (FH) Michael Herzog  Scheduling Prioritätengesteuertes Scheduling Das prioritätengesteuerte Scheduling ist eine Scheduling-Strategie, bei der die Ausführungsreihenfolge der Prozesse von deren Prioritäten abhängt. Jeder Prozess wird einer bestimmten Priorität zugeordnet, und der Scheduler wählt den Prozess mit der höchsten Priorität zur Ausführung aus. Es gibt verschiedene Varianten und Implementierungen von prioritätengesteuertem Scheduling, einschließlich präemptiver und nicht präemptiver Ansätze. Prioritätengesteuertes Scheduling wird in Echtzeitsystemen und in vielen anderen Systemen verwendet, um sicherzustellen, dass wichtige oder zeitkritische Aufgaben bevorzugt behandelt werden. Dipl.-Ing. (FH) Michael Herzog  Scheduling Zeitscheiben-Scheduling Das Zeitscheiben-Scheduling (Round Robin) ist eine spezielle Form des präemptiven Schedulings, bei dem jeder Prozess für eine festgelegte Zeitscheibe auf dem Prozessor ausgeführt wird. Wenn die Zeitscheibe abgelaufen ist, wird der Prozess unterbrochen, und der Scheduler wählt den nächsten Prozess aus der Warteschlange aus. Dieser Vorgang wiederholt sich zyklisch, wodurch jeder Prozess die CPU-Zeit in kleinen Intervallen erhält. Zeitscheiben-Scheduling wird oft in Betriebssystemen für Mehrbenutzer- umgebungen verwendet, um sicherzustellen, dass verschiedene Benutzer oder Aufgaben fair und reaktionsfreudig behandelt werden. Dipl.-Ing. (FH) Michael Herzog  Scheduling Weitere Scheduling-Strategien: First Come First Served Shortest / Longest Process Next Shortest / Longest Remaining Time Next Highest Response Ratio Next Earliest Deadline First Fair-Share-Scheduling Multilevel-Scheduling … Dipl.-Ing. (FH) Michael Herzog  Scheduling Scheduling unter Linux Dipl.-Ing. (FH) Michael Herzog  Scheduling Completely Fair Scheduler (CFS) Der Completely Fair Scheduler ist ein Prozess-Scheduling-Algorithmus, der im Linux-Kernel verwendet wird. Es wurde entwickelt, um eine faire Verteilung der CPU-Ressourcen zwischen verschiedenen Prozessen oder Threads auf einem Linux-System sicherzustellen. Der CFS wurde erstmals im Kernel 2.6.23 eingeführt. Der CFS ist Teil der Bemühungen von Linux, eine bessere Leistung und Gerechtigkeit bei der Verteilung von Ressourcen in Mehrbenutzer- umgebungen zu erreichen. Es ist wichtig zu beachten, dass die Implemen- tierung und genutzten Algorithmen im Laufe der Zeit variieren können Dipl.-Ing. (FH) Michael Herzog  Scheduling Grundprinzipien des CFS: Fairness Jeder ausführbare Prozess oder Thread sollte proportional zur Anzahl der CPU- Ressourcen, die er benötigt, bedient werden. Keine feste Zeitscheiben Die Ausführungszeit wird dynamisch an die Anforderungen der Prozesse angepasst. Gewichtungen Jeder Prozess wird mit einem "Gewicht" assoziiert. Prozesse mit höherem Gewicht erhalten eine größere Zeitanteilung auf der CPU. Virtual Runtime Prozesse mit kürzerer vruntime haben eine höhere Priorität und werden bevorzugt behandelt. Gewicht und reale Ausführungszeit führen zur Berechnung der vruntime. Als Entscheidungsstruktur dient ein nach der vruntime sortierter Rot-Schwarz-Baum. Dipl.-Ing. (FH) Michael Herzog  Scheduling Beispiel der Funktionsweise des CFS: Dipl.-Ing. (FH) Michael Herzog  Scheduling Beispiel der Funktionsweise des CFS: Neue Prozesse können während d