Discussion :

[fezvez]

Bonjour,

J'ai une question d'ordre générale, c'est à dire pas nécessairement spécifique au C++. Je participe au développement d'une application multithreadée assez lourde.

Aujourd'hui, j'ai un module X qui écrit de façon régulière et continue dans deux gros buffers. Quand un est plein, il le signale aux autres modules, leur envoie un pointeur vers le buffer, et ils peuvent travailler dessus. Puis, ce module X remplit l'autre buffer.

Premier souci : quand le module X a fini de remplir le second buffer (et qu'il le signale aux autres) il arrive parfois que certains modules qui font du traitement sur le premier buffer n'ont pas encore terminé!

Et là, magie des mutex, le module X n'écrit heureusement pas dans le buffer où il est sensé écrire. D'ailleurs, tant qu'un module travaille encore sur le buffer, ce buffer reste bloqué en écriture, impossible d'écrire dessus.

Bon, au moins, on a pas d'accès concurrent, c'est déjà pas la cata... Mais c'est pas terrible non plus. Tout simplement parce qu'on "saute" plein de buffers.

Existe-t-il une solution toute faite, un design pattern, un je-ne sais quoi (éventuellement un truc C++ de gourou) qui permet ceci :

• Le module X peut toujours remplir ses deux buffers.
• Les autres modules peuvent toujours avoir accès à un buffer sur lesquels ils peuvent travailler. Evidemment, si le travail sur le buffer prend trois fois le temps pour que le module X remplisse un buffer, alors le module n'a accès qu'à un buffer sur trois (en gros)
• On a une consommation mémoire faible : Hors de question d'allouer systématiquement des buffers à la volée. On peut en allouer, mais, disons qu'on veut borner la consommation mémoire.

Voilà, je n'ai pas trouvé de design pattern qui réponde à ma question, mais j'ai l'impression que c'est un problème fréquent en multithread.

Merci d'avance!

[JeitEmgie]

… vous "produisez" donc plus vite que vous "consommez"…

il n'y a pas de recette miracle… mais ajuster la taille des buffers peut aider…
le fait que ayez - selon vos propos - deux "gros" buffers… pour N consommateurs…
est dans doute la source du problème…

vous devriez analyser le temps que mettent les consommateurs pour faire leur travail… et ajuster la taille des 2 buffers en fonction…
a priori s'ils sont trop gros, le "producteur" attend que les "consommateurs" fassent tout leur travail alors que le début du "gros" buffer pourrait déjà être réutilisé…
donc si vous aviez plus de petits buffers… tout en occupant la même taille totale…
ou au lieu d'utiliser un mutex sur le buffer, utiliser un mutex (ou une condition) sur un pointeur qui indique jusqu'où le "producteur" peut utiliser le buffer courant…

[fezvez]

Merci de votre réponse

En effet, c'est très bien résumé, je consomme plus vite que je ne produis.

Et, oui, je suis d'accord, il n'y a pas de recettes miracles, il n'est tout simplement pas possible de demander en temps-réel à chaque module de traiter chaque buffer.

En fait, nous envisagions peut-être quelque chose dans ce goût là : les modules qui prennent le plus de temps ne reçoivent qu'épisodiquement des buffers, alors que ceux qui sont rapides (ou jugés comme critiques) traitent systématiquement chaque buffer.

Je crois que nous allons nous repencher dessus, notamment sur la taille (et le nombre) des buffers.

Et merci encore (mais si vous avez d'autres idées, je suis tout ouï! )

[Rupella]

N'est-il pas envisageable de découper le consommateur en deux, à savoir la lecture du buffer (je prends tout ce qu'il y a dedans), puis le travail sur les données lues...

[JeitEmgie]

N'est-il pas envisageable de découper le consommateur en deux, à savoir la lecture du buffer (je prends tout ce qu'il y a dedans), puis le travail sur les données lues...

"je prends" pour les mettre où ?
un autre buffer ?

un des critères imposés par la question originale est de ne pas toucher à l'empreinte mémoire du programme existant…