Prozessverwaltung

Prozesse in einem Betriebssystem sind ein wichtiges Konzept (zusammen mit der Speicherverwaltung).

Auch wenn wir hier beide Konzepte teilweise separat anschauen, arbeiten sie auf einem Computer-System Hand in Hand:

Ein Prozess benötigt immer auch Speicher, also ist das Speichermanagement betroffen.

Technisch ausgedrückt ist ein Prozess ein laufendes Programm.

Umgangssprachlich ausgedrückt können Sie sich ein Kuchenrezept vorstellen:

Man gebe in eine Schüssel: 200 g Mehl, 100 g Zucker und 3 Eier. Man verrühre nun die Zutaten und gebe den Teig in eine Backform. Anschließend backe man diesen Teig 1 Stunde lang bei 200 Grad.(Herold et al. 2017:41¹⁾)

Dieses Kuchenrezept für sich alleine macht noch nichts. Das steht einfach auf Papier da. Sobald wir es aber nehmen und daraus wirklich einen Kuchen backen, dann wird aus dem Kuchenrezept ein Prozess (in diesem Fall der Zubereitungsprozess).

Bei Betriebssystemen ist der Ablauf genau gleich: die auf einer SSD gespeicherten Programme wie beispielsweise Microsoft Word, Edge, Excel, etc. liegen als "Kuchenrezept", im konkreten Fall als eine Bitfolge irgendwo im Speicher vor. Die tun von sich aus nichts.

Nun können wir aber einen Prozess starten, und beim Starten eines Prozessen sagen wir dem Betriebssystem, es soll dieses oder jenes Programm starten. Das heisst, der "IP" (Instruction Pointer, siehe Modul "Rechnerarchitektur") wird auf die entsprechende Speicherstelle gesetzt und ab dort wird das Programm ausgeführt.

Zu MSDOS-Zeiten waren Prozesse noch nicht nötig. Da war es lediglich möglich, ein einziges Programm, z.B. von Diskette oder Festplatte, zu laden und zu verwenden.

Ein zweites Programm konnte nicht geladen werden.

Dieses eine Programm hatte Zugriff auf den ganzen verfügbaren Speicher. Es war die Verantwortung der Entwickler*innen des Programms, dass sie sinnvoll Speicherzellen gelesen und geschrieben haben.

Nun, in der heutigen Zeit sind wir uns gewohnt, mit mehreren Programmen zu arbeiten. Beim Start von Windows wird beispielsweise gleich Microsoft Teams gestartet, im Hintergrund läuft sicher auch OneDrive und wir starten Word, weil wir ein Protokoll schreiben sollen.

Damit sich die verschiedenen Programme nicht in die Quere kommen, wurde das Konzept der Prozsesse erfunden. Ein Prozess 1 ist in sich abgeschlossen und hat beispielsweise nur auf einen bestimmten Teil des Speichers Zugriff. Ein anderer Prozess, z.B. Prozess 2 hat keinen Zugriff auf den Speicher von Prozess 1.

Jedes laufende Programm, also somit jeder Prozess, macht irgendwas. Und mit irgendwas ist gemeint, dass es nicht nur irgendwo im RAM rumdümpelt, sondern Aufgaben erledigt. Und sehr häufig will ein Prozess auf die SSD oder auf einen anderen Speicher als das RAM ausserhalb des Prozessors zugreifen.

Der Zugriff auf solche "externen" Speicher ist aber um Dimensionen langsamer als der Zugriff auf das RAM. Egal, ob SSD, Fesplatte, USB-Stick, oder früher DVD, Floppy Disk, etc., das Zeugs ist unglaublich viel langsamer.

Nun darf es natürlich nicht sein, wenn beispielsweise der Prozess "OneDrive" gerade eine Datei speichert (was lange dauern kann), die anderen Prozesse blockiert sind. Sonst hätten wir beim Arbeiten am Computer ständig Ruckler.

Das heisst, es muss irgendeine Möglichkeit geben, dass das Betriebssystem zwischen den einzelnen, gerade laufenden, Prozesse hin und her wechseln kann.

Multitasking beschreibt generell die Fähigkeit eines Betriebssystems, Prozesse parallel zu verarbeiten.

Erinnern Sie sich an das System von IBM mit dem Hauptrechner 7094, welcher für die Berechnungen zuständig war, und die beiden kleineren Computer 1401, welche für den Input und für den Output zuständig waren?

Damals war der 7094 jeweils nur in der Lage, ein einziges Programm laufen zu lassen. Das heisst, wenn man den 7094 auch zum Ausdrucken verwendet hätte, wäre der Computer blockiert gewesen für andere Prozesse.

In dieser Zeit wurde das "Multiprogramming" erfunden, indem man mehrere Prozesse zuliess und jeweils nach einer bestimmten Zeit vom einen Prozess zum nächsten wechselte.

Damit wir als Anwender*innen das Gefühl haben, dass Prozesse zeitlich parallel ablaufen, greifen die Betriebssysteme zu einem Trick: sie wechseln einfach regelmässig vom einen laufenden zum nächsten laufenden Prozess. Wenn das sehr häufig passiert, einige tausend Mal pro Sekunde, haben wir das Gefühl, dass die Programme gleichzeitig laufen. Hier spricht man von einer Quasiparallelität.

Prozessoren wurden seit dem Intel 8086 aus dem Jahr 1978 immer leistungsfähiger. Einerseits wurden die Adress- und Datenbusse immer breiter und man verbaute mehr Register. Aber vor allem wurden sie immer schneller. Dieser Geschwindigkeitszuwachs war möglich, indem man die Taktrate jeweils erhöhte. Während die ersten Prozessoren mit ein paar Kilohertz (kHz) getaktet waren, ging es schlussendlich über 33MHz beim 80386 (1984) über 120 MHz beim Pentium (1995) bis auf 4 GHz bei einem Pentium IV.

Es ist gut und recht, die Taktrate immer mehr zu erhöhen, aber irgendwann gab es technische Probleme. Eines davon war die Abwärme. Die Dinger wurden unglaublich heiss und man konnte sie nicht mehr sinnvoll kühlen.

Da kamen die Hersteller von Prozessoren (z.B. Intel oder AMD) auf die Idee, statt die Taktrate zu erhöhen, einfach zwei Prozessoren auf gleicher Gehäusegrösse zu verpacken. Man nennt diese einzelnen Prozessoren Kerne. Der erste Wurf 1996 war ein so genannter Zweikern-Prozessor. Englisch auch "Dual Core" genannt. Microsoft nannte diese erste Linie von neuen Prozessoren "Core2Duo". Im Jahr 2008 wechselte Intel die Bezeichnung zur sog. i-Linie:

• i3 als billige Zweikern Prozessoren
• i5 als Vierkerner im Mittelfeld
• i7 als Vier- bis Zehnkerner im oberen Mittelfeld
• i9 als Highendprozessor (ab etwa 10 Kernen)

Die Nummerierung ist übrigens etwa gleich wie bei den Fahrzeug-Modellen von BMW🤣.

Die Taktrate wurde beim Wechsel von Ein- auf Mehrkerner deutlich verringert, weil nun zwei Kerne ihre Arbeit verrichten konnten.

Das Problem ist, dass das Betriebssystem und die Anwender-Software Mehrkernprozessoren auch unterstützen müssen. Bei Windows ist das seit Windows XP der Fall, aber bei Anwender-Software ist noch heute nicht immer selbstverständlich. Das sorgte damals dafür, dass eine Anwender-Software plötzlich schlagartig langsamer wurde mit dem neuen Mehrkernprozessor, weil sie nur einen Kern sah; der lief aber mit einer deutlich reduzierten Taktrate…

Sobald ein Betriebssystem eine Art des Mehrprogrammbetriebs erlaubt, benötigt es ein Verfahren, um den verschiedenen Prozessen entsprechend Zeit zur Verfügung zu stellen.

Nach welchem System soll das Betriebssystem den Prozessen Zeit zur Verfügung stellen? Sollen alle Prozesse immer gleich viel Zeit kriegen? Gibt es Prozesse, die wichtiger sind? Beispielsweise, weil sie möglichst schnell fertig sein sollen? Und wer entscheidet das? Oder muss beispielsweise der Prozess, der auf eine Tastatur-Eingabe wartet, möglichst schnell reagieren können, während ein anderer Prozess gelegentlich mal was rechnen kann, dies aber nicht sonderlich schnell geschehen muss?

Es gibt verschiedene Möglichkeiten, den Prozessen Zeit zur Verfügung zu stellen. Das nennt man das Scheduling von Prozessen.

Lesen Sie im Dokument "Baun 2017_Scheduling.pdf" nach, worum es geht. Sie finden das Passwort-geschützte Dokument im Team (das Passwort ist dort in einer Textdatei abgelegt).

Hier nochmals ein Übersichtsvideo zu Scheduling-Verfahren:

Zu den häufigsten Scheduling-Verfahren finden Sie hier die folgenden Videos zum Schauen:

Lässt man Prozesse nebeneinander laufen, können sog. Race Conditions auftreten. Schauen Sie das folgende Video von Andreas Wilkens, das das Problem erklärt:

Sobald wir mehrere Prozesse haben, die auf gemeinsame Ressourcen (z.B. SSD, Drucker, etc.) zugreifen wollen, kann es zu drei Problemen kommen:

• Blockieren
  Damit ist gemeint, dass z.B. Prozess A den Drucker blockiert, Prozess B aber auch gerne drucken möchte. Prozess B wird solange blockiert, bis Prozess A den Drucker wieder freigibt. Dieses Blockieren macht durchaus Sinn, damit eben kein Buchstabensalat auf dem Drucker erscheint, aber irgendwann sollte Prozess A den Drucker wieder freigeben. Passiert das nicht, wird Prozess B blockiert, was man nicht will
• Verhungern (Starvation)
  Kriegt ein Prozess vom Scheduling keine CPU-Zeit zur Verfügung gestellt, obwohl die CPU eigentlich nichts zu tun hat (aufgrund fehlerhafter Programmierung oder falscher Prioritätensetzung), dann verhungert der Prozess
• Zwei Prozesse verklemmen (Deadlock)
  Zwei Prozesse verklemmen, wenn sie gegenseitig auf die Freigabe einer Ressource warten. Keiner der beiden Prozesse kann die aktuell blockierte Ressource freigeben, weil sie auf die Freigabe des anderen Prozesses warten

Stellen Sie sich eine einfache Kreuzung im Strassenverkehr mit Rechtsvortritt vor:

Wenn alle nach rechs schauen und deshalb nicht fahren, wird hier nie jemand fahren können.

Um mehrere Prozesse verwalten zu können, gibt es den PCB, den sog. Process control block. Dieser ist ein Speicherbereich, in welchem bestimmte Informationen zu jedem Prozess gespeichert werden.

Schauen Sie sich dazu das folgende Video an: