Forum: PC-Programmierung Was ist ein Thread aus Sicht eines Betriebssystems?


von Bernd (Gast)


Lesenswert?

Hallo !
Kann mir mit eigenen Worten beschreiben was ein Thread aus Sicht eines 
Betriebssystem ist ? Ich habe damit ein Verständnisproblem und kann den 
Begriff leider immer noch nicht so richtig einem Betriebssystem 
zuordnen.

Manche helfen einfache Wörter um die komplexen Dinge der Technik zu 
beschreiben...

Wäre wirklich dankbar für ne konstruktive Aufklärung :-) :-)

Mfg Bernd

von Andreas K. (a-k)


Lesenswert?

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

von Kai G. (runtimeterror)


Lesenswert?

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.

von Jojo S. (Gast)


Lesenswert?

wichtig ist vielleicht noch das Threads als effizientere Variante 
eingeführt wurden als alles in verschiedene Prozesse zu packen wie es 
unter Unix üblich war. Da wurden mit 'fork' und 'spawn' neue Prozesse 
erzeugt und das OS muss beim Wechseln zwischen Prozessen mehr Resourcen 
umschalten als beim Wechsel zwischen Threads. Soweit ich weiss war OS/2 
eines der ersten OS die das eingeführt hatten.
Edit:
Wikipedia hilft da auch weiter: 
http://de.wikipedia.org/wiki/Thread_%28Informatik%29

von Bartli (Gast)


Lesenswert?

Ist doch alles hochgradig plattformabhängig (auch die 
Terminologie)...wenn du unter Linux mit pthreads arbeitest, siehst du 
für jeden pthread in deinem Programm einen Prozess, welcher allerdings 
nicht mit fork(), sondern mit clone() erzeugt wurde.
clone sorgt dabei unter anderem dafür, dass der Kindprozess keine 
Kopie der Daten das Vaterprozess erhält, sondern dieselben Daten. So 
gesehen gibt es aus sicht des Linuxkernels gar keine Usermode-Threads, 
nur Prozesse.

von Sven W. (woehlb)


Lesenswert?

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!

von Christoph _. (chris)


Lesenswert?

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

von Bartli (Gast)


Lesenswert?

> Vorsicht, "Usermode-Threads" bezeichnet ueblicherweise ein anderes
> Konzept als das, was du meinst. Du meinst Kernel-Threads...

Einen Moment lang wollte ich protestieren, dass ich schon weiss, was ein 
Kernelthread (rein aufn Linuxkernel bezogen!) ist, aber du hast 
natürlich recht.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.