Aufgabe 1)

Monolithische Architekturen Ein Architekturstil bei dem ein System als eine einzige, untrennbare Einheit implementiert wird.

• Alle Komponenten (UI, Geschäftslogik, Datenzugriff) in einem einzigen Codebase.
• Häufig schwer skalierbar und wartbar.
• Gegensatz zu Microservices.
• Hohe Abhängigkeiten zwischen Modulen.

a)

Diskutiere drei Hauptgründe, warum eine monolithische Architektur oft schwer skalierbar und wartbar ist. Beziehe Dich dabei auf Anforderungen und Herausforderungen in der realen Welt.

Lösung:

Warum eine monolithische Architektur schwer skalierbar und wartbar ist:

• Hohe Abhängigkeiten zwischen Modulen: In einer monolithischen Architektur sind alle Komponenten eines Systems eng miteinander verknüpft. Das bedeutet, dass Änderungen an einer Komponente häufig erfordern, dass auch andere Teile des Systems angepasst werden müssen. Dies kann den Wartungsaufwand erheblich erhöhen, da Entwickler sicherstellen müssen, dass ihre Änderungen die anderen Teile des Systems nicht negativ beeinflussen.
• Skalierbarkeit: In einer monolithischen Architektur wird das gesamte System als eine einzige Einheit ausgeführt. Das bedeutet, dass die Skalierung des Systems, um eine höhere Last zu bewältigen, auf der Ebene der gesamten Anwendung erfolgen muss, anstatt nur derjenigen Teile, die tatsächlich mehr Ressourcen benötigen. Dies kann ineffizient sein und erhebliche Kosten verursachen, da die gesamte Anwendung repliziert werden muss, auch wenn nur ein kleiner Teil der Anwendung zusätzliche Ressourcen benötigt.
• Komplexität bei der Implementierung neuer Funktionen: Neue Funktionen oder Änderungen an bestehenden Funktionen erfordern oft umfangreiche Tests, um sicherzustellen, dass die Änderungen keine unbeabsichtigten Nebenwirkungen haben. In einer monolithischen Architektur kann dies besonders herausfordernd sein, da es schwieriger ist, den Umfang der Tests zu begrenzen. Die Entwicklungszyklen können daher länger sein, was langsameres Release neuer Funktionen bedeutet und die Reaktionsfähigkeit auf Markt- und Kundenanforderungen beeinträchtigt.

b)

Vergleiche und kontrastiere die monolithische Architektur mit einer Microservices-Architektur. Erkläre dabei, wie die Skalierbarkeit und Wartbarkeit in diesen beiden Architekturstilen unterschiedlich gehandhabt werden.

Lösung:

Vergleich und Kontrast von monolithischer Architektur und Microservices-Architektur:

• Skalierbarkeit:
  • Monolithische Architektur: Bei einer monolithischen Architektur wird das gesamte System als eine einzige, große Einheit ausgeführt. Um die Leistung zu verbessern, wird das ganze System skaliert, was bedeutet, dass jeder Teil der Anwendung repliziert werden muss, selbst wenn nur ein kleiner Teil des Systems einen höheren Ressourcenbedarf hat. Dies kann sehr ineffizient und kostenintensiv sein.
  • Microservices-Architektur: In einer Microservices-Architektur wird das System in kleinere, unabhängige Dienste aufgeteilt. Jeder Dienst kann individuell skaliert werden, basierend auf seinen spezifischen Leistungsanforderungen. Dies ermöglicht eine weitaus effizientere Ressourcennutzung und kann die Kosten erheblich senken. Beispielsweise kann ein datenintensiver Dienst nur für sich selbst skaliert werden, während andere Dienste unverändert bleiben.
• Wartbarkeit:
  • Monolithische Architektur: Die Wartung eines monolithischen Systems kann extrem herausfordernd sein, da alle Komponenten stark miteinander verknüpft sind. Änderungen an einem Teil des Systems können unbeabsichtigte Nebenwirkungen auf andere Teile haben, was umfangreiche Tests und Überprüfungen erforderlich macht. Diese enge Kopplung erschwert auch das Verstehen und das Arbeiten an dem Code, insbesondere für neue Entwickler im Team.
  • Microservices-Architektur: Die Wartung von Microservices ist oft einfacher, da jeder Dienst unabhängig und meist kleiner im Umfang ist. Änderungen können in einem Dienst vorgenommen werden, ohne dass dies die anderen Dienste beeinträchtigt. Dies ermöglicht schnellere Entwicklungszyklen und einfachere Implementierung von Updates und neuen Funktionen. Außerdem können verschiedene Dienste von unterschiedlichen Teams verwaltet werden, was die Arbeitsteilung und Spezialisierung erleichtert.
• Abhängigkeiten und Modularität:
  • Monolithische Architektur: In einer monolithischen Architektur sind die Komponenten stark miteinander verknüpft und es gibt viele gegenseitige Abhängigkeiten. Dies kann die Modularität einschränken und dazu führen, dass Änderungen an einer Komponente andere Komponenten beeinträchtigen.
  • Microservices-Architektur: Microservices fördern eine lose Kopplung und hohe Modularität. Jede Komponente ist ein unabhängiger Dienst mit klar definierten Schnittstellen. Dies reduziert die Anzahl der Abhängigkeiten zwischen Diensten und ermöglicht eine klarere Trennung der Verantwortlichkeiten. Dadurch können Dienste unabhängig entwickelt, getestet und bereitgestellt werden.

c)

Stelle Dir vor, dass du für ein Softwareunternehmen arbeitest, das von einer monolithischen zu einer Microservices-Architektur wechseln möchte. Erkläre detailliert die Schritte und Überlegungen, die bei diesem Transformationsprozess berücksichtigt werden müssen, um sicherzustellen, dass der Übergang reibungslos verläuft.

Lösung:

Schritte und Überlegungen bei der Transformation von einer monolithischen zu einer Microservices-Architektur:

• Analyse der bestehenden Architektur: Zunächst musst Du eine detaillierte Analyse der bestehenden monolithischen Anwendung durchführen. Identifiziere die verschiedenen Module, ihre Abhängigkeiten und wie sie zusammenarbeiten. Diese Analyse hilft Dir, die verschiedenen Dienste zu definieren, die in der Microservices-Architektur benötigt werden.
• Ziele festlegen: Definiere die Hauptziele der Transformation. Dazu gehören eine verbesserte Skalierbarkeit, erhöhte Wartbarkeit und möglicherweise schnellere Entwicklungs- und Bereitstellungszyklen. Diese Ziele helfen dabei, den Fokus während des gesamten Transformationsprozesses zu bewahren.
• Schrittweiser Ansatz: Ein kompletter Wechsel von monolithisch zu Microservices auf einmal wäre zu riskant. Stattdessen solltest Du die Transformation schrittweise vornehmen. Beginne mit der Identifizierung von weniger kritischen Modulen oder Funktionen, die relativ leicht in Microservices umgewandelt werden können.
• Microservices definieren und entwerfen: Basierend auf der Analyse der bestehenden Architektur und den festgelegten Zielen solltest Du die verschiedenen Microservices definieren. Jeder Dienst sollte klein genug sein, um unabhängig zu sein, aber groß genug, um eine sinnvolle Funktion zu erfüllen. Erstelle für jeden Dienst klare Schnittstellen und API-Definitionen.
• Wahl der Technologie und Plattform: Bestimme die Technologie-Stacks und Plattformen, die für Microservices geeignet sind. Wähle ein Containerisierungs-Tool wie Docker und ein Orchestrierungstool wie Kubernetes. Entscheide Dich für Programmiersprachen, Datenbanken und andere Technologien, die gut zu den definierten Microservices passen.
• Implementierung der ersten Microservices: Beginne mit der Implementierung der ersten Microservices. Stelle sicher, dass sie vollständig von der monolithischen Anwendung unabhängig sind und ihre eigenen Datenbanken verwenden, um eine lose Kopplung zu gewährleisten.
• Infrastruktur und Deployment: Richten Sie eine Infrastruktur ein, die die Bereitstellung und Verwaltung von Microservices unterstützt. Dies kann Plattformen wie Kubernetes, CI/CD-Pipelines und Monitoring-Tools umfassen, um eine fehlerfreie Bereitstellung und Überwachung der Microservices sicherzustellen.
• Migration von Daten: Ein kritischer Aspekt der Transformation ist die Migration von Daten. Stelle sicher, dass die Datenmigration reibungslos erfolgt und dass die Integrität und Konsistenz der Daten erhalten bleibt. Dies kann erfordern, dass beide Systeme (monolithisch und microservices-basiert) für eine gewisse Zeit parallel betrieben werden.
• Testen und Validierung: Führe umfangreiche Tests durch, um sicherzustellen, dass die neuen Microservices korrekt funktionieren und keine negativen Auswirkungen auf bestehende Funktionen haben. Dies sollte Unit-Tests, Integrationstests und Systemtests umfassen. Automatisiere so viele Tests wie möglich.
• Schulung und Kommunikation: Schulung und Kommunikation innerhalb des Teams sind entscheidend. Entwickle Schulungsprogramme, um sicherzustellen, dass alle Teammitglieder vertraut mit der neuen Architektur und den damit verbundenen Technologien sind. Kommuniziere die Fortschritte und Ziele der Transformation regelmäßig an alle Stakeholder.
• Iterative Verbesserung: Nach der Implementierung der ersten Microservices solltest Du kontinuierlich Feedback einholen und den Prozess iterativ verbessern. Überwache die Leistung und Skalierbarkeit der Microservices und nimm Anpassungen vor, um die Architektur weiter zu optimieren.

d)

Wenn man annimmt, dass ein monolithisches System aus drei Hauptkomponenten besteht: User Interface (UI), Geschäftslogik und Datenzugriff, wie könnte eine Abhängigkeit zwischen diesen Komponenten in einer monolithischen Architektur mathematisch als Abhängigkeitsmatrix dargestellt werden? Zeichne ein Beispiel einer 3x3 Abhängigkeitsmatrix und diskutiere die Bedeutung der Einträge.

Lösung:

Darstellung und Diskussion einer Abhängigkeitsmatrix in einer monolithischen Architektur:

In einer monolithischen Architektur können die Abhängigkeiten zwischen den Hauptkomponenten User Interface (UI), Geschäftslogik und Datenzugriff als Abhängigkeitsmatrix dargestellt werden. Diese Matrix zeigt, wie stark jede Komponente von den anderen abhängig ist. Eine 3x3-Matrix könnte wie folgt aussehen:

	UI	Geschäftslogik	Datenzugriff
UI	0	1	1
Geschäftslogik	1	0	1
Datenzugriff	0	1	0

• Bedeutung der Einträge:
• 0: Keine Abhängigkeit zwischen den jeweiligen Komponenten.
• 1: Eine Abhängigkeit zwischen den jeweiligen Komponenten existiert.

In diesem Beispiel:

• Zeile 1: Die User Interface (UI) Komponente hat keine direkte Abhängigkeit von sich selbst (was sinnvoll ist), aber sie ist stark abhängig von der Geschäftslogik und dem Datenzugriff. Dies bedeutet, dass die UI-Logik direkt auf die Geschäftslogik und den Datenzugriff zugreifen und mit diesen interagieren muss.
• Zeile 2: Die Geschäftslogik hat eine Rückkopplung zum UI, was darauf hinweist, dass Änderungen in der Geschäftslogik auch die UI betreffen können. Außerdem hängt die Geschäftslogik vom Datenzugriff ab, was bedeutet, dass sie direkt auf die Daten zugreifen muss.
• Zeile 3: Der Datenzugriff hat keine Abhängigkeit von der UI, ist jedoch abhängig von der Geschäftslogik. Das bedeutet, der Datenzugriff wird durch Logik gesteuert, wie Daten verarbeitet oder abgerufen werden.

Diese Abhängigkeiten verdeutlichen, warum monolithische Architekturen schwer wartbar und skalierbar sind. Jede Änderung in einer Komponente (z.B. Geschäftslogik) könnte unbeabsichtigte Auswirkungen auf andere Komponenten (z.B. UI und Datenzugriff) haben, was umfangreiche Tests und Überprüfungen erforderlich macht. In einem solchen tightly coupled System wird die Wartung und Skalierbarkeit mit zunehmender Komplexität des Systems komplizierter und zeitintensiver.

Aufgabe 2)

Betrachte den Lebenszyklus eines Prozesses, der die verschiedenen Zustände durchläuft: erstellt, bereit, laufend, wartend und abgeschlossen. Ein Prozess wechselt durch Kontextwechsel zwischen diesen Zuständen. Die Erstellung eines Prozesses erfolgt durch \texttt{fork()} und \texttt{exec()}, während die Terminierung durch \texttt{exit()} und \texttt{abort()} erfolgt. Ein Wechsel zu 'bereit' tritt auf, wenn Ressourcen verfügbar sind, zu 'laufend' wird gewechselt, wenn CPU-Zeit zugeteilt wird, und zu 'wartend' wird gewechselt, wenn auf Ressourcen gewartet werden muss.

a)

Beschreibe detailliert den Vorgang der Prozesserstellung durch \texttt{fork()} und \texttt{exec()}. Gehe dabei auch auf die Unterschiede zwischen beiden Funktionen ein und erläutere deren typische Anwendungsfälle.

Lösung:

Um den Vorgang der Prozesserstellung durch fork() und exec() detailliert zu verstehen, ist es wichtig, die individuellen Funktionen und deren Unterschiede zu kennen:

• fork(): Die Funktion fork() wird verwendet, um einen neuen Prozess zu erstellen, indem ein exakter Duplikat des aktuellen Prozesses erstellt wird. Dieser neue Prozess wird als Kindprozess bezeichnet und erhält eine eigene Prozess-ID. Der Elternprozess und der Kindprozess setzen ihre Ausführung direkt nach dem fork()-Aufruf fort, wobei die Unterscheidung durch den Rückgabewert gemacht wird:
  • Im Elternprozess gibt fork() die Prozess-ID des Kindprozesses zurück.
  • Im Kindprozess gibt fork() den Wert 0 zurück.
  Beispielsweise:

   pid_t pid = fork(); if (pid == 0) { // Code for child process } else if (pid > 0) { // Code for parent process } else { // Fork failed }  

  Vorteile und typische Anwendungen:
  • Möglichkeit, parallele Prozesse zu erstellen.
  • Wird häufig in Multitasking- und Multiprozessor-Umgebungen verwendet, um separate Aufgaben parallel auszuführen.
• exec(): Nach dem Erstellen eines neuen Prozesses kann mit exec() ein neues Programm im Kontext des aktuellen Prozesses geladen und ausgeführt werden. Die Familie der exec()-Funktionen ersetzt den aktuellen Prozessbild (Code, Daten, Heap und Stack) durch ein neues. Sie führen das angegebene Programm aus, und falls erfolgreich, kehrt exec() nicht zurück: Das ausführende Programm ersetzt den Prozess, der exec() aufrief. Beispielsweise:

   execl('/bin/ls', 'ls', (char *)NULL);  

  Vorteile und typische Anwendungen:
  • Häufig verwendet, um einen neuen Prozess zu erstellen und dann ein anderes Programm in diesem Prozess auszuführen.
  • Typisch in Shell-Skripten und bei der Implementierung von Kommandoprogrammen, bei denen nach fork() ein spezielles Programm ausgeführt werden soll.
  • Nützlich, um verschiedene Programme innerhalb eines neuen Prozesses laufen zu lassen.

Unterschiede zwischen fork() und exec():

• fork() erstellt eine Kopie des aktuellen Prozesses, während exec() den aktuellen Prozess durch das neue Programm ersetzt.
• fork() gibt die Kontrolle an beide Prozesse zurück (Eltern und Kind), während exec() nur das neue Programm ausführt und nicht zurückkehrt, falls erfolgreich.
• exec() wird häufig unmittelbar nach einem fork() verwendet, um im neuen Prozess ein anderes Programm auszuführen.

Insgesamt kombinieren fork() und exec() die Prozesskopie und das Laden neuer Programme in einem Prozess, was in UNIX-ähnlichen Betriebssystemen eine flexible und mächtige Möglichkeit der Prozessverwaltung darstellt.

b)

Erläutere den Ablauf eines Kontextwechsels und warum dieser für Multitasking-Betriebssysteme essentiell ist. Welche Informationen müssen gesichert und wiederhergestellt werden, um den Kontextwechsel erfolgreich durchzuführen?

Lösung:

Ein Kontextwechsel ist der Prozess des Speicherns des Status eines laufenden Prozesses, damit ein anderer Prozess ausgeführt werden kann. Dies ist essenziell für Multitasking-Betriebssysteme, weil es ihnen ermöglicht, mehrere Prozesse scheinbar gleichzeitig auszuführen, indem zwischen ihnen gewechselt wird.

Ablauf eines Kontextwechsels

• Initiierung: Ein Kontextwechsel kann durch verschiedene Ereignisse initiiert werden, wie z.B. eine Unterbrechung (Interrupt), ein Systemaufruf oder wenn ein Prozess von 'laufend' zu 'wartend' wechselt.
• Speicherung des aktuellen Zustands: Der Zustand des aktuell laufenden Prozesses muss gesichert werden. Dazu gehört das Speichern der Inhalte der CPU-Register, des Programmzählers und anderer relevanter Architekturstatusinformationen in einem sogenannten Prozesskontrollblock (PCB).
• Planung: Der Scheduler des Betriebssystems entscheidet, welcher Prozess als nächstes ausgeführt werden soll. Diese Entscheidung basiert oft auf verschiedenen Scheduling-Algorithmen wie Round-Robin, Prioritätsbasierter Planung usw.
• Wiederherstellung des neuen Prozesses: Die gespeicherten Informationen des zu aktivierenden Prozesses (aus seinem PCB) werden in die CPU-Register und den Programmzähler geladen.
• Fortsetzung der Ausführung: Der neu ausgewählte Prozess wird fortgesetzt, als wäre er nie angehalten worden.

Wichtige Informationen für einen erfolgreichen Kontextwechsel

Um einen Kontextwechsel erfolgreich durchzuführen, müssen folgende Informationen gesichert und wiederhergestellt werden:

• CPU-Register: Alle allgemeinen und speziellen Register müssen gesichert werden, einschließlich des Programmzählers und des Statusregisters.
• Prozesszustand: Der aktuelle Zustand des Prozesses (z. B. bereit, laufend, wartend) muss im PCB gespeichert werden.
• Speicherverwaltung: Informationen zur Speicherzuordnung des Prozesses, z.B. Basis- und Limit-Register, Seitenverwaltungstabellen.
• CPU-Statusinformationen: Statusflags und andere kontextbezogene CPU-Informationen.
• Offene Dateien: Informationen über die vom Prozess geöffneten Dateien und deren Status müssen gesichert werden.
• Prozessidentifikation: Prozessnummer (PID), Elternprozessnummer (PPID) und andere Identifikationsmerkmale.

Kontextwechsel sind essenziell für Multitasking-Betriebssysteme, weil sie ermöglichen, dass mehrere Prozesse scheinbar gleichzeitig ausgeführt werden können. Sie maximieren die Nutzung der CPU und anderer Systemressourcen, sorgen für eine faire Ressourcenverteilung und verbessern die Systemresponsivität.

c)

Betrachte das folgende Pseudocode-Snippet:

 int pid = fork(); if (pid == 0) { printf('Child process'); } else if (pid > 0) { printf('Parent process'); } else { printf('Fork failed'); } 

Erkläre das Verhalten des Programms und wie der Lebenszyklus der beiden Prozesse, den Kinder- und Elternprozess, aussieht. Ergänze das Snippet, sodass der Kindprozess ein weiteres Programm mit \texttt{exec()} ausführt.

Lösung:

Schauen wir uns zunächst das Verhalten des gegebenen Pseudocode-Snippets an und erkläre den Lebenszyklus der beiden Prozesse.

Verhalten des Programms

 int pid = fork(); if (pid == 0) { printf('Child process'); } else if (pid > 0) { printf('Parent process'); } else { printf('Fork failed'); }  

Das Programm erstellt mittels fork() einen neuen Prozess:

• Wenn pid == 0, befindet sich der Code im Kindprozess und gibt 'Child process' aus.
• Wenn pid > 0, befindet sich der Code im Elternprozess und gibt 'Parent process' aus. Der Rückgabewert von fork() in diesem Fall ist die Prozess-ID des erstellten Kindprozesses.
• Wenn pid < 0, bedeutet dies, dass die fork()-Operation fehlgeschlagen ist, und die Meldung 'Fork failed' wird ausgegeben.

Lebenszyklus der beiden Prozesse

• Elternprozess:
  • Status: erstellt (nach Initialisierung des Programms)
  • Status: bereit (nach Initialisierung, aber vor Aufruf von fork())
  • Status: laufend (führt fork() aus und wartet auf das Ergebnis)
  • Nachdem der fork()-Aufruf abgeschlossen ist:
    • Wechselt zu bereit (wartet auf nächste CPU-Zeit) oder laufend (ausführen nach fork())
• Kindprozess:
  • Status: erstellt (nach Aufruf von fork())
  • Status: bereit (wartet auf CPU-Zeit)
  • Status: laufend (führt seine Anweisungen aus)
  • Status: abgeschlossen (nach Ausgabe von 'Child process')

Nun ergänzen wir das Snippet, sodass der Kindprozess ein weiteres Programm mit exec() ausführt:

  int pid = fork(); if (pid == 0) { // Kindprozess printf('Child process'); execl('/bin/ls', 'ls', (char *)NULL); // Falls execl fehlschlägt perror('execl failed'); exit(1); } else if (pid > 0) { // Elternprozess printf('Parent process'); } else { printf('Fork failed'); }  

Erklärung des erweiterten Codes:

• Im Kindprozess wird nach der Ausgabe von 'Child process' die Funktion execl() aufgerufen, die das aktuelle Programm durch das ls-Programm ersetzt.
• Falls execl() erfolgreich ist, führt der Prozess das ls-Programm aus und kehrt nicht zurück. Andernfalls gibt die Funktion eine Fehlermeldung aus und der Prozess terminiert mit einem Fehlercode (1).
• Der Elternprozess läuft parallel weiter und gibt 'Parent process' aus.

Durch diesen zusätzlichen Aufruf von exec() wird der Kindprozess ersetzt und führt ein neues, spezifiziertes Programm aus, was typisch für die Kombination von fork() und exec() ist.

d)

Berechne die Zeit, die für einen vollständigen Kontextwechsel benötigt wird, wenn das Sichern und Wiederherstellen des Prozessorzustands jeweils 5ns dauert, das Umschalten des Speicherkontexts 2ns und das Aktualisieren der Tabellen 3ns. Was sind die Nachteile eines zu häufigen Kontextwechsels in Bezug auf die Leistung?

Lösung:

Um die Zeit für einen vollständigen Kontextwechsel zu berechnen, addieren wir die Zeiten für das Sichern und Wiederherstellen des Prozessorzustands, das Umschalten des Speicherkontexts und das Aktualisieren der Tabellen:

• Sichern des Prozessorzustands: 5ns
• Wiederherstellen des Prozessorzustands: 5ns
• Umschalten des Speicherkontexts: 2ns
• Aktualisieren der Tabellen: 3ns

Die Formel zur Berechnung der Zeit für einen vollständigen Kontextwechsel lautet:

Totale Zeit = Zeit für Sichern des Prozessorzustands + Zeit für Wiederherstellen des Prozessorzustands + Zeit für Umschalten des Speicherkontexts + Zeit für Aktualisieren der Tabellen

Setzen wir die gegebenen Zeiten ein:

 Totale Zeit = 5ns + 5ns + 2ns + 3ns = 15ns 

Der vollständige Kontextwechsel dauert also 15 Nanosekunden.

Nachteile eines zu häufigen Kontextwechsels in Bezug auf die Leistung

Zu häufige Kontextwechsel können die Leistung eines Systems erheblich beeinträchtigen. Hier sind einige der Gründe:

• Overheads: Jeder Kontextwechsel verursacht einen gewissen Overhead, weil das System Zeit und Ressourcen benötigt, um den aktuellen Zustand zu speichern und den neuen Zustand zu laden. Wenn dies zu oft geschieht, führt dies zu einem höheren Zeitaufwand für Verwaltungstätigkeiten anstelle von tatsächlicher Anwendungsleistung.
• Cache-Effizienz: Ein Kontextwechsel kann den Inhalt des CPU-Caches unnötig verwerfen, wodurch die Cache-Hit-Rate verringert wird und der Prozess möglicherweise erneut auf langsameren Hauptspeicher zugreifen muss, was zu einer Erhöhung der Gesamtverarbeitungszeit führt.
• Speicherverwaltung: Häufige Änderungen im Speicherkontext und ständige Aktualisierungen von Tabellen (wie Seitenverwaltungstabellen) können die Effizienz der Speicherverwaltung beeinträchtigen und den gesamten Speicherbedarf erhöhen.
• Komplexität und Fehleranfälligkeit: Zu viele Kontextwechsel verkomplizieren die Systemsteuerung und erhöhen die Wahrscheinlichkeit von Synchronisationsproblemen sowie von harten oder weichen Fehlern im Betriebssystem.

Im Allgemeinen führen zu häufige Kontextwechsel zu einer erheblichen Verschlechterung der Systemleistung und reduzieren die Effizienz der Resourcennutzung im Multitasking-System.

Aufgabe 3)

Das Betriebssystem verwendet Paging und Segmentierung zur Speicherverwaltung, um den Hauptspeicher effizient zu nutzen. Bei Paging wird der Adressraum in feste Seiten (Pages) zerlegt, die im physischen Speicher als Seitenrahmen (Page Frames) abgebildet werden. Bei Segmentierung wird der logische Adressraum in variable Segmente wie Code, Daten oder Stack unterteilt. Virtuelle Adressen werden durch Seitentabellen (Page Tables) und Segmenttabellen (Segment Tables) in physische Adressen umgerechnet. Die Vorteile von Paging sind eine einheitliche Blockgröße, einfache Speicherverwaltung und keine externe Fragmentierung; die Vorteile von Segmentierung sind logische Strukturierung, flexible Speicherverwaltung und Schutzmechanismen.

b)

In einem System mit Segmentierung sei ein Prozess, der aus drei Segmenten besteht: Segment 0 für Code (Basisadresse: 0x2000, Länge: 1 KB), Segment 1 für Daten (Basisadresse: 0x3000, Länge: 2 KB), Segment 2 für Stack (Basisadresse: 0x5000, Länge: 1 KB). Bestimme die physische Adresse, die der virtuellen Adresse 0x100 im Segment 1 entspricht.

Lösung:

Um die physische Adresse für die virtuelle Adresse 0x100 im Segment 1 zu berechnen, müssen wir die Basisadresse des Segments zur virtuellen Adresse hinzufügen. Folgen wir diesen Schritten:

• Schritt 1: Informationen identifizierenWir haben folgende Informationen:
• Segment 0 (Code): Basisadresse = 0x2000, Länge = 1 KB
• Segment 1 (Daten): Basisadresse = 0x3000, Länge = 2 KB
• Segment 2 (Stack): Basisadresse = 0x5000, Länge = 1 KB
• Schritt 2: Virtuelle Adresse in Segment 1Die virtuelle Adresse ist 0x100 im Segment 1.
• Schritt 3: Physische Adresse berechnenWir müssen die Basisadresse von Segment 1 zur virtuellen Adresse hinzufügen:

Physische Adresse = Basisadresse von Segment 1 + Virtuelle Adresse im Segment 1

Physische Adresse = 0x3000 + 0x100 = 0x3100

Schritt 4: ZusammenfassungDie physische Adresse, die der virtuellen Adresse 0x100 im Segment 1 entspricht, ist 0x3100.

c)

Begründe die Vorteile von Paging im Vergleich zur Segmentierung hinsichtlich der Speicherverwaltung. Diskutiere insbesondere den Aspekt der externen Fragmentierung und wie Paging dieses Problem löst.

Lösung:

Bei der Diskussion der Vorteile von Paging im Vergleich zur Segmentierung hinsichtlich der Speicherverwaltung lassen sich mehrere Aspekte hervorheben:

• Einheitliche BlockgrößeBeim Paging wird der Adressraum in gleich große Blöcke, sogenannte Seiten (Pages), aufgeteilt. Dies erleichtert die Speicherverwaltung erheblich, da alle Seiten gleich groß sind:
• Einfachere Speicherverwaltung: Da alle Seiten dieselbe Größe haben, ist es einfacher, den verfügbaren Speicher zu verwalten und zuzuweisen. Der Betriebssystemkern muss sich nicht mit unterschiedlich großen Speicherblöcken auseinandersetzen, was die Komplexität verringert.
• Externe FragmentierungEin wesentlicher Vorteil von Paging gegenüber der Segmentierung ist die Vermeidung externer Fragmentierung:
• Bei der Segmentierung können Segmente unterschiedlich groß sein, was dazu führt, dass im physischen Speicher Lücken (fragmente) entstehen, wenn Speicherblöcke freigegeben und neue Speicherblöcke angefordert werden. Dies ergibt eine unoptimale Speicherverteilung und führt zu externer Fragmentierung.
• Paging löst dieses Problem, indem der gesamte Speicher in gleich große Seiten aufgeteilt wird. Auch wenn Seitenrahmen (Page Frames) unterschiedlicher Prozesse im physischen Speicher verteilt sind, bleibt die Größe der Einheiten konstant. Dies verhindert, dass Lücken entstehen, die durch unterschiedlich große Speicherblöcke verursacht werden könnten.
• Interne FragmentierungEs gibt jedoch einen kleinen Nachteil:
• Interne Fragmentierung: Beim Paging kann es zu interner Fragmentierung kommen, da der Speicher in festgelegten Seitenrahmen zugewiesen wird. Wenn ein Prozess weniger Speicher benötigt als die Größe eines Seitenrahmens, bleibt der restliche Speicher innerhalb dieses Rahmens ungenutzt.
• Einfacher Zugriff auf SpeicheradressenEin weiterer Vorteil von Paging ist der einfachere Zugriff auf Speicheradressen:
• Seitentabellen (Page Tables): Virtuelle Adressen werden durch Seitentabellen in physische Adressen umgewandelt. Jede virtuelle Adresse wird in eine Seitennummer (Page Number) und einen Offset aufgeteilt, was die Übersetzung effizient und schnell macht.
• ZusammenfassungDie Vorteile von Paging gegenüber der Segmentierung in Bezug auf die Speicherverwaltung lassen sich wie folgt zusammenfassen:
• Paging verhindert externe Fragmentierung durch die Aufteilung des Speichers in gleich große Seitenrahmen.
• Die einheitliche Blockgröße erleichtert die Speicherverwaltung und die Zuweisung von Speicherblöcken.
• Der Zugriff auf Speicheradressen erfolgt effizient über Seitentabellen.

d)

Ein System verwendet ein hybrides Speicherverwaltungssystem, das sowohl Paging als auch Segmentierung kombiniert. Segment 0 (Code) hat eine Länge von 8 KB, Segment 1 (Daten) hat eine Länge von 4 KB und jede Seite (Page) hat eine Größe von 4 KB. Ein Segment-Offset von 0x800 im Segment 0 wird auf Seite 1 abgebildet. Bestimme die physische Adresse, wenn die Basisadresse von Segment 0 bei 0x10000 liegt und die erste Seite (Page Frame) bei Adresse 0x2000 beginnt.

Lösung:

Um die physische Adresse in einem hybriden Speicherverwaltungssystem zu berechnen, das sowohl Paging als auch Segmentierung kombiniert, folgen wir diesen Schritten:

• Schritt 1: Informationen identifizierenWir haben folgende Informationen:
• Segment 0 (Code): Länge = 8 KB
• Segment 1 (Daten): Länge = 4 KB
• Seitengröße (Page Size): 4 KB
• Segment-Offset: 0x800 im Segment 0
• Basisadresse von Segment 0: 0x10000
• Die erste Seite (Page Frame) beginnt bei Adresse: 0x2000
• Schritt 2: Adresse im Segment berechnenDie virtuelle Adresse innerhalb des Segments ist:

Virtuelle Adresse = 0x10000 (Basisadresse von Segment 0) + 0x800 (Segment-Offset) Virtuelle Adresse = 0x10800

Schritt 3: Virtuelle Adresse in Seitennummer und Offset aufteilenDa jede Seite eine Größe von 4 KB (0x1000) hat, teilen wir die virtuelle Adresse in Seitennummer und Offset:

Seitennummer = \( \frac{0x800}{0x1000} = 0 \) (die Seitennummer ist 0, da 0x800 weniger als 0x1000 ist)Offset innerhalb der Seite = 0x800

Schritt 4: Adresse der ersten Seite berechnenDie Page-Frame-Adresse der ersten Seite (Seite 1) zu Segment 0 ist gegeben als 0x2000:

• Physische Basisadresse der Seite: 0x2000
• Die Offset innerhalb der Seite bleibt unverändert: 0x800

Schritt 5: Physische Adresse berechnenDie physische Adresse ergibt sich durch Addition der physischen Basisadresse der Seite und des Offsets:

Physische Adresse = Physische Basisadresse der Seite + Offset innerhalb der Seite Physische Adresse = 0x2000 + 0x800 = 0x2800

ZusammenfassungDie physische Adresse, die der virtuellen Adresse 0x800 im Segment 0 entspricht, wenn die Basisadresse von Segment 0 bei 0x10000 liegt und die erste Seite (Page Frame) bei Adresse 0x2000 beginnt, ist 0x2800.

Aufgabe 4)

Journaling-Dateisysteme

Journaling-Dateisysteme sind spezialisierte Dateisysteme, die zur Erhöhung der Konsistenz und Integrität durch Protokollierung von Änderungen in einem separaten Log (Journal) genutzt werden. Sie schützen vor Datenverlust bei Systemausfällen und verbessern die Recovery-Prozesse, indem sie einen schnelleren Systemstart nach einem Absturz ermöglichen. Änderungen werden in zwei Phasen durchgeführt: Zuerst wird das Log geschrieben, dann die eigentlichen Daten. Zu den häufigen Journaling-Dateisystemen gehören ext3, ext4, NTFS und ReiserFS. Es gibt verschiedene Typen von Journaling: Writeback, Ordered und Data. Allerdings entsteht durch den Journaling-Prozess ein zusätzlicher Overhead.

a)

Teilaufgabe 1:

Erkläre den Unterschied zwischen den verschiedenen Typen des Journalings (Writeback, Ordered, Data) bei Journaling-Dateisystemen. Gehe dabei insbesondere auf die Auswirkungen auf die Datenintegrität und die Systemperformance ein.

Lösung:

Teilaufgabe 1:

Journaling in Dateisystemen kann auf unterschiedliche Weisen durchgeführt werden, weshalb es verschiedene Typen des Journalings gibt: Writeback, Ordered und Data. Diese Typen unterscheiden sich hinsichtlich der Art und Weise, wie sie Datenintegrität und Systemperformance beeinflussen.

• Writeback Journaling:Beim Writeback Journaling wird nur das Journal (Log) im ersten Schritt geschrieben, und die eigentlichen Daten werden später auf die Festplatte geschrieben. Dies kann zu einer schnelleren Systemperformance führen, da Daten zunächst nur im Journal festgehalten werden. Jedoch beinhaltet diese Methode ein Risiko für Dateninkonsistenzen. Falls das System während des Übertragung der eigentlichen Daten abstürzt, könnten Daten verloren gehen, da sich die Daten im Journal und die eigentlichen Daten auf der Festplatte unterscheiden können. Die Integrität der Daten könnte dadurch beeinträchtigt werden.
• Ordered Journaling:Ordered Journaling stellt sicher, dass die Daten zuerst auf die Festplatte geschrieben werden, bevor das Journal aktualisiert wird. Dadurch steigt die Datenintegrität, da die eigentlichen Daten sicher und konsistent geschrieben werden, bevor das Journal seine Einträge macht. Dies führt zu einem gewissen Overhead und könnte die Systemperformance im Vergleich zu Writeback Journaling verringern, aber es bietet eine bessere Datenkonsistenz.
• Data Journaling:Beim Data Journaling werden sowohl die Metadaten als auch die eigentlichen Daten zuerst ins Journal geschrieben; erst danach werden diese auf die Festplatte übertragen. Diese Methode maximiert die Datenintegrität und Minimiert Datenverlust bei Systemausfällen, da sowohl die Metadaten als auch die Nutzdaten im Journal gesichert sind. Die Nachteile sind ein erheblicher Overhead und eine reduzierte Systemperformance, da die Daten im Wesentlichen doppelt geschrieben werden.

Zusammenfassend lässt sich sagen, dass Writeback Journaling eine höhere Systemperformance zulässt, jedoch auf Kosten der Datenintegrität. Ordered Journaling bietet einen guten Kompromiss zwischen Performance und Datenintegrität, während Data Journaling die höchste Datenintegrität sicherstellt, jedoch die Systemperformance am meisten beeinträchtigt.

b)

Teilaufgabe 2:

Angenommen, ein ext4-Dateisystem verwendet für seine Journaling-Operationen eine Blockgröße von 4 KB und das Journal umfasst 10 MB. Berechne den Overhead, der durch das Journaling bei einer Änderung von 100 MB an Nutzdaten entsteht, wenn das Dateisystem den 'Ordered' Mode verwendet. Gehe dabei von einer logarithmischen Zunahme des Journals aus und berücksichtige sowohl das Schreiben der Änderungen in das Journal als auch das anschließende Schreiben der Daten auf die Platte.

Hinweis: Verwende die folgenden Formeln, um den Overhead zu berechnen:

• Journalgröße pro Änderung: \frac{\text{Größe der Änderung}}{4 \text{ KB}} Blöcke
• Gesamtspeicheraufwand für das Journal: \text{Journalgröße pro Änderung} \times 2 (Initiales Schreiben ins Journal + endgültiges Schreiben der Daten)

Zeige alle Berechnungen ausführlich!

Lösung:

Teilaufgabe 2:

Für die Berechnung des Overheads bei einer Änderung von 100 MB Nutzdaten im 'Ordered' Mode des ext4-Dateisystems, werden wir die angegebenen Formeln verwenden. Gegeben sind:

• Blockgröße: 4 KB
• Journalgröße: 10 MB (dies wird verwendet, um den Gesamt-Overhead zu verstehen, aber für die Änderung selbst are alle Blöcke erstellt und geschrieben)
• Nutzdatenänderung: 100 MB

Schritte zur Berechnung:

1. Berechne die Anzahl der 4 KB-Blöcke in 100 MB:

• 1 MB = 1024 KB = 1024 / 4 Blöcke = 256 Blöcke pro MB
• 100 MB = 100 × 256 = 25600 Blöcke

2. Berechne den Journal-Speicheraufwand für Initiales Schreiben und endgültiges Schreiben der Daten:

• Journalgröße pro Änderung = Größe der Änderung / Blockgröße = 25600 Blöcke
• Gesamtspeicheraufwand für das Journal: 25600 Blöcke × 2 = 51200 Blöcke

3. Konvertiere die Blöcke zurück in Megabyte (MB), um den Overhead zu finden:

• 1 Block = 4 KB ➞ 4 KB = 4 / 1024 MB = 0.00390625 MB
• Gesamtspeicheraufwand für das Journal: 51200 Blöcke × 0.00390625 MB/Block = 200 MB

4. Der Overhead beträgt somit 200 MB.

Zusammengefasst: Bei einer Änderung von 100 MB an Nutzerdaten mit einem ext4-Dateisystem im 'Ordered' Mode, ergibt sich ein Overhead von 200 MB durch das Journaling. Dies liegt daran, dass die Daten zuerst ins Journal geschrieben und dann endgültig auf die Festplatte übertragen werden, was den Gesamtspeicheraufwand verdoppelt.