Discussion :

[WDKyle]

Bonsoir,

Je suis sur un problème d'ordre architectural sur une application C#/WPF.

Cette application doit pouvoir gérer la lecture simultanée (donc dans des threads) du contenu de divers fichiers (txt, xml, json). Cette partie est OK et est géré dans une classe nommée "Titrage", une instance de la classe gère un fichier.

J'ai ensuite une classe nommée "Zone" qui est constitué d'une propriété de type "Titrage" et chaque instance de la classe peut lancer un thread.

J'ai donc une question sur la notification d'une modification du contenu d'un fichier. Je suis parti pour l'instant sur un système d’événement pour notifier la classe "Zone" que "Titrage" à évolué (voir schéma).



Je pensais que c'était une bonne solution pour garder mes classes indépendantes au maximum mais est-ce vraiment le cas ? En écrivant ces lignes, je me dis qu'une simple vérification périodique dans le thread de la classe "Zone" protégé par une sémaphore ferait le boulot ...? Car les évenements sont-ils thread-safe ?

Merci.

[Pol63]

les events sont threads safe, vu que ce sont des simples appels, mais c'est sur le code que tu mettras dedans qu'il faut faire attention

il y a différents problèmes avec le multi threading
le plus connu est qu'il est impossible de modifier l'UI depuis un thread différent de celui qui a créé l'interface (le thread principal donc)
ici je crois comprendre que ce n'est pas ton cas, donc je ne vais pas détailler les solutions

après il y a le fait que 2 threads qui vont utiliser la même chose à un instant T peuvent créer un comportement génant
à savoir a = a +1 par exemple, si 2 threads font ca en même temps et que a vaut 1 au départ il est possible que a valle 2 au lieu de 3
car a = a + 1 c'est lecture de a puis incrément puis rangement dans a
donc si les 2 threads lisent en même temps la valeur ca pose problème
pour éviter ca il y a les locks et readerwriterlockslim, ceci permet de mettre faire en sorte que sur une portion de code définie un seul thread puisse rentrer, le suivant attend que ca soit libre

les collections et toutes les classes/méthodes non thread safe sont aussi problème
le plus connu c'est un thread qui fait un foreach et un autre qui fait .add, ca plante direct

autre problème, la concordance des données
si dans une classe tu as 3 propriétés écrites par un thread, et lues par un autre, il est possible que le thread lecteur commence à lire la 1ère avant de lire les autres, et que le threads qui écrit commence écrivent entre temps
donc entre le moment ou tu as lu la 1ère et le moment ou tu vas lire les 2 autres les données reflètent 2 états différents
pour ca une copie en thread safe des données peut suffire

[WDKyle]

Merci Pol63 pour ta réponse

Y'a pas de soucis pour les accès concurrentiel aux propriétés, j'en suis conscient d'ou ma proposition de sémaphore.

Si je pars bien sur des events, ceux-ci enverrai en argument une instance de type "Contenu" je doit donc protéger les appels à celle-ci dans le code de l’événement ? Un lock par exemple ? Car le but serait de lancer un thread depuis une instance de type "Zone" pour effectuer des actions diverses à chaque changement de "Contenu".

Si je pars pas sur des events, je suis obligé d'avoir un thread lancé en permanence dans une instance de type "Zone" pour vérifier régulièrement les modifications de "Contenu" dans la propriétés "Titrage". C'est peut-être pas si dégueulasse que çà d'un point vue séparation du code ?

Merci.

[Pol63]

si A prévient B par event, tu peux faire sans thread qui attend côté B, tu peux aussi démarrer un thread côté B à ce moment là pour traiter les données de B
attention par contre là aussi si A prévient B plus vite que B traite tu peux alors avoir plusieurs threads sur B
là aussi il y a des solutions, le backgroundworker par exemple encapsule un thread et a une notion de Busy (déjà en cours)

après niveau séparation, si B a besoin de connaitre A tu ne pourras rien y faire, et ton code me semble déjà bien séparé si tu as un thread qui lit et un autre qui traite

[WDKyle]

Merci pour ton retour.

J'ai commencé avec un Task plutot qu'un BackgroundWorker mais je pense qu'il y a aussi l'information si un Task est en cours non ?