Citation:
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.
Citation:
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.
Citation:
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.
Citation:
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.
Citation:
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.:aie:
Citation:
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.
