ThreadPool overhead

  • Thread starter Thread starter DM
  • Start date Start date
D

DM

Hello.

I'm considering use of ThreadPool in my application.
However I'm concerned about an impact it may have. I believe
that calling a ThreadPool.QueueUserWorkItem would invoke a static
constructor that would start several threads. Because currently
there is only one place I can think of where TharePool would be
of any use for me and it would be used very rarely just to run
a thread for a simple task, I'm wondering if makes sense to keep
several threads just for one simple task.

Thanks for any suggestions.
 
The ThreadPool does not start several threads at once. It only starts one
every time you "ask" it to... It is built on the Threading.Timer (creating a
Timer with a period of 0 has exactly the same effect as QueueUserWorkItem).
ThreadPool is more convenient to use than explicitly creating threads (less
lines of code plus you can easily pass state)...

A threadpool thread -if it matches the desktop behaviour- after completing
the task, instead of terminating, it waits in case it can satisfy another
request.. After a "certain interval" the thread eventually dies...

Be aware that in CF 1.0 there is no limit of 25 like the full framework.
This means:
a) Porting a desktop design to the CF may produce different results
b) When CF 2.0 comes out you will have to retest/redesign your app if it
currently pushes the ThreadPool to its limits

In general use the ThreadPool for short lived background tasks (i.e. not for
tasks where blocking will occur)... In fact, I'd advise on explicitly using
threads only for the opposite scenario (i.e. when the task will be waiting
on some event etc).

Cheers
Daniel
 
Back
Top