In der Informatik bezeichnet Thread [θɹɛd] (englisch thread, ‚Faden‘, ‚Strang‘) – auch Aktivitätsträger oder leichtgewichtiger Prozess genannt – einen Ausführungsstrang oder eine Ausführungsreihenfolge in der Abarbeitung eines Programms. Ein Thread ist Teil eines Prozesses.

Es wird zwischen zwei Arten von Threads unterschieden:

1. Threads im engeren Sinne, die sogenannten Kernel-Threads, laufen ab unter Steuerung durch das Betriebssystem.
2. Im Gegensatz dazu stehen die User-Threads, die das Computerprogramm des Anwenders komplett selbst verwalten muss.

Dieser Artikel hier behandelt den Thread im engeren Sinne, also den Kernelthread.

Threads aus Sicht des Betriebssystems

Ein (Kernel-)Thread ist ein sequentieller Abarbeitungslauf innerhalb eines Prozesses und teilt sich mit den anderen vorhandenen Threads (Multithreading) des zugehörigen Prozesses eine Reihe von Betriebsmitteln:

• das Codesegment,
• das Datensegment,
• die verwendeten Dateideskriptoren (ggf. im Datensegment).

Historisch wurde dafür von Friedrich L. Bauer der Begriff Sequentieller Prozess geprägt.

Threads innerhalb des gleichen Prozesses können verschiedenen Prozessoren zugeordnet sein. Jeder Thread besitzt einen eigenen sogenannten Threadkontext:

• unabhängiger Registersatz inkl. Befehlszeiger (Instruction Pointer),
• einen eigenen Stapel (Stack), jedoch meist im gemeinsamen Prozess-Adressraum.
• Als Besonderheit kann es Betriebsmittel geben, die nur von dem erzeugenden Thread benutzt werden können oder dürfen (Beispiel: Thread-local storage, Window-Handle).

Andere Betriebsmittel werden von allen Threads gemeinsam verwendet. Durch die gemeinsame Nutzung von Betriebsmitteln kann es auch zu Konflikten kommen. Diese müssen durch den Einsatz von Synchronisationsmechanismen aufgelöst werden.

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

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 sowie umfangreiche Aufgaben auf mehrere Prozessorkerne verteilt werden.

Bei den meisten Betriebssystemen kann ein Thread neben den Zuständen aktiv (englisch running), bereit (englisch ready) und blockiert (englisch waiting) auch einen Zustand inaktiv annehmen. Im Zustand ‚rechnend‘ (=aktiv =running) findet die Ausführung von Befehlen auf der CPU statt, bei ‚rechenbereit‘ (=bereit =ready) ist der Thread gestoppt, um einen anderen Thread rechnen zu lassen und bei ‚blockiert‘ (=waiting) wartet der Thread auf ein Ereignis (meist dass ein Betriebssystem-Dienst fertig/durchgeführt wurde). Ein Thread im Zustand ‚inaktiv‘ wird meist gerade vom Betriebssystem neu eingerichtet oder hat fertiggerechnet und kann vom Betriebssystem nun aus der Threadliste entfernt oder anderweitig wiederverwendet werden.

Bedeutungsunterschied (Kernel-)Thread gegenüber Prozess, Task und User Thread

Ein Prozess bezeichnet den Ablauf eines Computerprogrammes auf einem oder mehreren Prozessor(en). Einem Prozess sind ein Adressraum und weitere Betriebssystemmittel zugeordnet – insbesondere sind Prozesse gegeneinander abgeschirmt: Versucht ein Prozess, auf Adressen oder Betriebsmittel zuzugreifen, die ihm nicht zugeteilt wurden (und ggf. einem anderen Prozess gehören), so schlägt dies fehl und er wird vom Betriebssystem abgebrochen. Ein Prozess kann mehrere Threads oder – wenn bei dem Programmablauf keine Parallelverarbeitung vorgesehen ist – auch nur einen einzigen Thread beinhalten. Threads teilen sich innerhalb eines Prozesses Prozessoren, den Speicher und andere betriebssystemabhängige Ressourcen wie Dateien und Netzwerkverbindungen. Deswegen ist der Verwaltungsaufwand für Threads üblicherweise geringer als der für Prozesse. Ein wesentlicher Effizienzvorteil von Threads besteht zum einen darin, dass im Gegensatz zu Prozessen beim Threadwechsel kein vollständiger Wechsel des Prozesskontextes notwendig ist, da alle Threads einen gemeinsamen Teil des Prozesskontextes verwenden, zum anderen in der einfachen Kommunikation und schnellem Datenaustausch zwischen Threads.

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

Ein Thread ist wörtlich ein einzelner Ausführungsfaden eines Programms, der Begriff Thread wird aber auf den Ausführungsstrang aus Sicht des Betriebssystems eingesetzt (Kernelthread). In einer Anwendersoftware kann dieser Ausführungsstrang durch geeignete Programmierung nochmals in unabhängige Einzelstränge unterteilt werden. Im englischen Sprachraum hat sich für einen einzelnen solchen Ausführungsstrang der Anwendersoftware der Begriff User-Thread (bei Microsoft Fiber, deutsch: Faser) eingebürgert. Bei User Threads ist allein die Anwendersoftware für die Verwaltung ihrer Ausführungsstränge zuständig.

Implementierungen

#include <windows.h>
DWORD threadId;
HANDLE hThread = CreateThread (NULL, 0, runInThread, p, 0, &threadId);
CloseHandle (hThread);

DWORD WINAPI runInThread(LPVOID runnableInstance)
{
   Runnable* runnable = static_cast <Runnable*> (runnableInstance);
                        // Klassenzeiger oder Zeiger auf Basisklasse
   return(runnable->run()); // run-Methode dieser Klasse wird gerufen.
}

class Runnable // abstrakte Basisklasse (als Schnittstelle verwendbar)
   {
      virtual DWORD fachMethode()=0; // API zum Vererben
   public:
      DWORD run() { return(fachMethode()); } // API zum Aufrufen
      virtual ~Runnable() {} // Wenn vererbt werden soll: Dtor virtuell
   };

class MyThreadClass : public Runnable
   {
      DWORD fachMethode(); // Überschreibt/implementiert die Fachmethode
   };

MyThreadClass myThreadObject;
hThread = CreateThread (NULL, 0, runInThread, &myThreadObject, 0, &threadId);

SetThreadPriority (hThread, THREAD_PRIORITY_BELOW_NORMAL);

DWORD dwExitCode;
GetExitCodeThread (hThread, &dwExitCode);

Schwierigkeiten

Die Verwendung von Threads sowie einfacher Synchronisationsmechanismen wie Mutexen und Semaphoren erweist sich in der Praxis als anspruchsvoll. Da der Programmablauf nicht mehr einfach sequentiell ist, kann ein Entwickler diesen nur schwer vorhersagen. Da die Ausführungsreihenfolge und der Wechsel zwischen den Threads vom Scheduler geregelt wird und der Entwickler nur wenig Einfluss darauf hat, gerät ein nebenläufiges Programm leicht in einen vorher nicht vorgesehenen Gesamtzustand, welcher sich durch Deadlocks, Livelocks, Datenfehler und Abstürze äußert. Diese Effekte treten sporadisch auf und sind somit kaum reproduzierbar, was die Fehlersuche in einer Anwendung schwierig macht.

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 abgearbeitet. Die Quasiparallelität wird dadurch erreicht, dass jeder Zustandsübergang sehr kurz ist (in der Praxis wenige Mikrosekunden bis Millisekunden) und daher das Nacheinander der Abarbeitung als parallel erscheint. Der Übergang von einem Zustand 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 Userthread. 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 Systems zuordnen können. Das UML-Werkzeug Rhapsody kennt dazu den Begriff der aktiven Klasse. Jede aktive Klasse ist einem eigenen Thread zugeordnet.

Zusätzlich zur Formulierung von Parallelarbeit mit Zustandsdiagrammen 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 außen
   {
      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.

Siehe auch

• Hyper-Threading, Multithreading, User-Thread
• Kritischer Abschnitt
• Nebenläufigkeit
• Parallele Programmierung
• Prozess
• Threadsicherheit

Literatur

• Peter Ziesche: Nebenläufige & verteilte Programmierung. W3L, 2004, ISBN 3-937137-04-1.
• 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. 1. Auflage. Fachbuchverlag Leipzig, 2001, ISBN 978-3-446-21780-5, S. 176. 
• Andrew S. Tanenbaum: Moderne Betriebssysteme (= Pearson Studium – IT). 3. aktualisierte Auflage. Addison-Wesley Verlag, 2009, ISBN 978-3-8273-7342-7, S. 1248 (englisch: Modern Operating Systems.). 
• Edward A. Lee: The Problem with Threads. Technical Report, University of California at Berkeley, berkeley.edu (PDF; 199 kB)
• Clay Breshears: The Art of Concurrency. O’Reilly, ISBN 978-0-596-52153-0.
• Dietrich Boles: Parallele Programmierung spielend gelernt mit dem Java-Hamster-Modell – Programmierung mit Java-Threads. (PDF; 4,1 MB) Vieweg+Teubner-Verlag, 2008, ISBN 978-3-8351-0229-3.
• James H. Anderson, Yong-Jik Kim, Ted Herman: Shared-memory mutual exclusion: major research trends since 1986. In: Distrib. Comput. Band 16, Nr. 2–3. Springer-Verlag, September 2003, ISSN 0178-2770, S. 75–110, doi:10.1007/s00446-003-0088-6. 
• M. Raynal, D. Beeson: Algorithms for mutual exclusion. MIT Press, Cambridge MA 1986, ISBN 0-262-18119-3. 

Weblinks

• 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)
• Joseph Albahari: Threading in C#. 27. April 2011, abgerufen am 3. April 2013 (englisch, Ausführliche Anleitung zum Umgang mit Threads in C#). 

Einzelnachweise

1. ↑ vgl. gotw.ca