J'ai une classe relativement complexe en C ++. Cela fonctionne parfaitement lorsqu'il est utilisé dans un processus. Cependant, maintenant, je veux que plusieurs processus puissent partager une instance d'objet de cette classe. Un processus (maître) accédera à des fonctions de lecture et d'écriture de l'objet, tandis que les 2 autres processus (esclave) n'utiliseront que les fonctions de lecture. Je veux modifier la classe aussi peu que possible. Jusqu'à présent, j'ai envisagé des singletons et de la mémoire partagée, mais non plus idéal ou simple. Ceci est une demande de recherche qui ne sera jamais utilisée que par moi sur Linux. Quelle est la solution la plus simple possible?
Merci beaucoup!
Edit: Pour être absolument clair, l'astucieux souhaite partager un objet sur plusieurs processus multiples , pas threads.
5 Réponses :
Je pense que la solution de codage la plus simple serait un singleton avec un mutex global (ou une instance de classe), bien que la partie singleton de celle-ci soit facultative. Personnellement, je pense que Singletons est un idiome surutilisé. Jusqu'à vous si vous pensez que c'est un bon design dans ce cas ou non. En réalité, l'ajout du mutex global est tout ce dont vous avez besoin.
Pour la partie interprocession, je recommande Boost.
La communication inter-processus n'est jamais simple. Vous voudrez peut-être utiliser une bibliothèque pour IPC / RPC et n'exposer que la fonction que les esclaves utilisent pour lire des données, pas la classe entière.
Je ne peux pas vous donner de bonnes recommandations car je n'ai jamais trouvé une bibliothèque qui l'a fait simple et je n'ai pas beaucoup d'expérience avec elle.
Une idée peut être d'utiliser la prise ou une bibliothèque de socket pour partager les données entre les processus. Une bibliothèque qui semble être très pratique pour cela pourrait être Ømq . Vous pouvez également essayer d'utiliser Boost :: Asio qui est un peu plus complexe.
Vous pouvez trouver un petit exemple pour Ømq ici .
La solution est encore plus simple que Ømq.
Une option est d'avoir à la fois les processus maîtres et esclaves créent des instances du même objet. Étant donné que le processus maître sera le seul à modifier cet objet "partagé", il ne doit alerter que les processus d'esclaves à toutes les modifications apportées à l'objet "partagé". Pour ce faire, vous pouvez configurer un système de messagerie que le processus maître utilisera pour communiquer des modifications à l'objet partagé avec les processus esclaves. L'inconvénient ici est que les processus esclaves peuvent faire référence à l'objet partagé lorsqu'il est désynchronisé avec le maître, mais il s'agit d'un problème courant dans la réplication. De plus, vous pouvez utiliser une superposition RPC pour faciliter le développement / entretenir des applications principales / esclaves.
Je vais essayer de fournir un exemple de niveau très élevé de cette conception ci-dessous. Pardonne-moi d'avoir utilisé du code réel et du code Psuedo côte à côte; Je ne voulais pas coder complètement cela, mais je ne voulais pas non plus que ce soit simplement composé de commentaires :) p>
Voici notre objet partagé qui est défini dans le code maître / esclave P>
while(true){
//wait on the socket for updates
read(mysock,msgbuf,msgbufsize,0);
//parse the msgbuf
int newv1 = the int value of var1 from the msg;
//if we're in another thread we need to synchronize access to the object between
//update thread and slave
pthread_mutex_lock(&objlock);
//update the value of var1
sharedobj.var1 = newv1;
//and release the lock
pthread_mutex_unlock(&objlock);
}
Voir "Mémoire partagée" dans Boost Interprocess: http://www.boost.org/doc/libs/1_63_0/doc/html/interprocess/sharedMemoryBetweenProcesses.html
Je ne l'ai pas utilisé, mais vous ne mentionnez pas de prendre conscience de Boost.interprocess .
Vous voudrez peut-être rechercher une mémoire partagée . Voici une question sur SO mais pour
C (sorcière peut également fonctionner pour C ++)Passez à Delphi et utilisez des bpls (une sorte de dlls sur les stéroïdes) :)
J'ai eu la fortune de travailler récemment sur un problème similaire. Permettez-moi de partager ma nouvelle sagesse trouvée. La partie de partage des données est la partie facile. Le vrai problème est avec vos processus multiples. Cela dépend de la manière dont ces processus vont courir. C'est la vraie question. Le traitement fonctionnera-t-il comme des threads ou des processus individuels. S'ils seront exécutés en tant que processus distincts, vous devez comptabiliser le partage de la mémoire car les processus individuels n'ont pas accès à la même mémoire. Si le multitraitement est effectué à l'aide de threads, la solution est assez simple car d'autres ont suggéré.
Rien d'élaborer comme une bibliothèque de boost n'est requis dans l'un des cas.