Verständnisfrage über die Funktion fork()

konkret

Hallo liebe C++ und Ubuntu Freunde!

Ich habe mal eine Verständnisfrage im Bezug auf die Funktion fork().

Die Funktion starten doch ein neuen Prozess aus einem Eltern-Prozess heraus.

Mal ein einfache Beispiel:

if ((child_id = fork()) == 0){
           \\ Hier starten der Kind-Prozess
           \\ Hier sind meine Berechnungen
           \\ Schreibe Berechnungen in die Pipe
           Return 0
        }
          else // Fehlermeldung
// Hier Beginnt Eltern-Prozess

Wenn jetzt das Return nicht wäre, würde das Kind-Prozess noch aktiv sein? Sind die Klammern innerhalb, ein Anzeichen für das Kind-Prozess. Oder zählt hier die Bedingung, dass das Kind-Prozess aktiv ist (erzeugt wurde) if Klausel!
Oder sind Eltern und Kind-Prozess jetzt gleichzeitig aktiv, und besitzen eine unterschiedliche ID!!!

Ich wollte eine Grafick-Bibliothek benutzen, und jeweil für das Eltern und das Kind-Prozess eine While-Bedingung starten. Das Kind-Prozess und das Eltern Prozess sollen jeweils Application -Handler zugewiesen bekommen. Das Kind-Prozess soll einen bestimmten Rahmen aus dem Bild berechnen, und mit Hilfe einer Pipe den Eltern Prozess die Koordinaten mitteilen.

Bringt das überhaupt Vorteile mit sich, das Programm auf mehrere Prozesse aufzuteilen (Performance)

Über Antworten wäre ich sehr dankbar!

Grüße

scimansix

konkret schrieb:

Wenn jetzt das Return nicht wäre, würde das Kind-Prozess noch aktiv sein? Sind die Klammern innerhalb, ein Anzeichen für das Kind-Prozess. Oder zählt hier die Bedingung, dass das Kind-Prozess aktiv ist (erzeugt wurde) if Klausel!
Oder sind Eltern und Kind-Prozess jetzt gleichzeitig aktiv, und besitzen eine unterschiedliche ID!!!

fork() erzeugt eine Kopie des aufrufenden Prozesses. Die Kopie unterscheidet sich nur in einigen wenigen Aspekten. Dazu zählt eine neue PID, die der erzeugte Kindprozess erhält. Die Ausführung der beiden Prozesse wird an der gleichen Stelle fortgesetzt. fork() gibt dem Child 0 zurück, dem Parent die PID des Child. So können die beiden Prozesse unterscheiden, ob sie nun Vater- oder Kindprozess sind.

Wäre das return im if-Block nicht, würde der Kindprozess einfach weiterlaufen, ja. Übrigens solltest du deinen else-Block nochmal überdenken. An den Parent wird wie gesagt die PID des Child zurückgegeben. Ein Fehler ist nur aufgetreten, wenn fork() -1 zurückgibt.

konkret schrieb:

Bringt das überhaupt Vorteile mit sich, das Programm auf mehrere Prozesse aufzuteilen (Performance)

Das bringt nur etwas, wenn mehrere Prozessoren (oder Kerne) vorhanden sind (oder der Prozessor wenigstens über so etwas wie HyperThreading verfügt). Auf einem Prozessor (bzw. Kern) wird das Ganze im schlimmsten Fall durch den entstehenden Overhead (Pipe etc.) sogar langsamer.

Eventuell wären auch Threads eine Alternative für dich. Die ändern zwar nichts an diesem Problem, erzeugen aber etwas weniger Overhead, da die Kommunikation bspw. direkt über den gemeinsamen Hauptspeicher erfolgen kann.

konkret

Danke für deine Antworten!

So in etwa habe ich mir das auch gedacht.

Es wäre auf einen Mehr-Prozessor-System ein Vorteil, ein Programm auf mehrere Prozesse aufzuteilen. Ich denke da an die Bildverarbeitung. Man könnte ja in einem Prozess eine Teilaufgabe lösen, und diese Lösung für einen zweiten Prozess nutzen.

Wenn ich das Program nicht aufteilen würde, dann wäre z.B. nur ein Kern aktiv?

Grüße

scimansix

konkret schrieb:

Es wäre auf einen Mehr-Prozessor-System ein Vorteil, ein Programm auf mehrere Prozesse aufzuteilen. Ich denke da an die Bildverarbeitung. Man könnte ja in einem Prozess eine Teilaufgabe lösen, und diese Lösung für einen zweiten Prozess nutzen.

Wenn dann der erste Prozess nicht nur auf den zweiten Prozess wartet, sondern in der Zwischenzeit etwas anderes tut, dann ist das sehr sinnvoll Ich könnte mir einen Prozess vorstellen, der die zu erledigende Aufgabe unterteilt, auf mehrere Prozesse aufteilt und hinterher die Teilergebnisse wieder zusammenfügt.

konkret schrieb:

Wenn ich das Program nicht aufteilen würde, dann wäre z.B. nur ein Kern aktiv?

Ja, ein Prozess/Thread kann nicht auf mehrere Kerne aufgeteilt werden.

RHBaum

Es wäre auf einen Mehr-Prozessor-System ein Vorteil, ein Programm auf mehrere Prozesse aufzuteilen.

Generell ein positives Ansinnen.
Aber wie immer, steckt der Teufel in der Umsetzung, also in der Implementierung.

Auslastung von mehreren Kernen kann man über multithreading und/oder multiprozessing erreichen.
Dafuer muss aber die "Aufgabe" wirklich auch parrallelisierbar sein, wie scimansix scho andeutet.
Wichtig dabei ist es, das die Aufgaben groesstenteils unabhangig voneinander sein sollten, also die Kommunikation zur laufzeit zwischen den 2 Prozessen / Threads anteilmaessig gegen 0 geht.

Hier tun sich Anfänger mit multiprozessing oft leichter. Weil Kommunikation zwischen 2 Prozessen -> IPC -> "Aufwand" "Schmerz" fuer den Programmierer. Er tut also sehr bewusst Daten austauschen (und hoffentlich nicht unnötig).

Im Gegenzug Multithreading, Gemeinsamer Speicherbereich -> Datenaustausch per Referenz auf Speicher ohne weiteres Möglich.
Der ungeübte Programmierter erzeugt recht schnell Code, der sich "Totsynchronisiert" und am Ende schneller laueft, wenn man das Programm von aussen künstlich auf einen Kern begrenzt.

Mittlerweile sind aber auch Unix und vor allem Linux recht flott mit threads unterwegs, obwohl das eher mal die windows-Domäne war und die *nixe eher gern auf multiprozessing zrueckgegriffen haben.
In Sachen Performance (beim erzeugen und zersoeren, sowie datenaustausch) sind Threads klar im Vorteil.
Prozesse sollten heut eher genutzt werden, wenn die Prozesse unterschiedliche Umgebungen nutzen, also z.b. unter anderen user laufen sollen, etc. ...
Oder um Systembeschränkungen zu den Threads zu umgehen ...

Ciao ....

konkret

Vielen dank für die guten Antworten!

Ich glaube, dass ich das mit den Prozessen mal versuchen werde. Die Prozesse laufen aber quasi paralell ( Wenn man das parallel nennen kann!)

Grüße

RHBaum

Wenn man das parallel nennen kann!

dann nenn es "asynchron"
Da faellt alles drunter, was nicht strikt linear definiert nacheinander kommt ^^

Aber glaub "normale" Programmierer machen Dir keinen Vorwurf, wenn du nen Scheduler mit Zeitscheibe als "parallel" bezeichnest, wenn es nicht im Kontext von kernel oder echtzeit des betriebssystem steht

Ciao ...