Betriebssysteme (18) - Threads

in #de-stem4 years ago

Zum Kontext eines Prozesses gehören neben den Registerinhalten auch Informationen über seinen Adressraum, bei seitenbasierter Speicherorganisation zum Beispiel eine Seitentabelle. Die Verwaltung dieser Informationen kostet beim Prozesswechsel Rechenzeit.

Nun gibt es Probleme, bei deren Lösung man mehrere Prozesse einsetzen möchte, die parallel ablaufen und dabei alle auf denselben Speicherbereich zugreifen. Eine zeitaufwendige Einrichtung neuer Adressräume ist also beim Wechsel zwischen diesen Prozessen nicht erforderlich. Für solche Fälle hat man das Konzept der leichtgewichtigen Prozesse (thread) entwickelt.

Beispielszenario

Betrachten wir zunächst ein Beispiel. In Rechnernetzen werden oft Dateiserver (file server) verwendet, Rechner also, die darauf spezialisiert sind auf Festplatten gespeicherte Dateien zu bearbeiten. Von jedem Rechner im Netz können Klienten Aufträge an den Server übermitteln, die dieser ausführt und beantwortet.
Weil der Dateiserver nur diese eine Aufgabe wahrnimmt, könnte man meinen, dass er im wesentlichen mit einem einzigen Anwendungsprozess auskommt. Dieser Prozess schaut in einem Briefkasten (mail box) nach, ob ein Auftrag A vorliegt. Wenn das so ist, wird ihm die logische Dateiadresse entnommen, und es wird zunächst geprüft, ob die entsprechenden Daten im Hauptspeicher-Cache des Servers stehen. Ist das nicht der Fall, wird die physische Adresse der Daten auf der Festplatte berechnet. Dann erteilt der Prozess einen Befehl an den Gerätetreiber.

Bei diesem Ansatz gibt es zwei Möglichkeiten: Der Serverprozess könnte jetzt blockieren, bis Gerätetreiber und Controller den Befehl ausgeführt haben. Dann könnte er die Antwort an den Klienten formulieren und abschicken. Dieses Verfahren ist recht einfach, aber sehr ineffizient; denn während der Serverprozess blockiert ist, wäre die CPU des Dateiservers die ganze Zeit über untätig. Oder aber der Serverprozess könnte eine Notiz über den Zustand der Bearbeitung von Auftrag A1 ablegen und schon einmal den nächsten Auftrag aus dem Briefkasten holen. Wenn dann später der Gerätetreiber den zu A1 gehörenden Befehl ausgeführt hat, könnte der Serverprozess mit der Bearbeitung des aktuellen Auftrags A2 innehalten und zunächst dem Klienten von Auftrag A1 seine Antwort schicken. Dieses verschachtelte Vorgehen versucht, mit einem einzelnen Prozess Parallelität nachzumachen; das ist zwar effizient, aber nicht so leicht zu programmieren und sehr unübersichtlich.

Viel eleganter ist die Verwendung mehrerer Serverprozesse, von denen jeder einen kompletten Auftrag sequentiell ausführt. Während einer von ihnen blockiert, weil er auf die Erledigung eines Ein-/Ausgabebefehls wartet, braucht die CPU nicht untätig zu sein, denn inzwischen kann ja ein anderer Serverprozess rechnen.

Diese Serverprozesse greifen alle auf dieselben Hauptspeicherbereiche zu: auf den Briefkasten und den Hauptspeicher-Cache. Es besteht also kein Grund, ihnen individuelle Adressräume zuzuweisen, die den Prozesswechsel verlangsamen. Deshalb verwendet man zur Steuerung eines Dateiservers am besten leichtgewichtige Prozesse.

leichtgewichtige Prozesse

Mehrere leichtgewichtige Prozesse (auch LWP genannt) teilen sich ein Programm, einen Adressraum und dieselben Dateien. Jeder LWP hat aber seine eigenen Registerinhalte und einen eigenen Stapel (Stacksegment). Solch eine Gruppe von zusammengehörigen leichtgewichtigen Prozessen wird als Task (Aufgabe) bezeichnet; Dazu folgende Abbildung:

bs.png

Leichtgewichtige Prozesse können dieselben Zustände annehmen wie gewöhnliche Prozesse; sie können Kinder generieren und blockierende Systemaufrufe ausführen. Beim Zugriff auf den gemeinsamen Speicherbereich kann es aber zu Problemen kommen, so dass Synchronisationsmechanismen benötigt werden. Dabei kann man allerdings davon ausgehen, dass zusammengehörende leichtgewichtige Prozesse sich kooperativ verhalten.

Es gibt verschiedene Möglichkeiten, leichtgewichtige Prozesse zu implementieren: Kernel-Threads und Benutzer-Threads. Kernel-Threads werden im Betriebssystemkern realisiert, Benutzer-Threads hingegen im privaten Speicherbereich eines Prozesses. Dazu kommen noch Mischformen aus beiden Imple-mentierungen.

Quelle

https://web.cs.wpi.edu/~cs3013/c07/lectures/Section04-Threads.pdf [letzer Zugriff: 22.11.2019, 18:44]

Sort:  


This post has been voted on by the SteemSTEM curation team and voting trail. It is elligible for support from @curie and @minnowbooster.

If you appreciate the work we are doing, then consider supporting our witness @stem.witness. Additional witness support to the curie witness would be appreciated as well.

For additional information please join us on the SteemSTEM discord and to get to know the rest of the community!

Please consider using the steemstem.io app and/or including @steemstem in the list of beneficiaries of this post. This could yield a stronger support from SteemSTEM.

Danke für deinen Beitrag. Eine tolles Wochenende wünsch ich dir

Coin Marketplace

STEEM 0.25
TRX 0.11
JST 0.033
BTC 62777.23
ETH 3059.34
USDT 1.00
SBD 3.81