Discussion :

[babaille27]

Bonjour,

Je développe un logiciel qui est interfacé avec un capteur laser. Celui-ci m'envoie la distance entre le capteur et l'objet qui se situe devant lui. Il travaille à 2000Hz. Je communique avec lui à travers une API fournit.
Pour faire simple, j'ai créé une thread qui est en interface avec ce capteur. Les trames reçues sont mises dans une Queue pour traiter aussi vite que possible et ne pas perdre de trame. Ensuite, une autre Thread vient prendre les trames et les décoder.
Pour un objet donné, je constitue un ensemble de points mesurés avec le capteur. Je fais ensuite des calculs sur cet ensemble de points.

Dans le module de calcul, pour améliorer les performances j'ai utilisé un Parallel.ForEach(). Cela fonctionne bien et j'ai amélioré mes temps de calcul.
Tout va bien tant que je fonctionne par étapes : 1) mesure d'un objet puis 2) calcul sur les points obtenus.

Pour encore gagner en productivité, j'aimerai : mesuré la pièce "n+1" pendant que je calcule la pièce "n". Et là, les problèmes commencent. J'ai régulièrement des pertes de trames. J'en conclu qu'il y a un conflit entre la fonction Parallel.ForEach() et les Threads d'acquisition de points.

Qu'en pensez-vous ? Comment améliorez les choses ?

J'ai essayé de mettre les Threads dans une priorité plus haute, voir même critique. Soit je n'ai pas réussi, soit ca ne fonctionne pas ...

[Pol63]

il faudrait quelques bouts de code pour comprendre l'origine du problème

mais quand plusieurs threads doivent accéder aux même objets il faut que ceux ci soient dit thread safe
la classe queue par exemple ne l'est pas
quand on utilise des objets non thread safe (enfin c'est plutôt une granularité au niveau des méthodes) il faut alors utiliser des mécanismes de verrou (lock, readerwriterlockslim ...)

[tatayo]

Bonjour,
Tu peux aussi utiliser une ConcurrentQueue, qui elle est thread-safe.

Tatayo.

[babaille27]

Merci pour vos réponses. C'est difficile de mettre du code car le projet est plutôt volumineux.

Tout se passe bien "entre les treads". J'ai mis en place des lock, pour que la thread "acquisition" puisse ajouter une trame dans la file, et que la thread "decodage" puisse retirer une trame tranquillement.

Le problème est vraiment lié à l'utilisation en même temps du Parallel.ForEach. D'ailleurs, si à la place j'utilise un ForEach basique, plus de problème. Mon temps de calcul est plus long, mais il ne perturbe pas l'acquisition.

[Pol63]

dans ce cas c'est peut etre votre lock qui est trop long en traitement, que celui ci est aussi utilisé par l'acquisition faisant que l'acquisition rate des infos ...
comme se passe l'acquisition ? c'est une demande de données envoyé ? par tcp/serial ? ou juste un flux à lire ?

si c'est une demande il faut en effet que celle ci ne soit pas bloquée longtemps par un lock
il faudrait l'acquérir vite, juste enqueue pendant le lock
de l'autre côté seul le dequeue doit être dans un lock, le traitement devrait être hors lock et avec la donnée acquise par le dequeue

[babaille27]

C'est une bonne piste. Je vais regarder de près le contenu des lock. Quelle serait le rapport avec le Parallel.Foreach ? car si je le retire, je n'ai pas de trous ...