Thread

Ein Thread (auch: Aktivitätsträger) ist in der Informatik ein Ausführungsstrang beziehungsweise eine Ausführungsreihenfolge der Abarbeitung der Software.

Bedeutungsunterschied Thread gegenüber Prozess, Task und Fiber

Ein Prozess (Informatik) bezeichnet den Ablauf eines Computerprogrammes auf einem Prozessor. Ein Prozess kann genau einen Thread des Betriebssystems belegen, wenn bei dem Programmablauf keine Parallelverarbeitung vorgesehen ist. Unter Unix gibt es von je her einfach zu beherrschende Systemaufrufe zur Erzeugung paralleler Prozesse (fork), mit diesem Mittel wird unter Unix/Linux traditionell die Parallelverabeitung realisiert. Threads sind erst in neueren Unix/Linux-Versionen eingeführt. Gegenüber einem Prozess wird ein Thread auch als Leichtgewichtprozess bezeichnet, da die Umschaltung zwischen Prozessen mehr Aufwand (Rechenzeit) im Betriebssystem erfordert als die Umschaltung zwischen Threads eines Prozesses. Einem Prozess ist ein Speicherraum und weitere Betriebssystemmittel zugeordnet, mehrere Threads eines Prozesses teilen sich hingegen die Betriebsmittel des Prozesses und greifen auf den selben Speicherraum zu.

Bereits in den 80-ger Jahren gab es sogenannte Multitask-Betriebssysteme, da im Unterschied zu den joborientierten Systemem insbesondere in der damals so bezeichneten Prozessrechentechnik mehrere Aufgaben quasiparallel ausgeführt werden mussten. Damals hat sich der Begriff Task für eine Aufgabe aus Sicht des Betriebssystems eingebürgert, das ist synonym zu dem hier beschriebenem Thread. Der Begriff Task (deutsch: Aufgabe) wird in der Softwarearchitektur aber auch unscharf allgemein für zusammenhängende Aufgaben benutzt, insbesondere auch synonym für Prozess eingesetzt.

Ein Thread ist wörtlich ein einzelner Ausführungsfaden eines Programmes, der Begriff Thread wird aber auf den Ausführungsstrang aus Sicht des Betriebssystems eingesetzt. In einer Anwendersoftware kann dieser Ausführungsstrang durch geeignete Programmierung nochmals in unabhängige Einzelstränge unterteilt werden, das geschieht beispielsweise bei der Abarbeitung verschiedener in UML notierter Statecharts im selben Betriebssystem-Thread. Im englischem Sprachraum hat sich für den einzelnen Ausführungsstrang der Anwendersoftware der Begriff Fiber (deutsch: Faser) eingebürgert. Die folgende Tabelle ist aus der englischen Wikipedia kopiert und ohne Bedeutungsänderung übersetzt und zeigt die Begriffsunterschiede. (Achtung: Die Tabelle enthält einige Links aus der original englischen Wikipedia, die hier nicht funktionieren. Es muss entschieden werden, welche Links eingedeutscht oder beibehalten werden.)

In der Tabelle bedeuten P Prozess, T Thread und F Fiber.

P	T	F	Beispiel
Nein	Nein	Nein	Ein Computerprogramm unter MS-DOS ablaufend. Das Programm kann zu einer Zeit nur eine Aktion ausführen.
Nein	Nein	Ja	Windows 3.1 auf der Oberfläche von DOS. Alle Windows programme laufen in einem einfachem Prozess, ein Programm kann den Speicher eines anderen Programmes zerstören, was den bekannten General Protection Fault zur Folge hat.
Nein	Ja	Nein	Amiga OS's ursprüngliche Implementierung. Das Betriebssystem unterstützt vollständig Threads und erlaubt dabei, dass mehrere Applikationen unabhänig voneinander ablaufen, vom Betriebssystemkern scheduled. Wegen der nichtvorhandenen Prozess-Unterstützung ist das System effizienter (wegen der Vermeidung des Zusatzaufwandes des Speicherschutzes), mit dem Preis, dass Applikationsfehler den gesamten Computer lahmlegen (crash) können.
Nein	Ja	Ja	Mac OS 9 unterstützt Fibers mittels Apple's Thread Manager und Threads mittels Apple's Multiprocessing Services, das mit dem nanokernel arbeitet, eingeführt in Mac OS 8.6. Damit werden Threads unterstützt, aber immernoch der MultiFinder's Weg des Verwaltens von Applikationen benutzt.
Ja	Nein	Nein	Die meisten bekannten Implementierungen von Unix. Das Betriebssystem kann mehr als ein Programm zu einem Zeitpunkt ausführen, die Programmabarbeitungen sind gegeneinander geschützt. Wenn ein Program sich falsch verhält, kann es seinen eigenen Prozess stören, was das Beenden dieses einen Prozesses zur Folge haben kann, ohne dass das Betriebssystem oder andere Prozesse gestört werden. Jedoch kann der Informationsaustausch zwischen Prozessen entweder fehlerbehaftet sein ( bei Nutzungen von Techniken wie shared memory) oder aufwändig (bei Nutzung von techniken wie message passing). Die asynchrone Ausführung von Aufgaben benötigt einen aufwändigen fork() Systemaufruf.
Ja	Nein	Ja	Sun OS vor Solaris. Sun OS ist Sun Microsystem's Version von Unix. Sun OS implementiert sogenannte green threads um einem einfachen Prozess die asynchrone Ausführung mehrerer Aufgaben zu ermöglichen, beispielsweise playing a sound, repainting a window, oder auf ein Bediener-Ereignis zu reagieren wie die Anwahl des stop button. Obwohl die Prozesse pre-emptively verwaltet werden, sind die green threads oder Fibers kooperativ arbeitend. Dieses Modell wird oft genutzt anstelle von richtigen Threads. Dieses Modell ist immernoch aktuell in Mikrocontroller- und sogenannten embedded devices.
Ja	Ja	Nein	Das ist der allgemeine Fall der Applikationen unter Windows NT abe 3.51 SP3+, Windows 2000, Windows XP, Mac OS X, Linux, und anderen modernen Betriebssystemen. Obwohl alle diese Betriebssysteme den Programmierer die Nutzung von Fibers beziehungweise von Bibliotheken, die mit Fibers arbeiten, erlauben, nutzen die meisten Programmierer nicht die Fibers in ihren Anwendungen. Die Programme sind multithreaded und laufen unter einem multitasking operating system, aber führen keine user-level - Umschaltung (context switching) aus. On the typical home computer, most running processes have two or more threads. A few processes will have a single thread. Usually these processes are services running without user interaction. Typically there are no processes using fibers.
Ja	Ja	Ja	Die meisten Betriebssysteme seit 1995 fallen in diese Kategorie. Die Nutzung von Threads zur gleichzeitigen Ausführung ist die gewöhnliche Auswahl, obwohl es auch multi-process und multi-fiber - Applikationen gibt. Diese werden beispielsweise benutzt, damit ein Programm sein grafisches Benutzerinterface (graphical user interface) abarbeiten kann während es gleichzeitig auf eine Eingabe des Benutzers wartet oder eine Rechtschreibprüfung ausführt.

Thread aus Sicht des Betriebssystems

Auf Betriebssystemen, die Threads unterstützen, ist der Verwaltungsaufwand für Threads üblicherweise geringer als der für Prozesse. Ein wesentlicher Effizienzvorteil von Threads besteht darin, dass im Gegensatz zu Prozessen beim Threadwechsel kein vollständiger Austausch des Prozesskontextes notwendig ist, da alle Threads einen gemeinsamen Teil des Prozesskontextes verwenden.

Das Bild zeigt die beschriebenen Zusammenhänge im Detail. Ein Thread teilt sich mit den anderen vorhandenen Threads des zugehörigen Prozesses eine Reihe von Betriebsmitteln, nämlich das Codesegment, das Datensegment und die verwendeten Dateideskriptoren. Allerdings bewahrt jeder Thread seinen eigenen Befehlszähler und seinen eigenen Stack. Durch die gemeinsame Nutzung des Speicherbereichs kann es natürlich auch zu Konflikten kommen. Diese müssen durch den Einsatz von Synchronisationsmechanismen aufgelöst werden. Die Gesamtheit zusammengehöriger Threads inklusive ihrer Betriebsmittel bezeichnet man als Task.

Da Threads, die dem selben Prozess zugeordnet sind, den gleichen Adressraum verwenden, ist eine Kommunikation zwischen diesen Threads von vorneherein möglich (vgl. mit Interprozesskommunikation bei Prozessen).

Threads innerhalb des gleichen Prozesses verwenden voneinander unabhängige Stapel (Stacks), die unterschiedlichen Abschnitten des Adressraums zugeordnet sind.

Jeder „Programmfaden“ ist für die Ausführung einer bestimmten Aufgabe verantwortlich. Die Ausführungsstränge der Programmfunktionen können damit in überschaubare Einheiten aufgeteilt werden.

Bei den meisten Betriebssystemen kann ein Thread neben dem Zustand inaktiv die Zustände rechnend (engl. running), rechenbereit (engl. ready) und blockiert (engl. waiting) annehmen. Im Zustand rechnend findet die Ausführung von Befehlen auf der CPU statt, bei rechenbereit ist der Thread gestoppt, um einen anderen Thread rechnen zu lassen und bei blockiert wartet der Thread auf ein Ereignis.

Threads in Java

Die Programmiersprache Java ist auf fast allen Plattformen lauffähig und kann als allgemein bekannt angesehen werden. Daher soll Java zur Illustration der Threadverarbeitung herangezogen werden. In Java ist ein Arbeiten mit mehreren Threads von vornherein vorgesehen. Dabei funktioniert das Multithreading auch, wenn das Betriebssystem dieses nicht oder nur mangelhaft unterstützt. Möglich ist das, weil die Virtuelle Maschine des Java die Threadumschaltung einschließlich Stackverwaltung übernehmen kann. In Betriebssystemen mit Threadunterstützung können die Betriebssystemeigenschaften direkt genutzt werden. Die Entscheidung darüber liegt in der Programmierung der Virtuellen Maschine.

In Java gibt es im Basis-Package java.lang die Klasse Thread. Instanzen von dieser Klasse sind Verwaltungseinheiten der Threads. Thread kann entweder als Basisklasse für eine Anwenderklasse benutzt werden, oder eine Instanz von Thread kennt eine Instanz einer beliebige Anwenderklasse. Im zweiten Fall muss die Anwenderklasse das Interface java.lang.Runnable implementieren und demzufolge eine Methode run() enthalten.

Ein Thread wird gestartet mittels Aufruf von thread.start(). Dabei wird die zugeordnete run()-Methode abgearbeitet. Solange run() läuft, ist der Thread nicht inaktiv.

In der Methode run() oder in den von dort gerufenen Methoden kann der Anwender mittels wait() den Thread eine Zeit (in Millisekunden angegeben) oder auch beliebig lange warten lassen. Dieses Warten wird aber mit einem notify() aus einem anderen Thread beendet. Das ist ein wichtiger Mechanismus der Inter-Thread-Kommunikation. wait() und notify() sind Methoden der class Object und auf alle Instanzen von Daten anwendbar. Zueinandergehörige wait() und notify() sind an der selben Instanz (einer Anwenderklasse) zu organisieren, sinnvollerweise werden in dieser Instanz dann auch die Daten übergeben, die ein Thread dem anderen mitteilen möchte.

Die Realisierung von kritischen Abschnitten erfolgt mit synchronized.

In der ersten Version von Java wurden Methoden der class Thread zur Unterbrechung eines Threads von außen, Fortsetzung und Abbruch eingeführt: suspend(), resume() und stop(). Diese Methoden wurden aber recht schnell in Nachfolgeversionen als Deprecated (missbilligt) bezeichnet. In der ausführlichen Begründung wurde ausgeführt, dass ein System unsicher ist, wenn ein Thread von außen angehalten oder abgebrochen werden kann. Die Begründung mit wenigen Worten ist folgende: Ein Thread kann sich möglicherweise in einer Phase eines kritischen Abschnittes befinden und Daten teilweise geändert haben. Wird er angehalten, dann ist der kritische Abschnitt blockiert und deadlocks sind die Folge. Wird er abgebrochen und die Blockierung vom System aufgehoben, dann sind Daten inkonsistent. An dieser Stelle kann ein Laufzeitsystem nicht selbst entscheiden. Ein Anhalten oder Abbruch eines Threads kann nur im Anwenderprogramm selbst gesteuert erfolgen. Dazu muss der Anwender an bestimmten Stellen Bedingungen für Abbruch oder Warten abfragen. Das ist auch meist recht einfach programmierbar, da Threads meist zyklische Aktivitäten erledigen müssen und daher in Schleifen programmiert sind. Dies ist eine wichtige Erfahrung beim Umgang mit Threads.

Threaddarstellung in UML

Parallele Prozesse werden in der Unified Modeling Language (UML) oft mit Zustandsdiagrammen (Statecharts) dargestellt. In einem Zustandsdiagramm sind innerhalb eines Zustandes interne parallele Teil-Zustandsdiagramme darstellbar. Alle Zustandsdiagramme des Gesamtsystems werden quasiparallel angearbeitet. Die Parallelität wird dadurch erreicht, dass jeder Zustandsübergang atomar kurz sein soll (in der Praxis in wenigen Mikrosekunden bis Millisekunden abgearbeitet ist) und daher das Nacheinander der Abarbeitung als parallel erscheint. Der Übergang von einem State in einen anderen wird typischerweise mit einem Ereignis (Event) ausgelöst, das zuvor in die sogenannte Eventqueue eingeschrieben wurde. Dieser Übergang aufgrund eines Ereignisses ist nach der oben angegebenen Definition ein Fiber. Prinzipiell ist die damit realisierte Parallelität mit nur einem einzigen Betriebssystem-Thread erreichbar.

Setzt man UML für schnelle Systeme ein, dann spielt die Frage einer zeitlichen Priorisierung eine Rolle. Können Zustandsübergänge längere Zeit in Anspruch nehmen oder es soll in einem Übergang noch zusätzlich auf Bedingungen gewartet werden (passiert bereits bei einem einfachen Lesen oder Schreiben auf eine Datei), dann muss eine Parallelität mit Threads realisiert werden. Aus diesem Grunde muss man die Zustandsdiagramm-Abarbeitung mehreren gegebenenfalls unterschiedlich prioren Threads des System zuordnen können. Das UML-Werkzeug Rhapsody kennt dazu den Begriff der aktiven Klasse. Jede aktiven Klasse ist einem eigenem Thread zugeordnet.

Zusätzlich zur Formulierung von Parallelarbeit mit Statecharts kann auch in UML-entworfenen Systemen eine Parallelität mit Threads modelliert werden. Es kann dazu das Programmier-Modell verwendet werden, das Java bietet. In diesem Fall ist im Anwender-Modell eine explizite Klasse Thread mit den in Java bekannten Eigenschaften einzubringen. Damit sind hochzyklische Probleme einfacher und effektiver zu beherrschen, wie das folgende Beispiel zeigt:

void run()
{ 
  while(not_abort)          //zyklisch bis zum Abbruch von aussen
  {
    data.wait();            //der Zyklus beginnt wenn Daten vorliegen
    dosomething();          //Abarbeitung mehrerer Dinge
    if(condition)
    { 
      dotheRightThing();    //Abarbeitung ist von Bedingungen abhängig
      partnerdata.notify(); //andere Threads benachrichtigen
    }
  } 
}

Die hier gezeigte Methode run() ist eine Methode einer Anwenderklasse, in ihr ist die gesamte Abarbeitung im Thread wie bei funktionalen Abarbeitungen auch in der UML üblich in Programmzeilen beschrieben. Die UML wird benutzt, um diese Anwenderklasse, die zugehörige Klasse Thread und deren Beziehungen zu zeigen (Klassendiagramm), ergänzt beispielsweise mit Sequenzdiagrammen. Die Programmierung ist übersichtlich. Ein Zustandsdiagramm bietet für diesen Fall keine besseren grafischen Möglichkeiten.

Threads unter UNIX und Windows

folgt noch mit kurzer Benennung einiger wichtiger Funktionsrufe

Siehe auch

• Thread (andere Bedeutungen des Wortes)
• Verklemmung (deadlock)
• Multithreading
• Hyper-Threading
• Kritischer Abschnitt
• Nebenläufigkeit
• Parallelisierung
• Parallelisierbarkeit
• Prozess
• Semaphor
• Synchronisation
• Locking (Sperre)
• Socket
• Server
• Task
• Kommunikation
• Mutex

Literatur

• Peter Ziesche: Nebenläufige & verteilte Programmierung, W3L, 2004, ISBN 3937137041
• Marcus Roming, Joachim Rohde: Assembler - Grundlagen der Programmierung. MITP-Verlag, ISBN 3-8266-0671-X
• Olaf Neuendorf: Windows Multithreading mit C++ und C#. MITP-Verlag, ISBN 3-8266-0989-1
• Heinz Kredel, Akitoshi Yoshida: Thread- und Netzwerk-Programmierung mit Java. Dpunkt Verlag, ISBN 3-89864-133-3
• Rainer Oechsle: Parallele Programmierung mit Java Threads. Hanser Fachbuchverlag, ISBN 3-446-21780-0
• Andrew S. Tanenbaum: Moderne Betriebssysteme. Pearson Studium Verlag, ISBN 3-8273-7019-1
• Hans Joachim Müschenborn: OS/2 Systemprogrammierung. Multitasking – Interprozesskommunikation – Multithreading – DB/2-Integration. tewi-Verlag, ISBN 3-89362-344-2

Weblinks

• Programmierung mit POSIX- und Java-Threads - Pack die Threads in den Bankomat!
• Prozesse und Threads - Hintergrund und aktuelle Entwicklungen - Klon-Debatte
• Newsgroup: comp.programming.threads
• Antworten zu häufig gestellten Fragen aus comp.programming.threads (englisch)
• Frequently Asked Questions, Most FAQ (englisch)
• Diskussion „Writing a scalable server“ (englisch)
• The C10K problem (englisch)
• Business logic processing in a socket server – thread pools (englisch)
• Einführung in Pthreads mit C (englisch)

Dieser Beitrag stammt in seiner ersten oder einer späteren Version der deutschsprachigen Wikipedia. Er ist dort unter Thread_(Informatik) zu finden, die Liste der bisherigen Autoren befindet sich in der Versionsliste.