Discussion :

[Jean-Philippe André]

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

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

[tomlev]

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.

[Jean-Philippe André]

Hum, OK,

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

[tomlev]

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...

[Jean-Philippe André]

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

[tomlev]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Jean-Philippe André]

Là c'est du chinois pour moi

je regarde de quoi il s'agit

[Jean-Philippe André]

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Sub HandleEventParent() Handles Parent.Result
Traitement()
RaiseEvent Result
End Sub

à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[tomlev]

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

oui

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Sub HandleEventParent() Handles Parent.Result
Traitement()
RaiseEvent Result
End Sub

à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

voire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[Jean-Philippe André]

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 ^^

[tomlev]

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...

[Jean-Philippe André]

Héhé,

en fait j'ai une structure comme sur le dessin


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.

je cherche donc à diminuer le temps de traitement au mieux

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

[youtpout978]

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

[tomlev]

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.

[Jean-Philippe André]

Hum,
ca consisterait à faire du

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

au lieu de faire des

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[tomlev]

Oui c'est ça

[Jean-Philippe André]

je m'en vais essayer ca asap

[Jean-Philippe André]

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

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 ?

[tomlev]

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.

[Jean-Philippe André]

Bon j'ai fait un dessin pour donner ma configuration


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