Discussion :

[LoGGi]

Bonjour à tous,

Je poste ici ma question mais il s'agit d'une question de prog c++ plus globale.

"Partagée" veut bien dire que la même bibliothèque peut être utilisée par plusieurs exécutables.

D'après ce qui est dit dans le topic
http://www.developpez.net/forums/d88...ynamiques-dll/ :

La lib n'existe qu'une seule fois en mémoire (la librairie est partagée entre tous les processus qui l'utilisent)

Mais chaque processus qui l'utilise l'instancie dans sa propre zone mémoire ?
Ce que je vais demander est pt une grosse bétise mais je veux en avoir le coeur net.

Est il possible de partager la même donnée contenue dans la dll par plusieurs exécutables qui l'utilisent ? ce qui équivaut à dire la même instance de la dll auquel cas le terme "partagé" prendrait tout son sens ?

[eomer212]

si tu mets static devant ta definition de variable, celle si ne sera instanciée qu'une fois, et donc accessible par toutes les instances du code qui l'utilisent, et donc, partagée.
c'est utile, mais ca pose aprés des problémes d'accés en ecriture/modification, et il faut gérer les sections critiques pour éviter les accés concurrents inopportuns ou des events.


va voir ici, ca peut aider.
http://bob.developpez.com/tutapiwin/article_54.php

[LoGGi]

Merci pour ta réponse.

Donc tu veux dire que si j'ai ma dll :

Code :

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

1
2
3
4
 
class DLL_EXPORT maDll {
 static int maVariable = 0;
}

et que j'ai 2 appli qui instancient maDll :
app1.exe qui met maVariable à 1.

maVariable sera à 1 dans app2.exe ?

[bacelar]

NON.

Dans une dll, il y a plusieurs sections, comme dans n'importe quel exécutable.

La section de code, la section des données globales initialisées, la section des données globales non initialisées, etc ...

Chaque section dispose de "flags" indiquant au chargeur des dll de l'OS quelles sections peuvent être partagées entre les différents programmes.
Ces flags sont renseignés par l'éditeur de lien au moment du link.
En générale, la section du code est partagée et les sections de données ne sont pas partagées.

Vous pouvez changer la section ou sera mis votre code ou vos données via #pragma data_seg (http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx) , et vous pouvez changé le caractère partagées d'une section via l'option de link /SECTIOn (http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx)

Exemple :
http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx

[LoGGi]

YES,

Merci bcp de m'aiguilller Bacelar,

Les data seg sont d'après ce que j'ai compris utiles pour des données basiques,
Mais dans mon cas c'est un peu plus compliqué, je dois pouvoir partagée une hashmap <key, ptrSurMonObjet>
et l'autre solution qui a l'air plus adaptée consiste à utiliser les Memory Mapped Files : http://msdn.microsoft.com/en-us/library/ms810613.aspx
Et là ya de la lecture donc je m'y mets...

[bacelar]

Pour partager des données entre programme, il est clair que les fichiers mappés sont une approche bien plus directe mais là, il n'y aura pas de code dans une dll pour faire l'arbitrage entre les accès concurrents entre ces programmes.

Les fichiers mappés est une solution qui peut apparaître simple au premier abord mais le niveau d'abstraction et donc de service est extrêmement bas, pas de synchronisation des accès, pas de correspondances des adresse portable entre les applicatifs (donc, le parcours de pointeur dans une map, ça va être corsé), allocation d'objet dans cette zone à faire sans la C-Runtime etc...

Quel est votre problème initial, car là, vous êtes en train de réinventer la roue.

[LoGGi]

Oups j'ai du faire un break sur ce projet pour bosser sur un autre...

Merci encore pour ta réponse Bacelar et sorry de ne pas avoir répondu plus tôt.

En fait pour tout te dire, il s'agit d'une dll assez imposante dans laquelle je veux partager sa structure de donnée principale la hash map dont je te parlais, qui est utilisée par quasi toute les méthodes de ma dll, bon là encore sa reste gérable...

Qui plus est, c'est une dll dédiée à du traitement multimédia pour gérer des applications tps réel, ce qui veut dire que cette donnée va être sollicitée et mise a jour en permanence, d'où à mon avis, après mure réflexion, la gestion des accès et conflits entre plusieurs appli pour y accéder est quasi impossible.

Pour finir, cette dll, ou plutôt cette librairie dynamique est multi-plateforme, ce qui n'arrange pas les choses, les segments de donnée et les fichiers mappés de la msdn deviennent inutilisables

En fait ma dll fonctionne actuellement mais lorsque plusieurs appli l'utilisent, elles doivent chacune connaitre certains paramètres des autres (des paramètres créés grâce à ma dll biensur) et jusque à ce jour j'utilise le réseau pour les récupérer et les copier. Le top serait de pouvoir les partager sans avoir à faire tout ça...

Enfin voilà j'arrête je pourrais en écrire un roman

[bacelar]

veux partager sa structure de donnée principale la hash map dont je te parlais, qui est utilisée par quasi toute les méthodes de ma dll, bon là encore sa reste gérable

Préceptes de base de la programmation objet, éviter de faire des variables globales, l'encapsulé dans un singleton, à la rigueur. Pour ne pas avoir de dépendance avec l'implémentation d'un type, utilisez des interfaces et non un type concret. Cela permet aussi de ne publier que les méthodes vraiment utilisées à la manipulation des données.

Qui plus est, c'est une dll dédiée à du traitement multimédia pour gérer des applications tps réel,

Il est impossible de faire du temps réel sous Windows, sauf sous WinCE en mode Kernel.
Le temps réel et la haute performance n'ont rein à voir entre elles.

ce qui veut dire que cette donnée va être sollicitée et mise a jour en permanence,

Rien n'est mis à jour en permanence, la permanence n'existe pas en informatique, il y a toujours des choses entre 2 cycles d'horloge même CPU.

Pour choisir la bonne structure de données, il est primordial que vous ayez soigneusement étudié le mode et les patterns d'accès à cette structure. D'où l'intérêt d'utiliser une interface pour pouvoir la choisir en fonction de ces informations sans avoir à tout casser après, voir pouvoir avoir une implémentation adaptative.

d'où à mon avis, après mure réflexion, la gestion des accès et conflits entre plusieurs appli pour y accéder est quasi impossible.

Il n'y a rien d'intrinsèquement impossible, il faut juste étudié les modes d'accès pour voir se qui doit être synchronisé en comment.
C'est clair que l'utilisation multi application n'est pas un choix qui me semble judicieux pour les performances, mais même en mono-process multi-threading, l'étude de l'utilisation des structures de données est primordiale.

Pour finir, cette dll, ou plutôt cette librairie dynamique est multi-plateforme, ce qui n'arrange pas les choses, les segments de donnée et les fichiers mappés de la msdn deviennent inutilisables

Bull Sheet, un code multi-plateforme, c'est du code qui marche sur plusieurs plates-formes, PAS UN code mais du code.
De plus, le concept de mémoire mappée existe sous UNIX/Linux aussi bien qu'en Win32. Les API ne sont pas forcement les mêmes, mais le principe reste le même donc le code est facilement adaptable avec des #define. Je crois que l'API UNIX est aussi une API Posix donc avec de très grande chance d'avoir une implémentation sous Win32.
Je pense aussi que le concept de segment de données partagées existe en Unix/Linux. En Posix, c'est moins sûr.

En fait ma dll fonctionne actuellement mais lorsque plusieurs appli l'utilisent, elles doivent chacune connaitre certains paramètres des autres (des paramètres créés grâce à ma dll biensur)

C'est la preuve du manque d'encapsulation de votre approche. Encapsulez l'accès à votre structure d'en un ensemble de fonctions exportées de votre dll, faite en sorte que la structure de données soit invisibles de l'extérieur de la dll et stocké dans un segment de données partagées.
L’ensemble des fonctions d'accès aura la charge des problèmes de concurrence d'accès et de la gestion des adresses de base de structure de données différentes selon le processus appelant.

Je pense que votre architecture n'est pas adaptée à votre problème. On ne fait pas de hautes performances avec du multi-process sur les mêmes données.

[LoGGi]

Ok je te remercie pour toutes ces infos bacelar,

Je vais tenter d'investiguer la dessus et améliorer mon architecture.