Die Atmosphäre war entspannt. Vom Beisitzer wurden keine Fragen gestellt. Die Fragen haben sich immer auf dem vorherigen Thema entwickelt. Deswegen lassen sie sich nicht gut kategorisieren. Bei manchen Fragen wusste ich nicht gleich, worauf er hinauswollte. Zweimal bin ich gar nicht auf die richtige Antwort gekommen. Weil ich aber sonst zu jede Frage sofort detailiert antworten konnte, fiel das nicht ins Gewicht. Note war eine 1,0.

P: Erzählen sie mir doch mal was über die Entstehung von Betriebssystemen
S. *Erzählt von Bibliothekssystemen, Monlithen und Mikrokernels*

P: Warum ist denn ICP bei Mirkokernen problematisch?
S: Es ist langsamer als Syscalls.

P: Eigentlich macht das keinen großen Unterschied. Was passiert denn, wenn ich z.B. eine Film geschnitten habe und jetzt die 4GB in die Datei schrieben will?
S: Dann sendet die Anwendung einen IPI and den Filesystem Server und der macht einen Syscall um in den Speicher zu schreiben.

P: Und wo ist da ein Problem?
S: Wenn die App und der Server kein Shared Memory haben, müssen die Daten kopiert werden.

P: Wie implementiert man den Message passing mit Shared Memory?
S: Eine Queue, eine Semaphore für Zahl der gesendeten Nachrichten.

P: Woher weiß der Sender, dass der die Queue nicht voll ist?
S: Das könnte man mit einer Semaphore machen, die anzeigt, ob der Buffer voll ist. Der Sender wartet dann darauf, das er wieder schreiben kann. (das war nicht die erwartete ntwort, aber OK)

P: Nach welchen Kriterien kann man schedulen?
S: Z.B. Nach Reaktionszweit für interaktive Anwendungen,
Termineinhaltung bei Echtzeitanwendungen
oder Gleichverteilung der Zeit, wie bei Linux.

P: Wie könnte man eine solche Strategie umsetzen?
S: Bei Windows gibt es Priorisierung nach Reaktionszeit mit „Dynamic Boost“ wenn ein Prozess einen Interrupt bekommt.

P: Warum versucht Windows Prozesse immer auf dem gleichen Kern auszuführen?
S: Wegen dem Caching. Wenn ein Prozess ständig die Kerne wächselt, müssen die Daten neu geladen und dafür andere rausgeworfen werden.
Falls aber kein Prozess in der Warteschlange ist, sollte sich der Kern einen von einem anderen Kernen holen, sonst verschwendet er Zeit.

P: Wie kann man das umsetzen?
S: Mit einer Queue pro Kern

P: Was ist denn die Alternative?
S: Eine globale Queue. Wenn man z.B. Termine einhalten muss, muss ein Prozess auf dem nächsten freien Kern ausgeführt werden, statt auf den richtigen zu warten.

P: Was passiert denn wenn ein Prozess ein fork aufruft?
S: Dann wird der neue Thread in die Warteliste eingetragen.

P: Passiert sonst noch etwas?
S: Falls es einen wartenden Kern gibt, muss der mit einem IPI geweckt werden.

P: Wie implementiert man eine Lock?
S: Man kann es mit aktivem Warten implementieren, mit einem atomic exchange.

P: Ist das sinnvoll bei einem Einprozessor-System?
S: Nein, man wartet mindestens bis Ende der Zeitscheibe, weil der Thread, der das Lock besitzt, ausgelagert wurde.

P: Wie kann man das besser machen?
S: Mit passivem Warten, dann wird der Prozess erst einmal ausgelagert.

P: Können sie den Code dafür aufschreiben?
S: *Schreibt Code auf*

P: Worauf muss man noch achten?
S: Man muss Interrupts blocken. Sonst kann ein Lost-Wakeup entstehen, wenn das Lock zwischen der Prüfung und dem Schlafenlegen geöffnet wird.
Bei Mehrprozessor-Systemen braucht man außerdem noch ein Lock um diesen Abschnitt, weil das Lock parallel auf eindem anderen Kern geöffnet werden kann.

P: In welcher Reihenfolge macht man das?
S: Immer erst Interrupts blockieren und dann Mutex locken. Ansonsten kann es sein, dass nach dem Lock ein Interrupt kommt, der es auch locken will. Dann entsteht ein Deadlock.

P: Wie funktioniert das Schlafenlegen genau?
S: Der Scheduler wählt den Thread aus, der als nächstes drankommen soll.
Den gibt er an den Dispatcher, welcher den Threadwechsel durchführt.
Das ganze passiert mit der Assembly Funktion toc_switch.
Darin werden die callee-saved register gespeichert, auch SP.
Dann werden von dem neuen Thread die Register geladen.
Zuletzt wird ret ausgerufen. Da der Stackpointer getauscht wurde, zeigt er jetzt auf die Returnadresse nach dem Resume-Aufruf dieses Threads.
Wegen dem Wechsel von Adressräumen muss das im priviligierten Modus passieren.

P: Wie verhindert man ein Lost-Wakeup?
S: Wir machen das in MPStuBS auf der Epilogebene.

P: Wie kommt man dann wieder aus der Ebene raus?
S: Weil resume immer auf der Epilogebene aufgerufen wird, verlässt der neue Thread anschließend die Ebene.

P: Es gibt auch präemptives Scheduling. Wie implementiert man das?
S: Mit Timer-Interrupts. Der Prolog fordert einen Epilog an, der resume aufruft.

P: Was machen Prolog und Epilog im allgemeinen?
S: Der Prolog holt sich die neuen Daten vom Gerät und speichert sie zwischen.
Der Epilog trägt sie dann in eine gemeinsam mit den Anwendungen genutzte Datenstruktur ein.

P: Das ganze dauert länger, als wenn man alles im Prolog machen würde. Warum macht man es trotzdem?
S: Um möglichst kurz die Interrupts zu deaktivieren, denn Epiloge könne unterbrochen werden.

P: Warum möchte man möglichst kurz Interrupts sperren?
S: Damit keine Daten verloren gehen. (Gewollt war die Antwort, dass wichtige Interrupts, wie der vom Reaktorkühler, schnell dran kommen sollen)

P: Warum machen wir dann nicht auch das Auslesen der Daten vom Gerät im Epilog?
S: Auch, damit keine Daten verloren gehen. (Gewollt war die Antwort, dass sonst z.b. bei Nichtabholen des neuen Zeichens von Tastatur der Interrupt aktiv bleibt)

P: Treiber kommunizieren mit dem Betriebssystem in zwei Richtungen, was passiert da jeweils?
S: Zum einen greifen Anwendungen über das Betriebssystem auf Treiber zu. Dazu werden bei Linux z.B. die Funktionen open, close, read, write und ioctrl verwendet.
Außerdem nutzt der Treiber das Betriebssystem z.b. für Speichermanagement und Synchronisierung.