On Mon, 17 Nov 2008 02:20:01 -0800, Paul Hatcher
<Pa*********@discussions.microsoft.comwrote:
I have a small program which has a large (~50K) number of objects which
need
to do work.
I create a BackgroundWorker object and fire it off whenever each of the
instances needs to do work; this all works fine, but I'm not sure if I'm
using the class correctly.
Should have an internal limit on the number of BackgroundWorkers I fire
off,
or does the fact that it internally uses the ThreadPool anyway mean that
I
don't need to bother?
It depends on what your objectives are, as well as the specifics of the
activity of your objects (how often they start a new task, how long that
task takes, and whether the task is CPU-bound or not).
The thread pool adds a new thread every half second as long as there are
queued tasks waiting. If your tasks take that long or longer, or you are
queueing a large number of them at once, the thread pool could wind up
allocating a very large number of threads. If those threads are
CPU-bound, then that could indeed cause undue contention for the CPU.
If your tasks are not CPU-bound, or they take significantly less than a
half-second to complete and you won't have a lot of them active at once,
then using the thread pool (via BackgroundWorker or otherwise) is probably
fine. Otherwise, you may want to create your own work queue that you can
throttle, so as to avoid CPU contention.
Note that doesn't mean you have to forego using the thread pool...it just
means limiting the number of tasks concurrently assigned to the thread
pool at once. In fact, one possible approach would be to have the
RunWorkerCompleted event handler for the BackgroundWorker check your queue
and if there's something still to be executed, restart that same
BackgroundWorker with the new work item, avoiding the need to churn
BackgroundWorker instances.
Pete
