Callback main application à partir d'une classe thread

Bonjour à tous,

- une application main
- instancie un listener réseau qui est une classe dérivée de thread (mécanisme proposé par le framework que j'utilise)
- enregistre auprès de ce listener des callbacks (des méthodes de différentes classes de l'application)
- démarre le thread listener
- le listener procède à l'écoute, empile les messages reçus et appelle les callbacks

Quels sont les risques ? le code d'une méthode peut se retrouver exécuté aussi bien dans l'application que dans le contexte du thread appelant - Cela peut-il poser des problèmes ? Je pars du principe que le dernier a raison. Si l'application dit "bleu" et que le thread reçoit une commande "rouge", pas de problème, ça sera rouge. Mais l'accès aux classes, à leurs méthodes peut-il provoquer des crashs ? une instabilité ?

Si oui, sachant que le listener peut appeler des dizaines de méthodes (via les callbacks) de classes de l'application, comment se prémunir des conflits ? Le listener peut aisément utiliser un 'lock' avant d'appeler le callback, mais du côté de l'appli ? Je ne peux quand même pas pourrir mon code et mettre des verrous partout, pour la moindre opération, au cas où le thread tenterait d'accéder aux même données...

C'est un peu le brouillard ;-)

Lu'!

Citation:

Envoyé par Paganoni

le code d'une méthode peut se retrouver exécuté aussi bien dans l'application que dans le contexte du thread appelant - (1) Cela peut-il poser des problèmes ? Je pars du principe que le dernier a raison. Si l'application dit "bleu" et que le thread reçoit une commande "rouge", pas de problème, ça sera rouge. (2) Mais l'accès aux classes, à leurs méthodes peut-il provoquer des crashs ? une instabilité ?

(1) Oui, ça peut poser des problèmes, si les accès sont fait sur des données partagées (donc même objet, ou champs statiques). Une fonction membre (en C++ on parle de plus de fonction membre que de méthode : voir les messages du compilos par exemple), ne fait pas forcément qu'une opération. Et chaque fonction membre doit maintenir l'invariant de la classe. Si plusieurs threads sont susceptible d'appeler différentes fonctions membres d'une classe sur un même objet, il faut maintenir un invariant plus faible (généralement) mais de manière plus forte : après chaque opération grosso-modo, et même comme ça il faut que les éléments accédés soient accédés de manière atomique.

(2) Donc oui, et des bugs difficilement reproductibles d'ailleurs, et au moins où tu t'y attendra le moins, en production, quand tu seras en vacances, et qu'il y aura plein de gens qui auront besoin de l'application.

Citation:

Envoyé par Paganoni

Si oui, sachant que le listener peut appeler des dizaines de méthodes (via les callbacks) de classes de l'application, comment se prémunir des conflits ? Le listener peut aisément utiliser un 'lock' avant d'appeler le callback, mais du côté de l'appli ? Je ne peux quand même pas pourrir mon code et mettre des verrous partout, pour la moindre opération, au cas où le thread tenterait d'accéder aux même données...

La bonne manière de faire de la concurrence, c'est de ne pas faire de concurrence. Parce que c'est compliqué, qu'on va se planter ou qu'on va le faire de manière inefficace.

Comment fait-on pour ne pas avoir à faire de concurrence : on limite les points où la concurrence est nécessaire au strict minimum, et on laisse des gens vachement meilleurs que nous le faire à notre place. Généralement ça passera par le fait qu'on voudra garantir la possession exclusive d'une ressource pour un thread qui est modifiant et ne laisser au thread ayant une possession partielle que le droit de lire ces ressources (une ressource ne pouvant être à la fois possédée de manière exclusive par un thread et partielle par un autre au même moment). Pour garantir cette possession exclusive, on donnera la responsabilité des ressources à des conteneurs thread-safe dans lesquels on peut ajouter des ressources en en cédant la propriété, y accéder en lecture sans en prendre la propriété, et les récupérer en écriture en prenant la propriété.

Le résultat c'est qu'à tout moment un thread doit être l'exclusif propriétaire d'une ressource qui est entrée dans son scope (qui est le seul endroit qu'il a le droit de modifier). La concurrence doit être traitée par les structures de données thread-safe et ça on ne le code pas nous même (voir dans boost, il y en a un paquet, plus ou moins lockées). Ces structures de données agissent comme des canaux de communication entre les threads.

Si tu ne vois pas comment adapter cette méthodologie à ton problème, expose le concrètement, qu'on voit quel genre de solution est adaptée.

Ok, je vais y réfléchir et essayer de formuler ma question le plus clairement possible... Je suis pour l'instant coincé sur autre chose, du coup de préfère ne pas trop m'avancer sur la question des threads