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

Beide Seiten, vorherige ÜberarbeitungVorherige Überarbeitung
Nächste Überarbeitung		Vorherige Überarbeitung
Nächste ÜberarbeitungBeide Seiten, nächste Überarbeitung
pruefungen:hauptstudium:ls4:bs:bs-2018-03-14-2 [14.03.2018 14:52] – Vadrakpruefungen:hauptstudium:ls4:bs:bs-2018-03-14-2 [14.03.2018 15:57] – Vadrak
Zeile 5: Zeile 5:
     - 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.     - 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 i.d.R. 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 =====