.NET Thread Pool - Unresponsive WinForms UI

Question

Scenario

I have a Windows Forms Application. Inside the main form there is a loop that iterates around 3000 times, Creating a new instance of a class on a new thread to perform some calculations. Bearing in mind that this setup uses a Thread Pool, the UI does stay responsive when there are only around 100 iterations of this loop (100 Assets to process). But as soon as this number begins to increase heavily, the UI locks up into eggtimer mode and the thus the log that is writing out to the listbox on the form becomes unreadable.

Question

Am I right in thinking that the best way around this is to use a Background Worker? And is the UI locking up because even though I'm using lots of different threads (for speed), the UI itself is not on its own separate thread?

Suggested Implementations greatly appreciated.

EDIT!!

So lets say that instead of just firing off and queuing up 3000 assets to process, I decide to do them in batches of 100. How would I go about doing this efficiently? I made an attempt earlier at adding "Thread.Sleep(5000);" after every batch of 100 were fired off, but the whole thing seemed to crap out....

Answer 1

More threads does not equal top speed. In fact too many threads equals less speed. If your task is simply CPU related you should only be using as many threads as you have cores otherwise you're wasting resources.

With 3,000 iterations and your form thread attempting to create a thread each time what's probably happening is you're maxing out the thread pool and the form is hanging because it needs to wait for a prior thread to complete before it can allocate a new one.

Apparently ThreadPool doesn't work this way. I've never choked it with threads before so I'm not sure. Another possibility is that the tasks begin flooding the UI thread with invocations at which point it will give up on the GUI.

Answer 2

It's difficult to tell without seeing code - but, based on what you're describing, there is one suspect.

You mentioned that you have this running on the ThreadPool now. Switching to a BackgroundWorker won't change anything, dramatically, since it also uses the ThreadPool to execute. (BackgroundWorker just simplifies the invoke calls...)

That being said, I suspect the problem is your notifications back to the UI thread for your ListBox. If you're invoking too frequently, your UI may become unresponsive while it tries to "catch up". This can happen if you're feeding too much status info back to the UI thread via Control.Invoke.

Otherwise, make sure that ALL of your work is being done on the ThreadPool, and you're not blocking on the UI thread, and it should work.

Answer 3

If you are creating 3000 separate threads, you are pushing a documented limitation of the ThreadPool class:

If an application is subject to bursts of activity in which large numbers of thread pool tasks are queued, use the SetMinThreads method to increase the minimum number of idle threads. Otherwise, the built-in delay in creating new idle threads could cause a bottleneck.

See that MSDN topic for suggestions to configure the thread pool for your situation.

If your work is CPU intensive, having that many separate threads will cause more overhead than it's worth. However, if it's very IO intensive, having a large number of threads may help things somewhat.

.NET 4 introduces outstanding support for parallel programming. If that is an option for you, I suggest you have a look at that.

Answer 4

If every thread logs something to your ui, every written log line must invoke the main thread. Better to cache the log-output and update the gui only every 100 iterations or something like that.

Answer 5

Since I haven't seen your code so this is just a lot of conjecture with some highly hopefully educated guessing.

All a threadpool does is queue up your requests and then fire new threads off as others complete their work. Now 3000 threads doesn't sounds like a lot but if there's a ton of processing going on you could be destroying your CPU.

I'm not convinced a background worker would help out since you will end up re-creating a manager to handle all the pooling the threadpool gives you. I think more you issue is you've got too much data chunking going on. I think a good place to start would be to throttle the amount of threads you start and maintain. The threadpool manager easily allows you to do this. Find a balance that allows you to process data while still keeping the UI responsive.