Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 4 » Allgemein   (Übersicht)

Allgemein

Angenehme Atmosphäre, es werden nach meinem Gefühl generell erst allgemeine Fragen gestellt, worauf dann welche zum Nachdenken folgen. Benotung ist mehr als fair, trotz einiger Hänger hat es bei mir noch für die 1.0 gereicht.

Debugging

Was gibt es denn für Möglichkeiten ein Betriebssystem zu Debuggen?

→ printf, emulatoren, gdb, Debugregister, Hardware Debugging (Lauterbach), etc. erklären

Es könnte ja jetzt sein, dass bspw. beim debugging mit printf das System keinen Fehler gibt, dann aber ohne printf kaputt geht. Wie kann denn so etwas zustande kommen?

→ printf ändert interen Zustand, bspw. Timing Geschichten könnten dann kaputt gehen

Interrupts

Sie haben ja erwähnt, dass bei der INT3 Instruktion ein Trap/Interrupt ausgelöst wird. Was passiert denn so beim einem Interrupt?

→ Weg des Interrupts von der Tastatur zur CPU + Behandlungsroutine erklären

Bei der Tastatur handelt es sich ja um eine gewisse Interrupt Art. Welche gibt es denn noch?

→ Level-Triggered, Edge-Triggered, Spurious und Shared Interrupts genannt. IPI war noch zusätlich gefragt.

Wofür kann man IPIs verwenden?

→ Scheduling, IPC, Semaphoren, …

Welches Problem könnte denn bspw. auftreten, wenn der Interrupt einer Tastur nicht Level-, sondern Edge-Triggered wäre?

→ Mehrere Interrupts auf der selben Leitung können kaputt gehen

Scheduling

Erklären sie mal den Weg des Schedulers

→ Watch, Scheduler::resume und Kontextwechsel erklärt

Wie wird denn beim Kontextwechsel der PC gesichert?

→ Durch den call

Nach welchen Kriterien kann man Schedulen?

→ Schedulingkriterien bei Windows (bspw. Cache Effekte nutzen) und beim O(1) Scheduler erklärt (Interaktivität)

IPC

Es gibt ja hier zwei Arten, wobei man dass eine mit dem anderen emulieren kann. Implementiere doch mal Message Passing mittels Shared Memory.

→ Mailbox implementiert

In deiner Variante erhöhst du ja den Counter erst nach dem unlock. Theoretisch könnte man es auch anders herum machen, das wäre aber weniger performant. Warum?

→ Bei erhöhen des Counters wird einem wartender Thread signalisiert. In der performanteren Variante (.v() nach .unlock()) kann der signalisierte Thread dann sehr wahrscheinlich direkt weiter machen (da er nicht am .lock() warten muss).

Fragen, die bei anderen gestellt worden sind

Was ist ein Beispiel, wo in Echtzeit gearbeitet werden muss?

→ DVD Brenner

Was ist ein großes Problem bei Bibliotheksbetriebssystemen?

→ Muss immer wieder neu kompiliert werden.

Impementiere einen Semaphor mit p(int).

→ In v() alle aufwecken, in p(int) Bedingung + Update anpassen und if durch while ersetzen.

Wie wird bspw. bei RRZE gescheduled?

→ HPC, Stapelbetrieb, möglichst wenig schedulen (Mehr Zeit für eigentliche Prozesse)