Nun schauen wir mal uns Linux an und zwar beginnen wir mit der ersten, einer der ersten

Linux Varianten Version 2.4, wo wir so Epochen und Zeitquanten als die beiden wichtigen konzeptionellen

Begriffe für einen typischen Linux Scheduler halt hatten. Die zugewiesene Prozessorzeit für

die Prozesse wurde in den Epochen unterteilt. Man kann sich so eine Epoche grob so vorstellen,

dass das einmal so ein Durchlauf ist eines Schedulers über alle laufigen Prozesse. Alle,

die gerade zu einem bestimmten Zeitpunkt laufig sind, wurden denn in einer Epoche zusammengefasst.

So kann man eben auch sagen, dass praktisch am Beginn einer solchen Epoche eben alle laufigen

Prozesse ihr jeweiliges Zeitquantum erhalten haben und am Ende praktisch alle laufigen Prozesse

ihr Zeitquantum verbraucht haben. Die Zeitquanten um die es halt hier geht die variieren von Prozess

zu Prozess und sie variieren auch durchaus von Epoche zu Epoche. Grob hat man hier auch

Einstellmöglichkeiten von der Anwendungsseite mit dem Nice System Qual. Das definiert hier die

Zeitquantumsbasis, die letztendlich denn für jeden Prozess dann entsprechend einstellbar ist und die

wurde dann halt eben periodisch pro Tick eben neu berechnet. Sie nahm dann halt immer entsprechend

ab, sodass dann die Dringlichkeit, die Wichtigkeit eines solchen Prozesses den Prozess zu geteilt

zu bekommen, dann halt eben abnimmt, sodass dann andere Prozesse eben auch den mal die CPU

irgendwann bekommen konnten. So eine typische Größenordnung halt hier war so ein Zeitkontom von

um die zweieinhalb Millisekunden für so ein Prozess. Diese Werte, die man hier hat, die lieferten

dann letztendlich die sogenannte dynamische Priorität eines Prozesses, mit der man dann

eine entsprechende dynamische Anpassung für die Laufzeit eines solchen Prozesses dann nach

so einer Formel hier durchgeführt hat, um das nächste Quantum, Zeitquantum für den Prozess,

dann jeweils zu berechnen. Da sehen wir dann eben auch, dass die Prozesse eben unterschiedliche

Zeitquantumwerte halt bekommen. Das heißt also, die Verarbeitung der Prozesse lief denn nicht in

festen Zeitscheiben halt entsprechend ab. Es gab dann noch Unterstützung für Echtzeitprozesse,

die hatten statische Prioritäten von 0 bis 99. Je kleiner der Wert ist, umso höher denn die

Priorität. Es war eben doch auch tabellemäßig durchaus eine Grundidee dann organisiert. Aber

man muss hier schon so sehen, dass die Echtzeitfähigkeit hier sich nur auf schwache Echtzeit

bezog. Zumindest für die normalen Scheduler, wie er in Linux integriert ist. Es gab dann spezielle

Realtime-Varianten, die auch bis zur harten Echtzeit gingen. Aber das, was man normalerweise eben in dem

klassischen Linux-System denn drin hatte, war die Fähigkeit für die schwache Echtzeit. Das System

unterstützte unterschiedliche Einplanungsklassen, für die dann halt eine entsprechende Gütefunktion

verwendet worden ist, um zu berechnen, welcher Prozess jetzt praktisch den Vorzug für die

Prozessenzuteilung erhalten sollte. Da gab es grob drei Scanling-Klassen, FIFU, RR und dann eben

irgendeine andere, die dann für die normalen konventionellen Time-Sharing-Prozesse denn verwendet

worden sind. Alle Prozesse dieser verschiedenen Klassen waren in derselben Bereitliste organisiert.

Das heißt also, damit eben auch die Prozessauswahl, die sich denn im Wesentlichen auf so eine

Gütefunktion basierte, mit UN-Komplexität versehen war. Da wurde nicht einfach der Prozess der

vorne praktisch am Anfang der Liste steht halt genommen, sondern der musste erst gefunden werden,

entsprechend bei der, wo dann für jeden Eintrag die Gütefunktion ausgewertet worden ist. Der Wert,

den man betrachtet hat, V, hier in dem Beispiel, der mit jedem Prozess dann verbunden worden ist,

wurde dann so gedeutet, stand dann im Minus 1000 und dann wusste man, ist der Inet-Prozess,

ist das eine Null, denn war ein Prozess, dessen Zeitquantum im Verbrauch, das war der Wert zwischen

Null und 1000, dann hat der Prozess noch irgendein Zeitquantum verfügbar, dann würde man den,

der im kleinsten Zeitquantum hat oder wenn es ein Prozess ist, ein Eintrag ist, wo der Wert V über

1000 lag, dann war das ein Echtzeitprozess, dann wurde er bevorzugt betrachtet. Nun, diese Auswertung

bedeutete halt immer, über die komplette Liste halt rübergehen, die man da halt hat. Das ist

natürlich ein durchauses Skalierungsproblem, je größer die Anzahl der Einträge auf dieser

Liste ist, umso schlechter skaliert letztendlich diese Implementierung. Was hier noch erwähnungswert

ist, ist, dass die Prozesse bei der Auswahl durchaus einen Boost, also einen Bonus praktisch

erhalten konnten und zwar genau dann, wenn man Prozess identifiziert hat, dessen Vorgänger,

wenn man so hört, das ist ein laufender, wo der laufende Prozess mit dem jetzt betrachteten