ContextSwitchDeadLock : optimisation du temps de traitement. Multithread ?

Hello,

j'envoie par API des demandes de TimedBar (données financieres), avec une période assez large (~5minutes). Je me tape une erreur ContextSwitchDeadLock au bout dun' moment :aie:

Autant je peux comprendre que 5 minutes soit long à l'échelle d'un programme, autant je ne trouve aucune info pertinente sur le sujet :(

Des idées pour s'affranchir de ce :bug:

Déjà, il faut savoir que ContextSwitchDeadlock n'est pas vraiment une exception, mais un MDA (Managed Debugging Assistant). Donc en fait c'est le debugger qui déclenche cette erreur quand il détecte un problème potentiel ; cette erreur ne se produit pas si le programme s'exécute en dehors du debugger. Tu peux désactiver ce MDA en allant dans Debug > Exceptions > Managed Debugging Assistants et en décochant ContextSwitchDeadlock.

Cela dit, ce n'est pas parce que tu peux "désactiver" cette erreur, qu'il faut le faire... Typiquement, ce problème se produit quand tu fais une opération longue qui implique COM sur le thread principal. La solution la plus évidente est de faire ce traitement sur un autre thread, pour ne pas bloquer le thread principal.

Hum, OK,

avec un timer, en lançant de façon "fictive" un autre processus, ca fonctionnerait alors ?

Citation:

---

Envoyé par jpcheck

avec un timer, en lançant de façon "fictive" un autre processus, ca fonctionnerait alors ?

---

C'est à dire ? Je comprends pas trop ce que tu entends pas lancer de façon fictive un autre processus...

Ben,

j'ai un timer sur le formulaire en début de processus, je peux lui faire effectuer une action avec un Tick < 1minute. La désactivation du bug, ne me semble pas la solution à ce niveau de développement :aie:

Bah si tu utilises un timer Windows Forms, ça va rien changer : l'évènement Tick est déclenché sur le thread UI, donc tu auras le même problème. Il faut exécuter le traitement long sur un nouveau thread

Par exemple, au lieu d'appeler directement FaireQuelqueChose(), tu fais ça :

Code:

---

1 2	Dim t As New Thread(AddressOf FaireQuelqueChose) t.Start()

---

Par contre seul le thread UI a le droit d'accéder à l'UI. Si tu dois y accéder à partir d'un autre thread, il faut utiliser la méthode Invoke pour demander au thread UI de le faire.

Là c'est du chinois pour moi :calim2:

je regarde de quoi il s'agit :)

Re,

bon la piste du "multi" thread me parait la plus prometteuse pour diminuer mes temps de traitement.

En effet, je me retrouve avec ma pile de blocs qui reçoivent des evenements des blocs parents, lancent un traitement éventuel et font descendre l'information aux blocs en dessous.

Comme il n'est pas nécessaire que le traitement soit finalisé pour faire redescendre l'information, je pense recourir au thread pour les traitements.

J'ai les notions théoriques du multi thread, mais jamais fait en vb.net :aie:

Peut-on lancer un thread sans avoir à détecter sa "fin" ?

Peut-on finalement passer d'un processus (je donne l'idée hein, pas tout le code)

Code:

---

1 2 3 4

Sub HandleEventParent() Handles Parent.Result Traitement() RaiseEvent Result End Sub

---

à

Code:

---

1 2 3 4 5 6 7

Sub HandleEventParent() Handles Parent.Result Dim ThreadTraitement As New Thread(AddressOf Traitement) ThreadTraitement.Start() RaiseEvent Result End Sub Sub Traitement() End Sub

---

voire

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Sub HandleEventParent() Handles Parent.Result Dim ThreadTraitement As New Thread(AddressOf Traitement) Dim ThreadResult as New Thread(AddressOf RaiseResult) ThreadTraitement.Start() ThreadResult.Start() End Sub Sub Traitement() End Sub Sub RaiseResult() RaiseEvent Result End Sub

---

ou est-ce utopique ?

Merci d'avance pour vos lumières :ccool:

Citation:

---

Envoyé par jpcheck

Peut-on lancer un thread sans avoir à détecter sa "fin" ?

---

oui

Citation:

---

Envoyé par jpcheck

Peut-on finalement passer d'un processus (je donne l'idée hein, pas tout le code)

Code:

---

1 2 3 4

Sub HandleEventParent() Handles Parent.Result Traitement() RaiseEvent Result End Sub

---

à

Code:

---

1 2 3 4 5 6 7

Sub HandleEventParent() Handles Parent.Result Dim ThreadTraitement As New Thread(AddressOf Traitement) ThreadTraitement.Start() RaiseEvent Result End Sub Sub Traitement() End Sub

---

---

Non, si tu fais ça tu vas déclencher l'évènement Result avant que le traitement soit terminé (Start n'est pas un appel bloquant, le thread courant continue de s'exécuter pendant que le nouveau thread s'exécute en parallèle)

Il faudrait plutôt que la méthode Traitement déclenche l'évènement Result quand elle se termine

Citation:

---

Envoyé par jpcheck

voire

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Sub HandleEventParent() Handles Parent.Result Dim ThreadTraitement As New Thread(AddressOf Traitement) Dim ThreadResult as New Thread(AddressOf RaiseResult) ThreadTraitement.Start() ThreadResult.Start() End Sub Sub Traitement() End Sub Sub RaiseResult() RaiseEvent Result End Sub

---

ou est-ce utopique ?

---

Je vois pas trop l'intérêt de déclencher l'évènement sur un nouveau thread... qu'est-ce que ça va t'apporter ?

D'accord,

pas de plus-value sur le déclenchement de l'event dans un thread.

Par contre, je n'ai pas de pré-requis dans le traitement, que je souhaiterais donc lancer "en solo" et déclencher l'event dans la foulée.

Si j'ai un traitement "montant" vers le parent et un traitement "descendant" vers les blocs enfants, là je peux faire du thread pour chaque donc ?

Ca m'a l'air très prometteur cette histoire ^^

Citation:

---

Envoyé par jpcheck

Si j'ai un traitement "montant" vers le parent et un traitement "descendant" vers les blocs enfants, là je peux faire du thread pour chaque donc ?

---

Je comprends pas très bien ton système en fait, donc j'ai du mal à me rendre compte si ce serait judicieux...

Héhé,

en fait j'ai une structure comme sur le dessin
http://uppix.com/f-blocks4fe184fc00103ef7.jpg

Les info montent du blocks 7 vers le block 2 qui est "pluggé" au data provider.
Le truc c'est que j'en ai plein en meme temps des demandes, donc pleins de retour.

Mon problème s'est situé au moment où ma quantité de retours entre chaque timebar de 5 minutes s'est mis à dépasser les 5 minutes. :aie:

je cherche donc à diminuer le temps de traitement au mieux :ccool:

j'utilise le code de la :faq: à ce sujet http://faqvbnet.developpez.com/index...d#thread_param

sinon tu as le backgroundworker qui est assez simple d'utilisation
http://glarde.developpez.com/dotnet/bgworker/vb/

Bah tu peux sans doute paralléliser certaines choses, mais il faut faire gaffe de pas lancer trop de threads à la fois, parce que c'est couteux en mémoire (chaque thread ayant sa propre stack). Il vaudrait donc mieux utiliser le ThreadPool plutôt que de créer manuellement des threads.

Hum,
ca consisterait à faire du

Code:

---

1 2 3

Dim tmpthread As New ThreadBlock(Me, DESC_PARAM) ThreadPool.QueueUserWorkItem(New WaitCallback(AddressOf tmpthread.ThreadFunc)

---

au lieu de faire des

Code:

---

1 2 3 4

Dim OtherThread As Thread Dim tmpthread As New ThreadBlock(Me, DESC_PARAM) OtherThread = New Thread(AddressOf tmpthread.ThreadFunc) Thread.Start()

---

à chaque fois, c'est bien ca ?

Oui c'est ça

je m'en vais essayer ca asap :ccool:

Bon, grosse frustration, ca n'améliore pas assez mes performances de code, j'ai meme l'impression que ca les amoindrit :cry:

quelles alternatives s'offrent à moi ?

je cherche à récupérer environ 400 valeurs en moins de 5 minutes (300 secondes donc)...

est-ce que l'écriture à la volée des résultats dans un fichier avec lecture du dit fichier toutes les x minutes/secondes est pertinent ?

Bah je sais pas comment tu récupères tes valeurs, donc je sais pas comment tu pourrais améliorer...

En fait j'ai l'impression que tu pars sur une fausse route. Quand je te proposais de faire ton traitement sur un thread séparé, c'était pour résoudre le problème de ContextSwitchDeadlock, pas pour améliorer les perfs.

Paralléliser les traitements n'est pas efficace dans tous les cas, certains traitements s'y prêtent et d'autres pas. Au départ je te suggérais de faire tes traitements dans un autre thread, pas dans plein de threads... Je ne sais pas si le parallélisme est une bonne idée dans ton cas.

Bon j'ai fait un dessin pour donner ma configuration
http://uppix.com/f-piou4fe1d8cc00103f7f.jpg

j'ai des montées d'info jusqu'à un bloc connecté au data provider par API.
A chaque retour de timedbar, je fais redescendre l'info.

A chaque récupération d'une timebar (données ouverture,min max, cloture), je dois en lancer une nouvelle avec le début de période = fin de période de la précédente...

les timebars sont enregistrées en base SQL Server.

pour l'instant je n'arrive qu'à une soixantaine d'enregistrmeents effectués en 5 minutes :/

je change le titre du sujet en conséquence :)

Rien compris :aie:
Ca te semble peut-être évident parce que tu es en plein dedans, mais même avec tes explications, pour moi ça reste complètement abstrait...

D'autre part, il me semble que le problème de ContextSwitchDeadlock et l'optimisation de ton traitement sont 2 problèmes différents... Il vaudrait peut-être mieux que tu ouvres une nouvelle discussion

OK