Hi!
Wer kann mir einen mögliche Abgrenzung dieser Begriffe geben?
Also außer Stappelbetrieb / Dialogbetrieb...
Ich habe bisher nur gefunden, die z.B. Microsoft oder Sun für Ihre BS diese Begriffe definieren, aber nicht, wie sie in der Informartik allgemein definiert werden.
Das Unterscheidet sich tatsaechlich von Betriebssystem zu Betriebssystem. Du hast noch den beliebten Thread vergessen.
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 kannn. Eine
Menge von Threads bildet einen Task. Prozess ist ein abstrakteres Wort fuer Task, das z.B. in Systemen ohne Threads immer noch das gleiche meint.
Ein Job ist meiner Meinung nach ein System von Tasks, das durch einen einzelnen Benutzerbefehl gestartet wurde. der Begriff Job wir aber z.B. im Scheduling durchaus fuer "Task" benutzt, das hat aber historische Gruende.
Ich denke das ist es so einigermassen. Jeder Autor hat da so seine Definition und z.B. in machLinux zerfaellt ein thread
nochmals in eine "Activation" und irgendwas anderes.
Chaos.
MFG
Martin
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
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?
Danke fuer Deine Antwort.
Gruss bolo
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
Hallo,
der Begriff scheint heute nicht mehr so gebräuchlich
zu sein (weil heutige Rechentechnik etwas anders arbeitet).
Ich kenne diesen Begriff noch aus der Zeit
der Großrechner (Rechenzentrum) mit Lochkarteneingabe.
Da war ein Job ein auszuführendes Programm, das wenn es an
der Reihe war, in den Rechner eingeladen und komplett
abgearbeitet wurde. Dem entsprechend hieß dann z.B. auch
der Lochkartenstapel mit dem gestanzten Programmcode
"Job". Allerdings mußten es nicht unbedingt Lochkarten sein.
Ein Job konnte z.B. auch von einem Magnetband oder auch
Lockstreifen geladen werden.
Die Angestellten des Rechenzentrums haben also normalerweise
den ganzen Tag "Jobs" abgearbeitet.
Gruß Uwi
