Backgroundworkers ou threadpools

Question

Je suis en train de créer une application qui permet plusieurs demandes de recherche tout en maintenant l'utilisation de l'interface utilisateur pour permettre l'interaction. Pour les demandes de recherche multiples, j'avais initialement une seule demande de recherche en cours d'exécution avec une interaction utilisateur toujours possible en utilisant un backgroundworker pour cela. Maintenant, je dois étendre ces fonctions en permettant plus de fonctions de recherche et en les mettant simplement en file d'attente. Je ne sais pas si je dois utiliser plusieurs backgroundworkers ou utiliser le threadpool car je veux être capable de connaître le progrès de chaque tâche de recherche à tout moment.

Si j'utilisais le threadpool, tout ce que je ferais serait d'ajouter cela dans la boucle qui est appelée à chaque fois qu'une demande de recherche est faite

 ThreadPool.QueueUserWorkItem(AddressOf Search)

mais si j'utilise des backgroundworkers, c'est la seule façon que je connaisse et je ne sais pas comment les ajouter à autre chose qu'un arraylist et je peux appeler reportprogress depuis chaque bgw.

édition :

par exemple, voici mon code actuel

 For Each Thread In ThreadList
                    'Thread.Sleep(500)
                    SyncLock Me

                        If searchChoice = "google" Or fromUrl.Contains("google") Then
                            links = parsingUtilities.GetGoogleLinksFromHtml(fromUrl, html, searchItem)
                            posts = parsingUtilities.GetPostLinksFromHtml(links)
                            If links.Count = 0 Then
                                Exit Sub
                            End If
                            Exit For
           .....

donc dans le code ci-dessus, les liens et les messages sont des arraylists que j'utilise pour obtenir les URLs dont j'ai besoin et ils sont utilisés pour différents choix de recherche et j'avais initialement le synclock sur les liens et les messages mais quelqu'un d'autre m'a dit d'utiliser le synclock me à la place. Donc de votre point de vue, devrais-je assigner un contrôle de données séparé pour chaque contrôle de recherche et après un temps suffisant verrouiller le bon et le transférer pour l'écrire. merci

Answer 1

En général, je laisse le threadpool tel quel. C'est une ressource globale du processus qui peut être configurée avec différentes tailles, notamment dans les applications web. Cependant, comme votre application semble être une application de formulaire côté client, vous ne partagerez pas de threadpool avec d'autres applications et vous pouvez le configurer selon vos besoins.

Votre cas d'utilisation convient mieux au threadpool que la plupart, mais il n'y a pas un énorme avantage à le faire.

Answer 2

Vous pouvez toujours recevoir des mises à jour de progression avec les BackgroundWorkers, donc je ne vois pas de raison d'arrêter de les utiliser.

Le BackgroundWorker utilise lui-même le pool de threads pour recycler les threads à ma connaissance. Donc vous pourriez probablement toujours limiter la taille du pool et continuer à utiliser les BWs.

Answer 3

Vous pouvez utiliser le ThreadPool de la même manière que vous utilisez BackgroundWorker.

La seule différence est qu'avec le ThreadPool, vous devrez utiliser Dispatcher.Invoke ou Control.Invoke pour marquer vos événements de progression et de terminaison sur le thread UI vous-même. Cependant, le ThreadPool vous permet de facilement mettre en file d'attente et d'exécuter autant de tâches que vous le souhaitez.

Answer 4

Je pense que vous devriez utiliser le pool de threads, car d'après ce que vous avez écrit, vous aurez encore plus de threads créés par les threads en arrière-plan.

Dans des conceptions comme celle-ci, j'ai vu le système surchargé par des milliers de threads. Un pool de threads est plus facile à gérer car vous avez un seul endroit pour définir des limites sur les threads. Certains travaux peuvent avoir besoin d'attendre avant de pouvoir accomplir leur tâche, mais c'est mieux que de surcharger l'ensemble du système.

Mise à jour:
Je ne savais pas cela, mais il semble que BackgroundWorker utilise le ThreadPool donc vous n'êtes pas en danger d'avoir un nombre explosif de threads. Le système que j'ai vu exploser avec des milliers de threads était écrit en C++.