Ich verstehe Deine Antwort leider nicht:
Ein Thread ist ein Teil mit einem „point of execution“, also
etwas, das einen eigenen Programmcounter besitzt. Ein Thread
ist also ein Programmstueck, wobei es sich den Programmtext
(also den Code) bereits mit mehreren anderen Threads teilen
kann.
Kannst Du das bitte mal genauer erlaeutern. Deiner Definition
entnehme ich das ein Thread ein Stueck Programmcode ist?!
Ein Task und Prozess sind auch ein Stueck Programmcode oder?
Auch koennen die sich ein Stueck Programmcode „teilen“, wenn
Du zum Beispiel zweimal das selbe Anwendungsprogramm startest.
Was verstehst Du unter point of execution in diesem
Zusammenhang? Was ist ein Programmcounter?
Znuaechstmal: Wir haben einen Prozessor, der Code ausfuehrt. das ist die Realitaet. Alles andere sind Konstrukte, die man sich ueberlegt hat, um die Komplexitaet der Sache beherrschbar werden zu lassen. Es „geht“ also immer alles; die Frage ist nur, ob man es dann noch versteht. Tasks koennen sich also auch Programmcode
teilen, das ist z.B. bei shared Libraries der Fall.
Es geht konkret darum moeglichst flexible Moeglichkeiten zur Verfuegung zu stellen ohne die Absturzwahrscheinlichkeit zu erhoehen.
Das Grundlegende Konzept hierfuer ist das des Prozesses (meistens ein Task) ein Prozess besitzt Speicher, auf den nur er zugreifen
kann, kann den Prozessor fuer gewisse Zeit in Anspruch nehmen und darf fuer gewisse Zeit auf Geraete zugreifen. Prozesse sind also gegeneinander abgeschottet.
das war den Leuten zu restriktiv.
Als wurde Inter-Prozess-Komunikation erfunden (IPC), die es den
Prozessen erlaubt Botschaften auszutauschen. Da man des weiteren feststellte, dass die Standartbibliotheken von vielen Prozessen
gleichermassen benutzt wurden, verzichtete man darauf, diese
wie bisher mehrfach in den Speicher zu laden. Man erfand shared memory, in dem jeweils nur eine Kopie der Bibliothek liegt.
Hier wird jetzt das konzept des „points of execution“ interessant:
Die selbe Bibliothek kann „gleichzeitig“ (Mutitasking) von meheren Prozessen benutzt werden, d.h. die Prozesse koennen sich
gleichzeitig „im selben Code“ an verschiedenen (oder gleichen) Stellen „aufhalten“. Dazu hat man eben statt einem Counter (der frueher mal zu einem Register korrespondierte) fuer jeden Prozess einen Programmcounter, der wenn der Prozess halt an der Reihe ist,
in das entsprechende Registerv kopiert wird. Code der eine solche gleichzeitig-mehrfach-Ausfuehrung zulaesst heist auch „reentrant“, was wesentlich staerkere Bedinungen stellt als das uebliche „ohne Seiteneffekte“.
Nun, das hat den Leuten immer noch nicht gereicht, sie meine Interprozesskommunikation waer zu langsam, der wechel zwischen Prozessen dauert zu lange etc. Dann hat man sich entschieden die
Prozesse in „Threads“ aufzuteilen und das ganze „Task“ zu nennen.
Ein Thread hat einen eigenen Point of execution und eigene stack-variablen. Er teilt sich alles andere mit den anderen Threds seines Tasks. man kann also z.B. ueber globale Variablen kommunizieren. Warerend die task voreinander geschuetzt werden,
muss hier also der Programmierer aufpassen, dass alles klappt.
S. z.B. die Buecher von Tanenbaum oder Siberschatz/Galvin.
MFG
Martin