Nun der Klassiker des kooperativen Skeletalings, nämlich First Come First Serve.

Das ist ein faires Verfahren. Das ist auch sehr einfach zu implementieren.

Es basiert im Wesentlichen auf einer FIFO-Warteschlange.

Aber es heißt eben nicht, dass es ein unproblematisches Einplanungsverfahren ist, wie wir gleich sehen werden.

Bei FCFS werden die Prozesse nach ihrer Ankunftszeit eingeplant.

Wer zuerst kommt, malt zuerst. Und entsprechend dieser Reihenfolge, wie die Prozesse eintreffen,

also ankommen, wie sie in diese Warteschlange eingereiht werden, genauso in dieser Reihenfolge,

wenn die Prozesse dann auch abgearbeitet sind. Es ist ein nicht verdrängendes Verfahren.

Und es bedeutet eben, dass die Prozesse sich kooperativ verhalten müssen,

sodass dann jeder eine Möglichkeit hat, die CPU dann irgendwann zu bekommen.

Nur ist es ein gerechtes Verfahren auf Kosten einer Antwortzeit, die im Mittel einfach schlecht ist.

Es führen bestimmte Kategorie von Prozessen.

Das führt auf der anderen Seite auch durchaus dazu, dass ein Ausgabedurchsatz niedrig ist.

Und insbesondere genau dann, wenn wir einen Mix haben von kurzen und langen Rechenstößen,

also von unterschiedlich langen Prozessen.

Wenn wir eine Situation haben, wo die Prozesse alle gleich lang sind oder etwa gleich lang sind,

egal ob sie kurz sind oder lang sind, dann ist FCFS eigentlich ein ganz gutes Verfahren.

Eine andere Situation haben wir typischerweise nicht.

Wenn wir jetzt so Universalsysteme, etwa wie Linux oder so betrachten,

da haben wir genau dann diesen Mix von kurzen und langen Rechenstößen.

Und da sehen wir dann halt eben, dass die Prozesse mit den langen Rechenstößen eigentlich begünstigt werden.

Hinsichtlich des Anteils von CPU-Zeit, den sie bekommen,

dass die Prozesse mit den kurzen Rechenstößen eben benachteiligt werden.

Das Hauptproblem hier ist der sogenannte Convoy-Effekt.

Das ist eine Situation, wo wir kurze Prozesse haben, die einem langen Prozess oder langen Prozessen folgen.

Und kurze und lange Prozess bezieht sich im Wesentlichen immer auf die Rechenstöße.

Und der Convoy kommt dann praktisch dann zustande.

Dann muss man sich vorstellen, als wenn schnelle kleine PKWs auf einer Landstraße an einem LKW sozusagen vorbei wollen.

Die kurzen Prozesse reihen sich hinter dem langen Prozess in der Warteschlange zur CPU ein.

Wenn der lange Prozess sozusagen die CPU aufgibt, kooperatives Verfahren,

dann werden die kurzen Prozesse ganz schnell ihre Rechenstöße durchführen.

Kurze Prozesse sind interaktive Prozesse.

Das bedeutet, die haben für gewöhnlich kurze Rechenstöße und führen dann wieder eine Ausgabeoperation aus.

Die warten zum Beispiel auf die Eingabe über die Tastatur und wären dann wieder blockiert.

Sodass die Situation für die wieder so sein kann, dass wenn sie das nächste Mal bereitgestellt werden,

sie sich wieder hinter einem langen Prozess befinden und demzufolge wieder als Convoy in der Warteschlange aufreihen.

Und so heißt es im Endeffekt, dass im Mittel der eine Ausgabedurchsatz eben gering ist, der ist niedrig.

Und Prozesse mit kurzen Laufzeiten, die werden durchaus benachteiligt.

Das sieht man hier auch an diesem Beispiel ganz gut.

Ich habe hier einen Prozessmix von vier Prozessen A, B, C, D,

die zu unterschiedlichen Zeitpunkten im System eingespeist werden, die unterschiedlich lang sind.

Das sehen wir hier. Prozess A und Prozess C sind die kurzen Prozesse.

Prozess B und Prozess D sind die langen Prozesse.

Entsprechend ihrer Ankunftszeit werden die Prozesse denn eigentlich eingereitet in die Warteschlange.

Und auch in dieser Reihenfolge abgearbeitet, natürlich zu unterschiedlichen Zeitpunkten.

Wir sehen also, dass A, der startet sofort zum Zeitpunkt Null, B startet, wenn A zu Ende ist,

C startet, wenn B zu Ende ist, also zum Zeitpunkt 101 und D startet, wenn C zu Ende ist.

Wir sehen hier die Durchlaufzeit der Prozesse, die durchaus unterschiedlich ist,

auch sehr im Widerspruch durchaus stehen kann zu der Bedienzeit der Prozesse.

Die Bedienzeit wäre die Zeit, die der Prozess, die CPU besitzt.