zwei Programme Zugriff auf selben Speicherberich

[tin-dong]

Hallo Leute!!

Ich habe ein Problem, bei dem Ihr mir bestimmt helfen könnt. Wie funktioniert das unter C (Linux) das ein Programm1 ein weiteres kleines Programm2 aufruft welches aber auf einen Speicherbereich zugreifen soll welcher von Programm1 benutzt. In diesem Speicherbereich befinden sich Bilddaten welche mir Programm2 ausgeben soll. Der Speicherbereich wird dynamisch von Programm1 bestimmt. Ich muß also den Wert den Speichers des Bildzeigers dem Programm2 übergeben. Geht das überhaupt oder gehe ich einen völlig falschen Weg. Darf Programm2 überhaupt diesen Speicherbereich benutzen?? Ein kleines Beispielprogramm würde mir sehr helfen.

tin-dong

[Jasper]

dafür gibt es "shared memory". google spuckt dazu viel aus.


-j

[panzi]

Bzw. muss es echt ein 2. Programm sein oder kann es auch einfach "nur" ein 2. thread sein? Siehe: pthreads

[RapidMax]

Und vergiss nicht, den Zugriff über Semaphoren zu schützen!

man 5 ipc
man 8 ipcs
man 2 shmget
man 2 semget

Gruss, Andy

[tin-dong]

Alles klar, vielen Dank. Ihr habt mir wirklich weitergeholfen!!!!

tin-dong

[[0x[90]|]

Also komm, wer fuer so ne Lappalie pthreads vorschlaegt ist doch mal krank. Die dinger fressen an speicher, das ist nicht mehr Normal. Ausserdem ist es schwer damit ein sauberes Programm hinzubekommen. Man sollte pthreads wirklich nur da verwenden, wo man nicht anders kann.

[panzi]

|']Also komm, wer fuer so ne Lappalie pthreads vorschlaegt ist doch mal krank. Die dinger fressen an speicher, das ist nicht mehr Normal.
Das war mir nicht klar. Ich hab bis jetzt nur ein paar ganz kleine Übungsprogramme mit pthreads geschrieben, und da war das verwenden von pthreads sehr einfach. Das pthreads speicherfresser sind wusste ich nicht, warum tun sie das?

Ausserdem ist es schwer damit ein sauberes Programm hinzubekommen.
Wieso das? Also bei dem, was ich bis jetzt mit pthreads gemacht hab, hatte ich nicht diesen eindruck.

Man sollte pthreads wirklich nur da verwenden, wo man nicht anders kann.

[[0x[90]|]

Das war mir nicht klar. Ich hab bis jetzt nur ein paar ganz kleine Übungsprogramme mit pthreads geschrieben, und da war das verwenden von pthreads sehr einfach. Das pthreads speicherfresser sind wusste ich nicht, warum tun sie das?

Nun, wenn du geschickt programmierst, verbraucht jeder neu erstellte Thread das doppelte an speicher der gesammten Anwendung. Sprich: 8Mb -> 16Mb -> 32Mb.
Es ist natuerlich nicht so, dass sie per definition Speicherfresser sind, aber er reichen geringe Fehler die jedem Semi-Pro auch passieren koennen, um ein Programm zu einem Speicherfresser mutieren zu lassen.



Wieso das? Also bei dem, was ich bis jetzt mit pthreads gemacht hab, hatte ich nicht diesen eindruck.


Verwendest du die Funktion pthread_cancel? Yay, dann faengt's ja schon an :) Diese Funktion beispielsweise ist im Grunde kompletter Muell, da sie dein Programm sehr leicht unbrauchbar machen kann. Darum verwenden Libs die auf pthreads aufbauen (beispielsweise gthreads) diese Funktion nicht (sie haben sie nicht einmal implementiert).

Ach ja, nicht zu erwaehnen dass sehr viele Libraries (u.a. GTK) nicht pthread faehig sind und man sich wirklich einen ab-coden muss um ein Workaround hinzubekommen.

[panzi]

|']Nun, wenn du geschickt programmierst, verbraucht jeder neu erstellte Thread das doppelte an speicher der gesammten Anwendung. Sprich: 8Mb -> 16Mb -> 32Mb.
Es ist natuerlich nicht so, dass sie per definition Speicherfresser sind, aber er reichen geringe Fehler die jedem Semi-Pro auch passieren koennen, um ein Programm zu einem Speicherfresser mutieren zu lassen.
Aha.

Verwendest du die Funktion pthread_cancel?
Nein.
Ach ja, nicht zu erwaehnen dass sehr viele Libraries (u.a. GTK) nicht pthread faehig sind und man sich wirklich einen ab-coden muss um ein Workaround hinzubekommen.
Naja, solche libs haben oft ja eingne thread-libs. Also bei GTK weiß ich's nicht, aber Qt, z.B. Dann verwendet man halt diese.

[almoeli]

@[0x[90]]



Nun, wenn du geschickt programmierst, verbraucht jeder neu erstellte Thread das doppelte an speicher der gesammten Anwendung. Sprich: 8Mb -> 16Mb -> 32Mb.


Köntest du diese These mal etwas mit Argumenten bzw. Beispielen untermauern. Oder gehst du davon aus, dass sich die Anwedung im neuen Thread komplett kopiert?
So ganz nachvollziehen kann ich diese Behauptung noch nicht. Aber würde mich mal interresieren, ob pthreads wirklich so verschwenderisch implementiert wurde.

Viele Grüsse

almoeli

[RHBaum]

Sorry, ich komm aus der windows ecke ....
und threads unter linux kenn ich nur die pthreads lib ....

iss nur pthread <zensiert> implementiert, oder wird threading vom linux kernel <zensiert> unterstuetzt ?

Unter windows iss ja multithreading das a.o. und multiprocessing eher die ausnahme ....
was nutzt man denn unter linux, wenn man den overhaed vom multiprozessing scheut und schlanke parallele Anwendungen braucht ohne gleich mit IPC drauf loszuschiessen ??? Von haus aus gemeinsam benutzter Speicher hat nun mal erhebliche vorteile, wenn es um performance geht ...

Und noch ne Frage zu dem Thema, vielleicht kann mir ja da auch jemand helfen .... gibt es nen Konzept / bibliothek zum generischen datenaustausch zwischen programmen auf der selben maschine (also muss keine komminication ueber sockets sein, pipes SHM geht auch), ohne den overhaed von corba, und plattformunabhaengig (also nur durch neucompilation auf windoofs und linux etc einsetzbar, nicht dataenaustausch zwischen linux und windows prozessen :) ) ....
sollte klein und performant sein ... von mir aus nachrichtenbasiert ...

gibts da was fertiges ?

Ciao ...

[anda_skoa]

Unglaublich :eek:

Ein Thread hat logischerweise nicht eine Kopie des gesamten Prozessspeichers sondern nur einen eigenen Stack.
Wäre sonst ziemlich nutzlos, da könnte man auch einen Kindprozess benutzen und müßte sich keine Gedanken um gleichzeitigen Zugriff auf Resourcen machen.

@panzi: Qt benutzt als Implementierung Threadingklassen unter Unix auch pthread, heißt ja nicht umsonst POSIX Threads :)

@RHBaum: echtes Threading wird praktisch immer im Kernel unterstützt, weil der nunmal der einzige ist, der gewisse Atomarität garantieren kann.

Der Linux Kernel ist da keine Ausnahme, pthread ist nur die POSIX API für Threads, die dann je nach Betriebsystem mit den dort verfügbaren Systemcalls implementiert wird.

Ich kenn da niemanden, der extra die Native API benutzt und damit auf die Portabilität der pthread API verzichtet.

Ciao,
_

[[0x[90]|]

Nun, ich koennte nun zwar anfangen das ganze bis in's kleinste zu beschreiben und bla. Da ich darauf aber keine lust habe, zieh dir doch einfach mein altes Projekt (http://prdownloads.sourceforge.net/gnotify/gnotify-1.2.tar.gz?download) und schau dir selber an, was fuer einen Muell man mit pthreads hinbekommt. Mittlerweile habe ich mit einer komplett ueberarbeiteten Version des Projekts angefangen (wie man in meiner Signatur sehen kann).
Viel Spass beim Sourcecode lesen ;)

I love obfuscation,
Bye

[panzi]

Also es gibt unter Linux viele möglichkeiten für IPC, z.B. auch UNIX-Sockets: http://unixhelp.ed.ac.uk/CGI/man-cgi?unix+7

[RapidMax]

|']Mittlerweile habe ich mit einer komplett ueberarbeiteten Version des Projekts angefangen (wie man in meiner Signatur sehen kann).
Viel Spass beim Sourcecode lesen ;)

Kommt mir das nur so vor, oder willst du hier nur dein Projekt vorstellen? :p

Gruss, Andy

[[0x[90]|]

Ich kann meinen Post gerne wieder loeschen und nichts antworten. Haette ich das getan, waere man auch nicht zufrieden. Ach wie ich die Menschheit hasse ;)

[bischi]

Kommt mir das nur so vor, oder willst du hier nur dein Projekt vorstellen? :p

Gruss, Andy

Naja - darf er ja... Er hat seine Meinung zu den Threads ja gesagt.

MfG Bischi

[anda_skoa]

Nichtsdesotrotzt ist die Aussage, weiter Threads würden den Speicherbedarf verdoppelt, im Normalfall falsch.

Wenn er es durch "besonders geschicktes" Coden geschafft hat, diesen Effekt zu erreichen ist er selber Schuld :D

Ciao,
_

[klewan]

dieses speicher fressen :-)

is das nicht nur die wollbekannte /proc top, ps problematik? :-d *FG*