Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 4 » bs-2014-03-27   (Übersicht)

Prüfungsfach

Betriebssysteme (7,5 ECTS MPStuBS)

Prüfer

Daniel Lohmann, Gabor Drescher (hat nur protokolliert)

Was mich etwas überrascht hat:

Im Vergleich zu anderen Prüfern, die ich bisher hatte, bekam ich bei Hr. Lohmann immer einen skeptischen Blick wenn ich etwas erklärte. Lasst euch davon nicht verunsichern, denn der skeptische Blick kam bei mir auch, wenn ich Fragen richtig beantwortet hatte.

Was ist ein Betriebssystem?

Die Schnittstelle zwischen Hard- und Software. Das Betriebssystem verwaltet die Betriebsmittel und stellt sie der Software zur Verfügung. Dabei gibt es unterschiedliche Konzepte, was alles Aufgabe des Betriebssystems ist:

Beim Bibliotheksbetriebssystem wird nur eine Menge Treibern zur Verfügung gestellt, die von der Software verwendet werden kann oder nicht.

Der Monolith ist ein Superprogramm, dass sämtliche Zugriffe auf die Hardware steuert, die Programme voreinander schützt und die Ausführung explizit in Systemmodus und Anwendungsmoduns unterteilt.

Ein Mikrokernel ist ein abgespeckter Monolith, bei dem einige Funktionalitäten als eigener Server im Nutzermodus ablaufen. Ziel ist es, alles was man im Nutzermodus laufen lassen kann, auch im Nutzermodus laufen zu lassen.

Der Exokernel ist noch weiter abgespeckt, er multiplext im Prinzip nur die Hardware und stellt sicher, dass die Anwendungen voreinander geschützt sind.

Gibt's für die Anwendung von der Schnittstelle her einen Unterschied zwischen einem Monolith und einem Mikrokernel?

Bei einem Mikrokernel wird z.B. ein Dateizugriff zunächst an einen Datei-System-Server weitergeleitet, der selbst im Nutzermodus arbeitet. Dieser greift dann entweder direkt auf die Hardware zu oder über den Kernel.

Das war zwar vom Prinzip her richtig, was allerdings hier die richtige Antwort wäre: Es ist dem Programm eigentlich egal, ob ein Mikrokernel oder ein Monolith als Betriebssystem verwendet wird. Ein write-Aufruf beim Zugriff auf eine Datei sieht prinzipiell bei beiden Betriebssystemen gleich aus.

Ist das bei einem Exokernel genauso?

Bei einem Exokernel muss die Software sich selbst um Treiber, allgemein um den Zugriff auf die Hardware kümmern. Hier muss hinter diesem Write-Zugriff also noch ein eigener Treiber den die Software selbst mitbringt.

Hr. Lohmann malt die 3 Ebenen (0, 1/2, und 1) hin: Auf der unteren Ebene wird die Interruptbehandlung durchgeführt. Warum brauchen wir dann eigentlich die Epilogebene?

Bei der Bearbeitung der Interrupts werden andere Interrupts gesperrt, um Wechselwirkungen zu vermeiden. Um die Zeit in der Interrupts gesperrt sind zu reduzieren, wird nur das unbedingt notwendige in der untersten Ebene durchgeführt. Alles andere wird auf die Epilogebene verlagert.

Hier wäre es sicherlich gut gewesen, wenn man das mit einem Beispiel hätte belegen können: Wenn der Timer-Interrupt einen Kontextwechsel verursacht und parallel dazu ein Keyboard-Interrupt kommt, versuchen beide auf den Queue des Schedulers zuzugreifen. Das gilt es zu verhindern

Hr. Lohmann ist noch nicht abschließend zufrieden und skizziert eine ISR bei der nur im ersten Teil die Interrupts gesperrt sind und für die zweite Hälfte wieder freigegeben sind:

ISR {

cli

Prolog sti Epilog

}

Warum implementiert man die ISR nicht so und spart sich damit die Epilogebene?

(Siehe vorheriges Beispiel) Sowohl die Keyboard-ISR als auch die Timer-ISR greifen auf den Scheduler zu. Diese Zugriffe müssen gegeinander synchronisiert werden. Es ist also notwendig diese Zugriffe mit einer Semaphore zu sichern. Außerdem müssen dabei die Interrupts ausgeschaltet werden:

…

cli

Semaphore.lock()

kritischer Scheduler Zugriff

Semaphore.unlock()

sti

…

Warum müssen die Interrupts vor dem .lock() gesperrt werden?

Würden Sie danach gesperrt werden, käme es zu einem Deadlock, wenn ein Interrupt nach dem .lock() aber vor cli kommt. Dann wäre der kritische Bereich gesperrt, aber es könnte ihn kein anderer mehr freigeben. Für eine Freigabe wäre es notwendig, dass der abgebrochene Thread wieder vom Scheduler eingeplant wird. Dazu müsste der Scheduler aber wieder in den kritischen Bereich, der gesperrt ist.

Welche Betriebsmittel habt ihr bei MPStuBS verwaltet und wie habt ihr die gescheduled?

In erster Linie die CPU. In einer Queue wurden alle Threads verwaltet, die auf die CPU zugreifen wollen. Mit Hilfe eines Timers wurde nach Ablauf einer Zeitscheibe der aktuelle Thread gewechselt und der so gestoppte Thread wieder in die Queue eingefügt. Außerdem konnte ein Thread, der auf eine Ressource wie die Tastatur wartet, sich aktiv schlafen legen. Damit wurde er gestoppt und in die Queue der Tastatur eingehängt und ein anderer Thread wurde gestartet. So muss nicht bis zum Ablauf der Zeitscheibe gewartet werden.

Was kann beim Mikrokernel im Vergleich zum Monolithen in den Userspace ausgelagert werden? Scheduler und Dispatcher?

Der Scheduler kann ausgelagert werden, da er nur für die Auswahlstrategie des neuen Threads zuständig ist. Der Dispatcher muss weiterhin im Kernelmodus bleiben.

Was genau ist der kritische Bereich im Dispatcher, der nicht im Nutzermodus ablaufen kann?

Durch das Verändern des Stackpointers in toc_switch kann der aufrufende Thread mit den Stack.pop()-Befehlen auf den Kontext/Stack des anderen Threads zugreifen. Würde das im Usermodus durchgeführt werden, dann käme ein Trap. (Hier ist es wichtig, dass das Verändern des Stackpointers ansich kein kritischer Befehl darstellt, vielmehr der dadurch verursachte Wechsel des Stacks, der die Manipulation des anderen Stacks durch .pop()-Befehle ermöglicht)

Anmerkung

Ich habe mir die Freiheit genommen, vom tatsächlichen Prüfungsverlauf abzuweichen und gleich die richtigen Antworten aufzuschreiben, da ich öfters auf dem Schlauch stand und manchmal nur mit Hilfe weiter kam. Entsprechend war das Ergebnis auch nur zwischen 2 und 3.

Vorbereitung

Ich habe mit einem Komilitonen eine Zusammenfassung des Skripts erstellt. Dabei haben wir von vornherein alles Geschichtliche und viele Konkreten Implementierungen (Wie macht es Windows, wie macht es Linux) ausgeschlossen. Auch haben wir keine Register oder ähnliches gelernt. Das hat gut funktioniert.

Außerdem haben wir oft in den Code geschaut. Hierbei ist es wichtig den Code auch kritisch anzuschauen und sich zu fragen, warum mach ich das genau so und nicht anders? Oder: Was passiert wenn ich zwei Befehle vertauschen würde?

Feedback der Prüfer

Wenn es darum ging, Dinge zu beschreiben, wie wir sie in der Übung implementiert hatten, war ich sicher, bei Transfersfragen hatte ich so meine Probleme.