1 3.3.4 Dynamische Prioritäten Statische Prozess-Prioritäten sind sinnvoll, falls Prozesse in wenige Klassen einteilbar (3.3.3) Dynamische Prioritäten.

Präsentation zum Thema: "1 3.3.4 Dynamische Prioritäten Statische Prozess-Prioritäten sind sinnvoll, falls Prozesse in wenige Klassen einteilbar (3.3.3) Dynamische Prioritäten."—  Präsentation transkript:

1 1 3.3.4 Dynamische Prioritäten Statische Prozess-Prioritäten sind sinnvoll, falls Prozesse in wenige Klassen einteilbar (3.3.3) Dynamische Prioritäten bringen mehr Flexibilität, falls Verhaltensprofil der Prozesse nicht vorhersagbar; befördern typische Betriebsziele wie hohe Auslastung der Ressourcen, hoher Durchsatz.

2 2 Grundprinzip: die Peripherie so stark wie möglich beschäftigen, jedenfalls so stark, wie es das Verhaltensprofil der Benutzerprozesse hergibt; Folgerung: Dringlichkeit eine Prozesses orientieren  an seiner E/A-Intensität  an der Geschwindigkeit der benutzten E/A-Geräte demnach vermeiden, dass ein Gerät untätig ist, obwohl es Prozesse gibt, die es benutzen wollen.

3 3 2 Beispiele für Operationalisierung dieses Prinzips:  diskrete Vorgehensweise mit der Annahme Programme haben E/A-Phasen und CPU-Phasen:  in regelmäßigen Abständen E/A-Intensität messen und Priorität entsprechend umsetzen  kontinuierliche Anpassung an CPU-Verbrauch:  Rangzahl entspricht akkumulierter Rechenzeit, allerdings mit Dämpfungsfaktor für länger zurückliegende Aktivität

4 4 Bei Zeitscheibenende bzw. Blockade von Prozess p: bestimme neuen Rang von p und aktiviere den Prozess i mit minimaler Rangzahl rank i ohne Dämpfung: incr = elapsed rank p ‘ = rank p + incr rank p ‘ = akkumulierte CPU-Zeit

5 5 Bei Zeitscheibenende bzw. Blockade von Prozess p: bestimme neuen Rang von p und aktiviere den Prozess i mit minimaler Rangzahl rank i ohne Dämpfung:mit Dämpfung: incr = elapsedincr =  * elapsed * weight weight= weight + incr rank p ‘ = rank p + incr rank p ‘ = akkumulierte  > 0, anfangs weight = 1 CPU-Zeit(bei Überlauf von weight alle rank i und weight durch weight dividieren)

6 6 3.3.5 Deadline Scheduling bei Echtzeitsystemen System mit harten Echtzeit-Anforderungen (hard real-time system): auf bestimmte Ereignisse muß durch den behandelnden Prozess unbedingt binnen bestimmter Zeit reagiert werden  Prozessattribut deadline = zukünftiger Zeitpunkt, zu dem der Prozess beendet sein muß

7 7 Probleme: 1. keine Erfolgsgarantie, sofern man nicht vollständige Kenntnis vom Verhalten des externen Prozesses und sichere obere Grenzen für die Behandlungszeiten hat; 2. nicht gut geeignet, wenn sowohl hard deadlines als auch soft deadlines einzuhalten sind. Deadline Scheduling: zu jedem Zeitpunkt muß der Prozess mit der nächstliegenden Deadline aktiv sein

8 8 3.4 Synchronisation  Kurzzeitige Sperrsynchronisation ohne Prozesswechsel:  Unterbrechungsunterdrückung,  Spin Locks  Allgemeine Synchronisation mit Prozesswechsel bei Blockade:  Semaphore u.ä.

9 9 3.4.1 Unterbrechungsunterdrückung Achtung: Unterbrechungen - Zeitgeberunterbrechung, - Geräteunterbrechung, - Inter-Prozessor-Unterbrechung, -..... führen in der Regel zurProzessumschaltung - daher darf die Prozessumschaltung selbst nicht unterbrochen werden! Alternative Sicht: Operationen der Prozessverwaltung müssen unteilbar sein (interrupt inhibition)

10 10  Die Operationen der Prozessverwaltung arbeiten zuverlässig nur in einem Prozessorzustand mit vollständiger Unterbrechungsunterdrückung (interrupt inhibition), erreicht durch  Unterbrechungssystem, das beim Auftreten einer Unterbrechung weitere Unterbrechungen unterdrückt - nach Maßgabe des neu geladenen Prozessorstatus -  oder durch explizite Unterdrückung durch einen Maschinenbefehl DISABLE_INTERRUPTS ( ENABLE_INTERRUPTS hebt Unterdrückung auf)

11 11 Unterbrechungsunterdrückung ist einfaches und an verschiedenen Stellen im System eingesetztes Mittel zur kurzfristigen Sperrsynchronisation und dient auf einem Einprozessorsystem zu Realisierung unteilbarer Befehlsfolgen: DISABLE_INTERRUPTS();... // critical... ENABLE_INTERRUPTS(); ... // critical...  (vgl. NSP 1.2.2)

12 12 Beachte: Unterdrückte Unterbrechungen gehen nicht verloren („pending interrupts“); sie unterbrechen den Prozessor, sobald sie wieder zugelassen werden. Differenzierte Unterbrechungsunterdrückung (  3.5.1.4): 3.5.1.4  Unterbrechungsarten selektiv unterdrücken, z.B. über Bitfeld im Prozessorstatus  Unterbrechungsprioritäten berücksichtigen, z.B. über Prozessorpriorität im Prozessorstatus – dringlichere Unterbrechungen werden dann zugelassen ! Ungeeignet für zuverlässige Sperrsynchronisation !

13 13 3.4.2 Spin Locks Bei Mehrprozessorsystemen benötigt man zusätzlich Spin Locks (NSP 5.1.1), um kurze Befehlsfolgen unteilbar zu machen. Die Operationen auf einem Boole‘schen Spin Lock sind: LOCK(lock); bewirkt while(TAS(lock)); UNLOCK(lock); bewirkt lock = false;

14 14 Ein mit LOCK geschützter kritischer Abschnitt sieht so aus: DISABLE_INTERRUPTS(); LOCK(lock);... // critical... UNLOCK(lock); ENABLE_INTERRUPTS(); (Testfrage: warum muss die Schachtelung genau so aussehen und nicht anders?)

15 15 3.4.3 Semaphore (Zur Erinnerung: NSP 5.2.2) class Semaphore { private boolean lock = false; private int count = 0; private Set waitingList = new Queue ();... Zwecks Fairness wird die Warteliste gemäß FCFS bedient.

16 16 public void P() { DISABLE_INTERRUPTS(); LOCK(lock); count--; if(count < 0) { waitingList.enter(Process.current()); Process.current().block() } UNLOCK(lock); ENABLE_INTERRUPTS(); } Beachte: 1.kurzfristiges Sperren mit Unterbrechungsunterdrückung und Spin Locks ! 2.Wenn der Prozess blockiert, wird die Sperre an den aktivierten Prozess „weitergereicht“.

17 17 public void V() { DISABLE_INTERRUPTS(); LOCK(lock); count++; if(count <= 0) waitingList.remove().wake(); UNLOCK(lock); ENABLE_INTERRUPTS(); } } // end of class Semaphore