Threads vs. Prozesse Vor- und NAchteile

[Guest]

Hi,

nun definiert die Literatur ja einen Prozess als ein Programm in Ausführung. Verschiedene Prozesse haben verschiedene Adressräume wohingegen Threads den gleichen Adressraum nutzen. Es wird immer argumentiert, dass man einen Geschwindigkeitsvorteil hat, z.B. an Bsp. eines Webservers auf dem dann mehrere Prozesse laufen. Könnte man aber nicht die Aufgaben die Threads lösen auch in der Art lösen das ein Prozess in mehrere Prozesse zerlegt wird, man also statt Threads mehrere Prozesse nutzt? Diese könnte man doch so programmieren, dass sie z.B. über irgendwelche Funktions- bzw. Methodenaufrufe trotzdem auf den Adressraum des anderen Prozesses zugreifen könnten. Nur weil zu Prozessen etwas mehr Arbeit notwendig ist, Register kopieren usw. ist der Geschwindigkeitsverlust doch nicht so gravierend, oder?

Was ist also der wirkliche Vorteil wenn man Threads, wenn man jetzt mal vernachlässigt, dass Prozesse etwas langsamer sind. Wieso kann man also nicht einfach mehrere Prozesse erzeugen um beim Bsp. des Webservers zu bleiben die die Abarbeitung von Anfragen übernehmen? Gut, die Anzahl von Ports ist begrenzt, aber die Prozesse könnten ja alle am selben Port lauschen und ein Wechsel muss bei nur einer CPU bei Threads und Prozessen durchgeführt werden.

Vielleicht habe ich das alles auch falsch verstanden. Würde mich also freuen, wenn jemand die Sache idiotensicher erklären könnte wieso man Threads statt Prozesse bzw. meiner Prozesszerlegung nutzt.

Ich hoffe das war nicht zuviel Text

 

[Kim Stebel]

"Wieso kann man also nicht einfach mehrere Prozesse erzeugen um beim Bsp. des Webservers zu bleiben die die Abarbeitung von Anfragen übernehmen?"
Natürlich geht das...gibt es ja auch als eine Option bei Apache.

 

[Gast]

Gut, damit wäre es nach deiner Angabe also doch egal ob man Prozesse oder Threads nimmt, aber einen Grund für die Verwendung von Threads muss es ja geben, denn wenn beide Ansätze äquivalent wären, dann bräcuhte ich auch nur Prozesse bzw. Threads und nicht beides...

 

[Kim Stebel]

Du hast doch schon selbst auf den Performance-Aspekt hingewiesen....der Overhead ist bei Prozessen eben größer. Und es gibt keinen gemeinsam genutzten Speicher. Läuft alles über message passing oder ähnliches. Das ist eine ganz andere Architektur.

 

[Gast]

bei threads hat man aber das problem ggf. daten im gemeinsamen speicher konsistent zu halten, oder nicht? Und so groß kann der Performance Gewinn doch nicht sein, oder irre ich mich?

 

[Murray]

bei threads hat man aber das problem ggf. daten im gemeinsamen speicher konsistent zu halten, oder nicht?

Das hat man bei verschiedenen Prozessen auch; bei Thread hat man aber mehr Lösungsmöglichkeiten dafür, weil ja alle Threads auf die gleichen Daten zugreifen können, was bei unterschiedlichen Prozessen so ohne weiteres nicht geht.

Und so groß kann der Performance Gewinn doch nicht sein, oder irre ich mich?

Ich vermute mal, dass zwischen Thread- und Prozessumschaltung Größenordnungen liegen. Es wird aber
wohl von der Relation zur eigentlichen Bearbeitungszeit der einzelnen Tasks abhängen, ob die Wechselzeiten eine Rolle spielen.

 

[Kim Stebel]

Performance-Gewinn hängt von der Anwendung ab. Wenn die beiden Prozesse nahezu gar nicht kommunizieren müssen, ist der Performance-Gewinn durch Threads auch nicht so hoch. Sonst schon...
Natürlich hat man bei gemeinsam genutzem Speicher auch die Möglichkeit, Inkonsistenzen zu erzeugen. Aber es gibt ja selbst bei Threads die Möglichkeit, getrennte Speicherbereiche zu verwenden.
Wenn dich die Performance interessiert: es gibt genug tools um sowas zu messen.

 

[ice-breaker]

also ein Prozesswechsel kostet sehr sehr viel Rechenlast, da Prozessregister umgeschrieben werden müssen, etc etc
Also Threads sind dort deutlich besser, und ich spreche von Größenordnungen von 100-1000.

 

[SlaterB]

die Zahl für sich hat einige Ausdruckskraft, aber was genau bedeutet sie?
falls das Umschalten nun 1ns statt 300 ns dauert aber eh nur alle 10ms stattfindet, dann bringt dieser Faktor 300 praktisch nix