Discussion :

[actionthomas]

Bonjour.

J'ai un problème avec le multithreading.
Je développe un service Windows qui va aller se connecter à n clients pour leur envoyer une commande.
Pendant mes premiers tests, quand j'avais peu de clients connectés, tout allait bien. Mais maintenant que j'ai environ 200 clients, ca ne marche plus.

Voici le fonctionnement actuel :
J'ai un thread qui effectue un foreach sur la liste des clients connectés.
Dans ce foreach, j'instancie un ManualResetEvent (situé dans un tableau), et j'appelle la fonction qui va faire la connection et tout par un ThreadPool.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
For Each c In ListeClients
 
            manualEvents(i) = New ManualResetEvent(False)
 
            Dim _args As New List(Of Object)
            _args.Add(strProgName)
            _args.Add(strArgs)
            _args.Add(stream)
            _args.Add(broadcastID)
            _args.Add(c)
            _args.Add(manualEvents(i))
 
            ThreadPool.QueueUserWorkItem(AddressOf SendCommandThread, _args)
            Trace.WriteLine("Created", "ThreadpoolCommand")
            i += 1
Next

Et ensuite j'attends que tous les manualResetEvent soient signalés pour continuer :

Code :

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

1
2
3
4
5
6
If WaitHandle.WaitAll(manualEvents) Then
            Trace.WriteLine("End", "ThreadpoolCommand")
            Return CHAR_ACK
Else
            Return CHAR_NACK
End If

Le problème, c'est que WaitAll ne peut pas prendre en paramètre un tableau de plus de 64 manualResetEvents. D'où mon bug...

Auriez-vous une idée pour que je puisse contourner cette limitation ?

Merci !

[joKED]

Je suis tombé sur la même limitation il y a peu de temps.
Après moultes recherches, la solution donnée le plus souvent (et que j'ai utilisée), est de travailler par "paquets" de 64.

C'est pas beau, et si tu trouves une plus belle meilleure bonne solution, je suis preneur

[Bluedeep]

Je ne suis pas du tout convaincu que le ThreadPool soit l'idéal pour gérer des threads dans ce contexte.

[actionthomas]

Que me proposes-tu en remplatement ?

[Bluedeep]

Que me proposes-tu en remplatement ?

Gérer tes threads "normalement" sans le threadpool.

[actionthomas]

Dans ce cas comment faire pour savoir quand tous les threads ont terminé ?

[Bluedeep]

Plusieurs solutions mais la plus simple me semble d'allouer un ManualResetEvent (ou n'importe quel autre objet de synchro) à chaque thread, et utiliser la méthode static WaitAll pour attendre que tous les Events soient signalés.

[actionthomas]

C'est ce que je fais déjà.
C'est pas le fait de passer par un ThreadPool qui plante, mais le WaitAll qui ne peut gérer que 64 objets de synchro maximum...

---- Message court d'assertion ----
Exception : Le nombre de WaitHandles doit être inférieur ou égal à 64.

[Bluedeep]

Ok, je devrais prendre l'habitude de lire plus attentivement avant de répondre.

Donc, moyen simple de contourner :

- pour chaque bloc de 64 threads, tu démarre un thread "superviseur" qui WaitAll ses 64 thread supervisées (et qui se charge de les démarrer).

- chaque thread superviseur à lui même un Event qu'il signale quand il a fini d'attendre sur son WaitAll.

- les event des threads superviseurs, sont eux-même WaitAll par ton ton thread initiateur des threads superviseurs.

Donc 64x64 dispo.

Si ce n'est pas suffisant, tu peux même appliquer la méthode de manière récursive.

je ne connais pas le nombre de Event que peut gérer un domain d'application, vérifier si il y a une limite de ce coté.