Wer hat Multithreading erfunden?
-
Bashar schrieb:
Multithreading bezeichnet spezifisch das Nebeneinanderlaufen mehrerer Abarbeitungsstränge (Threads) innerhalb des Adressraumens eines Tasks/Prozesses.
Womit du Prozess und Task gleichsetzt. Wer sagt, dass ein Thread kein Task ist?
Ein Task ist doch eher eine "Aufgabe". Ob das nun ein Thread oder ein Prozess ist ist doch egal.
-
Bashar schrieb:
Multithreading bezeichnet spezifisch das Nebeneinanderlaufen mehrerer Abarbeitungsstränge (Threads) innerhalb des Adressraumens eines Tasks/Prozesses. Maschine hat keinen Speicherschutz und keine Idee von getrennten Adressräumen? Kein Threading. Maschine kennt nur Heavy-Weight-Prozesse? Kein Threading.
ich würd das nicht so eng sehen. z.b. bezeichnen die hersteller von rtos wie cmx und embos ihre 'threads' als tasks. diese systeme haben keinen speicherschutz und nur eine sehr eingeschränkte ressourcenverwaltung eine 'task' dort besteht aus einem registersatz (incl. pc), einem eigenen stack und einer startfunktion. unter windoows z.b. wird das 'thread' genannt...
-
-.-
-
TactX schrieb:
Womit du Prozess und Task gleichsetzt. Wer sagt, dass ein Thread kein Task ist?
Den Begriff Task wollte ich nicht definieren, das kann sein, dass das ungenau ist. Ich hoffe es ist klar, was ich gemeint habe, also bitte nur an der Definition von Thread rummosern
-
O.K. ich überleg mir was
-
naja, es benennt ja doch jeder wie er's will
fette os'se mit virtual memory o.ä haben eben prozesse für multitasking und thread für's aufteilen von tasks (ok, so'n oller linux kernel 2.4 hatte noch keine threads sondern nur prozesse bzw. tasks) und alle anderen, die nur eins davon haben, nennen's task oder thread, wie sie's lieber mögen...
-
net schrieb:
(ok, so'n oller linux kernel 2.4 hatte noch keine threads sondern nur prozesse bzw. tasks)
Damit ist es möglich (seit Linux 2.0) Prozesse zu erzeugen, die sich den Adressraum (und mehr) teilen.
Den Teil der Definition von Threads erfüllt es. Die Frage ist nur, was ist ein "Heavy-Weigth-Prozess"?
Wenn man sich Kernelthreads auf populären Betriebssystemen anguckt, sind die alle nicht sehr leicht. Threads kann man richtig leicht wohl nur im Userspace (oder auf anderer Hardware) implementieren, so wie es in Erlang gemacht wird.
-
rüdiger schrieb:
net schrieb:
(ok, so'n oller linux kernel 2.4 hatte noch keine threads sondern nur prozesse bzw. tasks)
Damit ist es möglich (seit Linux 2.0) Prozesse zu erzeugen, die sich den Adressraum (und mehr) teilen.
Den Teil der Definition von Threads erfüllt es. Die Frage ist nur, was ist ein "Heavy-Weigth-Prozess"?
Wenn man sich Kernelthreads auf populären Betriebssystemen anguckt, sind die alle nicht sehr leicht. Threads kann man richtig leicht wohl nur im Userspace (oder auf anderer Hardware) implementieren, so wie es in Erlang gemacht wird.
Ich dachte, das ginge nur mit Microkerneln?
-
kingruedi schrieb:
Ich dachte, das ginge nur mit Microkerneln?
nein, wieso sollten Userspace-Threads nur mit µKerneln funktionieren? Natürlich umgehst du so den Scheduler und bastelst was eigenes.
-
rüdiger schrieb:
Natürlich umgehst du so den Scheduler und bastelst was eigenes.
windows z.b. hat sowas schon eingebaut. schimpft sich 'fibers'. aber warum m$ das gemacht hat weiss wohl keiner mehr (vielleicht zur unterstützung von javas 'green threads'?). jedenfalls kenne ich kein programm. dass fibers verwendet. es sind ja auch keine 'richtigen' threads...