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