variable memoire partagée entre plusieurs instances d'une DLL

variable memoire partagée entre plusieurs instances d'une DLL - C++ - Programmation

Marsh Posté le 26-01-2009 à 13:37:54    

bonjour,
 
petite question concernant le partage de memoire entre DLL.
 
j'ai un programme qui utilise n instances d'uns DLL. cette DLL travaille sur des données. est-il possible que chaque instance de cette DLL travaille sur la même zone mémoire correspondant à mes données.
 
exemple:
DLL_instance1 : crée un vector de dimension n
DLL_instance2 : modifie les valeurs du vector précedent.
DLL_instance3 : modifie aussi les valeurs de ce vector.
 
est-ce que c'est possible ?


---------------
Mes ventes vers Grenoble & Gresivaudan
Reply

Marsh Posté le 26-01-2009 à 13:37:54   

Reply

Marsh Posté le 26-01-2009 à 13:47:37    

Oui, ça dépends comment comment tu accède/passe le vector<>.
 
A ma connaissance, généralement ce qui peut poser des problèmes ce sont les objets statiques.  
 
Donc peut-être plustôt utiliser une classe de contexte de travail (qui va encapsuler ton vector<> et d'autres objets a partager), que l'exe fait créer par l'instance 1 et passe aux instance 2 et 3.
 

Reply

Marsh Posté le 26-01-2009 à 15:01:03    

merci, mais c'est pas très claire pour moi, qu'est-ce que tu entends par "classe de contexte de travail" ?
 
je n'ai rien de "static", concrètement ma dll crée un buffer de 3 éléments de type struc. cette struct contient des unsigned int et un std::vector<std::vector< double > > alloué dynamiquement.
est-ce que je peut remonter l'adresse de cette structure après utilisation de la première instance de dll et passer cette adresse (via param de fonction) aux autres instances de cette dll ?
 
en gros:
prog principal -> appel 1ere instance de dll qui crée les variables et renvoie le  pointeur.
prog principal -> appel autre instance de dll en passant le pointeur.
 
c'est vraiment pas mon domaine ce genre de programmation du coup je patauge completement :/


---------------
Mes ventes vers Grenoble & Gresivaudan
Reply

Marsh Posté le 26-01-2009 à 16:39:09    

normalement oui. mais il peut y avoir des blagues :D
au blair:
- évite d'avoir des runtimes différents (compiler tout le monde avec le même compilo et le même runtime DLL, pas statique sinon tu auras des heap différents)
- si jamais ça passe par un heap différent par instance de DLL, normalement définir tes propres operator new/delete pour wrapper vers l'exe devrait te permettre de mixer des new/delete d'objets entre exe et instances de dll.
 
genre un truc comme ça:
des pointeurs sur les new/delete a utiliser coté DLL:
 
static void *(*GlobalNew)(size_t) = NULL;
static void (*GlobalDelete)(void *) = NULL;
 
void *operator new(size_t Size) { return( (*GlobalNew)(sz) ); }  
void *operator new[](size_t Size) { return( (*GlobalNew)(sz) ); }  
void operator delete(void *Ptr) { (*GlobalDelete)(m); }
void operator delete[](void *Ptr) { (*GlobalDelete)(m); }
 
et genre a l'initialisation de ta DLL, tu t'arrange pour initialiser GlobalNew et GlobalDelete au new/delete d'allocation de l'exe. (comme ça tu est sûr de passer par le heap process)
 
mais je pense (mais pas sûr), que si tu lies l'exe et tes dlls au runtime dll, ça utilise le même heap (mais ça dépends de l'implémentation du runtime je dirais). donc je dis peut être des conneries, donc c'est comme si j'avais rien dit :D


Message édité par bjone le 26-01-2009 à 17:00:17
Reply

Marsh Posté le 26-01-2009 à 17:29:34    

oh my god! j'ai pas tout compris là...
 
déjà dès la 2 eme ligne : le fait d'avoir un programme en VB6 qui utilise des plugins C# qui appellent ma DLL en C++, ça pose problème ?
 
heap ? wrapper? va falloir que je cherche ce que tu entend par là.
 
je vais aussi regarder du coté de tes mots clé "globalnew" et "globaldelete".
 
de mon coté j'ai trouver des infos autour de "createfilemapping" je sais pas si ça peut servir ?


---------------
Mes ventes vers Grenoble & Gresivaudan
Reply

Marsh Posté le 26-01-2009 à 18:13:42    

GlobalNew et GlobalDelete c'est les noms que j'ai donné aux pointeurs sur fonction pour rediriger les allocations/déallocs au sein de la DLL vers l'allocateur/déallocateur de l'EXE.  
 
les void *operator new(), c'est des fonctions locales à la DLLs qui vont permettre d'avoir la STL compilée localement a ta DLL d'utiliser ceux de l'EXE.
 
C'est la solution qui permet d'être sûr (à ma connaissance), que tu puisses croiser des allocations/déallocations entre l'EXE et ses DLLs.
 
----
 
"createfilemapping" sert pour les mémoire partagées, ça sert dans les cas de communication entre process (ou juste pour avor un accès performant à un fichier en le projetant en mémoire), pas entre DLL.
 
----
 
Maintenant si tu essayes d'utiliser en VB6, des DLLs C# employant elles-même des DLLs C++, je cours m'enfuir loin très loin en laponie.


Message édité par bjone le 26-01-2009 à 18:16:44
Reply

Marsh Posté le 29-01-2009 à 07:45:59    

bon j'ai réussi à faire quelque chose mais seulement avec le principe de filemapping.  
le prog VB crée n instance d'un plugin c# qui lui meme crée une instance de ma dll.
le premier plugin écrit une valeur en mémoire
et j'arrive a la lire dans les autres plugin. c'est cool.
 
maintenant faut que j'arrive à écrire les données que je veux et à les relire pour les remettre en forme... c'est pas gagné.
 
au fait, c'est beau la laponie ? :D


---------------
Mes ventes vers Grenoble & Gresivaudan
Reply

Marsh Posté le 29-01-2009 à 11:30:03    

y fait froid :D

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed