Thread (Informatik)

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
Mehrere Kernelthreads in einem Prozess (Task)

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:

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.

Beispiele

Die folgende Tabelle zeigt Beispiele für die verschiedenen Kombinationen aus Prozess, Kernel- und User-Thread:

Prozess Kernel-
Thread		 User-
Thread		 Beispiel
Nein Nein Nein Ein Computerprogramm unter MS-DOS ablaufend. Das Programm kann zu einer Zeit nur eine von drei Aktionen ausführen.
Nein Nein Ja Windows 3.1 auf der Oberfläche von DOS. Alle Windows-Programme laufen in einem einfachen Prozess, ein Programm kann den Speicher eines anderen Programms zerstören, was jedoch bemerkt wird und einen General Protection Fault (Allgemeine Schutzverletzung) zur Folge hat.
Nein Ja Nein Ursprüngliche Implementierung des Amiga OS. Das Betriebssystem unterstützt vollständig Threads und erlaubt dabei, dass mehrere Applikationen unabhängig voneinander ablaufen, vom Betriebssystemkern zeitlich geplant. Wegen der nicht vorhandenen Prozessunterstützung ist das System effizienter (wegen der Vermeidung des Zusatzaufwandes des Speicherschutzes), mit dem Preis, dass Applikationsfehler den gesamten Computer lahmlegen können.
Nein Ja Ja DR-DOS 7.01, 7.03, 8.0; Enhanced DR-DOS alle Versionen
Mac OS 9 unterstützt User-Threads mittels Apples Thread Manager und Kernelthreads mittels Apples Multiprocessing Services, das mit dem nanokernel arbeitet, eingeführt in Mac OS 8.6. Damit werden Threads unterstützt, aber immer noch das Verfahren des MultiFinder zum Verwalten von Applikationen benutzt.
Ja Nein Nein Die meisten bekannten Implementierungen von Unix (außer Linux). Das Betriebssystem kann mehr als ein Programm zu einem Zeitpunkt ausführen, die Programmabarbeitungen sind gegeneinander geschützt. Wenn ein Programm 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 fehlerträchtig sein (bei Nutzungen von Techniken wie shared Memory) oder aufwendig (bei Nutzung von Techniken wie message passing). Die asynchrone Ausführung von Aufgaben benötigt einen aufwendigen fork() Systemaufruf.
Ja Nein Ja Sun OS (Solaris) von Sun. Sun OS ist Sun Microsystems Version von Unix. Sun OS implementiert User-Threads als 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 Bedienerereignis zu reagieren wie die Anwahl des stop button. Obwohl Prozesse präemptiv verwaltet werden, arbeiten die green threads kooperativ. Dieses Modell wird oft an Stelle von richtigen Threads genutzt und ist in Mikrocontrollern und sogenannten embedded devices immer noch aktuell, und wird sehr häufig genutzt.

Windows 3.x im Enhanced Mode bei Verwendung von DOS-Boxen fällt ebenfalls in diese Kategorie, da die DOS-Boxen eigenständige Prozesse mit abgeschottetem Adressraum darstellen.

Ja Ja Nein Dies ist der allgemeine Fall der Applikationen unter Windows NT ab 3.51 SP3+, Windows 2000, Windows XP, Mac OS X, Linux, und anderen modernen Betriebssystemen. Alle diese Betriebssysteme erlauben dem Programmierer die Nutzung von User-Threads beziehungsweise von Bibliotheken, die selbst User-Threads verwenden, jedoch nutzen nicht alle Programme diese Möglichkeit aus. Weiterhin können User-Threads auch vom Betriebssystem automatisch für jede gestartete Applikation angelegt werden (zum Beispiel zur Bedienung der grafischen Benutzeroberfläche), ohne dass dies explizit vom Programmierer getan werden muss; solche Programme sind dann automatisch multithreaded. Außerdem ist es notwendig, mehrere User-Threads zu verwenden, wenn man mehrere Prozessoren/Prozessorkerne in der Anwendung ausnutzen möchte.
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 seine grafische Benutzerschnittstelle abarbeiten kann, während es gleichzeitig auf eine Eingabe des Benutzers wartet oder andere Arbeiten im Hintergrund ausführt.

Bemerkungen:

  • Die Nutzung von User-Threads ist prinzipiell unabhängig vom Betriebssystem. Sie ist damit mit jedem Betriebssystem möglich. Wichtig ist nur, dass sich der komplette Zustand des Prozessors auslesen und wieder zurückschreiben lässt (User-Threads sind auch in einigen 8-Bit-Betriebssystemen implementiert worden, so z. B. als GEOS auf dem C64/C128). Daher sind die Werte in der Tabelle als Anhaltswerte zu sehen.
  • Einige moderne Betriebssysteme (z. B. Linux) lassen keine strikte Unterscheidung zwischen Prozessen und Kernel-Threads mehr zu. Beides geschieht mit demselben Systemruf (clone(2)), man kann feingranular angeben, welche Ressourcen geteilt und welche nicht geteilt werden (Ausnahme: CPU-Register, Stack). Bei etlichen Ressourcen kann man das zur Laufzeit des Threads sogar noch ändern (Speicher: TLS vs. Shared Memory, File Handle: socketpair).

Implementierungen

Java

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 von 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 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 beliebigen Anwenderklasse. Im zweiten Fall muss die Anwenderklasse die Schnittstelle 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 aktiv.

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 Klasse Object und auf alle Instanzen von Daten anwendbar. Zueinandergehörige wait() und notify() sind an derselben 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 (ausgedient, 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 das Anwenderprogramm selbst steuern.

.NET

.NET unterstützt von Haus aus Threadprogrammierung. Realisiert wird dies durch die Klassen im Namensraum System.Threading.

Zusätzlich zu den oben genannten Konstrukten Prozess und Thread gibt es dort noch das Konzept einer Anwendungsdomäne (AppDomain). Ein Prozess kann dabei mehrere Anwendungsdomänen enthalten, diese werden von der Runtime isoliert („logischer Prozess“), eine vom .Net-Framework bereitgestellte Ressource ist an die erzeugende Anwendungsdomäne gebunden. Betriebsmittel des unterliegenden Betriebssystems (auch Kernelthreads!) sind aber nicht an diese logischen Prozessgrenzen gebunden.

Auch bietet die .NET-Runtime einen von der Runtime verwalteten Threadpool, der durch diese zur Verarbeitung von asynchronen Ereignissen und Ein-/Ausgabeoperationen verwendet wird.

Die .NET-Runtime unterscheidet außerdem zwischen Vordergrundthreads und Hintergrundthreads. Ein Thread wird zum Hintergrundthread durch Setzen der Eigenschaft Background auf true. Ein Prozess wird beendet, wenn der letzte Vordergrundthread beendet ist. Alle dann noch laufenden Hintergrundthreads werden automatisch beendet. Threadpool Threads werden als Hintergrundthread gestartet.

Einen eigenständigen Thread startet man über eine neue Instanz einer Thread-Klasse, der im Konstruktor eine Rückruffunktion (Delegate) übergeben wird. Der Thread wird dann über die Instanzmethode Start() gestartet. Der Thread wird beendet, wenn die Rückruffunktion die Kontrolle an den Aufrufer zurückgibt.

Alternativ ist für kurze Hintergrundverarbeitung der ThreadPool der .NET Runtime nutzbar. Dieser hält eine gewisse Anzahl von Threads vor, die über ThreadPool.QueueUserWorkItem() zur Verarbeitung genutzt werden können. Nach Rückkehr der übergebenen Rückruffunktion wird der Thread dann nicht durch das Betriebssystem zerstört, sondern für die spätere Verwendung zwischengespeichert. Vorteil dieser Klasse ist die optimierte, beschränkte Nutzung des zugrunde liegenden Betriebsmittels.

Eine externe Steuerung der Threads ist möglich (Abort(), Suspend(), Resume()), kann aber zu unvorhersehbaren Ereignissen wie deadlocks oder Abbrüchen der Anwendungsdomäne führen. Deshalb sind Suspend und Resume in neueren Versionen von .NET als obsolet markiert.

Die Synchronisation von Threads erfolgt durch ein WaitHandle. Genutzt wird dieser meistens über die Klasse Monitor die einen durch jedes .NET-Objekt zur Verfügung gestellten Mutex nutzt. In C# kann dazu das lock(object){ Anweisung; } Konstrukt genutzt werden. Viele Klassen des .Net-Framework existieren zusätzlich in einer Threadsicheren Variante die über eine statische Methode Synchronized() erstellt werden kann.

Unix/Linux

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 Parallelverarbeitung realisiert. Threads sind in späteren Unix-Versionen eingefügt worden, jedoch war die Portabilität zwischen früheren Derivaten nicht gewährleistet. Der Standard POSIX-Thread (Native POSIX Thread Library) legte schließlich einen einheitlichen Mindestfunktionsumfang und einheitliche API fest, die auch von aktuellen Linux-Versionen unterstützt wird (NPTL). Gegenüber einem Prozess wird ein Thread auch als Leichtgewichtprozess (Solaris) bezeichnet, da die Umschaltung zwischen Prozessen mehr Aufwand (Rechenzeit) im Betriebssystem erfordert als die Umschaltung zwischen Threads eines Prozesses.

Windows

Um unter Windows in C oder C++ einen eigenen Thread zu erzeugen, kann man direkt auf die Windows-API-Schnittstellen zugreifen. Dazu muss man als einfaches Muster aufrufen:

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

runInThread ist die Subroutine, die in diesem Thread laufen soll, sie wird unmittelbar danach aufgerufen. Wird runInThread beendet, dann ist auch der Thread beendet, ähnlich wie Thread.run() in Java.

Diese API ist eine C-orientierte Schnittstelle. Um Threads auch objektorientiert zu programmieren, kann nach folgendem Schema in der Subroutine runInThread eine Methode einer Klasse gerufen werden:

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.
}

Diejenige Klasse, die die run()-Methode für den Thread enthält, ist hier in einer Klasse Runnable enthalten, das kann auch eine Basisklasse einer größeren Klasse sein. Der Zeiger auf die Instanz einer gegebenenfalls von Runnable abgeleiteten Klasse muss bei CreateThread als Parameter (p) übergeben werden, und zwar als (Runnable*) gecastet. Damit hat man hier die gleiche Technik wie bei Java in der Hand. Wie folgt wird die universelle Basisklasse (eine Schnittstelle) für alle Klassen, deren run()-Methoden in einem eigenen Thread laufen sollen, definiert:

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
   };

Folgend wird die Anwenderklasse, mit der fachMethode[1] definiert:

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

Folgend wird die Anwenderklasse instanziiert und der Thread gestartet:

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

Wegen des dynamischen Bindens wird die gewünschte Methode myThread->fachMethode() gerufen. Achtung: Es muss auf den Lebenszyklus von myThreadObject geachtet werden: Man darf es nicht implizit „abräumen“, solange der neue Thread noch damit arbeitet! Hier ist Threadsynchronisation gefragt.

Weitere Zugriffe auf den Thread auf API-Ebene können unter Kenntnis des zurückgelieferten HANDLE ausgeführt werden, beispielsweise

SetThreadPriority (hThread, THREAD_PRIORITY_BELOW_NORMAL);

oder um den Rückgabewert der aufgerufenen Methode runInThread abzufragen (im Beispiel 0):

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

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.

Einzelnachweise
  1. vgl. gotw.ca
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.