Question d'optimisation a propos des Thread (backgroundworker)

Bonsoir,

J'ai une application multithread et je voudrais l'optimiser,

J'ai 10 threads qui , et un 11eme thread qui est appelé par les 10 threads (Me.Invoke).

Dans ce 11eme thread je remplis une collection protégé par un lock et donc je me demandais si en faisant comme ça je limitais les accès concurrentiel ou pas du tout ?

Que me conseillerez vous pour optimiser mon application ? est-ce que si je fais les traitement totalement séparé je gagnerais beaucoup en performance ou non ? sachant que mon application lance 10 socket a la fois (comme c'est du réseau il doit y avoir moins de concurrence ? )

Aussi j'aurais voulu savoir si je fait mon application avec des vrai thread plutôt qu'avec des backgroundworker je gagnerais en performance ?

un backgroundworker ne fait qu'encapsuler un thread et quelques petits trucs pratique

si par lock tu veux dire synclock, c'est écrit dans l'aide ce que ca fait, à savoir qu'un seul thread peut entrer dans la partie lockée à la fois (les autres attendent à l'entrée) ca apporte de la sécurité mais ca peut limiter les performances
il y a le readerwriterlock[slim] qui peut gagner des perfs par rapport à un synclock mais ca dépend de ce que tu fais, dans certains cas ca ne peut pas etre utilisé


l'utilisation des sockets est forcément multithreadée, soit on appelle les méthodes asynchrone dans un thread (beginconnect, beginread etc...) qui ne font qu'attendre dans un thread créé par le framework, soit on créé un thread soi meme et on appelle connect, read etc...



d'une manière générale le multithreading apporte forcément plus de performances, la montée en fréquence est plus que ralentie depuis quelques années, par contre ils arrivent à mettre 16 cores sur un processeur ...

Citation:

---

Envoyé par Pol63

un backgroundworker ne fait qu'encapsuler un thread et quelques petits trucs pratique

si par lock tu veux dire synclock, c'est écrit dans l'aide ce que ca fait, à savoir qu'un seul thread peut entrer dans la partie lockée à la fois (les autres attendent à l'entrée) ca apporte de la sécurité mais ca peut limiter les performances
il y a le readerwriterlock[slim] qui peut gagner des perfs par rapport à un synclock mais ca dépend de ce que tu fais, dans certains cas ca ne peut pas etre utilisé


l'utilisation des sockets est forcément multithreadée, soit on appelle les méthodes asynchrone dans un thread (beginconnect, beginread etc...) qui ne font qu'attendre dans un thread créé par le framework, soit on créé un thread soi meme et on appelle connect, read etc...



d'une manière générale le multithreading apporte forcément plus de performances, la montée en fréquence est plus que ralentie depuis quelques années, par contre ils arrivent à mettre 16 cores sur un processeur ...

---

Enfaite je voulais dire est-ce que j'aurais mieux fait de faire le lock dans les 10 threads plutot que d'appeler un autre thread qui lui fait le lock ? (oui SynLock, j'avais lu des trucs sur les readerwriterlock, il serait plus performant mais moins safe, je préfère faire attention)

le readerwriterlock n'est pas moins safe, il est différent
si 1 thread fait un .add pendant qu'un autre fait un for each il faut en effet un synclock sinon ca plante, par contre si 2 threads font un for each, le synclock va faire attendre le 2ème alors que ca ne poserait pas de soucis qu'il lise la collection en même temps
en gros le readerwriterlock permet de laisser tout le monde faire tel type d'action en meme temps, alors que pendant le type d'action qui est critique (ici .add) tous les accès deviennent l'équivalent d'un synclock


je comprends pas trop ton histoire de thread qui lock pour les 10 autres
si tes 10 threads accèdent à la même collection, c'est l'accès à la collection qui doit être thread safe

Citation:

---

Envoyé par Pol63

le readerwriterlock n'est pas moins safe, il est différent
si 1 thread fait un .add pendant qu'un autre fait un for each il faut en effet un synclock sinon ca plante, par contre si 2 threads font un for each, le synclock va faire attendre le 2ème alors que ca ne poserait pas de soucis qu'il lise la collection en même temps
en gros le readerwriterlock permet de laisser tout le monde faire tel type d'action en meme temps, alors que pendant le type d'action qui est critique (ici .add) tous les accès deviennent l'équivalent d'un synclock


je comprends pas trop ton histoire de thread qui lock pour les 10 autres
si tes 10 threads accèdent à la même collection, c'est l'accès à la collection qui doit être thread safe

---

Merci pour ces précieuses informations, donc je pense que je pourrais utiliser un readerwriterlock alors.

Enfaite j'ai 10 threads qui téléchargent des fichiers, pour chaque thread il y a des centaines de fichiers téléchargés, puis analysé, et le résultat obtenu est ajouté a une collection.

Ca marche très bien mon truc, je me demandais juste si ce que j'avais fait était bête ou non c'est a dire de rajouter un 11eme thread ou je fais le lock plutot que de faire le lock dans les boucle de chaque threads, j'me disait que ca devait être plus performant si un seul thread est bloqué par le lock.

Apres on pourrait imaginer que si c'est plus performant, je pourrais mettre 16 thread,
et ensuite mettre par exemple 4 thread avec 4 lock et ensuite 1 thread avec 1 lock

comme ceci :

Threads de téléchargement :
1-2-3-4______5-6-7-8______9-10-11-12____13-14-15-16
Threads permettant d'éviter les "collisions" :
__17_________18____________19___________20
Thread permettant l'ajout à la collection :
____________________21

De cette manière seulement 4 thread rentreraient en collision a chaque fois, l'ajout de la collection est censé être extrêmement rapide donc je ne pense pas que ce soit si intéressant si ce que je dis marche, il faudrait voir

Ps: désolé pour les underscore mais l'affichage aurait été incompréhensible sinon

rien compris, mais je pense que ton 11ème thread ne sert à rien, et que tes étages de thread non plus