Partage de la mémoire entre les modules

Pour une utilisation à partir du processus en cours uniquement, vous n'avez pas besoin de concevoir une fonction ou une structure spéciale.

Vous pouvez le faire même sans aucune fonction, mais c'est plus sûr et une plate-forme croise conviviale pour définir l'ensemble des fonctions fournissant accès aux données partagées. Et ces fonctions pourraient être mises en œuvre par la bibliothèque statique commune. P>

Je pense que cette configuration est que: "Qui va posséder les données?". Il doit exister un seul et un seul propriétaire des données partagées. P>

avec ces idées de base, nous avons pu esquisser l'API comme ceci: p> xxx pré>

ou c ++ La classe avec le modèle singleton sera appropriée. p>

update strong> p>

J'ai été confus. Un vrai problème peut être défini comme "Comment implémenter une classe Singleton dans une bibliothèque statique qui sera liée à plusieurs bibliothèques de chargement dynamique (sera utilisée dans le même processus) de la plate-forme de manière indépendante". P>

Je pense , la base de base n'est pas très différente mais assurez-vous que le singleton est le seul single est le problème supplémentaire de cette configuration. P>

À cette fin, vous pouvez utiliser Boost.InterProcess. P>

#include <boost/config.hpp>
#include <boost/interprocess/sync/named_mutex.hpp>
...
boost::interprocess::named_mutex* singleton_check = 0;

// in the Create function of the singleton
try {
    singleton_check = new boost::interprocess::named_mutex(boost::interprocess::create_only, "name_of_the_mutex" );
    // if no exception throw, this is the first time execution
}
catch (...)
{
}

Je pense que vous allez avoir besoin d'aide d'une bibliothèque partagée pour le faire de manière portable. Il n'a pas nécessairement besoin de savoir quoi que ce soit sur les objets partagés entre les modules, il doit simplement fournir un mappage accessible à l'échelle mondiale d'une clé (probablement une chaîne) à un pointeur.

Toutefois, si vous êtes prêt à appeler OS API, cela est réalisable, et je pense que vous n'avez peut-être pas besoin de deux implémentations de la pièce spécifique au système d'exploitation (une pour les DLLS Windows et GetProcAddress, une pour les OSES qui utilisent Dlopen).

Comme chaque module se charge, il marche la liste des modules précédemment chargés à la recherche de tout ce qui exportait une fonction spécialement nommée. S'il en trouve un (tout, peu importe qui, parce que l'invariant est que tous les modules entièrement chargés sont conscients de l'objet commun), il reçoit l'adresse de l'objet commun du module précédemment chargé, puis incrémente le nombre de références . S'il est incapable de trouver, il attribue de nouvelles données et initialise le nombre de références. Pendant le déchargement du module, il décrémente le nombre de références et libère l'objet commun si le nombre de références atteint zéro.

Bien sûr, il est nécessaire d'utiliser l'allocator du système d'exploitation pour l'objet commun, car bien que peu probable, il est possible qu'il soit traité d'une bibliothèque différente de celle qui l'a chargé d'abord. Cela implique également que l'objet commun ne peut contenir aucune fonction virtuelle ni autre type de pointeur sur des segments des différents modules. Toutes ses ressources doivent être allouées de manière dynamique à l'aide de l'allocateur à l'échelle du processus d'exploitation. C'est probablement moins d'un fardeau sur les systèmes où libc ++ est une bibliothèque partagée, mais vous avez dit que vous liez statiquement le CRT.

fonctions nécessaires dans Win32 inclurait énumprocessmodules , getprocAdress , heaphoc , et heapfree , getProcessheap et getcurrentProcess .

Tout considéré, je pense que je voudrais coller l'objet commun dans sa propre bibliothèque partagée, qui exploite les structures de données du chargeur pour le trouver. Sinon, vous réinventez le chargeur. Cela fonctionnera même lorsque le CRT est statiquement lié à plusieurs modules, mais je pense que vous vous préparez pour les violations ODR. Être vraiment particulier pour garder la podage de données commune.