Wie funktioniert Kooperatives Scheduling?
- Faden gibt die CPU freiwillig her (Scheduler::resume()), entweder direkt mit einem weiteren Thread oder Scheduler entscheiden lassen
(Noch erwähnt: Prämptiv wo die CPU weggenommen wird)
- Kontextwechsel zu nächstem Thread (Register sichern, Stack Pointer umbiegen, Register wiederherstellen, zurückspringen)

Welche Kriterien kann denn der Scheduler verwenden, um den nächsten Thread auszuwählen?
- Echtzeitkriterien
- Run-To-Completion (→ Rechenzentrum)
- „normaler“ Modus (Interaktive Fäden für Nutzerinteraktion, aber auch Hintergrundfäden)

Rechenzentrum: Wie intelligent Schedulen?
- eigentlichen langfristige Tasks ohne große Timer-Interrupts
- Timer ggf. auch ausschalten, um möglichst effizient zu arbeiten

Was ist jetzt aber, wenn sich ein Nutzer anmelden will?
- Wenn Nutzer angemeldet ein/zwei special CPUs für Interaktives Scheduling

Welche Arten von Interrupts gibt es noch neben Timer-Interrupts?
- Inter Process Interrupts
- Device-Interrupts

Wie funktionieren diese?
- Timer: innerhalb der CPU / der LAPIC
- IPI: Zwischen CPU's / deren LAPIC
- Device Interrupt: Von extern via IOAPIC

Welche Konfigurationsmöglichkeiten gibt es?
- IOAPIC Register

1. Masked
   
2. Level / Edge Triggered
   
3. Interrupt Vector
   
4. Delivery Mode (Round Roubin, Single CPU)
   

Wofür braucht man denn den Delivery-Mode?
- Single CPU: Cache Ausnutzen bei Häufigen Interrupts
- Round Roubin: Lastverteilung

Wofür braucht man denn Level bzw. Edge Triggered Interrupts?
- Level: z.B. Tastatur, Daten liegen im Buffer → solange Daten vorhanden sind
- Edge: Kurzer Impuls, z.B. Timer (da dann unklar, wann nicht mehr benötigt)

Was für Debugging-Möglichkeiten gibt es denn?
- Hardware-Emulation (kvm, qemu)
- Hardware-Debugging via Serial Port
- Hardware-Dings zwischen CPU und Socket
- printf() (geht natürlich nur, wenn Ausgabe bereits funktioniert)

Wie kann man dabei Race-Conditions mitkriegen?
- CPU anhalten → Dann Zustand anschauen (am besten kommen dann keine Timer-Interrupts)
- Compiler Fragen (je nach Compiler hat dieser Support dafür, Thread-Sanitisier, Pfadausdrücke, Annotierungen für locks (siehe JITTY))

Normales Semaphor implementieren (Pseudo-Code)

Irgendwie auf Deadlocks gekommen
- kurz erklärt, zwei Fäden die gegenseitig locken wollen

Welche Erweiterungen gibt es denn noch?
- P(n), V(n), also um mehr als 1 Inkrementen oder Dekrementieren
- P(a, b, c), V(a, b, c): Vektorsemaphore

Was müssten wir denn für die Semaphore mit +/- n ändern?
- Siehe SP2 Altklausur WS 23/24
- Einfach statt ++ ein += n und für – ein -= n

Was müssten wir denn für Vektorsemaphore ändern?
- while wartet auf mehrere Variablen
- mehr Threads wecken (entweder alle, oder bis wir einen finden, der passt)

Kombination aus beiden?
- Einfach n für jeden Parameter

Welche Schnittstellen müssen denn Treiber anbieten?
- read: z.B. Tastatur
- write: z.B. Serial Interface
- open/close: Resourcenverwaltung
- ioctrl: Alles mögliche

Irgend eine Frage zu Stacked Treibern
- Idee: Mehrere Treiber „aneinander anschließen“, um Treiber(teile) wiederzuverwenden (z.B. Dateisystem)
- Beispiel: Dateisystem (Hardware ansprechen, Blockverwaltung, eigentliches Dateisystem)
- Grafikeinheit (statt einzelne Pixel z.B. OpenGL)

Was stellt denn das Betriebssystem so einem Treiber bereit?
- IOPorts & Interrupt Verwaltung
- Interfaceverwaltung „nach oben“
- Speicherverwaltung (malloc)

Was müssen wir beim Kompilieren beachten?
- Keine Unterstützung durch Libraries, keinen gescheiten Speicher, keine Ausgabe, etc.
- müssen uns einiges selbst zusammen basteln (z.B. Ausgabe & Speicher)
- Linker entsprechend anweisen

An sich eine enstspannte Atmosphäre.
Auch wenn ich auf ein paar Dinge nicht sofort kam (printf-debugging, malloc für Treiber, kurzer Denkfehler bei Semaphoren), immer noch eine sehr gute Note.