Re : problème de fil d'attente

[noir_desir]

Bonjour tous le monde,

J'ai un soucis au niveau de mon système temps réel, en effet je pilote mon sytème via un système de file d'attente de message.

Mais j'ai rajouté des fonctions qui me nécessite d'avoir plusieurs point d'entrée dans celle-ci. J'ai donc des soucis de concurrence.

En effet, des éléments sont lus par des mauvais "dequeue", du coup, l'élement disparait mais sans avoir été au bon endroit.

J'ai utilisé du coup, l'élement voir le premier élément de la queue pour voir éviter de retirer celui-ci s'il ne correspond pas au bon endroit. Mais du coup, je recherche une méthode, disons un peu plus pro...

Cordialement

[MaximeR · Accepted solution]

Bonjour,

Si j'ai bien compris, tu veux émettre à plusieurs personnes des données, mais en fonction de la donnée, le récepteur ne doit la lire que si elle lui ai destinée. 

Si tu sais a qui doit s'adresser la donnée, et qu'elle ne peut être lue que par une seule personne, pourquoi ne pas faire plusieurs file d'attente. Tu dispatch au départ, et chacun écoute/attend que des données qui l'interesse.

Cordialement

[noir_desir]

C'est sûr, j'y ai pensé, mais il me reste 3% de place sur mon Crio de dispo, ca me laisse peu de place pour éventuellement de futur nouvelle option de développement. Hors une file d'attente prend un peu de place même si par exemple je laisse ma file à 20 élèments.

[Eric.M]

Les files d'attente sont utilisées pour faire de la communication N:1. On ne doit donc avoir qu'un seul consommateur (1 seul Dequeue). Plusieurs Dequeue = mauvais choix de communication ou d'architecture. Comme je n'ai pas le code, je ne ferai que citer les notificateurs et événements utilisateur pour remplacer les files d'attente. Chacun ont leurs avantages et inconvénients bien sûr (notif = pas de bufferisation, User Event = nécessité d'avoir une structure événement...).

L'alternative : refactoriser une partie du code pour n'avoir qu'un seul "controleur" où se situe le vidage de la FIFO.

Cdt,

[noir_desir]

Je suis passé à 3 files d'attentes différentes, mais j'ai réduit le nombre d'élement à 50, vu que ce ne sont que des messages, pas forcement besoin de plus...

Pour la refactorisation ca me semble plus compliqué. Les boucles en question sont dans des structures cadensés, car elles doivent "vivre leur propre vie", et pas trop se soustraire à d'autre processus.