Folien Kapitel 6 - Universität Ulm

6 Prozessmanagement 

Prozessmanagement in verteilten Systemen geschieht auf zwei Ebenen 

• in einem Server die von verschiedenen Klienten eintreffenden Anfragen bearbeiten 

• ein feiner abgestuftes Prozesskonzept an sich bereitstellen, um die obige Aufgabe effizienter 

zu lösen 

6.1 Iterative und nebenläufige Server 

6.1.1 Iterative Server 

• jeweils immer ein Auftrag nach dem anderen bearbeiten 

Programmfragment: 

forever 

receive (request, client); 

perform request; 

send (reply, client); 

endforever; 

Prof. Dr. Michael Weber; Verteilte Systeme, SS99, Universität Ulm 

Eigenschaften und Bewertung 

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 6, Seite 1 

• um während der Bearbeitung neue Aufträge annehmen zu können, ist für eingehende Aufträge 

ein Puffer bereitzustellen 

• dies muss vom entsprechend zu wählenden Kommunikationssystem übernommen werden 

• die Antwortzeit für einzelne Aufträge kann sehr lang werden 

• die Bearbeitungsreihenfolge ist immer First-Come-First-Served 

• für einfache Dienste mit geringer Auftragsbearbeitungszeit und nicht allzu hoher Anfragehäufigkeit 

geeignet 

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 6, Seite 2

6.1.2 Nebenläufige Server 

• ein nebenläufiger Server kann mehrere Aufträge gleichzeitig in Bearbeitung haben 

• dies ist durch die Einführung mehrerer Kontrollflüsse innerhalb des Servers möglich 

Vorteile gegenüber der iterativen Methode: 

• die mittlere Antwortzeit pro Klient wird verbessert 

• stehen Wartezeiten für Ein-/Ausgabeoperationen an, so kann diese Zeit zur Bearbeitung anderer 

Aufträge genutzt werden 

• es ist unter Umständen möglich, die Reihenfolge der Bearbeitung geeignet zu wählen 

• die Ausnutzung mehrerer Prozessoren bei Multiprozessormaschinen kann unterstützt werden 

Bild 6.1: Nebenläufiger Server 

Realisierungsvarianten hängen davon ab, ob die vom Betriebssystem bereitgestellte Multiprozessfähigkeit 

genutzt werden soll/kann oder nicht 

Multiplex-Server 

Klienten 

Klient 

Klient 

Klient 

Master 

erzeugt 

Server 

Slave 

Slave 

Slave 


• keine Unterstützung des Betriebssystems 

• verwendet nur einen einzelnen echten Kontrollfluß 

• Kontrollfluß wird vom Server selbst auf mehrere Aufträge verteilt 

• für jeden Auftrag verwaltet der Server eine Kontrolldatenstruktur, in der er den aktuellen 

Bearbeitungszustand des Auftrags speichert 

• an geeigneter Stelle wechselt der Server von der Bearbeitung eines Auftrags zur Bearbeitung 

eines anderen 

Nachteile: 

• Ist der Server durch einen blockierenden Systemaufruf blockiert, kann er die Wartezeit nicht 

für andere Aufgaben nutzen. 

• Die Aufteilung der einzelnen Aufträge in Bearbeitungsportionen ist schwierig. 

• Die Programmstruktur des Servers entspricht nicht herkömmlichen Programmierparadigmen 

und erscheint unnatürlich. 


Programmfragment eines Multiplex-Servers: 

record ControlBlock 

request; 

state; 

endrecord; 

var ControlBlock_List : 

linear_list of ControlBlock ; 

forever 


-- nicht blockierend! 

insert into ControlBlock_List; 

choose request from ControlBlock_List; 

perform next part of request; 

if (request = done) then 


delete request from ControlBlock_List; 

endif; 

endforever; 

Realisierung mit Prozessen 


• Betriebssystem stellt eine Unterstützung für mehrere Kontrollflüsse zur Verfügung 

• für jeden Auftrag einen eigenen Prozess verwenden 

Programmbeispiel: 

forever 


if (fork = 0) then -- fork = 0 prüft, ob Kindprozess 

perform request; 


endif; 

endforever; 


Bewertung 

• Nebenläufigkeit ist mit dem Prozessmanagement des Betriebssystems einfach zu erreichen 

• die gesamte Verwaltungsarbeit wird vom Betriebssystem übernommen 

• der Programmierer hat wenig Aufwand 

• Ein neu erzeugter Prozess ist „schwergewichtig” 

• er verfügt über alle Ressourcen, z.B. einen komplett eigenen Adressraum, um vollkommen 

eigenständig als Betriebssystemprozess zu leben 

• der große Verwaltungsaufwand durch Anlegen von Kopien des Stack und des Heap des 

Vaterprozesses, Erstellen von Ein-/Ausgabetabellen etc. verursacht eine lange Erzeugungsdauer 

• ein Prozesswechsel ist aufwendig, da diese gesamte Information getauscht werden muß 

• da das Betriebsystem keine Kenntnis über die Semantik der Aufträge besitzt, kann es keine 

Optimierung der Bearbeitungsreihenfolge vornehmen 

• das übliche Zeitscheibenverfahren kommt auch hier zum Tragen 

6.2 Threads 


• kein Verzicht auf die betriebssystemseitige Unterstützung von Nebenläufigkeit 

• vermeiden der Schwergewichtigkeit von Prozessen 

• unabhängige Threads mit jeweils eigenem Kontrollfluß laufen in einem gemeinsamen 

Adressraum ab 

• der Prozess dient lediglich als Ausführungsumgebung und ist selbst nicht aktiv 

Bild 6.2 Single-threaded und multi-threaded System 

dress 

a) Single-threaded b) multi-threaded 

Computer Prozess Kontrollfluß Programm-Zähler 


Eigenschaften threadbasierter Systeme 

• Threads laufen innerhalb eines gemeinsamen Adressraums ab 

- Zugriff auf gemeinsame Speicherobjekte 

- Interthreadkommunikation kann über gemeinsame Variablen erfolgen und benötigt keinen 

Nachrichtenaustausch 

- bei nebenläufigem Zugriff auf die gemeinsamen Ressourcen ist eine Synchronisation unter 

den beteiligten Threads notwendig 

• Das Erzeugen eines weiteren Threads ist viel weniger aufwendig als einen neuen Prozess zu 

kreieren 

- Adressraum und sonstige gemeinsam benutzte Ressourcen sind bereits angelegt 

- der Kontextwechsel zwischen Threads ist einfacher als bei Prozessen 

- nur wenige Zustandsinformationen müssen gewechselt werden 

- die Zustandsinformation von Threads beinhaltet: Programmzähler, Registersatz, threadlokalen 

Stack und Heap, Liste der Kindthreads, Ausführungszustand (running, blocked, 

ready) 

- dies ist nur wenig mehr Kontextinformation, als bei einem lokalen Prozeduraufruf 

- im Gegensatz dazu besitzt ein Prozess folgende Kontextinformation: kompletten virtuellen 

Adressraum (d.h. Seitentabelle und Seiten), Liste geöffneter Dateien, Liste der Kindprozesse, 

Kontrollstrukturen verwendeter Betriebssystemressourcen, wie Timer, Signale 

oder Semaphore, und Managementdaten, wie Accountinginformationen und Benutzerdaten. 

Organisationsformen threadbasierter Systeme 

• Dispatcher/Worker-Modell 

- ein Thread empfängt die Aufträge und 

- teilt sie anderen Bearbeitungsthreads zu, die 

- bereitstehen (Thread-Pool) oder 

- jeweils neu erzeugt werden 

- dieses Modell nennt man auch Master/Slave-Modell 


• Team-Modell 

- alle Threads sind gleichberechtigt 

- hat ein Thread seine bisherige Aufgabe abgearbeitet, bedient er sich selbst mit einem neuen 

Auftrag aus dem Eingangspuffer 

- der Puffer ist eine gemeinsam benutzte Ressource und muß gegen konkurrierenden Zugriff 

geschützt werden 

• Pipeline-Modell 

- die Threads sind logisch in einer Kette angeordnet 

- jeder Thread bearbeitet nur einen Teil des Auftrags und gibt ihn dann zur Weiterbearbeitung 

an den nachfolgenden Thread 

- der Auftrag muss eine dazu entsprechende Struktur haben 


a) Dispatcher/Worker-Modell b) Team-Modell 

c) Pipeline-Modelll 

Dispatcher 

Kommunikationspuffer Kommunikationspuffer 

Kommunikationspuffer 

Bild 6.3 Organisationsformen threadbasierter Server 

6.2.1 Implementierung von Threads 


Die Verwaltungsfunktionen für Threads können auf unterschiedlichen Ebenen implementiert 

werden 

• im Betriebssystemkern: Kernel-level Threads 

• im Arbeitsbereich eines Benutzers: User-level Threads mit einem entsprechenden Laufzeitsystem 

User 

Space 

Kernel 

Space 

Bild 6.4 Implementierung von Threads 

a) User-level Threads b) Kernel-level Threads 

Laufzeitsystem 

Kern 

Thread 

Kern 

Thread 


Vorteile von User-level Threads: 

• das Betriebssystem braucht nicht verändert zu werden 

• alle Systemaufrufe an das Betriebssystem werden über das Thread-Laufzeitsystem abgewikkelt 

• die threadbasierte Anwendung ist weitgehend unabhängig vom Betriebssystem und damit 

leichter portabel 

• die Umschaltung zwischen Threads ist schneller, da dies im Usermodus geschieht 

• das Laufzeitsystem muß lediglich Programmzähler, Registersatz und Kellerzeiger austauschen 

• es werden keine Kern-Traps ausgelöst, um dann dort die Threads zu wechseln 

• ein Wechsel in den Kern würde einen Prozesswechsel bewirken, so daß die Idee der Threads 

verloren geht. 

• die verwendeten Schedulingalgorithmen können an die Threads und damit an die Anwendung 

angepaßt werden 

• es ist möglich, zum gleichen Zeitpunkt unterschiedliche Schedulingstrategien für verschiedene 

threadbasierte Programme ablaufen zu lassen. 

• User-level Threads skalieren gut, da sehr wenig Informationen pro Thread geführt werden 

müssen. 

Nachteile von User-level Threads: 


• Problem blockierender Systemaufrufe 

- der Thread blockiert und mit ihm das Laufzeitsystem, welches vom Betriebssystem als ein 

einzelner Prozess gesehen wird 

- die Kontrolle kann somit nicht an einen anderen Thread übergeben werden 

• das Problem zu lösen, bedeutet ein Ändern der Systemroutinen 

- dies ändert auch die Semantik dieser Routinen und macht Anwenderprogramme unter 

Umständen fehlerhaft 

- zweite Variante: im Betriebssystem Select-Jackets um die Systemroutinen programmieren, 

die einen asynchronen Mechanismus sonst blockierender Aufrufe anbieten 

• Rechnende Threads müssen sich nicht freigeben 

• das Laufzeitsystem hat keine Möglichkeit laufende Threads zu unterbrechen 

- diese müssen spezielle Routinen des Laufzeitsystems aufrufen, um ein Scheduling zu erlauben 

Kernel-level Threads vermeiden die Nachteile, haben aber dafür nicht die Vorteile der User-level 

Threads zu bieten 

• jeder Aufruf einer Threadverwaltungsoperation wird zu einem Systemaufruf 

• die kernbasierte Implementierung vermeidet die Probleme blockierender Aufrufe 

Es ist ein Trend zu Kernel-level Threads in Betriebssystemen zu erkennen (siehe z.B. Windows 

NT, Solaris) 


6.2.2 Programmieren mit Threads 

• Programmieren mit Threads ist Programmieren nebenläufiger Programme 

Globale Variablen 

• Threads können auf globale Variablen zugreifen, die durch andere Threads des gleichen 

Adressraums beeinflußt werden 

Aufruf einer Systemfunktion 

Fehler: errno = 42; 

Kontrolle an anderen Thread 

if (errno != 0) { 

Bild 6.5 Threads und globale Variablen 

Thread-Wechsel 

Aufruf einer Systemfunktion 

Kein Fehler: errno = 0; 

Kontrolle an anderen Thread 


Lösungen des Problems: 

• globale Variablen verbieten 

- dann wären Threads in allen Betriebssystemen, die mit solchen Variablen operieren (z.B. 

Unix), nicht möglich 

• pro Thread Kopien globaler Variablen anlegen 

- dies führt zu einer zusätzlichen Sichtbarkeitsebene 

- system-globale Variablen (sichtbar für alle Threads) 

- thread-globale Variablen (sichtbar innerhalb eines Threads) 

- lokale Variablen (sichtbar innerhalb einer Prozedur eines Threads) 

- erneutes Problem: 

- Programmiersprachen kennen die Zwischenform nicht 

- man benötigt neue Systemfunktionen für threadspezifische globale Variablen 

- z.B.: create_global, write_global, read_global 


Systemaufrufe 

Verwendung von (unterbrechbaren) Systemfunktionen 

• ein Thread wird bei der Ausführung einer Systemfunktionen unterbrochen 

• ein anderer Thread greift dann potentiell auf die gleichen Datenstrukturen zu, in dem er die 

gleiche Funktion ebenfalls aufruft 

send(m1) 

Nachricht im Puffer 

zusammenbauen 

Puffer inkonsistent 

Bild 6.6 Threads und Systemfunktionen 

Thread-Wechsel 

send(m2) 

Nachricht im Puffer 

zusammenbauen 


Problem: 

• die meisten Systemfunktionen sind nicht reentrant programmiert 

• d.h. die Funktion geht davon aus, daß sie in einem Kontrollfluß zusammenhängend durchlaufen 

wird 

Lösungen: 

• Funktionen reentrant nachprogrammieren 

• Zugang zu den Funktionen durch Semaphore schützen 


Threadbibliothek 

Threadfunktionen werden meist in einer Threadbibliothek angeboten 

Wichtige Vertreter: 

• POSIX 1003 

• Threadpaket von OSF DCE 

• Leightweight-Process-Paket von Sun 

typische Komponenten und Aufrufe 

• Thread-Verwaltung 

- create, exit, join, detach 

• Thread-Kontrolle 

- cancel, setcancel 

• Semaphore 

- init, destroy, lock, trylock, unlock 

• Bedingungs-Variablen 

- init, destroy, wait, signal 

• Verwaltung thread-globaler Variablen 

- create, set, get

Folien Kapitel 6 - Universität Ulm

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?