Prozesse/ Threads Unterschied?

[M@tes]

Dachte bisher das seien beide die gleichen Sachen, aber anscheinend ist das nicht so?
Kennt sich da jemand aus? Bevor ich da was heikles programmiere, wovon ich kaum nen Plan habe,
frag ich lieber..
Was ist da bei der "Verwaltung" zwischen Unix/ Windows anders?
Gs

[del_4901]

jeder Prozess hat seinen eigenen Adressraum, bei Threads muss das nicht sein.
Jeder Prozess hat mindestens einen Thread. Jeder Thread hat genau einen Prozess.

[Senior Sanchez]

Das was Prozesse und was Threads sind, ist allgemein auch ne Frage des verwendeten Betriebssystems.

In der Regel kann man sagen, dass ein Prozess den gesamten Programmstatus repräsentiert, inklusive eigenem Adressraum wie AlphaTier schon sagt. Die Threads sind aber in der Regel Bestandteil eines Prozesses und sind die eigentlichen Ausführungseinheiten. Ein Prozess besteht somit in der Regel aus mindestens einem Thread, kann aber eben auch mehrere besitzen.

Manchmal werden Threads auch als leichtgewichtige Prozesse bezeichnet, da sie eben wesentlich einfacher strukturiert sind und somit auch der Threadwechsel wesentlich billiger ist.
Es gibt aber auch Betriebssysteme (waren das die Unix-artigen), da können Threads auch losgelöst sein von Prozessen.

Gerade stelle ich fest, dass das AlphaTier eigentlich alles gesagt hat :D

[M@tes]

OMG =) Ist nämlich folgendes:
Probier gerade in Perl mehrere Programmteile paralell laufen zu lassen.
Hab erstmal mit Fork probiert um quasi ein Kindprozess zu erzeugen, aber Windows hat so seine Mühe, weils anscheinend nur emuliert wird.
Wollte zum testen in 2Kindprozessen gleichzeitig jeweils eine eigene Datei speichern, nur sollang die Unendlichschleife im einen lief, machte der andere nix.
Komischerweise nur beim schreiben. Vermute ein Problem von Windows...
Jetzt will ichs eben mit Threads probieren, da das ganze aber ziemlich Systemnah ist, ists halt schon von Vorteil, wenn man das Backgroundwissen besitzt =)
Gibt es bei den genannten Dingen etwas, was man beachten sollte? Gibts da z.B. irgendwelche Grenzen (Grenzwerte z.B. von verwendeten BS)?

[Grestorn]

OMG =) Ist nämlich folgendes:
Probier gerade in Perl mehrere Programmteile paralell laufen zu lassen.
Hab erstmal mit Fork probiert um quasi ein Kindprozess zu erzeugen, aber Windows hat so seine Mühe, weils anscheinend nur emuliert wird.
Wollte zum testen in 2Kindprozessen gleichzeitig jeweils eine eigene Datei speichern, nur sollang die Unendlichschleife im einen lief, machte der andere nix.
Komischerweise nur beim schreiben. Vermute ein Problem von Windows...
Jetzt will ichs eben mit Threads probieren, da das ganze aber ziemlich Systemnah ist, ists halt schon von Vorteil, wenn man das Backgroundwissen besitzt =)
Gibt es bei den genannten Dingen etwas, was man beachten sollte? Gibts da z.B. irgendwelche Grenzen (Grenzwerte z.B. von verwendeten BS)?

Innerhalb einer Applikation nimmt man in aller Regel nur mehrere Threads. Alle Threads einer Applikation laufen üblicherweise im selben "Prozess", besser: Prozesskontext. Jeder Thread kann prinzipiell ohne Einschränkung auf die Resourcen (also Variablen etc.) eines anderen Threads zugreifen (aber Achtung: Ohne Maßnahmen, die den parallelen Zugriff steuern - Monitore, Semaphore etc. - kann es dabei schnell zu schwer aufzuspürenden Fehlern kommen!).

Prozesse sind dagegen vollkommen voneinander abgeschirmt. Ein direkter Zugriff auf die Resourcen eines anderen Prozesses ist nicht möglich. Wollen zwei Prozesse miteinander kommunizieren, muss ein vergleichsweise aufwendiges Verfahren verwendet werden - Shared Memory, Pipes, IP-Sockets oder ähnliches.

Ein Unix-fork erzeugt in der Tat einen neuen Prozess, wobei der alte komplett geklont wird. Das heißt, beide Prozesse haben zunächst tatsächlich die selben Variablenwerte. Aber eine Änderung einer Variable in dem einen Prozess wirkt sich nicht auf den anderen Prozess aus. Eine Kommunikation ist bei ge-forkten Prozessen deswegen üblicherweise auch nur über Pipes möglich.

Fork ist extrem ineffizient und sollte heutzutage eigentlich nicht mehr verwendet werden.

[Trap]

Fork ist extrem ineffizient und sollte heutzutage eigentlich nicht mehr verwendet werden.
Das ist sehr OS-abhängig.

[Grestorn]

Das ist sehr OS-abhängig.

Nein. Das Prinzip eines Forks ist grundsätzlich nicht sonderlich effizient. Einen Prozess samt allen von ihm benutzten Handles zu duplizieren ist sowieso keine gute Idee. Ich hab nie verstanden, was das mit dem Fork eigentlich soll. Ist zwar schön einfach und simple, aber auch ziemlich unsinnig.

[HellHorse]

Nein. Das Prinzip eines Forks ist grundsätzlich nicht sonderlich effizient. Einen Prozess samt allen von ihm benutzten Handles zu duplizieren ist sowieso keine gute Idee. Ich hab nie verstanden, was das mit dem Fork eigentlich soll. Ist zwar schön einfach und simple, aber auch ziemlich unsinnig.
Zum Glück gibt es Copy-on-write.

[M@tes]

Fand ich ehrlich gesagt auch bez komisch. Habs zwar auch mit Pipes und Socket geschafft, aber beim simpelstem, dem schreiben einer Datei mag er nimmer. Wenns nicht parallel lauft, bringts ja eh nix..
Hab gelesen, das bei XP bei 64 Kindprozessen schluss ist, stimmt das? Oder wäre das einstellbar?
Aber mal zu den Threads.. Wenn ich jetzt aus einem Programm raus 2 Threads starte und in einem die vorher erstellten Variablen ändere, sind diese Änderungen auch beim anderen gültig oder?
Wie sieht das aus, wenn Variablen erst später in einem der beiden Threads erstellt wird?
Wäre diese dann in anderen auch ansprechbar?
/edit: Copy-on-write? Könntest du das kurz beschreiben?

[Monger]

Jetzt mal ganz simpel gesprochen: Prozesse werden durchs Betriebssystem verwaltet, Threads durch Prozesse. Beide haben den Sinn, Nebenläufigkeit zu ermöglichen. Nicht mehr, nicht weniger.

Der wichtigste Unterschied ist, dass das Betriebssystem im allgemeinen nur sehr wenig darüber weiß, was ein Prozess eigentlich macht. Ein Prozess fordert Speicher an, das Betriebssystem teilt ihn zu. Darüber hinaus gibt es noch ein paar Statuscodes die der Prozess absetzen kann oder auch nicht, und damit erschöpft sich im wesentlichen die Kontrolle des Betriebssystems.

Die Kommunikation zwischen verschiedenen Prozesses ist oftmals etwas schwierig, weil nunmal das Betriebssystem als schützende und überwachende Instanz dazwischen steht. Bei Threads ist das viel einfacher, deshalb auch das Schlagwort "leichtgewichtige Prozesse".

[M@tes]

Ah ok! Super! Endlich mal brauchbare Infos, danke! Jetzt macht das ganze auch nen Sinn..
Mitm Taskmanager kann man sich da jetzt auch einwenig ein Bild machen, wie andere Programme funktionieren.
Aber vllt mal so am Rande noch: Was sind Handles? Hab ich gerad zufällig im Taskmgr gesehen.

[Monger]

Aber vllt mal so am Rande noch: Was sind Handles? Hab ich gerad zufällig im Taskmgr gesehen.
Ein Handle ist, wenn du eine Referenz auf ein COM-Objekt hältst. Wenn du also aus deinem Programm heraus irgendwelche fremden Bibliotheken anbindest, und diese benutzst, reservieren sich diese Programme "Handles".

Meines Wissens bezieht sich das jetzt einzig auf die COM Welt. Runtime Umgebungen wie Java oder .NET melden afaik keine Handles an sondern wickeln das intern ab, kann mich aber auch irren.

[Gast]

Ein Handle ist, wenn du eine Referenz auf ein COM-Objekt hältst. Wenn du also aus deinem Programm heraus irgendwelche fremden Bibliotheken anbindest, und diese benutzst, reservieren sich diese Programme "Handles".

Meines Wissens bezieht sich das jetzt einzig auf die COM Welt. Runtime Umgebungen wie Java oder .NET melden afaik keine Handles an sondern wickeln das intern ab, kann mich aber auch irren.
Das ist nur eine Form von Handles. Wenn man eine Datei öffnet, entstehen auch Handles etc. Verallgemeinert kann man sagen das Handles eine Art Zeiger auf Betriebssystemressourcen darstellen.

[Ectoplasma]

Ein Handle ist, wenn du eine Referenz auf ein COM-Objekt hältst. Wenn du also aus deinem Programm heraus irgendwelche fremden Bibliotheken anbindest, und diese benutzst, reservieren sich diese Programme "Handles".

Meines Wissens bezieht sich das jetzt einzig auf die COM Welt. Runtime Umgebungen wie Java oder .NET melden afaik keine Handles an sondern wickeln das intern ab, kann mich aber auch irren.

Nicht ganz. Es ist Betriebssystemabhängig, was ein Handle ist und was nicht. Letztendlich ist ein Handle die Adresse eines Stück Speichers, welches vom Betriebssystem alloziert wurde. Ein Handle ist hier zunächst abstrakt zu betrachten. Handles können im Einzelnen aber Dateien, Speicher, Pipes, Devices und andere Dinge sein. Meist gibt es eine Reihe von Funktionen, die man auf jedes beliebige Handle ausführen kann, wie z.B. "gib mir mal deinen Namen". COM Objekte sind eine ganz andere Gruppe von Handles, als z.B. I/O Handles oder Fenster Handle. Interessant ist z.B., dass Handles vom OS überwacht werden und bei einem Absturz eines Prozesses auch wieder freigegeben werden.

Die Handles die der Taskmanager anzeigt, beziehen sich aber nur auf I/O, Prozess oder Device Handle, soweit ich informiert bin. Ja auch ein Prozess und ein Thread werden als Handle behandelt, jedenfalls ist es bei Windows so.

[Coda]

/edit: Copy-on-write? Könntest du das kurz beschreiben?
Es wird erst neuer physikalischer Speicher bei einem Kindprozess angefordert wenn die Speicherseite auch verändert wurde, ansonsten wird von beiden Prozessen die gleiche verwendet.

[Gast]

Interessant ist z.B., dass Handles vom OS überwacht werden und bei einem Absturz eines Prozesses auch wieder freigegeben werden.


Unter Windows wird der Referenzcount eines Kernelobjekt überwacht. Handles sind nur eine Möglichkeit indirekt (über die Handle Tabelle eines Prozess) darauf zuzugreifen. I.d.R. geht dieser zwar gegen Null, wenn der Prozess terminiert (dann werden die Kernelobjekte wie von dir erwähnt automatisch freigegeben), aber das muss ja nicht zwangsweise sein (z.B. wenn man ein named Mutext über mehrere Prozesse verwendet).

[Gast]

Meines Wissens bezieht sich das jetzt einzig auf die COM Welt.

Nein, vollkommen falsch! Das bezieht sich generell auf Kernelobjekte bzw. GDI Objekte (sind zwei verschiedene Handle Tabellen).

[Gast]

Zu erwähnen wäre vielleicht noch, dass unter Windows ausschließlich nur Threads gescheduled werden. Die können dann noch unterschiedliche Prioritäten bekommen.

[Der_Donnervogel]

Der meiner Meinung nach aus Programmierersicht wichtigste Unterschied ist, dass man bei Threads direkt mit den Objekten und Variablen der anderen Threads arbeiten kann. Dies ist einerseits sehr praktisch bei der Programmierung, andererseits sollte man aber ständig im Hinterkopf behalten was Grestorn nur so beiläufig in Klammern erwähnt hat:
(aber Achtung: Ohne Maßnahmen, die den parallelen Zugriff steuern - Monitore, Semaphore etc. - kann es dabei schnell zu schwer aufzuspürenden Fehlern kommen!)

[M@tes]

Kann das sein, das iTunes über 1700Handels hat?!?! :|
Der nächste grösste Prozess hat gerade mal 700Handels :confused:
Coda: Ah ok, wäre auch sinnvoller, eigentlich..
Also wenn ich die Prozesse richtig verstanden habe, macht es ja innerhalb eines Programms ja eher wenig/ selten Sinn.
Hab jetzt mal einwenig mit den Threads probiert. Wie es scheint, sind die Speicherbelegungen später unabhängig von einander.
Sie übernehmen die Selben Startvariablen, werden diese aber in einem Thread geändert, so sind im anderen immernoch die alten gültig.
Kann das sein?
Na da hab ich mir ja was eingebrockt^^

[del_4901]

Hab jetzt mal einwenig mit den Threads probiert. Wie es scheint, sind die Speicherbelegungen später unabhängig von einander.
Sie übernehmen die Selben Startvariablen, werden diese aber in einem Thread geändert, so sind im anderen immernoch die alten gültig.
Kann das sein?
Na da hab ich mir ja was eingebrockt^^
kommt drauf an, bei Threads wird der Stack neu angelegt. Heap und "Konstantenspeicher" wird geteilt.

[M@tes]

Ahh, noch mehr Fachbegriffe! Wieso hat mich da keiner gewarnt? :-(
Hab jetzt bei den Threads mit Pipes probiert. Ging aber nicht, bin ich damit überhaupt richtig?
Oder muss ich bei Threads mit Sockets arbeiten? Dachte, wenn ich den Pipe schon vor den Threads erstelle, sollte es ja gehn. Bei Fork gings ja.

[Ectoplasma]

Ahh, noch mehr Fachbegriffe! Wieso hat mich da keiner gewarnt? :-(

Da gibt es unter Windows noch die Fiber. Das ist ein Thread, bei dem man selbst kontrollieren, wann er gestartet wird und wann nicht. ;)