Discussion :

[DSGSLA]

Bonjour à tous,

Dans le cas d'une communication inter-processus ou inter-thread de type producteur/consommateur quel est la technique la plus performante dans le cas d'un échange d'une grande quantité de données ?

En regardant les techniques possibles (shared memory, socket, sémaphore, etc) il me semble que les processus/thread producteur et consommateur ne peuvent travailler simultanément, la donnée échangé est accédée par le consommateur ou le producteur mais pas simultanément. Ai-je raison ?

Dans les exemples donnés sur le concept producteur/consommateur la donnée échangée est toujours un buffer char. Mais si je veux transmettre un objet de taille variable ? Idéalement un conteneur de variant, est-ce possible ?

[Steph_ng8]

Bonjour,

Eh bien le consommateur ne peut pas lire les données tant qu'elles n'ont pas été écrites par le producteur, et inversement le producteur ne peut pas écrire des données tant que les précédentes n'ont pas été lues par le consommateur.
Sauf si la lecture et l'écriture peuvent se faire par bouts, et non pas en une seule fois.

Si la donnée à transférer peut être de taille variable, il faut d'abord envoyer au consommateur un indicateur qui lui permettra de déterminer la taille, et éventuellement le type effectif, des données à lire.
Et il faut évidemment que la mémoire utilisée pour partagée les données soit assez grande quoi qu'il arrive.

Ou sinon, peut-être utiliser la sérialisation.
Mais bon, je ne m'y connais pas vraiment dans ce domaine.

[ram-0000]

En regardant les techniques possibles (shared memory, socket, sémaphore, etc) il me semble que les processus/thread producteur et consommateur ne peuvent travailler simultanément, la donnée échangé est accédée par le consommateur ou le producteur mais pas simultanément. Ai-je raison ?

Cela dépend des techniques inter process utilisées.
Dans le cas "shared memory + mutex", il n'y en a qu'un à la fois qui peut utiliser la ressource partagée, dans le cas "socket", on peut écrire et lire simultanément dans le socket.

Dans les exemples donnés sur le concept producteur/consommateur la donnée échangée est toujours un buffer char. Mais si je veux transmettre un objet de taille variable ? Idéalement un conteneur de variant, est-ce possible ?

Comme indiqué au dessus, taille des données plus éventuellement un identifiant de type permettant au lecteur de savoir comment lire et réassembler les données.

[DSGSLA]

Bonjour,

Eh bien le consommateur ne peut pas lire les données tant qu'elles n'ont pas été écrites par le producteur, et inversement le producteur ne peut pas écrire des données tant que les précédentes n'ont pas été lues par le consommateur.
Sauf si la lecture et l'écriture peuvent se faire par bouts, et non pas en une seule fois.

Lecture et écriture pas bouts ? Je ne sais pas si on comprends ma même chose.
Dans le cas producteur/consommateur, le producteur n'accède jamais aux données déjà écrites, qui sont disponibles pour le consommateur.

Cela dépend des techniques inter process utilisées.
Dans le cas "shared memory + mutex", il n'y en a qu'un à la fois qui peut utiliser la ressource partagée, dans le cas "socket", on peut écrire et lire simultanément dans le socket.

Merci pour l'information.

[Steph_ng8]

Dans le cas producteur/consommateur, le producteur n'accède jamais aux données déjà écrites, qui sont disponibles pour le consommateur.

Sauf dans le cas d'une mémoire partagée., comme l'a mieux expliqué [a]ram-0000[/b].
Mais c'est vrai que si l'on écrit sur une bande, comme dans le principe du pipe (dans lequel j'inclue les sockets), il n'y a pas de souci de réécriture.

Lecture et écriture pas bouts ?

Je n'ai pas été clair, désolé.
Ce que je voulais dire, c'est que si le producteur écrit les données par blocs successifs au lieu de tout faire en une seule fois, le consommateur peut lire les blocs déjà complètement écrits, même si le producteur n'a pas terminé d'envoyer les données (il lui reste des blocs à écrire).

Imagine que le producteur envoie des chaînes de caractères, mais que le consommateur a besoin de connaître leur longueur avant de la lire.
Le producteur envoie donc deux blocs :

1. la longueur de la chaîne
2. la chaîne elle-même.

Du coup, le consommateur peut lire la longueur de la prochaine chaîne à lire même si le producteur n'a pas terminé d'écrire cette chaîne.
(Et hop ! un exemple pour illustrer deux concepts… )

[Médinoc]

Typiquement, un modèle producteur/consommateur peut être fait avec un tableau partagé de structures et deux sémaphores:

• Un qui compte les cases vides, décrémenté ("attendu") par le producteur avant écriture et incrémenté ("signalé") par le consommateur après lecture;
• Un qui compte les cases pleines, décrémenté ("attendu") par le consommateur avant lecture et incrémenté ("signalé") par le producteur après écriture.

La communication se fait une structure à la fois. Le modèle producteur/consommateur est utile pour paralléliser plusieurs tâches d'une même boucle, mais ne sert à rien s'il n'y a qu'une seule ressource à traiter.

[DSGSLA]

Merci à tous pour vos réponses.
Je vais faire comme décrit par Médinoc.
Je clos le fil.

[Médinoc]

Note que cela correspond à un seul producteur et un seul consommateur: S'il y a plus de deux participants, on se retrouve à avoir besoin d'objets de synchronisation supplémentaires pour protéger les indexes du tableau.

Ici, les indexes peuvent être des entiers nus, vu qu'un seul processus/thread touche à l'index d'écriture et un seul touche à l'index de lecture.