Have Geek Brain

Background workers or thread pools

I am trying to create an application that allows multiple searches while still using the UI to interact. For multiple search queries, I initially only had one search query working with user interaction, still capable of using a background worker to do this. Now I need to extend these functionality to allow more search functionality and basically just queue them. I'm not sure whether to use multiple background workers or use a threadpool as I want to know the progress of each search job at any time.

If I was using threadpool, then all I would do is add this in a loop that gets called every time a search request is made

 ThreadPool.QueueUserWorkItem(AddressOf Search)

but if using background workers this is the only way I know how and I cant add them to anything except perhaps to the arraylist and I can call reportprogress from each bgw.

change:

so for example this is my current code

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

so in the above codes, the links and posts are arraylists that I use to get the urls I want and they are used for different lookups and initially I had synclock on links and posts but someone else told me to use synclock me instead So from your point of view, I have to assign a separate data control to each search control and, after enough time, block the corresponding one and pass it to write it. thanks

+2


a source to share


4 answers


I generally leave the threadpool alone. It is a multi-process resource that can be customized to different sizes, especially in webapps. However, since your application is like a client form application, you will not be sharing the file stream with any other applications, and you can customize it to your needs.



Your use case suits the threadpool better than most, but there isn't much of a benefit to that.

+1


a source


You can still get progress updates with BackgroundWorkers, so I see no reason to stop using them.



The BackgroundWorker itself uses a thread pool to recycle threads AFAIK. This way you can still possibly limit the size of the pool and keep using BW.

+1


a source


You can use ThreadPool just like you use BackgroundWorker.

The only difference is that with ThreadPool you will need to use Dispatcher.Invoke or Control.Invoke to marshal your progress and completion events to the UI itself. However, ThreadPool allows you to easily queue up and run as many tasks as you like.

+1


a source


I think you should use a thread pool because from what you wrote you will have even more threads spawned by background threads.

In such constructions, I saw that the system is overloaded with thousands of threads. The thread pool is easier to manage because you have one place to set thread limits. Some jobs may have to wait before they can do their job, but this is better than overloading the entire system.

Update:
I didn't know about this, but it looks like the BackgroundWorker uses a ThreadPool, so you're not in danger of exploding threads. The system I have encountered with thousands of threads was written in C ++.

+1


a source






More articles:


All Articles