Stimmung war sehr entstpannt. Er hat aber für meinen Geschmack zu lange auf Antworten zu sehr spezifischen Sachen gewartet, anstatt irgendwann zu sagen, dass man zum nächsten Thema wechselt. Ich habe bei manchen Fragen auch nicht direkt gewusst, auf was er hinaus wollte und weitere Hilfe gebraucht. Deswegen auch „nur“ eine 2,0.

Was ist der Unterschied zwischen Mutex und Semaphore?

• Ich habe erzählt, dass Mutexe nur gelocked oder unlocked kennen, und Semaphoren eine Zählervariable verwalten, die es ermöglicht, dass mehrere Threads gleichzeitig in den kritischen Abschnitt können.

Und was ist der Unterschied zu Ticketlock und Spinlock?

• Habe erklärt, dass ein Ticketlock mit einer ticket und einer lock Variable arbeitet und die miteinander vergleicht und je nachdem ob sie übereinstimmen, das lock gewährt oder wartet. Danach wusste ich aber nicht wo der Unterschied zwischen Mutex und Spinlock liegt und habe gemeint, dass es keinen gibt. Da war ich mir nicht sicher, ob das die richtige oder falsche Antwort war.

Schreib mal den Pseudocode für eine Semaphore auf.

• Ich habe erst die einfache Implementierung aufgeschrieben, mit einer while-Schleife und aktivem Warten.

Wie könnte man das mit passivem Warten implementieren?

• Dafür habe ich die Implementierung in ein if-else geändert mit Scheduler::block und Scheduler::wakeup() und erwähnt, dass die Semaphore ein waitingroom ist und eine queue nutzt.

Das würde aber zu Wettlaufsituationen führen, wie löst man das Problem?

• eine Guarded Semaphore nutzen, also in die Epilogebene wechseln.

Wie ist denn das Scheduler::block implementiert?

• Beim aktiven Thread wird ein waiting_flag gesetzt, damit beim anschließenden resume der Thread nicht mehr in die ready-queue gepackt wird. Stattdessen wird er in einer Warteliste enqueued.

Wenn enter aufgerufen wird und man dann in die Warteschlange schlafen gelegt wird, wie kommt man dann aus der Epilogebene wieder raus?

• Hier habe ich lange gehangen. Er wollte darauf hinaus, dass nach dem Scheduler::resume() und context_switch der nächste Thread das leave() aufruft.

Erklär mir doch mal, wie das mit dem context_switch funktioniert.

• Habe das sichern und holen der nicht-flüchtigen Register auf dem Stack, den Wechsel des Stackpointers mit den als Funktionsargumenten mitgegebenen Stackpointern und das sichern und holen des instruction pointers mittels call und ret erwähnt.

Mit dem Scheduler::block haben wir ein kooperatives scheduling. Wie funktioniert dann das präemptive scheduling?

• Es wird regelmäßig ein Timer-Interrupt ausgelöst, wodurch die watch ein Scheduler::resume aufruft und so scheduled.

Wie oft sollte denn dieser Timer-Interrupt kommen, also wie oft sollte gescheduled werden?

• Das hängt von der Art des Systems ab. Bei einem sehr interaktiven System sollte sehr oft gescheduled werden, bei einem Rechenzentrum zum Beispiel sehr selten?

Warum sollte bei einem Rechenzentrum nur sehr selten gescheduled werden?

• Da Durchsatz die höchste Priorität hat und schedulen einen gewissen overhead mit sich bringt.

Wie hoch ist denn der overhead beim schedulen?

• Er wollte nicht nur darauf hinaus, dass ich aufzähle, dass das Schedulen über Interruptbehandlung mit der watch und Scheduler::resume, dispatch und context_switch geht, sondern vor allem, dass durch den context_switch der Cache invalidiert wird und pages neu eingelagert werden müssen. Darauf bin ich erst mit Hilfe gekommen.

Wir waren schon bei dem Thema Semaphoren, die kann man auch dazu nutzen eine Mailbox umzusetzen, wie funktioniert das?

• Habe den Aufbau von send() und receive() mit Mutex für queue und has_elem-Semaphore erklärt. Dann habe ich noch eine mögliche 3. Semaphore erwähnt, mit der man überprüfen kann, ob in der queue noch Platz ist. Das macht Sinn, da man nie unendlich Speicher zur Verfügung hat.

Die Implementierung kann man im Endeffekt auch als synchronisierten bounded buffer verwenden. Bei der Tastatur-Behandlung könnte man das doch als send im Epilog und receive in der Anwendung verwenden, oder?

• Hier habe ich erstmal gesagt, dass das einfacher mit einer Semaphore umsetzbar ist, das war ihm aber natürlich nicht genug. Also habe ich auch erstmal überlegt, warum das schief gehen könnte. Bin nicht wirklich auf eine Lösung gekommen. Er meinte glaube ich, dass es, wenn der Interrupt auf dem gleichem core behandelt wird wie der Prozess der wartet, zu einem dead lock kommen kann, weil der Interrupt auch im Epilog an einer P()-Operation wartet. Bin mir aber auch nicht 100% sicher.

Das Betriebssystem bietet den Geräte-Treibern zum Beispiel die angesprochenen P und V Operationen mit Semaphoren an. Was werden noch für Funktionen angeboten?

• Die Frage hat mich verwirrt und ich wusste echt nicht, was ich antworten sollte. Habe erstmal von open,close,read,write geredet, aber das meinte er nicht. Er wollte einfach, dass ich Funktionen wie malloc nenne. Sehr komische Frage meiner Meinung nach und dann war die Prüfung auch vorbei.