Was ist ein Thread aus Sicht eines Betriebssystems?

Beim Versuch, die Begriffe "Prozess", "Task" und "Thread" voneinander 
abzugrenzen, wird die Sache erst richtig interessant.

Stark vereinfacht: Den ausführbaren Teil eines Prozesses nennt man 
Thread. Möchte ein Prozess mehrere Aufgaben gleichzeitig erledigen, so 
kann er weitere Threads starten (Bild berechnen, Bild darstellen, 
Tastatur abfragen, ...), die dann quasi oder echt parallel ausgeführt 
werden.

Multithreading ist quasi Multitasking innerhalb eines Prozesses. Die 
Threads eines Prozesses teilen sich in der Regel dessen Ressourcen und 
können auf gemeinsame Daten zugreifen.

Wird der letzte Thread eines Prozesses beendet, so gilt auch der Prozess 
als beendet.

Hoffe, das war noch halbwegs verständlich und verzerrt die Wahrheit 
nicht zu sehr ;)

Aber wie oben schon angedeutet, sind die Begriffe relativ unscharf 
definiert.

Wird ein Programm gestartet, startet ein Prozeß mit eigenem 
Speicherbereich. Ein Thread könnte man als Subprozeß ohne eigenen 
Speicherbereich bezeichnen, er arbeitet im Speicherbereich des 
Elternprozesses.

Tschau Sven!

> So gesehen gibt es aus sicht des Linuxkernels gar keine Usermode-Threads,
> nur Prozesse.

Vorsicht, "Usermode-Threads" bezeichnet ueblicherweise ein anderes 
Konzept als das, was du meinst. Du meinst Kernel-Threads, das sind 
Threads, deren Existenz dem Kernel bekannt ist. Unter Windows bekommst 
du solche zum Beispiel durch die Funktion _beginthread(...).

Kernel-Threads haben den Vorteil, dass das Betriebssystem von deren 
Existenz weiss und daher die Thread-Wechsel selbst vornehmen kann. Wenn 
also ein Thread blockieren sollte oder in einer Endlosschleife haengt, 
werden die anderen Threads davon nicht beeintraechtigt. Ausserdem kann 
das Betriebssystem verschiedene Kernel-Threads auf verschiedene 
CPU-Kerne verteilen.

Ein grosser Nachteil von Kernel-Threads ist allerdings der Overhead: 
Jeder Thread-Wechsel ist relativ teuer, weil dazu in den Kernel-Mode 
geschaltet werden muss. Die Verwaltungskosten, also der Speicherbedarf, 
ist auch relativ gross verglichen mit dem naechsten Konzept.

Usermode-Threads sind dagegen Threads, die nur einen einzigen 
Kernel-Thread belegen und daher dem Betriebssystem nicht bekannt sind. 
Die Thread-Wechsel koennen dann sehr viel effizienter erfolgen, weil 
alles im User-Mode laeuft (daher der Name). Der Speicher-Bedarf von 
Usermode-Threads ist in der Regel auch viel geringer als der von 
Kernel-Threads. Nachteil ist allerdings, dass der Thread-Wechsel nicht 
preemptiv erfolgen kann, das heisst falls ein usermode-Thread in einer 
Funktion blockieren sollte, von der die Usermode-Thread-Library nichts 
weiss, kann dieser Thread nicht unterbrochen werden und blockiert damit 
alle anderen Usermode-Threads.


Dann gibt es auch noch Zwischendinger, die das beste von beiden Welten 
verbinden, wie "light-weight threads" in Haskell. Das sind zuerst einmal 
Usermode-Threads mit entsprechend extrem geringem Overhead, aber man 
kann festlegen auf wie viele Kernel-Threads diese User-Mode-Threads 
verteilt werden. Wenn du zum Beispiel 10 User-Mode-Threads hast, koennen 
je 5 davon einem Kernel-Thread zugewiesen werden. Wenn du ein 
Dual-Core-System hast, sind mehr als zwei Kernel-Threads sowieso wenig 
sinnvoll, da sind User-Mode-Threads effizienter.