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

[jblecanard]

Salut !

Je pense que tu peux utiliser le placement new.

Sinon, tu peux faire communiquer les processus par pipe, c'est également très rapide et cela permet de gérer facilement la concurrence sans utiliser de locks (libevent peut aider). Et c'est totalement implémentable en C pour ne rien gâcher.

[godskitchen]

Je pense que tu peux utiliser le placement new.

C'est plus ou moins l'idée qui me venait à l'esprit. Il faudrait que j'alloue un espace mémoire (partagée) de très grande taille et que j'y place des données les unes à la suite des autres. Dans ce cas il faudrait à chaque allocation que je déplace le curseur - permettant de désigner la première position d'espace libre dans mon buffer partagé - d'autant d'octets que de mémoire que j'ai alloué précédemment. Il restera à gérer la question épineuse du cast pour pouvoir stocker des données de n'importe quel type (int, double, char, short..) dans le buffer partagé qui sera vraisemblablement en char.

[JolyLoic]

Globalement, soit tu utilises le placement new aux endroits qui vont bien, ce qui peut être risqué (un oubli arrive vite), soit si le lieu d'allocation dépend du type de tes données (ce qui a l'air d'être ton cas), tu redéfinis les operateurs new et delete (et éventuellement new[] et delete[]) pour ton type afin qu'ils aillent piocher dans cette mémoire partagée.

Si un jour tu veux y mettre des données plus complexes (genre une map<string, vector<string>>), il faudra alors que tu t'intéresse aussi à la notion d'allocateur et que tu crées un allocateur en mémoire partagée.

Par contre, je ne suis pas certain que ce soit une bonne idée de mettre trop de choses en mémoire partagée, puisqu'en plus d'y mettre des données, tu devras gérer les accès asynchrones à celles-ci. Tu devrais essayer de cerner au plus juste ce qui a besoin d'être partagé et le reste. Du coup je n'évoque pas la possibilité de surcharger les opérateurs new et delete globaux (sauf que je viens de l'évoquer en ne l'évoquant pas...).

[godskitchen]

soit si le lieu d'allocation dépend du type de tes données (ce qui a l'air d'être ton cas), tu redéfinis les operateurs new et delete (et éventuellement new[] et delete[]) pour ton type afin qu'ils aillent piocher dans cette mémoire partagée.

.

Je pense que c'est la stratégie qui me sied le mieux.

puisqu'en plus d'y mettre des données, tu devras gérer les accès asynchrones à celles-ci

Dans mon cas l'accès mémoire est loin d'être compliqué à gérer (du moins de ce qui en ressort de mon analyse).

Enfin, il n'est pas nécessaire de surcharger directement les opérateurs, je peux par exemple créer des fonctions qui utilisent les opérateurs new et delete dont le but est d'allouer un espace mémoire à un endroit donné. D'ailleurs si je place tous mes buffer dans la pile je n'aurai pas besoin d'utiliser delete ...

[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 !

[Emmanuel Deloget]

.

Je pense que c'est la stratégie qui me sied le mieux.



Dans mon cas l'accès mémoire est loin d'être compliqué à gérer (du moins de ce qui en ressort de mon analyse).

Enfin, il n'est pas nécessaire de surcharger directement les opérateurs, je peux par exemple créer des fonctions qui utilisent les opérateurs new et delete dont le but est d'allouer un espace mémoire à un endroit donné. D'ailleurs si je place tous mes buffer dans la pile je n'aurai pas besoin d'utiliser delete ...

Je rappelle une autre technique : rien ne t'empêche de créer un opérateur new qui prends autant de paramètre que tu le souhaite, dès lors que le premier est un std::size_t. Dans son kit de développement de drivers, Numega utilise cette possibilité en offrant un opérateur new supplémentaire prenant en paramètre un objet d'un type opaque permettant de préciser si l'allocation mémoire se fait en mémoire "cachable" ou "non cachable". C'est aussi la technique utilisé par l'opérateur new nothrow.

Donc :

Code :

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

1
2
3
4
5
6
7
8
 
void *operator new(std::size_t n, shmobj& obj)
{
    return obj.alloc_in_shm(n);
}
 
// utilisation : 
someobj *o = new(someshm) somobj;

(si je ne me trompe pas ; je suis un peu rouillé sur l'opérateur new et ses délicatesses)

[godskitchen]

Toutes ces informations sont fort intéressantes, je vais méditer sur l'ensemble de ces suggestions, les approfondir et reviendrai si nécessaire. Merci encore.