If I use the ThreadPool in a nested way, my application hangs:
ThreadPool.QueueUserWorkItem((state) =>
ThreadPool.QueueUserWorkItem(Action));
How to get a second and independent ThreadPool to achieve nesting?
Parallel. For will use all the thread pool threads by default, and the number of thread pool threads is optimized for your cpu(s).
Thread pools do not make sense when you need thread which perform entirely dissimilar and unrelated actions, which cannot be considered "jobs"; e.g., One thread for GUI event handling, another for backend processing. Thread pools also don't make sense when processing forms a pipeline.
A thread pool is - as the name suggests - a pool of worker threads which are always running. Those threads then normally take tasks from a list, execute them, then try to take the next task. If there's no task, the thread will wait.
There is only one single ThreadPool - it's not something you can (or should) make more than one instance of in an application.
I don't recommend doing this, but if you really wanted to, you could use multiple instances of your own ThreadPool implementation, such as SmartThreadPool. This would, technically, allow separate "thread pools".
However, I suspect you're hanging due to a deadlock, not due to the ThreadPool usage. I would investigate where you're getting the hangs. The VS2010 concurrency visualizer is very nice for this, if you have a copy of the VS 2010 beta installed.
Your application is probably hanging because you are filling it up to the point where all of the active threads are waiting on queued threads. (I assume the original thread is waiting for the work item(s) it queues to complete.)
The ThreadPool has by default 25 * (number of CPUs) worker threads (IIRC).
You probably want to rework the way you're queuing items. If you're queuing them up and then finishing and exiting the thread, you're fine, but having work items hanging around waiting on other processes is generally a bad design; if that's what you're doing you probably need to use real threads or a completely different design. Using real threads is probably an equally bad idea because all that will do (based on what I can surmise of your usage) you'll just create a large number of threads, which will do nothing good for your performance.
A better design might be to have some kind of queue or stack that a few (2-4 depending on number of CPUs) worker threads add items to and pop items off to work. If an item needs to queue a new item it just adds it to the stack (and adds itself back to the stack with some kind of dependency tracking if it needs to wait for the other item).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With