Discussion :

[Cokate]

Bonjour a tous ,
J'ai encore une question pour vous (ca fait bien la 4eme que je pose ici ) bref ....

Alors en fait il y a une méthode qui doit normalement tourner 5 a 10 fois par seconde (le plus rapide étant le mieux bien sur) le problème c'est que cette méthode communique avec une application (plateforme de trading). Pour cette application, on lui fournit les "codes" des objets qui nous intéressent. Jusque la pas de problème quand il y avait 15/20 codes mais avec beaucoup de codes (190 /200) c'est beaucoup trop lent.
Donc pour accélérer les choses je me suis dit que j'allais créer un thread par code qui irait lire les informations avec l'application .
La j'hésite entre 2 solution parce qu'en fait les infos sont toutes récupérées dans un dataset commun d'où problème d'exclusion mutuelle ... alors soit le protège les zones de code susceptible de toucher au dataset soit chaque thread remplit son dataset (une datatable /thread) et à la fin on met tout en commun ... qu'est ce qui vous semble le mieux ? sinon y-a-t-il une autre solution pour accélérer ?
Et autre question comment faire une barrière de synchronisation en C# ?

Merci d'avance ...

[SaumonAgile]

Pour synchroniser les threads, tu peux utiliser lock (= Monitor).
Après il te reste aussi la solution Mutex ou Semaphores.

[tomlev]

Vu le nombre de codes, créer un thread par code ne me semble pas très judicieux... n'oublie pas que les threads ne s'exécutent pas réellement en même temps, en fait ils se partagent le temps processeur. Au mieux tu n'auras que N threads vraiment simultanés, N étant le nombre de processeurs.

Pour ce genre de choses, il vaut mieux utiliser un ThreadPool

[theMonz31]

bonjour

Juste pour dire cela en passant :

Tu peux faire du multithread, du Threadpool, ou tout ce que tu veux, arrive un moment ou le goulet (le dataset par exemple) ou le volume des opérations à faire ne pourra pas rentrer dans le temps imparti

A certaines situations, le mutlithreading apporte une solution jusqu'à certaines limites

Il ne faut pas oublier cela !

The Monz, Toulouse

[dev01]

Tu peux faire du multithread, du Threadpool, ou tout ce que tu veux, arrive un moment ou le goulet (le dataset par exemple) ou le volume des opérations à faire ne pourra pas rentrer dans le temps imparti

En l'occurrence si j'ai bien compris, le problème vient du lien avec l'application de Trading qui met du temps à répondre. Donc thread les accès à cette application est une bonne solution

[theMonz31]

je suis d'accord que threader les accès avec l'application de trading est une solution qui peut résoudre le problème. Cela dit, si la dite application de Trading est lente, il va forcément arriver un moment ou les performances ne pourront être atteintes faute de performance du trading.

Perso, j'essayerais de faire un "benchmark" des performances de l'application de Trading pour être sur que de mettre en place une solution multithread apportera réellement une solution au problème !!!

The Monz, Toulouse

[dev01]

La j'hésite entre 2 solution parce qu'en fait les infos sont toutes récupérées dans un dataset commun d'où problème d'exclusion mutuelle ...

Si tu as un dataset, il doit surement être utilisé dans une interface graphique non ? Et dans ce cas ton dataset doit être créé et fonctionner dans le thread UI.

Dans ton cas rien ne t'empêche d'utiliser un ThreadPool ( avec par exemple une 20 de thread disponible ) et d'utiliser Invoke (en winform) ou Dispatch (en WPF) pour gérer la synchro dans le dataset. Par contre au niveau perf, faut voir, j'ai comme un doute sur la rapidité de Invoke ou Dispatch