Discussion :

[contremaitre]

Bonjour,

Sujet classique, mais j'ai une question sur un cas un peu particulier.

Jusqu'ici j'utilise les pipe pour communiquer entre thread.
Mais je me trouve dans un cas ou une certaine catégorie de thread doivent recevoir les meme messages.
C'est à dire que lorsque mon thread A doit envoyer des messages aux threads B C D E, il doit toujours l'envoyer a tous (jamais a B seulement par exemple).

Y a t'il un meilleur moyen que 4 pipe (un chacun) ou on enverai 4 fois ce message ?

merci

[Goundy]

Une shm (shared memory) ?
Ou encore une message queue

y'a le choix :-)

[Emmanuel Delahaye]

Une shm (shared memory) ?

Avec des threads ? La mémoire est déjà partagée (même processus).

[contremaitre]

ça n'explique pas comment gérer un message qui serait lu, une et une seule fois par tous les thread, puis qui serait supprimé. Avec les variables partagées on ne peut pas gerer une liste de message si ?

[Goundy]

Avec des threads ? La mémoire est déjà partagée (même processus).

Aouch quand il parlait de pipe j'avais compris process en effet !

ça n'explique pas comment gérer un message qui serait lu, une et une seule fois par tous les thread, puis qui serait supprimé. Avec les variables partagées on ne peut pas gerer une liste de message si ?

Une liste chaînée pour les messages, et dans chaque node stocker un compteur qui est incrémenté de 1 à chaque accès (en lecture) au message. Une fois que le compteur atteigne le nombre de threads tu delete le node.
C'est la première solution qui me passe par l'ésprit ^^


Euh juste une question, comment ça tes threads communiquent par le biais de pipe ?

[matafan]

Euh juste une question, comment ça tes threads communiquent par le biais de pipe ?

J'imagine qu'un thread écrit d'un côté du pipe, et qu'un autre lit l'autre côté. Rien n'empèche un process de s'envoyer des données à lui même.

[Goundy]

J'imagine qu'un thread écrit d'un côté du pipe, et qu'un autre lit l'autre côté. Rien n'empèche un process de s'envoyer des données à lui même.

Oui mais ça me parait très lourd d'utiliser les pipes pour une rétro-communication donc bon.
J'aurais utilisé des message queue pour ça :-)

[contremaitre]

Oui mais ça me parait très lourd d'utiliser les pipes pour une rétro-communication donc bon.
J'aurais utilisé des message queue pour ça :-)

Oui c'est bien comme ça que ça marche. C'est assez courant d'utiliser les pipe meme entre thread d'après ce que j'ai vu. Mais ce n'est pas moi qui avait écrit ce soft, et ça permet aussi d'envoyer des messages depuis l'exterieur.

Et puis ce n'est pas une communication intensive, mais plutot ponctuelle, donc ca ne pose pas de problème de perfs.

[oniric]

Une liste chaînée pour les messages, et dans chaque node stocker un compteur qui est incrémenté de 1 à chaque accès (en lecture) au message. Une fois que le compteur atteigne le nombre de threads tu delete le node.
C'est la première solution qui me passe par l'ésprit ^^

je pense que c'est une bonne solution aussi, mais pense à utiliser des mutex pour eviter les acces simultannée à la donnée (et surtout ecriture simultannée qui donnera un comportement aleatoire). Dans les tutoriaux il y a surement une explication sur les mutex. En gros c'est comme des verroux sur les données qui "bloque" les threads quand ils veulent acceder à une donnée qu'un autre thread est deja entrain d'acceder.