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.