Multithreading
-
tasks und threads sind aber schon was Verschiedenes.
-
Ich schätze, dass nicht viele von den Leuten, die überhaupt in der Lage sind Multithreading zu erkennen, darauf reinfallen würden.
-
Multithreading wird oft unterbewertet, von Leuten die nicht wissen, wie man damit umgehen muss.
-
Erhard Henkes schrieb:
tasks und threads sind aber schon was Verschiedenes.
kommt auf die sichtweise an. der windoof-progger kennt threads, prozesse, tasks und jobs, für low-leveler (RTOS-user etc.) ist task und thread dasselbe, wenn sie das wort 'thread' in dem zusammenhang überhaupt kennen.
~aber gleich kommt unser bärchen mit dem entzündeten hals und wird uns diesbezüglich eine entspannte belehrung erteilen.~
-
nö ich hab halsweh und geh jetzt lieber heia
-
drakon schrieb:
Imo ist es von aussen recht scher fets zu stellen, was ein Programm in welchem Thread macht..
So ist es. In den meisten Windows-Anwendungen werden beispielsweise ein, zwei Hintergrundthreads von den Shell-Dialogen gestartet, zu welchem Zweck auch immer (ich vermute Shell-Notifications).
-
;fricky schrieb:
bei single-core systemen bringts geschwindigkeitsmässig sowieso nix
Das ist falsch, denn es gibt auch noch Sachen wie I/O, wodurch auch ein Kern mal nichts zu tun hat.
-
byto schrieb:
;fricky schrieb:
bei single-core systemen bringts geschwindigkeitsmässig sowieso nix
Das ist falsch, denn es gibt auch noch Sachen wie I/O, wodurch auch ein Kern mal nichts zu tun hat.
das war richtig, auf applikationsseite bringen mehrere threads in dem fall nichts, denn jedes OS kuemmert sich schon mit threads um die sache.
und um auf ursprungsthema zurueck zu kommen, es wuerden die leute es merken die verschiedene cpus vergleichen.
-
byto schrieb:
;fricky schrieb:
bei single-core systemen bringts geschwindigkeitsmässig sowieso nix
Das ist falsch, denn es gibt auch noch Sachen wie I/O, wodurch auch ein Kern mal nichts zu tun hat.
naja, das ist systembedingt, das liegt daran, dass das OS selber sowieso schon threads benutzt. z.b. du rufst irgendeine write-funktion auf und schiebst dabei daten in einen buffer. das I/O-system nudelt sie in einem separaten thread raus. ist der buffer voll, wird dein thread beim schreibversuch geblockt, trotzdem kannste in einem anderen thread parallel was anderes machen. für programmierer praktisch, aber ganz ohne multithreading wäre es schneller (wie die thread-umschalterei entfällt), nur komplizierter.
-
aber ganz ohne multithreading wäre es schneller (wie die thread-umschalterei entfällt), nur komplizierter.
das ist vollkommener unfug.
ganz ohne multithreading/multitasking müsste man auf die platte warten. wenn man sich was eigenes schreibt, um währenddessen was anderes zu machen, schreibt man sich eine eigene kleinen multithreading/multitasking implementierung.
-
ausserdem gibts auch noch so dinge wie hyperthreading
-
rapso schrieb:
byto schrieb:
;fricky schrieb:
bei single-core systemen bringts geschwindigkeitsmässig sowieso nix
Das ist falsch, denn es gibt auch noch Sachen wie I/O, wodurch auch ein Kern mal nichts zu tun hat.
das war richtig, auf applikationsseite bringen mehrere threads in dem fall nichts, denn jedes OS kuemmert sich schon mit threads um die sache.
Klar kümmert sich das OS darum. Ändert trotzdem nichts, dass der Worker-Thread Deiner Applikation u.U. blockiert, bis der I/O Vorgang beendet ist. Lässt Du also einen zweiten Thread laufen, kannst Du den entstandenen Leerlauf sinnvoll nutzen.
Der Overhead des OS-Schedulers bei einem Thread mehr oder weniger ist im Übrigen verschwindend gering.Anderes Beispiel wären GUI Applikationen. Hier stehts wohl ausser Frage, dass man auch bei einem Kern Multithreading benötigt.
-
hustbaer schrieb:
ganz ohne multithreading/multitasking müsste man auf die platte warten.
auch ohne multitasking kann man die wartezeit nutzen, um was anderes zu machen. das ist nur etwas aufwendiger (schrieb ich ja bereits).
Anderes Beispiel wären GUI Applikationen. Hier stehts wohl ausser Frage, dass man auch bei einem Kern Multithreading benötigt.
nö, bei den ollen windosen, win 3.11 und so, gings auch ohne.
-
Manche geben auch einfach zu, wenn sie unrecht hatten. Denn das lässt sie auf Dauer nicht immer unglaubwürdiger erscheinen. Aber wahrscheinlich ist es bei Dir auch schon längst zu spät dafür.
-
;fricky weiß es nicht schrieb:
Anderes Beispiel wären GUI Applikationen. Hier stehts wohl ausser Frage, dass man auch bei einem Kern Multithreading benötigt.
nö, bei den ollen windosen, win 3.11 und so, gings auch ohne.
Win 3.11 hatte doch Multithreading.
Du verwechselst das in deinem jugendlichen Leichtsinn vielleicht mit preemtiven Multitasking.
-
volkard schrieb:
Win 3.11 hatte doch Multithreading.
Du verwechselst das in deinem jugendlichen Leichtsinn vielleicht mit preemtiven Multitasking.nee, win 3.11 lief unter DOS ohne threading u.ä. das fensterlesystem kam völlig ohne aus (wie übrigens auch heute noch). der unterschied war: wenn eine anwendung hing, hingen alle. heute läuft jede windosen-anwendung als separater thread und wenn eine in eine längliche schleife gerät, sind die anderen trotzdem noch bedienbar.
-
;fricky schrieb:
heute läuft jede windosen-anwendung als separater thread und wenn eine in eine längliche schleife gerät, sind die anderen trotzdem noch bedienbar.
Die Anwendung selbst wäre aber halt nicht mehr bedienbar, wenn die lange Operation im selben Thread laufen würde wie der Event Dispatcher der GUI. Von daher brauchst Du bei GUI Anwendungen immer Multithreading, egal ob ein oder mehrere Kerne.
-
;fricky schrieb:
volkard schrieb:
Win 3.11 hatte doch Multithreading.
Du verwechselst das in deinem jugendlichen Leichtsinn vielleicht mit preemtiven Multitasking.nee, win 3.11 lief unter DOS ohne threading u.ä. das fensterlesystem kam völlig ohne aus (wie übrigens auch heute noch). der unterschied war: wenn eine anwendung hing, hingen alle. heute läuft jede windosen-anwendung als separater thread und wenn eine in eine längliche schleife gerät, sind die anderen trotzdem noch bedienbar.
Du verwechselst Threads in deinem jugendlichen Leichtsinn vielleicht mit preemtiven Multitasking.
http://de.wikipedia.org/wiki/Thread_(Informatik)
Schau dort bei Windows 3.1
-
volkard schrieb:
Du verwechselst Threads in deinem jugendlichen Leichtsinn vielleicht mit preemtiven Multitasking.
http://de.wikipedia.org/wiki/Thread_(Informatik)
Schau dort bei Windows 3.1ja, stimmt, diese manuelle umschaltung hab' ich dabei ganz unterschlagen.
Die Anwendung selbst wäre aber halt nicht mehr bedienbar, wenn die lange Operation im selben Thread laufen würde wie der Event Dispatcher der GUI. Von daher brauchst Du bei GUI Anwendungen immer Multithreading, egal ob ein oder mehrere Kerne.
oder du siehst zu, dass du keine langen operationen hast, bzw. bei 'user threads' musste innerhalb von langen operationen die 'switch_to_another_thread()' funktion aufrufen, damit's nicht hängt.
-
;fricky schrieb:
oder du siehst zu, dass du keine langen operationen hast
Das lässt sich in nicht-trivialen Anwendungen ja auch so gut verhindern.
bzw. bei 'user threads' musste innerhalb von langen operationen die 'switch_to_another_thread()' funktion aufrufen, damit's nicht hängt.
Läuft die Operation in einem eigenen (User-) Thread, dann ist ja alles gut.
Keine Ahnung, was der zweite Teil des Satzes bedeuten soll.
