Einführung in Betriebssyteme


von Prof. Jürgen Plate

2 Prozesse

2.1 Programme, Prozeduren, Prozesse und Instanzen

Programm:

Die Lösung einer Programmieraufgabe (=Algorithmus) wird in Form eines Programms realisiert. Teillösungen werden dabei als Prozeduren (Unterprogramme) formuliert, welche nach Beendigung ihrer Arbeit zum aufrufenden übergeordneten Programm zurückkehren. Damit die Leistungen des Betriebssystemkerns problemlos in Anwenderlösungen eingebunden werden können, sind sie ebenfalls als Prozeduren realisiert. Ein Programm (Prozedur, Unterprogramm) besteht aus: Beide Komponenten sind problemorientiert.

Prozeß:

Wird ein Programm (Prozedur) unter der Kontrolle eines Betriebssystems (genauer gesagt unter der Kontrolle eines Betriebssystemkerns) ausgeführt, so wird dieser Ablauf als Prozeß (engl. Task) bezeichnet. Diese Betrachtungsweise macht es möglich, daß mehrere Programme gleichzeitig als Prozesse parallel auf einem sequentiell arbeitenden Rechnersystem (unabhängig von der realen Anzahl Prozessoren) ablaufen können. Als Sonderfall gilt die Ausführung mehrerer Prozesse auf einem Prozessor. Bei der Ausführung von Prozessen entstehen Daten, die durch den Betriebssystemkern verwaltet werden. Diese werden Statusinformationen genannt und sind systemabhängig, z. B. Registerinhalte.

Die Funktionalität des Betriebssystemkerns bezüglich der Verwaltung von Prozessen ist bei der Ausführung von n Prozessen auf einem Prozessor äquivalent der Verwaltung auf m > 1 Prozessoren. Dabei kann das Verhältnis m : n sowohl statisch als auch dynamisch änderbar sein.

Als weitere Komponente wird beim Ablauf eines Programms ein Kellerspeicher (Stack) aufgebaut. Somit läßt sich ein Prozeß modellhaft folgendermaßen darstellen.

Alle vier Komponenten, die bei der Ausführung eines Programms (einer Prozedur) beteiligt sind, werden als Instanz zusammengefaßt.

Instanz:

Eine Instanz umfaßt das Tupel (C, D, S, I):

C:Codesegment-->problemorientiert
D:Datensegment-->problemorientiert
S:Stacksegment-->system-/problemorientiert
I:Statusinformation-->systemorientiert

Die physische Anordnung dieser Komponenten im Arbeitsspeichers eines Rechners kann in unterschiedlichen Betriebssystemen verschieden sein.
Wir halten also fest:

Prozeßmodell

2.2 Prozeßzustände

Während seiner Abarbeitung kann ein Prozeß verschiedene Zustände einnehmen:

Die Situation in der Hardware stellt sich etwa folgendermaßen dar. Im Speicher liegen die einzelnen Instanzen der Prozesse. Jeweils ein Prozeß wird der CPU zugeteilt.

Zustandswechsel eines Prozesses:

Zu jedem Prozeß legt das BS einen Prozeßsteuerblock (process control block = PCB) in der Prozeßtabelle ab, der alle notwendigen Informationen über einen Prozeß enthält, z. B.:

2.3 Prozeßhierarchie

Ein Prozeß kann einen neuen Prozeß starten (fork, spawn); ein solcher Prozeß heißt "Kindprozeß" oder "Sohnprozeß" (child process) und der Erzeuger-Prozeß wird "Elternprozeß" oder "Vaterprozeß" (parent process) genannt.

2.4 Prozeß-Operationen des BS

CreateErzeugen eines Prozesses (z.B. Laden eines Programms)
  • Vergabe einer PID, Anlegen eines PCB in der Prozeßtabelle
  • Allokieren des benötigten Speichers
  • Reservieren der benötigten Resourcen
  • Vergabe einer Priorität
KillLöschen eines Prozesses
  • Löschen aller Einträge aus den Systemtabellen
  • Freigabe von Speicher und Resourcen (z.B. Dateien schließen)
  • Löschen aller Abkömmlinge (Kindp., Enkelp., usw.)
SuspendSuspendieren eines Prozesses
  • Suspendierung normalerweise nur bei Systemüberlastung durch Prozesse höherer Priorität, Wiederaufnahme erfolgt sobald möglich.
ResumeWiederaufnehmen eines suspendierten Prozesses
  • Suspendierung normalerweise nur bei Systemüberlastung durch Prozesse höherer Priorität, Wiederaufnahme erfolgt sobald möglich.
BlockBlockieren eines Prozesses
WakeupAufwecken eines blockierten Prozesses
DispatchCPU an einen Prozeß zuteilen
ChangePriorität eines Prozesses ändern

Durch die Suspendierungsmöglichkeit erweitert sich das Diagramm der Prozeßzustände:

2.5 Prozeß-Synchronisation

In einigen Multitasking-Betriebssystemen teilen sich verschiedene Prozesse gemeinsame Betriebsmittel. Bei gleichzeitigem Zugriff zweier Prozesse auf diese Betriebsmittel kann es zu Inkonsistenzen der Daten kommen, die u. U. selten auftreten und sehr schwer aufzuspüren sind.
Kooperierende nebenläufige Prozesse müssen daher wegen der zwischen ihnen vorhandenen Abhängigkeiten miteinander synchronisiert (koordiniert) werden. Prinzipiell lassen sich zwei Klassen von Abhängigkeiten unterscheiden:

Zur Realisierung einer Synchronisation bei beiden o. a. Abhängigkeitsklassen werden häufig Semaphore eingesetzt. Ein Semaphor (Sperrvariable, Steuervariable) signalisiert einen Zustand (Belegungszustand, Eintritt eines Ereignisses) und gibt in Abhängigkeit von diesem Zustand den weiteren Prozeßablauf frei oder versetzt den betreffenden Prozeß in den Wartezustand. Semaphore für den gegenseitigen Ausschluß sind dem jeweiligen exklusiv nutzbaren Betriebsmittel zugeordnet und verwalten eine Warteliste für dieses Betriebsmittel. Sie sind allen Prozessen zugänglich. Semaphore für die Ereignissynchronisation zweier voneinander datenabhängiger Prozesse sind diesen Prozessen direkt zugeordnet. Sie dienen zur Übergabe einer Meldung über das Ereignis zwischen den Prozessen.

Zur Manipulation und Abfrage von Semaphoren existieren zwei unteilbare, d. h. nicht unterbrechbare Operationen (Semaphor S):

Eine zweite Methode ist der sogenannte gegenseitige Ausschluß. Der Programmabschnitt, in dem ein Zugriff zu dem nur exklusiv nutzbaren Betriebsmittel (z. B. die gemeinsamen Daten) erfolgt, wird kritischer Abschnitt genannt. Es muß verhindert werden, daß sich zwei Prozesse gleichzeitig in ihren kritischen Abschnitten befinden. Lösungsmöglichkeit mittels Semaphor (Vorbesetzung Semaphor s=l): 

   unkritischer Abschnitt;
   request(s); /* Anfrage-Operation (P-Operation) */
   kritischer Abschnitt;
   release(s); /* Freigabe-Operation (V-Operation) */
   unkritischer Abschnitt;

Die dritte Methode ist die Ereignissynchronisation: Annahme: Es gibt einen Semaphor mit Namen "event". Dazu zwei BS-Funktionen:

Lösungsmöglichkeit für Produzenten-Konsumenten-Synchronisation (Vorbesetzung Semaphore: start = 0; finish = 0):

Produzent: Konsument:
  while (TRUE)
    {
    while (!buffer-full)
      write_into_buffer();
    signal(start);   /* V-Operation */
    wait(finish);    /* P-Operation */
    }
  
  while (TRUE)
    {
    wait(start);           /* P-Operation */ 
    while(!buffer-empty)
      read_from_buffer();
    signal(finish);        /* V-Operation */
    }

2.6 Prozeß-Kommunikation

Einige Möglichkeiten der Interprocess Communication (IPC):

Selbst bei sehr einfachen Betriebssystemen ist eine IPC notwendig, da zumindest eine Kommunikation zwischen einem Prozeß und dem Scheduler möglich sein muß.

2.7 Prozeß-Scheduling

In Multitasking-Betriebssystemen ist ein spezieller Prozeß notwendig, der aus den bereiten Prozessen den nächsten aktiven Prozeß auswählt. Sobald mehr als ein Prozeß den Zustand "bereit" besitzt, muß der Scheduler des Betriebssystems entscheiden, welcher Prozeß die CPU erhält (wir gehen zur Vereinfachung von einem System mit nur einem Prozessor aus). Kriterien für einen guten Scheduler sind:

Bei Multitasking-Betriebssystemen werden zwei Grundsysteme für das Sceduling unterschieden:

Scheduling-Strategien

Bei kooperativem Multitasking oder ereignisgesteuerten Scedulern wird die Zuteilungsstrategie über Prioritäten gesteuert, wobei man beim kooperativen System von relativem Vorrang spricht (der erst durch nach Freigabe der CPU durch den aktiven Prozeß wirksam wird) und beim ereignisgesteuerten System vom absoluten Vorrang (der sofort zum Prozeßwechsel führt).
Die Zeitscheibensteuerung kann als Sonderfall der Ereignissteuerung betrachtet werden, das Ereignis ist in diesem Fall der Ablauf der zugeteilten Zeitscheibe.

Einige Strategien, die in der Praxis verwendet werden, sind:

In Dialogsystemen wird normalerweise Round Robin verwendet, um den Benutzern akzeptable Antwortzeiten zu bieten. Bei Batchbetrieb und gemischten Systemen kommen oft Kombinationen der o. g. Strategien vor - z. B. getrenntes Sceduling für Dialog- und Batchbetrieb.

Jeder Prozeß (oder Thread) muß seinen lokalen Datenbereich besitzen, da es durchaus vorkommen kann, das ein Prozeß oder Thread von mehreren anderen aus gestartet werden kann (z. B. die Benutzershell bei einem Multiusersystem). Insbesondere dürfen Betriebssystemdienste keine globalen Speicherbereiche verwenden, da diese von allen laufenden Prozessen aufgerufen werden können und sonst bei der Prozeßumschaltung Werte des verdrängten Prozesses durch den BS-Aufruf des nun aktiven Prozesses überschrieben würden. Man nennt diese Eigenschaft Wiedereintrittsfähigkeit (engl. "reentrance").

Manche Singletasking-BS (z. B. MS-DOS) sind nicht reentrant und daher nicht oder nur schwer auf Multitaskingbetrieb erweiterbar.

2.8 Beispiele

Realzeitbetriebssysteme arbeiten in der Regel mit Zeitscheibenverfahren, wobei zusätzliche Bedingungen hinzukommen. Ereignisse (in der Regel Hardware- oder Software-Interrupts) müssen innerhalb einer bestimmten Sollzeit bearbeitet werden (Echtzeitbedingung). Daher findet sich hier häufig eine Aufteilung der Programme in einzelne Threads (bei Realzeitbetriebssystemen auch oft "Task" genannt).

Zum Inhaltsverzeichnis Zum nächsten Abschnitt

Copyright © FH München, FB 04, Prof. Jürgen Plate