Discussion :

[x2thez]

Bonjour,

J'ai développé il y a quelques temps une "grosse" application en C++ en utilisant les threads (chaque thread étant dédié à une fonction propre)
Par exemple: thread 1 reçoit des messages de l'extérieur (base de données ou autre programme)
thread 2 fait le traitement des messages
Tout fonctionne correctement(sans être parfait)

Je souhaite désormais dissocier mes 2 threads en 2 applis bien distinctes, ce qui me permettra par exemple d'arrêter le thread de traitement (2) tout en laissant le thread 1 recevoir les messages et les stocker pour un traitement ultérieur.

Alors je ne sais pas quel est le meilleur moyen pour faire cela, j'ai penser à utiliser une base de données intermédiaire mais je pense que ce sera trop lourd
les données échangées sont une structure d'entier et de float ....
est il possible de définir une zone mémoire utile à mes 2 programmes? ou autre?
quel est le meilleur moyen, le plus léger (à programmer et au niveau de l'execution) pour faire cela?

merci d'avance pour vos réponses

[Jerome S]

Pour faire communiquer deux applications entre elles, et chacune soit indépendante (pas besoin de l'autre pour fonctionner), tu n'a pas beaucoup de possibilités : base de données, ou fichier (texte).
A ma connaissance, il n'y a pas tellement d'autres possibilités...

[gbdivers]

Heureusement que si, il existe (beaucoup) de méthodes pour faire communiquer 2 applications entre elles (en fonction des contraintes : mémoire partagée ou distribuée, ordinateurs distants ou local, etc.)
Une petite recherche sur google avec "Inter-process communication". En vrac : boost.interprocess, boost.mpi, réseau (un de mes préférés, c'est facile de passer de local à distant), POSIX, D-BUS (linux only je crois), COM/DCOM/OLE/ (windows only ), etc. etc.

[x2thez]

salut, merci pour vos réponses, dans mon cas ce sera toujours sur un seul pc local sous Windows.
Je cherche le meilleur moyen sachant que cette "communication" se fera toujours de la même manière avec le même flux de données (une structure envoyée et une structure reçue)
j'étais en train de lire des articles sur la mémoire partagée.

(dans mon ancien programme basé sur MFC les threads communiquaient entre eux via les PostThreadMessage)

quand tu dis réseau est ton préféré t'entends quoi par réseau?

[gbdivers]

Un client et un serveur en local (ou en peer-to-peer ou en broadcast) : tu ajoutes des fonctionnalités de communication réseau (UDP et/ou TCP) et tu communiques en localhsost (IP = 127.0.0.1). Ca prend quelques lignes avec un bibliothèques adéquate (regarde par exemple la doc de Qt : serveur et client)

Pour la mémoire partagée, attention : 2 threads utiliseront une mémoire partagée (donc pas de problème) par contre, 2 processus auront des mémoires séparée et une tentative d'accès par l'un sur la mémoire de l'autre provoquera un memory acces violation (je crois)

[x2thez]

Ok super pour la mémoire partagée... j'étais en train de me dire qu'effectivement ça semblait être au sein d'une seule application.
Pour tout ce qui est des communications réseaux TCP/IP etc ... je connais parfaitement
je n'y avais pas pensé en premier car pour moi ça me semblait un poil lourd, et je voulais m'assurer qu'il n'y ait pas une solution plus simple et plus rapide.

Seul hic par rapport à cela : un des cas qui me pousse à vouloir scinder en deux mon programme est : en mode production(arrivée constante de messages) j'aimerais pouvoir débogguer la partie "traitement de message" avec des points d'arret et tout ce ci sans provoquer la perte de message du thread "COM" ...
Donc si je débogue et que je prends mon temps, je perdrai ma communication interne (entre mes 2 processus) non?

[gbdivers]

Euh... je maîtrise pas assez les débogueurs en multithread, mais pour moi, si tu débogues, tu stoppes tous les threads de l'application et donc tu ne peux plus recevoir de message du tout (quelque soit la méthode choisie : IPC, MPI, réseau, etc.)
Une solution (plus safe) est que le serveur ne supprime un message que lorsqu'il a reçu un accusé de réception du client. Sinon les messages peuvent être stockés et envoyés dès que la connexion est rétablie (circular buffer pour éviter la saturation ?)

[x2thez]

en fait le message envoyé correspond à une "map" donc il n'est pas grave de ne pas pouvoir envoyé des messages pendant un certain laps de temps
le second processus lorsqu'il sera "relancé" récupérera la map tel qu'elle est à ce moment là!

ça devrait le faire!

effectivement le débug multithread j'ai du mal et je pense comme toi que l'on stoppe tous les threads...

merci encore

[therwald]

En ce qui concerne la mémoire partagée, je crois que c'est possible entre deux processus distincts, mais ça dépend de l'OS...