Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 4 » Betriebssysteme 7.5 ECTS Prüfung 16.03.2023   (Übersicht)

Betriebssysteme 7.5 ECTS Prüfung 16.03.2023

Fazit:

Volkmar ist sehr nett und äußerst gelassen. Ich war am Anfang sehr aufgeregt, aber konnte mich dann auch durch die ruhige Stimmung entspannen. Wenn man etwas nicht auf Anhieb weiß wird weiter gefragt und es werden kleine Tipps gegeben, bis Volkmar zufrieden ist. Dabei wird kein Druck aufgebaut, fand ich sehr angenehm. Die Note war am Ende sehr zufriedenstellend.

Vorbereitung:

Ich habe in den 2 Wochen vor der Klausur nochmal ganz entspannt die Videos durchgeschaut um die Themen durchzuarbeiten. Danach habe ich mit den alten Protokollen geübt und immer, wenn ich etwas nicht wusste nochmal auf den Vorlesungsfolien nachgelesen. Der Hauptteil der Vorbereitung ist aber auf jeden Fall das gründliche Bearbeiten der Übungen. Viele Fragen bauen auf dem Verständnis des eigenen Betriebssystems auf. Ich habe zusammen mit einem Freund gelernt, ich fand das hat sehr geholfen.

Prüfung:

Es gibt ja zwei verschiedene Arten von Interrupts und zwar Edge-Triggered und Level-Triggered Interrupts, was ist denn der Unterschied dazwischen?

  • Erklärt, dass Edge-Triggered eben nur Flankengesteuert signalisiert wird und damit auch verloren gehen kann
  • Erklärt, dass Level-Triggered signalisiert wird bis es abgeholt wird

Es gibt noch Shared Interrupts, wie funktioniert das?

  • Ich wusste nicht was genau Shared Interrupts sind und habe nachgefragt

Also ganz früher bei der PC-Architektur hatte man zum Beispiel 8 Interrupteingänge, aber was, wenn man 10 Geräte hatte?

  • Man muss alle Geräte abfragen (Polling), ob eben ein Interrupt vorliegt

Genau und wie funktioniert das Polling dann?

  • War sehr verunsichert und wusste erstmal nicht so recht was ich sagen soll
  • Bin dann aber darauf gekommen zu sagen, dass die Geräte zum Beispiel über Memory Mapped IO eingebunden sind und man dann eben an der entsprechenden Stelle im Speicher anhand eines Status-Flags erkennen könnte, ob das Gerät einen Interrupt gesendet hat / Daten zum Abholen hat
  • Das Flag muss dann natürlich genullt werden, wenn die Daten abgeholt wurden

Ok und wenn man dann eben zum Beispiel die Tastatur ein Interrupt signalisiert, wie läuft das ab?

  • Ich habe gesagt die Tastatur signalisiert eben dem Interruptcontroller den Interrupt und der wiederrum signalisiert der CPU, dass es einen Interrupt gibt
  • Da wurde ich unterbrochen

Aber bei einem Multiprozessor an welchen Interruptcontroller schickt die CPU da denn den Interrupt oder wie genau funktioniert das?

  • Es gibt einen großen IO Interruptcontroller
  • Der signalisiert dann einem Lokalen Interruptcontroller

Und woher weiß der IO Interruptcontroller an welchen lokalen Interruptcontroller der Interrupt gehen soll?

  • Es kann zum Beispiel an alle lokalen gesendet werden
  • An einen fest zugeordneten lokalen Interruptcontroller, zB.: Tastatur immer an den ersten
  • Oder an die CPU auf dem gerade der Prozess mit der niedrigsten Priorität läuft

Aber woher weiß dann der Interruptcontroller, welche CPU gerade den Prozess mit der niedrigsten Priorität hat?

  • Die CPUs müssen dem Interruptcontroller mitteilen welche Priorität ihre Prozesse haben und daran kann dann entschieden werden

Also dem lokalen Interruptcontroller wurde dann der Interrupt signalisiert, was passiert dann weiter in der Interruptbehandlung, also in Hard und Software?

  • CPU deaktiviert Interrupts
  • CPU sichert einige Register (IE, IP)
  • CPU holt sich die IRQ-Nummer vom Interruptcontroller
  • CPU holt sich mit der IRQ-Nummer aus der Interrupt-Vektor-Tabelle den Vektor und schreibt ihn in den IP
  • Dadurch wird implizit in den Interrupthandler gesprungen
  • Dort werden weitere Register gesichert
  • hier wurde ich wieder unterbrochen

Welche Register werden da denn noch gesichert?

  • habe dann mit etwas hin und her geschafft zu erklären, dass in Assembler die flüchtigen Register gesichert werden und die Hochsprache dann die nicht flüchtigen Register sichert

Ok und wie geht’s dann weiter?

  • Der Interrupt wird behandelt
  • Interrupthandler stellt Register wieder her
  • iret
  • CPU stellt Register wieder her
  • implizit Rücksprung in eigentliche Routine

Genau was muss dann im Prolog in der Interruptbehandlung mindestens passieren

  • eigentlich nur ein iret (falsch)

Naja aber dann kann es passieren, dass wir in der Interruptbehandlung fest stecken

  • da wusste ich nicht so recht wieso und habe dann gefragt ob das Problem, dass er beschreibt bei einem Tastatur Interrupt auch bei einem Timer bestehen würde

Nein

  • dann kam ich drauf
  • Die Level Triggered Interrupts müssen abgeholt werden, sonst würde z.B. die Tastatur durchgehend weiter ein Interrupt signalisieren und man würde durchgehend wieder in die Interruptbehandlung springen ohne das eigentliche Programm weiter abzuarbeiten

Ok dann haben wir Prolog Epilog Modell, wie genau ist das aufgebaut?

  • Ebenen erklärt

Das Modell nutzt die Funktionen enter(), leave() und relay(), was genau machen die und wie funktionieren sie?

  • grob erklärt

Welche Funktion findest du am schwierigsten?

  • leave

Dann schreib die mal bitte hin

  • in Pseudocode die Funktion hingeschrieben inklusive wann Interrupts ein und aus geschaltet werden, wann Lock geunlocked wird usw.

Ist es wichtig, dass zuerst lock.unlock gemacht wird und die Epilogebene als frei markiert wird und danach die Interrupts aktiviert werden oder ist die Reihenfolge egal?

  • Nein ist nicht egal Interrupts dürfen erst danach aktiviert werden, sonst Deadlock / Lost-Wakeup

Ok was ist das für ein Lock?

  • wir hatten ein ticketlock

Wie funktioniert denn genau ein Ticketlock?

  • genau erklärt

Ist es problematisch, dass die Counter endliche Zählervariablen sind?

  • Nein nicht, wenn die Variablen denselben Datentyp haben
  • Und nicht mehr Akteure warten, als es Zahlen gibt

Jetzt haben wir eine sequentialisierte Epilogebene, was passiert aber wenn eine CPU ein Tastatur Interrupt bekommt und eine andere CPU einen Timer Interrupt und beide fordern einen Epilog an?

  • Beide müssen die Epilogebene betreten synchronisiert betreten und werden dadurch sequentialisiert

Und was machen wir, wenn jetzt das Atomkraftwerk sagt ihm wird warm, dass kommt ja auch erstmal ans Ende der Epilogebene und wird dann eventuell verspätet abgearbeitet

  • Epilogwarteschlange könnte eine Art PriorityQueue sein
  • Je nach Interrupt-Priorität in die Liste einlegen

Kann man mit so einem Prolog Epilog Modell auch eine Datenbank synchronisieren

  • können ja aber sollte man eher nicht
  • Denn es dürften ja mehrere gleichzeitig lesen, solange niemand schreibt, aber beim Prolog Epilog Modell gibt es einen gegenseitigen Ausschluss

Dann wollte er genauer wissen, wie das denn besser gehen würde

  • habe dann grob das Konzept eines Monitors erklärt und wie wir das in der Vorlesung gelöst haben
  • Wichtig war ihm, dass ich erklärt habe, dass startRead(), startWrite(), endRead() und endWrite() sequentiell ausgeführt werden müssten und read bzw. write dann eben parallel ausgeführt werden können

Ich habe Sicher ein oder zwei Fragen vergessen, aber dass sollte es so ziemlich gewesen sein :)