Discussion :

[godskitchen]

Bonjour à tous,

J'ai crée une mémoire partagée afin de pouvoir faire communiquer deux applications distinctes. L'une des applications fait des allocations dynamiques en tout début de programme. Etant donné que ces buffers (dynamiquement alloués) sont dans le tas, je suis obligé de faire des memcpy de ces buffers vers la mémoire partagée. Est-il possible de créer une grosse mémoire partagée et de faire en sorte que toutes les allocations dynamiques soient faites dans l'espace mémoire partagée ? Il faudra probablement surcharger les opérateurs new et delete mais je ne vois pas de quelle manière le faire ...

Merci de votre aide

[Emmanuel Deloget]

Bonjour à tous,

J'ai crée une mémoire partagée afin de pouvoir faire communiquer deux applications distinctes. L'une des applications fait des allocations dynamiques en tout début de programme. Etant donné que ces buffers (dynamiquement alloués) sont dans le tas, je suis obligé de faire des memcpy de ces buffers vers la mémoire partagée. Est-il possible de créer une grosse mémoire partagée et de faire en sorte que toutes les allocations dynamiques soient faites dans l'espace mémoire partagée ? Il faudra probablement surcharger les opérateurs new et delete mais je ne vois pas de quelle manière le faire ...

Merci de votre aide

Comme dirait un chantre de l'humour français, "y'en a qu'on essayé, ils ont eut des problèmes. Cela dit, c'est vous qui voyez."

C'est une (relativement) mauvaise idée. Le problème que tu vas rencontrer, c'est celui de la fragmentation de la mémoire. Tu risques donc d'être obligé d'écrire un garbage collector pour régler ce problème, et tu verras vite que 1) ce n'est pas simple 2) ce n'est pas très efficace en C++ 3) si jamais tu stocke des pointeurs, ça risque même d'être lent et vraiment, vraiment très compliqué.

Après, c'est tout a fait possible. Juste pas conseillé

[Bousk]

Bonsoir,

Pourquoi ne pas faire communiquer les applis via socket?

[godskitchen]

C'est une (relativement) mauvaise idée. Le problème que tu vas rencontrer, c'est celui de la fragmentation de la mémoire. Tu risques donc d'être obligé d'écrire un garbage collector pour régler ce problème, et tu verras vite que 1) ce n'est pas simple 2) ce n'est pas très efficace en C++ 3) si jamais tu stocke des pointeurs, ça risque même d'être lent et vraiment, vraiment très compliqué.

Le garbage collector est déjà implémenté, et je ne vois pas pourquoi ça risque d'être lent si je stocke des pointeurs.... ? Peux-tu m'éclairer ?

Pourquoi ne pas faire communiquer les applis via socket?

Pour plusieurs raisons:
La première est pour éviter d'avoir à créer un wrapper qui transforme mes structures de données en un tableau de char (format pour transmettre des donnnées via sockets) ensuite je veux limiter au maximum les duplications de données et enfin la communication par mémoire partagée est de loin la plus rapide.

Quelqu'un aurait une idée concrète de la manière dont il faut s'y prendre pour atteindre mon objectif ?

[koala01]

Salut,

Le garbage collector est déjà implémenté, et je ne vois pas pourquoi ça risque d'être lent si je stocke des pointeurs.... ? Peux-tu m'éclairer ?

Pas en C++ en tout cas...

Si tu disposes d'un GC, soit, c'est que tu ne code pas en C++ (au mieux en C++/CLI), soit tu en a implémenté un toi meme, mais, dans ce cas, es-tu sur qu'il est correct

Pour plusieurs raisons:
La première est pour éviter d'avoir à créer un wrapper qui transforme mes structures de données en un tableau de char (format pour transmettre des donnnées via sockets)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
UnType obj;
char  * temp =  reinterpret_cast<char *>(&obj);
UnType * ptr = reinterpret_cast<UnType*>(temp);

est le genre de comportement garanti par la norme...

Le seul point auquel il est sans doute nécessaire d'être attentif, c'est le cas où un membre est ou utilise un pointeur vers autre chose de manière interne.

En outre, boost::serialize peut franchement s'avérer pas mal et très utile:
Non seulement, tu te donnes la possibilité de sérialiser tes données "d'une autre manière"(par exemple si elles viennent d'une BDD, ca te permet de récupérer les données d'exécution dans un fichier de log ), mais cela permet d'obtenir assez facilement un tableau de caractères à passer au socket et inversement

ensuite je veux limiter au maximum les duplications de données et enfin la communication par mémoire partagée est de loin la plus rapide.

Mais plus limitée aussi : tu ne peux partager la mémoire qu'entre deux applications s'exécutant sur la même machine, alors que les sockets te permettent, le cas échéant, d'avoir l'une des applications se trouvant sur une machine distante

[godskitchen]

LE GC a été implémenté par mes soins, et je suis sûr qu'il fonctionne bien.

Pour des raisons particulières, l'une des applications est implémentée en C++ et l'autre en C, donc il m'est impossible d'utiliser des librairies C++. (pour info, avant chaque transmission de données celle-ci sont mise dans un "format C" --> utilisation d'une structure C).

Les deux applications tourneront, pour mon cas d'usage, sur la même machine donc j'ai tout intérêt à utiliser de la mémoire partagée.

[Ehonn]

Je ne pense pas que ce soit portable mais tu pourrais jetter un coup d'œil aux IPC.

Cette méthode évite de faire des copies de/vers l'espace système pour transférer de l'information. En effet, plusieurs processus voient la même zone mémoire dans leurs espaces virtuels respectifs et cette mémoire leur est accessible comme de la mémoire ordinaire: c'est donc à eux de gérer les problèmes des accès concurrents. Cette méthode est particulièrement recommandée dans la communication de gros volumes de données

[Emmanuel Deloget]

LE GC a été implémenté par mes soins, et je suis sûr qu'il fonctionne bien.

Pour des raisons particulières, l'une des applications est implémentée en C++ et l'autre en C, donc il m'est impossible d'utiliser des librairies C++. (pour info, avant chaque transmission de données celle-ci sont mise dans un "format C" --> utilisation d'une structure C).

Les deux applications tourneront, pour mon cas d'usage, sur la même machine donc j'ai tout intérêt à utiliser de la mémoire partagée.

Je me suis peut-être mal exprimé. Un GC (dans le sens où il se contente de récupérer les blocs et de les redonner au système) n'apporte pas grand chose. Si le GC déplace les blocs en mémoire, on peut alors luter contre la fragmentation de manière efficace.

Hors le déplacement en mémoire de blocs est une opération coûteuse. Maintenant, si tu rajoute la dedans qu'un bloc peut contenir un pointeur ou un offset vers un autre bloc de la même SHM, la tu commences à avoir un algo vraiment complexe, puisqu'il va aussi devoir (avec une heuristique qui minimise les risques d'erreur) déterminer où sont les offsets afin de les mettre à jour lorsque le bloc est déplacé.

Un tel GC est très complexe, et en plus d'être complexe il est relativement lent. Si tu as réussi a faire quelque chose qui effectue ces opérations en un temps court, alors nous sommes tous preneurs pour ta solution !