Méthode utilisées par 2 Threads

Bonsoir a tous,
Je commence a peine a me lancer dans le multithread et je rencontre un problème d’accès a une méthode a partir de plusieurs Threads, je m'explique :
Actuellement j'utilise une méthode pour Désactiver des événements le temps de faire de gros traitements sur des DataTable, puis pour réactiver ces événements dés que les traitements sont terminés. cette méthode est appelée ponctuellement a divers endroit de mon code mais toujours depuis le Thread principale (Thread A) ce qui ne pose aucun problème.

Aujourd'hui j'ai besoin de faire la même action mais depuis un Thread secondaire (Thread B) seulement les Threads risquent de se faire concurrences aux niveaux des Activation/Désactivation. Il faudrait que si Thread A désactive les Events, alors Thread B n'a pas le droit les réactiver tant que Thread A n'a pas terminé et réactivé ces Events, (il doit attendre sont tour). Idem depuis Thread B. (Le fonctionnement normal de l'application veux que ces événements soit toujours activés en temps normal). Je ne sais pas du tout comment faire cela.

Cela donne un truc du style :

Code:

---

1 2 3

ActiveControlesHandler(False) ' ici on lance des opérations sur un DataTable ActiveControlesHandler(True)

---

Le code pour Désactiver/Activer les évenements :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Dim ControleHanddlerIsActive As Boolean Public Sub ActiveControlesHandler(ByVal State As Boolean)   If State = True And ControleHanddlerIsActive = False Then AddHandler DataGridView1.CurrentCellDirtyStateChanged, AddressOf EventCurrentCellDirtyChanged AddHandler MainBindingSourcePaths.CurrentItemChanged, AddressOf EventbsCurrentItemChanged AddHandler MainBindingSourcePaths.CurrentChanged, AddressOf EventbsCurrentChanged AddHandler MainBindingSourcePaths.PositionChanged, AddressOf EventbsPositionChanged AddHandler dtTablePaths.ColumnChanging, AddressOf EventTableColumnChanging AddHandler dtTablePaths.ColumnChanged, AddressOf EventTableColumnChanged AddHandler dtTablePaths.TableNewRow, AddressOf EventTableNewRow   ControleHanddlerIsActive = True ElseIf State = False And ControleHanddlerIsActive = True Then RemoveHandler DataGridView1.CurrentCellDirtyStateChanged, AddressOf EventCurrentCellDirtyChanged RemoveHandler MainBindingSourcePaths.CurrentItemChanged, AddressOf EventbsCurrentItemChanged RemoveHandler MainBindingSourcePaths.CurrentChanged, AddressOf EventbsCurrentChanged RemoveHandler MainBindingSourcePaths.PositionChanged, AddressOf EventbsPositionChanged RemoveHandler dtTablePaths.ColumnChanging, AddressOf EventTableColumnChanging RemoveHandler dtTablePaths.ColumnChanged, AddressOf EventTableColumnChanged RemoveHandler dtTablePaths.TableNewRow, AddressOf EventTableNewRow   ControleHanddlerIsActive = False End If End Sub

---

Je vous remercie beaucoup pour votre aide.

à côté de la méthode ActiveControlesHandler tu met une variable privée as integer

quand tu rentres dans la méthode avec false tu fais +1 dessus, si l'int = 1 tu désactive
quand tu rentres avec true, tu fais -1, si l'int = 0 tu actives
ainsi lors du 2ème appel avec false l'int vaudra 2 et exit sub car ne vaut pas 1 (et ca aura été désactivé à 1)
lors du 1er true tu passes de 2 à 1 et exit sub car pas 0
lors du 2eme true tu passes à 0 et ca réactive

par contre il faut un synclock, ou alors l'incrémentation atomique mais je ne sais plus où elle est car en multithreading si 2 threads passent en même temps sur la ligne varint += 1 il se peut qu'en partant de 1 on arrive à 2 au lieu de 3
chaque thread va lire la valeur (1) puis faire +1 (2) puis ranger dans la variable
il faut donc interdire à 2 threads de faire ca en même temps

Bonsoir et merci de m'avoir répondu.
J'ai dus relire plusieurs fois car au début j'ai cru que cela ne réglait le problème qu'a moitié, en effet avec cette technique on ne mets pas en attente le Thread B si le Thread A a débuter une opération. En y réfléchissant bien c'est vraiment très astucieux car en effet il est inutile de vouloir rentrer dans la procédure (et mettre un Thread en attente) afin de la désactiver si celle-ci l'a déjà été par un autre Thread. Et la réactivation ne s'effectue que si il n'y a plus aucun Thread qui nécessite une désactivation.

Franchement vous êtes quelqu'un sur le site a données des réponses pertinentes a chaque fois, ça me laisse admiratif.
Je ne marque pas résolue tout de suite car je dois procéder a des essais, je le ferais plus tard. Et encore merci :ccool:

je veux bien croire qu'il faille relire plusieurs fois, c'est juste prémaché, il faut modéliser le tout pour comprendre le fonctionnement

sinon il faut bien cerner la problématique, si le but est de laisser en attente un thread il y a synclock qui permet de faire ca, ou éventuellement le readerwriterlockslim qui permet de gérer des cas de manière plus optimisé que synclock

si votre thread répond à une demande de chargement et que votre 2ème thread doit remplacer le traitement du 1er il y a mieux que de verrouiller l'accès, il faut annuler le 1er avec là aussi plusieurs méthodes

la technique que je vous ai donné c'est pour permettre de suspendre quelque chose dans le cas de x entrées de la méthode jusqu'à la xième sortie en gros
si vos 2 threads ont réellement besoin de faire le travail en même temps ca devrait convenir
on trouve ce genre de comportement dans le framework, comme dans la méthode suspendlayout/resumelayout, on peut appeler suspend plusieurs fois, et il faut appeler resume autant de fois pour réactiver le calcul du layout
décompiler le framework quand on veut comprendre comment marche l'outil qu'on utilise est une des méthodes qui permet d'apprendre plein de techniques
poser des questions pertinentes ici a l'air d'en être une autre ^^
il y a aussi des tutos sur les design pattern les plus courants, qui sont des méthodes connues qui répondent à des problématiques, de conception ou de performance (singleton, factory, lazy initialization etc...)


pour l'incrément atomique c'est interlocked.increment/decrement(variable)

Merci beaucoup pour l'explication.
En fait je ne sais pas très bien ce qu'il faut verrouiller, c'est là tout le problème. La seule chose dont je suis sûre c'est que je dois désactiver ces événements lors de certaines opérations et je ne maîtrise pas vraiment le moment quand ces opérations se produisent et donc il y a une probabilité pour que les Threads travaillent en même temps.
Voilà ou j'en suis pour l'instant :

J'ai ajouté une région critique afin de garantir la réactivation des événements en cas d’interruption du Thread.

Code:

---

1 2 3 4 5

Thread.BeginCriticalRegion() ActiveControlesHandler(False) ' ici on lance des opérations sur un DataTable ActiveControlesHandler(True) Thread.EndCriticalRegion()

---

A la place de 0 et 1, je fait un test avec -1 et 0, cela m’évite d'initialiser la variable lors de la première activation.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

Dim ControleHanddlerIsActive As Boolean Dim ControleHandlerCounterOfDésactive As Integer Public Sub ActiveControlesHandler(ByVal State As Boolean)   If State = False Then Interlocked.Increment(ControleHandlerCounterOfDésactive) Else Interlocked.Decrement(ControleHandlerCounterOfDésactive) End If   If State = True And ControleHanddlerIsActive = False And ControleHandlerCounterOfDésactive = -1 Then AddHandler DataGridView1.CurrentCellDirtyStateChanged, AddressOf EventCurrentCellDirtyChanged AddHandler MainBindingSourcePaths.CurrentItemChanged, AddressOf EventbsCurrentItemChanged AddHandler MainBindingSourcePaths.CurrentChanged, AddressOf EventbsCurrentChanged AddHandler MainBindingSourcePaths.PositionChanged, AddressOf EventbsPositionChanged AddHandler dtTablePaths.ColumnChanging, AddressOf EventTableColumnChanging AddHandler dtTablePaths.ColumnChanged, AddressOf EventTableColumnChanged AddHandler dtTablePaths.TableNewRow, AddressOf EventTableNewRow Debug.Print(String.Format("Les évenements ont été activés par le tread [{0}] <{1}>", Thread.CurrentThread.ManagedThreadId, Thread.CurrentThread.Name))   ControleHanddlerIsActive = True ElseIf State = False And ControleHanddlerIsActive = True And ControleHandlerCounterOfDésactive = 0 Then RemoveHandler DataGridView1.CurrentCellDirtyStateChanged, AddressOf EventCurrentCellDirtyChanged RemoveHandler MainBindingSourcePaths.CurrentItemChanged, AddressOf EventbsCurrentItemChanged RemoveHandler MainBindingSourcePaths.CurrentChanged, AddressOf EventbsCurrentChanged RemoveHandler MainBindingSourcePaths.PositionChanged, AddressOf EventbsPositionChanged RemoveHandler dtTablePaths.ColumnChanging, AddressOf EventTableColumnChanging RemoveHandler dtTablePaths.ColumnChanged, AddressOf EventTableColumnChanged RemoveHandler dtTablePaths.TableNewRow, AddressOf EventTableNewRow Debug.Print(String.Format("Les évenements ont été désactivés par le tread [{0}] <{1}>", Thread.CurrentThread.ManagedThreadId, Thread.CurrentThread.Name))   ControleHanddlerIsActive = False End If End Sub

---

Pour l'instant je pense que l'on est sur la bonne voie mais quelque chose me dit que je devrais peut être rajouter un Synclock/End SyncLock et je ne sais pas comment exactement ni si cela est vraiment nécessaire. En effet je n'ai pas nécessairement besoin de mettre un Thread en attente a condition que ma procédure soit suffisamment vérouillées (c'est ma crainte), c'est a dire que dans le cas ou 2 threads rentre en même temps dans la procédure il ne faudrait pas que l'un active pendant que l'autre désactive ou encore que cela entraîne une erreur dans le décompte de la variable integer car ensuite je ne pourrais plus réactiver. Je ne sais pas trop répondre a cette question.
Bien sûr dans mon programme pour chaque désactivation correspond une réactivation, les appels sont équilibrés.

Merci beaucoup si vous pouvez m'aider.

je ne connaissais pas Thread.BeginCriticalRegion, je vais regarder ce que ca donne
mais si j'ai bien compris ca sert à arrêter l'appli suite à un abort, et je ne suis pas sur que vous ayez compris la même chose ...

Merci Pol63,
En effet j'ai un gros doute, j'ai peut-être mal compris. Il me semblait que le Thread devait attendre d'être sortie d'une région critique avant de pouvoir effectivement s'interrompre en particulier dans le cas d'un Abort. En tout cas si une telle fonction existe je pense que c'est ce qu'il faudrait faire dans mon cas. L'ideal serait que cela fonctionne aussi dans le cas d'une levé d'exception dans le Thread mais peut-être que j'en demande beaucoup :roll: :)

Bonjour.

Il me semble que le problème est mal abordé et à mon avis désactiver ces événements pour un traitement de fond n'est pas souhaitable.

Premier problème : quel est le scénario exact ? Mon petit doigt me dit que ces événements sont normalement utilisés pour répondre à des actions de l'utilisateur mais qu'ils répondent également à des actions automatisées, ce qui n'est pas désirable. D'où le désabonnement avant ces actions automatisées. Juste ? Si oui il faut se rappeler que des actions de l'utilisateur peuvent survenir durant les actions automatisées effectuées en arrière-plan, donc se désabonner avant une action en arrière-plan ne serait pas la bonne solution.

Second problème : les contrôles UI ne peuvent être manipulés que depuis le thread sur lequel ils ont été créés (il y a une "affinité avec un thread" / "thread affinity"). Et par extension les tables liées à l'UI ne doivent être manipulées que depuis le thread UI. Un thread d'arrière-plan doit donc séparer les calculs purs qu'il réalise lui-même, des opérations de mise à jour de l'UI qui devront être envoyées vers le thread UI via Control.Invoke/BeginInvoke.

Partant de là deux scénarios possibles :
* Faire les calculs en arrière-plan et mettre à jour le datatable sur le thread UI. Valable uniquement si les calculs sont majoritaires.
* Créer un nouveau datatable en arrière-plan, puis l'attacher à l'UI.

Dans les deux cas la MAJ de la vue sera faîte uniquement sur le thread UI, donc se désabonner avant et se réabonner après ne posera pas de problème.



Régions critiques
Une "région critique" n'a d'effet que lorsque la CLR est hébergée par un processus natif (SQL Server, IIS, mode debug de VS, etc). Si une exception asynchrone (StackOverflow, OutOfMemory et ThreadAbort) survient dans une région critique, alors l'hôte considérera le domaine d'application comme corrompu et le déchargera.

Le raisonnement est simple : ces exceptions sont difficilement gérables car elles peuvent survenir n'importe quand ! Par exemple dans "maVariable = AllocUnamnagedMemory()" une exception peut survenir après l'allocation mais avant l'assignation, rendant le nettoyage impossible. De même une exception peut survenir après l'acquisition d'un verrou mais avant l'entrée dans un bloc "try". Et ainsi de suite. Il est parfois impossible (littéralement) d'écrire un code managé résilient.

Ainsi, quand SQL Server héberge le CLR, il gère plusieurs domaines d'applications piochant tour à tour des procédures managées en attente d'exécution. Si une exception asynchrone survient dans un de ces domaines, SQL Server laisse les choses suivre leur cours (l'exception peut être interrompue et gérée par le code, ou bien elle peut continuer à remonter, en vidant la pile d'appels). Mais si cette exception est survenue dans une région critique, alors SQL Server détruira purement et simplement le domaine d'application avant d'en recréer un.

Une région critique indique donc que si une des trois exceptions asynchrones survient, alors le domaine d'application doit être considéré par l'hôte comme corrompu et détruit. Et s'il n'y a pas d'hôte ça n'a aucun effet. A ne pas confondre avec une "section critique", terme de Win32 qui désigne un bout de code protégé par un verrou.

Bonsoir DonQuiche, merci pour ton intervention.

Citation:

---

Mon petit doigt me dit que ces événements sont normalement utilisés pour répondre à des actions de l'utilisateur mais qu'ils répondent également à des actions automatisées, ce qui n'est pas désirable. D'où le désabonnement avant ces actions automatisées. Juste ?

---

C'est exactement ça. Au départ j'ai utilisé ces événements pour répondre aux actions utilisateurs (Principalement pour valider des données dans ColumnChanging ou faire apparaître un formulaire de saisie dans TableNewRow). Puis j'ai eu besoin d'actualiser des données au moment du chargement, je me suis rapidement rendu compte que je n'avais pas besoin de validation des données durant cette tache, d'ou les désabonnements. (a ce moment là l'interface utilisateur n'est pas accessible donc ça ne présente aucun risque). J’aurais pu le faire différemment je suis tout a fait d'accord que c'est une faiblesse de mon application mais je m'en rend compte que maintenant. En même temps je ne suis qu'un amateur, je fait des erreurs et j'apprends.

Citation:

---

les contrôles UI ne peuvent être manipulés que depuis le thread sur lequel ils ont été créés (il y a une "affinité avec un thread" / "thread affinity"). Et par extension les tables liées à l'UI ne doivent être manipulées que depuis le thread UI

---

Pour les contrôles, c'est clair ça lève de suite une exception Cross-Threads mais pour les tables je ne savais pas. En réalité les interventions utilisateurs sur la table en question se limite a supprimer des enregistrements pendant que le traitement automatique en ajoute ou modifie des existants, cela expliquent peut-être pourquoi je n'ai jamais rencontré de problèmes ?!

Citation:

---

puis l'attacher à l'UI

---

En quoi consiste l'opération attacher exactement ?

Merci pour l'information sur les régions critiques.

@Pol63, j'ai décider de ne pas utiliser Abort pour arrêter le thread car je ne maîtrise pas le moment précis de son interruption. Je préfère tester une variable boolean "StopRequest" dans une boucle pour pouvoir sortir de la boucle et quitter le Thread au moment que j'ai choisis. Ensuite je fait un Join.
Concernant les exceptions j'ai ajouté un bloc Try comme ceci pour limiter les risques :

Code:

---

1 2 3 4 5 6 7

ActiveControlesHandler(False) Try ' ici on lance des opérations sur un DataTable Catch ex As Exception   End Try ActiveControlesHandler(True)

---

J'ai implémenté tous ça sur mon application réel, ça ne semble pas poser de problèmes mais je ne suis pas contre d'autres éventuels conseils ou réponses a ce qui a été dit plus haut.

Citation:

---

Envoyé par BasicZX81

je suis tout a fait d'accord que c'est une faiblesse de mon application mais je m'en rend compte que maintenant.

---

En soi ce n'est nullement une faiblesse, on voit ça tout le temps. Là où ça coince c'est quand tu peux avoir des opérations manuelles de l'utilisateur durant les traitements automatisés : dans ce cas tu es obligé de garder tes événements pour les traitements utilisateur et ton approche ne convient plus (il suffit de faire une édition durant le traitement de fond pour voir le bogue : pas de validation).

Si c'est bien ce que tu avais compris et que tu voulais dire que tu peux te permettre ce bogue, ok. Mais sinon il y a une solution : utiliser les mécanismes standard de validation puisque c'est ce que tu veux faire. A savoir utiliser les événements CellValidating, RowValidating et Validating de DataGridView. Ceux-ci ne seront déclenchés que suite à des actions manuelles de l'utilisateur et avant la mise à jour de la DataTable liée.

Citation:

---

Pour les contrôles, c'est clair ça lève de suite une exception Cross-Threads mais pour les tables je ne savais pas.

---

A vrai dire j'ai un doute. Il se peut que le DataGridView vérifie le thread courant lors de la levée de DataTable.TableNewRow afin de réaliser la mise à jour sur le thread UI si besoin est. Donc peut-être pas de problème.

Citation:

---

En réalité les interventions utilisateurs sur la table en question se limite a supprimer des enregistrements pendant que le traitement automatique en ajoute ou modifie des existants, cela expliquent peut-être pourquoi je n'ai jamais rencontré de problèmes ?!

---

Autre problème : deux threads réalisent donc simultanément des opérations d'écriture sur cette même datatable ? Si oui tu risques une corruption des données puisque DataTable n'est pas thread-safe dans ce genre de scénario. La solution est de modifier cette table depuis le thread UI exclusivement si tu veux conserver le data binding.

Citation:

---

En quoi consiste l'opération attacher exactement ?

---

Un mauvais choix de mot. "Assigner" aurait été plus judicieux, pour l'assignation de la nouvelle DataTable à la DataGridView.

Citation:

---

Si c'est bien ce que tu avais compris et que tu voulais dire que tu peux te permettre ce bogue, ok.

---

C'est pas vraiment ce que j'aurais voulu au départ mais je suis conscient du problème. Pour l'instant ça ne me gène pas plus que ça mais a terme j’essaierais de trouver une meilleure solution, c'est juste que ça remets en cause toute l'architecture de mon programme et je ne suis pas prêt a le faire :aie:;).
Pour la petite histoire, je m'était posé la question concernant la meilleure façon de traiter les actions utilisateurs sachant que je voulais produire un code (de calculs/validations) facilement transposable pour d'autres tables et indépendant des contrôles (ce que j'ai réussi a faire). Pour cela j'ai utilisé a fond (ou presque) le databinding et l'endroit qui m'ai apparu comme le plus évident pour traiter les actions utilisateurs est l’événement ColumnChanging puisque ici converge absolument toutes les modifications et on a aussi la possibilité d'annuler les saisies non valide. Aprés je ne dit pas que l'on ne peux pas faire la même chose au niveau des contrôles. D'ailleurs c'est une question que je me pose depuis longtemps, a quelle endroit ou a quelle moment il vaux mieux faire les validations ? au niveau Datatable ou au niveau des contrôles ? J'ai un élément de réponse avec le problème des traitements automatique mais cela m'interresse vraiment beaucoup de savoir qu'elle est la pratique utilisé couramment dans le monde pro.

Citation:

---

A vrai dire j'ai un doute. Il se peut que le DataGridView vérifie le thread courant lors de la levée de DataTable.TableNewRow afin de réaliser la mise à jour sur le thread UI si besoin est. Donc peut-être pas de problème.

---

Ça me mets le doute aussi mais j'ai tendance a dire que ça fonctionne puisque c'est une réalité dans mon programme, on voit bien des lignes apparaître toutes seules sur le DatagridView et cela depuis un thread secondaire sans utiliser d'Invoke/BeginInvoke.

Citation:

---

Autre problème : deux threads réalisent donc simultanément des opérations d'écriture sur cette même datatable ?

---

Ben oui je crois :oops: c'est la simultanéité que je ne peux pas prouver mais effectivement je crois avoir rencontrer un petit soucis une fois. (une ligne que j'ai modifié a la main et qui n'a pas été trouvé par le traitement automatique (ou un truc dans le genre). Il faudra que je vérifie cela aussi.

Citation:

---

La solution est de modifier cette table depuis le thread UI exclusivement.

---

Avec un Invoke donc si j'ai bien tout compris.

Je songe a passer la discussion en résolue :ccool: mais j'aimerais bien avoir votre avis sur la validation.

Concernant la validation la pratique courante est de la traiter via les événements "Validating" dédiés côté UI. Après tout ça a été conçu pour ça. Et de nos jours tous les contrôles/frameworks UI offrent des mécaniques standard de validation.

La seule justification pour mettre en oeuvre une mécanique personnalisée c'est lorsqu'on n'est pas satisfait par la mécanique standard en termes d'expérience utilisateur. Par exemple si on souhaite valider à chaque frappe de l'utilisateur plutôt que lors de la perte du focus.

Enfin, oui, il faut passer par Invoke. Tant pour la lecture de la table que pour sa modification.

Merci pour ces renseignements DonQuiche. C'est toujours trés interressant d'avoir le point de vue des vrais developpeurs. Ca me servira pour mon expérience personnelle et peut-être pour améliorer mon programme.
Je passe ne résolue. :ccool: