Discussion :

[OttisToole]

Bonjour,

Je dois transfert une structure de données (float et doubles) d'une application à une autre sur un même pc sous windows. Il m'a semblé intéressant d'utiliser les process IPC cependant je ne sais pas trop lequel choisir. J'hésite notamment entre passer mes données par de la mémoire partagée avec du filemapping ou alors utiliser un pipe.

J'aurais aimé avoir quelques informations concernant ces processus et éventuellement quelques exemples de codes (notamment pour les pipes ).

Merci d'avance

[Mac LAK]

J'aurais tendance à dire que tout dépend de la taille de la structure, et de combien de fois par seconde tu dois la transférer...

La mémoire partagée est, à mon avis, plus simple à implémenter que le pipe (qui se comporte à peu près comme un fichier / socket, donc avec un peu de gestion pour vérifier s'il y a des données ou pas).

La mémoire partagée, elle, est vue comme un tableau, qu'il faudra protéger via un mutex nommé et une section critique située dans la mémoire partagée elle-même. Ce n'est pas bien difficile, seule la décision de passage de l'information est gênante (l'idéal étant d'avoir un thread par processus dédié à ça).

Pour ma part, je préfère la mémoire partagée parce qu'elle n'est pas tributaire d'une taille ou d'une communication particulière : tu peux parfaitement avoir une application "maître", qui crée cette mémoire et lance les signaux indiquant qu'une donnée est prête, tandis que derrière de multiples applications "esclaves" peuvent alors récupérer les données.

Les pipes, eux, sont d'une application à l'autre, ce qui est plus restrictif... Toutefois, pour de gros volumes de données et/ou des données fréquentes et/ou un flux constant, ils sont bien plus efficaces que la mémoire partagée.

[OttisToole]

Ma structure n'est pas énorme (20 valeurs de type float au maximum), par contre je recherche une grosse vitesse d'accès afin d'avoir une base de donnée actualisée très souvent.

Je débute dans les processus IPC, j'ai déjà pas mal regardé la mémoire partagée et les mutex et la j'ai quelques soucis de synchronisation d'accès. Qu’entends-tu par avoir un thread par processus dédié à la décision de passage de l'information? Que doivent-ils faire?

[ram-0000]

Si ce que tu dois gérer doit être vu comme une base de données (partagée), je partirai vers une mémoire partagée protégée par un sémaphore.

Le gestionnaire principal des données (l'écrivain) créé la mémoire partagée et le sémaphore. Quand il veut écrire dedans, il prend le sémaphore et le libère quand il a finit d'écrire.

Les lecteurs quand ils veulent lire prennent le sémaphore, lisent la mémoire partagée et libèrent le sémaphore.

Après les moyens pour implémenter cela dépendent de ton architecture.

Sous Windows, je partirai vers CreateFileMapping() et ses petites soeurs pour le segment de mémoire partagée (regarde ici pour une introduction) et vers CreateSemaphore() pour le sémaphore.

Sinon, tu peux aussi voir du côté de boost s'il y a des équivalents ou alors du côté des appel SYSV (shmget et semget)

[Mac LAK]

Ma structure n'est pas énorme (20 valeurs de type float au maximum), par contre je recherche une grosse vitesse d'accès afin d'avoir une base de donnée actualisée très souvent.

Mémoire partagée alors.

Qu’entends-tu par avoir un thread par processus dédié à la décision de passage de l'information? Que doivent-ils faire?

Les threads "consommateurs" (appelés aussi "lecteurs") sont en attente bloquante d'un mutex / sémaphore : un mutex si un seul doit pouvoir lire en même temps, et sémaphore s'ils peuvent être plusieurs à lire simultanément.

Quand le "producteur" (aussi appelé "rédacteur") veut mettre les données à jour, il prends le contrôle de la mémoire partagée de façon exclusive (mutex le plus souvent), mets la donnée à jour, libère les threads consommateurs puis relâche la table.

Cela se règle habituellement avec un mutex de table, plus un mutex/sémaphore d'accès aux données. Le mutex de la table protège "physiquement" en fait l'accès au sous-mutex, qui lui protège "logiquement" les données.
Le premier empêche donc les bêtises (blocage réel d'un accès concurrent non autorisé), le second définit qui a le droit d'accès.

[OttisToole]

Merci des indications, je vais tenter d'implémenter tout ca

[3DArchi]

Salut,
J'arrive un peu après la bataille, mais bon... Globalement, je partage les indications données pour la mémoire partagée, mais j'amène quelques remarques :
1/ Attention à ce que le mécanisme de synchronisation pour l'accès ne soit pas pénalisant par rapport à un autre canal d'échange. Fais quelque chose de générique qui te permette de rapidement changer d'un mode d'échange à un autre pour faire ensuite un bench sur les performances ;
2/ Et j'en viens au second point. Tu construits un système en 2 applications distinctes sur le même poste. D'expérience, le client a souvent (mais pas toujours) dans un deuxième temps le souhait de déporter une des 2 applications sur un poste différent. Et là, la mémoire partagée Évalue ce risque par rapport à ton système.

[OttisToole]

C'est bon j'ai réussi a faire quelque chose de fonctionnel , merci encore à toi Mac LAK pour tes indications.

[Mac LAK]

Oups, j'avais zappé ton message du 27/07, désolé...

merci encore à toi Mac LAK pour tes indications.

De rien. Un p'tit alors ?