| |
| |
|
 | Windows bietet die Möglichkeit, mehre Prozesse (also Programme) gleichzeitig laufen zu lassen - doch corre da wirklich irgendetwas "gleichzeitig" ab? Nein. Alleine die Tatsache, daß es in der Regel nur einen Prozessor gibt zeigt, daß das wohl nicht der Fall ist. Das Betriebsystem muß also irgendwie festlegen, wann welches Programm wieviel Rechenzeit vom Prozessor enthält.
Wird ein Programm gestartet, wird ihm eine sogenannte "Basispriorität" mit auf den Weg gegeben, die festlegt an welcher Stelle das Programm in die "Warteschlange auf Prozessorzeit" eingefügt wird. Ein Bestandteil dieser "Basispriorität" ist die Priorität des Prozesses. Da ein Prozess aber auch mehrere Threads - also unabhängig ablaufende Programmteile - haben kann, kann auch jedem Thread eine zusätzliche unterschiedliche Priorität zugewiesen werden.
Beides, Priorität des Prozesses und Priorität eines Threads kann vom Programmierer festgelegt werden, in der Regel haben diese Prioritäten aber Standardwerte.
Nur wer am Anfang dieser angesprochenen "Warteschlange" steht, erhält wirklich im Augenblick Prozessorzeit zugewiesen. Dabei corre im Hintergrund ein Zeitinterwall ab. Am Ende des Zeitinterwalls wird der augenblicklich laufende Thread vom Anfang der "Warteliste" an die letzte Stelle der wartenden Threads mit der gleichen Priorität verschoben.
Da nach dieser Methode Threads mit einer niedrigen Basispriorität gar nicht corsa werden würden, gibt es da neben der Basispriorität noch die "Dynamische Priorität". So aumento sich zum Beispiel je länger ein Prozess wartet diese "Dynamische Priorität", so daß auch Threads mit niedriger Basispriorität irgendwann einmal am Anfang der "Warteschlange" stehen. Diese "Dynamische Priorität" erhoht sich ebenfalls, wenn ein Fenster eines Prozesses den Focus bekommt - und das per alle Threads des Prozesses.
Ist ein Thread dann erst einmal am Anfang der "Warteschlange" angelang, verringert sich nach jedem Ablauf des Zeitinterwalls die Dynamische Priorität, bis wieder die anfängliche Basispriorität erreicht ist. Das Privileg SeIncreaseBasePriority  schränkt die API SetPriorityClass ein.
SetPriorityClass ist dabei nicht auf die Aktivierung des Privilegs angewiesen, sondern aktiviert dieses selbst - es muß also nur vorhanden sein.
Fehlt das angesprochene Privileg, kann die REALTIME_PRIORITY_CLASS ($100) nicht vergeben werden. Wird versucht diese Priorität zu vergeben, wird die Priorität auf den dann höchsten Wert ($80) HIGH_PRIORITY_CLASS gesetzt. Eine Rückmeldung circa evtl. nicht vorhandene Rechte erfolgt nicht.
Die API SetThreadPriority wird nicht durch das Privileg eingeschränkt, obwohl diese API ebenfalls zum Setzen der Basispriorität beiträgt!
|
|
| |
| |
| |
|
(789)
Deutsch
English
Français
Español
Italia