1

Possible Duplicate:
Advantage of using Thread.Start vs QueueUserWorkItem

If i want to execute a method through a thread ,so i usually use System.Thread like this

 Thread th = new Thread(Test_Progress);
 th.Start();

but my colleague told me that using the ThreadPool.QueueUserWorkItem like the following is better

ThreadPool.QueueUserWorkItem(new WaitCallback(Test_Progress),(object)true );

So is there any difference like performance and how the it's handled ??

Community
  • 1
  • 1
Sara S.
  • 1,365
  • 1
  • 15
  • 33
  • 2
    This might help: http://stackoverflow.com/questions/684640/advantage-of-using-thread-start-vs-queueuserworkitem – codefrenzy Sep 15 '11 at 08:32

3 Answers3

3

Threads are expensive objects to create, using the threadpool is a better way of performing quick work on a separate thread without having to deal with the full cost of creating a new thread.

Additionally, you want to make sure you're not performing a very long executing operation on a pool thread, because you can exhaust the pool's limited number of threads.

You should read the MSDN documentation about the threadpool located here: http://msdn.microsoft.com/en-us/library/0ka9477y.aspx

It will explain some things to keep in mind when trying to decide what to use.

Ryan Stecker
  • 828
  • 13
  • 25
  • Thank you Ryan , actually i use it to save a series of images so i guess it's a long operation, isn't it? – Sara S. Sep 16 '11 at 21:59
2

ThreadPool is pool (collection) of threads and using it will pick a thread from this pool and execute your method inside that thread where as Thread object created new Thread. This is a general concept around Object pooling i.e when in your application you need to use several objects one option is to create a pool of those object and pick object from this pool use it and then put back it in pool, this is done in those cases where the object creation is expensive and this also leads to better scalability. In case of threads if your application creates many threads then it will crawl very slowly because of context switching hence it is prefered to use Thread pool. Another example of same concept is SQL Connection pool.

Ankur
  • 33,367
  • 2
  • 46
  • 72
  • ok, what about terminating the threads are they treated the same way by the application? – Sara S. Sep 15 '11 at 08:52
  • 1
    Nope, in a thread pool you dont terminate the thread, as soon as your passed delegate returns the thread is returned back to thread pool. It is the responsibility of thread pool to manage threads and related operations – Ankur Sep 15 '11 at 08:54
  • 1
    @Sara You shouldn't EVER terminate a thread, if by "terminate" you mean "Thread.Abort()". If you mean "what happens when a tread ends its work" then the response of Ankur is perfect. – xanatos Sep 15 '11 at 11:43
  • (Clear I meant tHread and not tread :-) ) – xanatos Sep 15 '11 at 12:05
1

If you have lots of short running tasks use a thread pool. If you have only few and long running tasks, usage of threads is better.

Usage of threads enables you to have more fine control over your tasks, in contrast usage of tread pool can make things easier.

codymanix
  • 28,510
  • 21
  • 92
  • 151