Quelqu'un at-il un bon conteneur de mémoire partagée pour C ++?
-
06-07-2019 - |
Question
Je recherche depuis longtemps un conteneur STLish que je pourrais placer dans un segment de mémoire partagée ou un fichier mappé en mémoire.
J'ai envisagé d'utiliser un allocateur personnalisé et un nouvel emplacement pour placer un conteneur STL standard dans un segment de mémoire partagée. (comme par exemple article ). Le problème est que les conteneurs STL auront en interne des pointeurs sur la mémoire qu'ils possèdent. Par conséquent, si le segment de mémoire partagée ou le fichier mappé en mémoire est chargé à une adresse de base différente (peut-être lors d'une exécution ultérieure ou dans un deuxième processus), les pointeurs internes deviennent alors tout à coup invalides. Autant que je sache, l'approche d'allocateur personnalisé ne fonctionne que si vous pouvez toujours mapper le segment de mémoire dans votre processus à la même adresse. Au moins avec les fichiers mappés en mémoire, j’ai beaucoup d’expérience que ce n’est PAS le cas si vous laissez le système le mapper là où vous le souhaitez.
J'ai réfléchi à la manière de procéder, mais j'aimerais éviter cela si quelqu'un d'autre a déjà fait le travail (c'est moi, être paresseux).
Je suis en train de quitter la discussion, la meilleure stratégie de verrouillage dépend fortement de l'application.
La solution
Le meilleur point de départ pour cela est probablement les bibliothèques boost Interprocess. Ils ont un bon exemple de carte en mémoire partagée ici: mappage de processus
Vous voudrez probablement aussi lire la section sur les pointeurs intelligents décalés, qui résout le problème du pointeur interne auquel vous faisiez référence. pointeur offset
Autres conseils
Vous pouvez également consulter la Conteneurs de blocs de construction Threading d'Intel (TBB) .
J'ai toujours eu de bonnes expériences (il y a des années) avec ACE . C'est un cadre de réseau / communication, mais une section sur la mémoire partagée.
Essayez d’utiliser l’implémentation QSharedMemory de Qt.