Discussion :

[al_bert]

Bonjour,

je souhaite bâtir un programme où je dois synchroniser plusieurs threads (i.e. un thread x doit attendre l'interruption d'un thread y avant de lancer ses calculs par exemple). J'ai remarqué en fouillant la bibliothèque MSDN les "ThreadState".

Ils ont ceci de pratiquent qu'ils me permettent d'éviter bien des variables booléennes. Or, toujours selon MSDN, ces propriétés ne devraient jamais être utilisées dans des contextes autre le débogage. Pourtant, les ayant essayé, elle permettent à mon programme de bien rouler et la synchronisation des threads se fait sans accros.

J'aimerais donc savoir s'il existe un risque réel à employer les "ThreadStates" ou bien s'ils sont fiables pour synchroniser des threads?

Merci bien

[Pol63]

je ne sais pas mais isalive et join ne devraient pas poser de problème (et peuvent à mon avis remplacer les états)

[al_bert]

En effet, IsAlive et Join sont très pratique et je les utilise déjà. Le seul hic c'est lorsqu'un thread met en pause un autre thread avant de lui-même poursuivre son exécution (à l'aide d'un ManualResetEvent par exemple).

Dans un cas comme ça, le thread en pause est toujours "vivant", mais il se trouve dans un état "WaitSleepJoin" et j'aurais besoin de discerner cet état précis afin que 2 thread ne tentent pas de communiquer en même temps via le port COM.

Je ne sais pas s'il existe donc une manière quelconque de contourner l'utilisation des ThreadState dans un tel cas par des méthodes telles que IsAlive ou bien Join?

Merci

[Pol63]

2 threads qui utilise le port com ça me parait mal conçu
c'est comme si tu faisais 3 classes d'accès aux données

le mieux serait peut etre de faire un thread qui s'occupe du port com avec par exemple une boucle infinie avec un sleep de x millisecondes
et ensuite il vérifie le contenu d'un queue(of ) (ou un stack je sais jamais le quel va dans quel sens, m'enfin le but c'est de faire du fifo)
dans la collection, stocker par exemple une classe qui contient la commande à envoyer, un booléen qui dit si c'est fait, un booléen qui dit si c'est traité ou erreur et une autre variable pour la valeur du retour

comme ca un thread qui veut communiquer, ajoute une instance dans la collection puis attend que ca soit traité (while sur la varaible de l'instance)

le thread de communication va voir rapidement que la pile contient un élément, le traite et marque le résultat dans la classe

et donc l'autre thread se débloque

NB: l'ajout à la queue doit etre une sub qui possède un synclock et une vérification que le thread de comm soit toujours en action sinon le redémarre

[al_bert]

Merci beaucoup de ces indications. Je vais essayer de procéder ainsi.

Mais sinon, je crois que je vais devoir me rabattre sur ma première idée et faire 2 thread séparés. Parce que le problème est que chaque thread doit accomplir des opérations dans un ordre précis et attendre la réponse de la carte (connectée au port COM) avant d'entreprendre toute autre action, car je dois calculer des vitesses et des positions de pièces/moteur avec les données reçues. Je crois que l'utilisation d'un queue amènerait un autre problème : il faudrait vérifier l'opération avant et après l'opération courante pour s'assurer que tout est fait dans le bon ordre et ainsi éviter d'avoir des résultats de calculs erronés.

Je vais donc essayer ta méthode et je vais sûrement aussi essayer d'utiliser la classe Monitor et les threadstates par exemple et comparer.

Merci bien de l'info!

[al_bert]

J'ai trouvé une page web qui répond bien à ma question sur les ThreadState : http://www.albahari.com/threading/part2.html pour ceux que ça pourrait intéresser.

En résumé, l'utilisation des ThreadStates n'est tout simplement pas recommandé parce qu'il n'existe aucun processus par lequel on peut tester l'état d'un thread et agir conséquemment tout en s'assurant que le thread n'a pas changé d'état entre temps; ce qui, dans mon cas, n'amène aucune incertitude.

Merci beaucoup sperot51 pour ton idée que je ne manquerai pas d'essayer!