Thread vs. Prozess
-
Also ich glaub ab P4 kann man sogar mit Hyperthreading zwei Threads gleichzeitig auf einem Kern laufen lassen.
Ansonsten ja sogar zum Teil zwei Threads pro kern
-
AlexanderKiebler schrieb:
Ich weiß dass das eigentlich nicht hier her gehört. Aber hab nichts gefunden wo cih hier die Frage passend fand + Hier bekommt man oft auch auf nur am Rand entfernte Themen echt gute Antworten....
Rund um die Programmierung
Alles zum Thema Programmieren: verschiedene Programmiersprachen, Libraries und Algorithmen.
-
@Frager:
Darum geht es bei der Sache ja.
- Wenn ein Multithread Programm nicht von mehreren Kernen profitieren würde, dann wäre die ganze Arbeit für nichts und man hätte sogar noch zusätzlichen Overhead gegenüber einem sequentiellen Programm.@Alexander:
Ich würde das so einteilen, dass wenn die Funktion im Projekt bleibt, dann wird es ein Thread. Allerdings könnte es unter Umständen Sinn machen ein seperates Progrmam zu schreiben, dass den Sinn des Lebens berechnet, welches du dann von deinem Programm aus startest (das muss dann wahrscheinlich aber auch in einem Thread passieren, wenn das Programm kehrt ja nicht zurück) un dann irgendwann bekommst du den Wert 42 zurück und kannst das deinem Spiel mitteilen.
-
Dieser Thread wurde von Moderator/in pumuckl aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
@Drakon
Der Film war echt lustig nicht *ggg* Ich mochte die Dialoge....Okay also ich kann mir dann wohl mal merken:
-Wenn ich ein eigenes Programm schreibe und dieses zum Beispiel mit system aufrufe,
dann muss ich die Kommunikaiton zwischen den Prozessen mit Shared Mem, Sockets etc. machen-Wenn ich einen Thread habe, kann ich auf die Membervariablen meine Programs aus dem Thread heraus zugreifen.
-Synchronisieren mit z.B. Mutex muss ich in jedem Fall.
-Wenn ich Daten aus einem Treiber lesen wollte, gäbe es da einen Vorteil zum lesen einen Prozess zu starten gegenüber zum Lesen einen neuen Thread zu starten ???
-
AlexanderKiebler schrieb:
@Drakon
Der Film war echt lustig nicht *ggg* Ich mochte die Dialoge....Wenn du den Fim mochtest, solltest du mal die Romane lesen. Alle fünf Teile der vierbändigen Trilogie.
-
@Nukularfüsiker
Ich wollte mal, hab von nem Komilitonen das empfohlen bekommen. Hab kurtz reingelesen, also ein zwei Seiten. Ech klasse aber leider nicht dazu gekommen sie zu kaufen und ganz zu lesen... Sollt ich mir mal wieder Uhrlaub leisten, dann muss ich das unbedingt machen ....
-
Ob Thread oder Prozess hängt oft von der gestellten Aufgabe ab und ist auch System-abhängig. Während der typische Win32-Weg Threads sind, setzen viele Unix-daemons auf ge-fork()te-Kindprozesse.
Da findet auch oft ein Umdenken statt. Plug-Ins werden neulich wieder in eigene Prozesse ausgelagert (siehe Firefox), damit ein korrupter Thread nicht alle anderen Threads beeinflusst.
Und unsere Webserver, die früher einen CGI-Prozess nach dem anderen gestartet haben, laden jetzt den Code in ein paar Workerthreads um die Performance zu erhöhen.
Dem Scheduler des Kernels sollte es eigentlich egal sein, ober er zwischen 10-Prozessen mit einem Thread oder 1 Prozess mit 10 Threads die CPU-Zeit verteilt.
(Ok, Ausnahmen bestätigen die Regel
)
-
Hmmm Also ich denke es wäre eine Tabelle mit Pro /contra Prozess gegen Thread hilfreich.
++Pro++
Thread:ProzessKommunikation einfacher (Keine Differentiellen Pointer in Shared Mem, da in gleichen Speicher gemappt):--
--:Ein Korrupter Prozess zerstört nicht den gesamten Programmablauf
Es Gibt Hyperthrading auf Einkernprozessoren:--
Über weitere Ergänzungen wäre ich sehr dankbar.
Auch für den Fall dass eine Hyperthreading Architektur nicht vorhanden ist sowie nur ein einzelner Kern existiert.
-
AlexanderKiebler schrieb:
Hmmm Also ich denke es wäre eine Tabelle mit Pro /contra Prozess gegen Thread hilfreich.
Hilfreich wofür? Beide haben unterschiedliche Eigenschaften. Ob ein Thread oder ein eigener Prozess geeigneter ist, hängt vom zu lösenden Problem ab.
Features sind nicht per Definition als gut oder schlecht einzustufen, entweder du brauchst sie oder du brauchst sie nicht. Shared Memory kann hilfreich oder kontraproduktiv sein.Überleg dir was du brauchst, dann lies nach was die Unterschiede zwischen Threads und Prozessen sind, dann entscheide dich für das passende.
-
Hmm Also ev. ist eine Pro Contra Tabelle zu wertend. Ich suche schon einfach nach genau den Eigenschaften worin die beiden sich unterscheiden.
Oh ja verstehe wie du das meinst ^^. Ich würde nie sagen, Thread ist besser als Prozess, oder Prozess besser als Thread. Eher ein Thread ist für Broblem A besser geeignet als ein Prozess, oder umgekehrt.Ich bin auf der Suche nach Entscheidungskrieterien, auf welche ich für ein gegebenes Problem zurückgreifen kann um eine Entscheidung für Prozess oder Thread zu treffen.
Die tabelle soll einfach Eigenschaften aufzählen. Und da bei dem gegebenen problem (Berechne sinn des Lebens ohne einfrieren->Ich benötige einen Prozess ODER einen thread) die beiden gegeneinander konkurieren, dachte ich eine emotionale Gestaltung mit vs. wäre einprägsam.Wir sind schon einer Ansicht bezüglich der Sache denke ich...
P.s.: Steht aber schon explizit im Text zum eröffnen der Diskussion.
(Also dass entscheidungskriterien gesucht sind)
-
Ok, ich versuche es einmal: Der große Unterschied ist ja der, dass Threads allesamt vom gleichen Prozess abhängen und sich dessen Ressourcen teilen, während Prozesse komplett unabhängig sind und untereinander eher umständlich kommunizieren müssen.
Prozesse:
- Benutzt man, wenn die Unabhängigkeit vom Konzept her wichtig ist. Browsertabs und Plugins sind zum Beispiel oftmals eigenständige Prozesse, so dass ein Fehler oder Absturz in einem Teil nicht zu Fehlern in anderen Teilen führt und auch nicht ein Teil die Kontrolle über andere übernehmen kann.
- Benutzt man, wenn die Unabhängigkeit von der Technik her wichtig ist. Prozesse können theoretisch auf komplett unterschiedlichen Computern laufen und dann über irgendeine nicht näher spezifizierte Schnittstelle kommunizieren. Dies ist zum Beispiel wichtig bei massiv parallelen Programmen. Man kann nur eine Handvoll Prozessorkerne auf einen Chip quetschen, will man größere Parallelisierung muss man irgendwie mehrere Computer zusammenschalten. Diese können sich aber nicht mehr die Ressourcen wie Arbeitsspeicher teilen, das wäre viel zu langsam. Man lässt dann auf jedem Kern einen Prozess einen kleinen Teilaspekt des Problems berechnen und abundzu tauschen die Prozesse untereinander Daten aus. Dies ist die Art und Weise wie in der Regel Supercomputer programmiert werden.
- Bei den beiden vorhergehenden Punkten wird in allen Prozessen das gleiche oder sehr ähnliche Programme ausgeführt, eventuell gibt es noch einen Meisterprozess welcher die anderen überwacht. Dieser Aspekt ist typisch für Prozessparallelisierung. Da die Prozesse relativ unabhängig voneinander sind, sind sie quasi eine Armee von Einzelkämpfern, die alle das gleiche machen.
Threads hingegen:
- Kurz gesagt: Benutzt man immer dann, wenn man keine Prozesse braucht
- Threads kümmern sich oftmals um sehr verschiedene Aufgaben innerhalb des Programms. Einer rechnet, einer kommuniziert mit dem Benutzer, einer schreibt auf die Festplatte, usw. Mit Prozessen würde man niemals Aufgaben auf diese Weise verteilen, weil dazu sehr viel Kommunikation nötig wäre. Bei Threads ist diese Art der Kommunikation hingegen trivial, da sie sich alle Ressourcen teilen.
Als Faustregel kannst du dies nehmen: Ist die Verteilung der Aufgabenstellungen sehr unterschiedlich? Nimm Threads. Ist die Verteilung der Aufgabenstellung so, dass viele auf gleiche Art und Weise an Teilen eines Problems arbeiten? Nimm Prozesse.
-
Hi SeppJ,
das ist sehr einleuchtend.
Hoffe ich bekomme bald etwas übung die richtige auswahl zu treffen.
Gruß
