Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 4 » Betriebssysteme » Scheduling

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

Nächste Überarbeitung
Vorherige Überarbeitung
pruefungen:hauptstudium:ls4:bs:bs-2018-03-14-2 [14.03.2018 14:43] – angelegt Vadrakpruefungen:hauptstudium:ls4:bs:bs-2018-03-14-2 [14.03.2018 16:14] (aktuell) Vadrak
Zeile 3: Zeile 3:
     - Habe hier einfach Aufgaben und Funktionen des Schedulers erklärt.     - Habe hier einfach Aufgaben und Funktionen des Schedulers erklärt.
   * **Wonach kann man beim Scheduling priorisieren?**   * **Wonach kann man beim Scheduling priorisieren?**
-    - Habe hier vorrangig Beispiele dafür gegeben, was für die Priorisierung ausschlaggeben sein kann (z.B. Bevorzugen interaktiver Prozesse, möglicht hoher Durchsatz, etc.), da ich die Fachbegriffe nicht alle im Kopf hatte. Das war aber völlig in Ordnung.+    - Ich habe Beispiele dafür gegeben, was für die Priorisierung ausschlaggeben sein kann (z.B. Bevorzugen interaktiver Prozesse, möglicht hoher Durchsatz, etc.), da ich die Fachbegriffe nicht alle im Kopf hatte. Das war aber völlig in Ordnung.
   * ** Ein weiterer Faktor zum Priorisieren ist auch die CPU, auf der ein Prozess das letzte mal gelaufen ist. Warum kann das ein sinnvolles Kriterium sein? **   * ** Ein weiterer Faktor zum Priorisieren ist auch die CPU, auf der ein Prozess das letzte mal gelaufen ist. Warum kann das ein sinnvolles Kriterium sein? **
-    - Moderne CPUs haben Caches, wenn ich den Thread auf der gleichen CPU laufen lasse, dann liegen potentiell die meisten Daten, die der Thread braucht, noch im Cache der CPU und somit läuft das Programm schneller. +    - Moderne CPUs haben Caches, wenn ich den Thread auf der gleichen CPU laufen lasse, dann liegen potentiell die meisten Daten, die der Thread braucht, noch im Cache der CPU und somit läuft i.d.R. das Programm schneller. 
-  * ** Jetzt hat man noch das Problem, dass potentiall ja immer nur der gleiche Thread dran kommt, wenn man nur nach der letzten CPU priorisiert, wie lässt sich das Problem lösen? **+  * ** Jetzt hat man noch das Problem, dass evtl. immer nur der gleiche Thread dran kommt, wenn man nur nach der letzten CPU priorisiert, wie lässt sich das Problem lösen? **
     - Habe eine Kombination aus Round-Robin (das was MPStuBS im Moment macht) und Priorisierung via letzter CPU vorgeschlagen. Also z.B. eine Run-Queue pro CPU, in die Threads, nachdem sie ihre Zeitscheibe aufgebraucht haben, hinten eingefügt werden.     - Habe eine Kombination aus Round-Robin (das was MPStuBS im Moment macht) und Priorisierung via letzter CPU vorgeschlagen. Also z.B. eine Run-Queue pro CPU, in die Threads, nachdem sie ihre Zeitscheibe aufgebraucht haben, hinten eingefügt werden.
   * ** Bei Multiprozessorsystemen mit einer einzelnen Run-Queue hat man ja das   * ** Bei Multiprozessorsystemen mit einer einzelnen Run-Queue hat man ja das
Zeile 25: Zeile 25:
     - Nein, da der andere Thread ja auch bereits schon einmal weggescheduled wurde, gibt er das Big Kernel Lock im Programmfluss garantiert wieder frei, weil er es auch schon mal gelockt haben muss.     - Nein, da der andere Thread ja auch bereits schon einmal weggescheduled wurde, gibt er das Big Kernel Lock im Programmfluss garantiert wieder frei, weil er es auch schon mal gelockt haben muss.
   * **Wenn das nicht richtig synchronisiert ist, gibt es da ja diverse Race-Conditions, die da vorkommen können oder?**   * **Wenn das nicht richtig synchronisiert ist, gibt es da ja diverse Race-Conditions, die da vorkommen können oder?**
-    - Neben anderen (Lost Update) gibt es vor allem noch ein Lost-Wakeup-Problem. Lost-Wakeup war wohl das Gewünschte.+    - Neben anderen (Lost Update) gibt es vor allem noch ein Lost-Wakeup-Problem. Lost-Wakeup war wohl das Gewünschte. Bin auch noch näher darauf eingegangen, wie genau es zum Lost-Wakeup-Problem kommt.
  
 ===== IPC ===== ===== IPC =====
Zeile 37: Zeile 37:
     - Hab hier gesagt, dass man Schreiboperationen am besten immer gebündelt vornehmen kann, so dass nicht für jede Operation die Pagefaultmechanik laufen muss.     - Hab hier gesagt, dass man Schreiboperationen am besten immer gebündelt vornehmen kann, so dass nicht für jede Operation die Pagefaultmechanik laufen muss.
   * **Hast du schon mal etwas von Raytracing gehört? Der genaue Ablauf ist für die Frage aber nicht unbedingt relevant. Worauf muss ich achten, um das im CIP (d.h. auf mehrere Rechner verteilt) schnell zu kriegen?**   * **Hast du schon mal etwas von Raytracing gehört? Der genaue Ablauf ist für die Frage aber nicht unbedingt relevant. Worauf muss ich achten, um das im CIP (d.h. auf mehrere Rechner verteilt) schnell zu kriegen?**
-    - Ich wusste tatsächlich nur, dass es irgendein Grafikalgorithmus ist; Man will das Bild in möglichst gleich große Stücke aufteilen, dass jede CPU ihren Bereich möglichst selbstständig berechnen kann. Eventuell müssen sich die einzelnen Rechner dann nur an den rändern unterhalten (scheint beim Raytracing aber keine Rolle zu spielen).+    - Ich wusste tatsächlich nur, dass es irgendein Grafikalgorithmus ist; Man will das Bild in möglichst gleich große Stücke aufteilen, dass jede CPU ihren Bereich möglichst selbstständig berechnen kann. Eventuell müssen sich die einzelnen Rechner dann nur an den Rändern unterhalten (scheint beim Raytracing aber nicht nötig zu sein).
   * **Alle Rechner brauchen ja die Szenerie, auf der sie rechnen sollen. Was muss ich dabei beachten?**   * **Alle Rechner brauchen ja die Szenerie, auf der sie rechnen sollen. Was muss ich dabei beachten?**
-    - Da ich das Verfahren nicht kannte, habe ich hier nochmal nachgefragt, ob sich die Szenerie im Laufe des Algorithmus verändert, oder ob sie gleich bleibt. Die Annahme war, dass sie sich nicht verändert, also habe ich gesagt, dass man die Szenerie dann ja nur am Anfang jedem Rechner schickenmuss und dieser sie dann am besten im eigenen Speicher vorrätig halten sollte, da Zugriffe dann deutlich schneller sind, weil sie lokal sind.+    - Da ich das Verfahren nicht kannte, habe ich hier nochmal nachgefragt, ob sich die Szenerie im Laufe des Algorithmus verändert, oder ob sie gleich bleibt. Die Annahme war, dass sie sich nicht verändert, also habe ich gesagt, dass man die Szenerie dann ja nur am Anfang jedem Rechner schicken muss und dieser sie dann am besten im eigenen Speicher vorrätig halten sollte, da Zugriffe dann deutlich schneller sind, weil sie lokal sind.
  
 ===== Nochmal Synchronisation ===== ===== Nochmal Synchronisation =====