Advantage of Using Thread.Start VS Queueuserworkitem

Advantage of using Thread.Start vs QueueUserWorkItem

The ThreadPool is always there, however, there are a finite number of threads allocated to the pool based on the number of processors. For ASP.NET applications, it is generally a bad idea to use Threads unless you really are starting off an Async process and know that there won't be a large number of requests (remember that there are a finite number of threads in the ThreadPool which you share with everything running in your AppDomain and there is a realistic limit on the total number of threads you want to create using new Thread() as well).

For WinForms apps consider using the BackgroundWorker instead of using a Thread or the ThreadPool. It uses the ThreadPool, however, it makes communicating between threads easier on the multi-thread savvy programmer.

Updated

Avoid using ThreadPool.QueueUserWorkItem as your app pool could disappear at any time. Move this work outside or use WebBackgrounder if you must.

From Hanselman.com - "Checklist: What NOT to do in ASP.NET"

Thread.Start() versus ThreadPool.QueueUserWorkItem()

Starting a new thread can be a very expensive operation. The thread pool reuses threads and thus amortizes the cost. Unless you need a dedicated thread, the thread pool is the recommended way to go. By using a dedicated thread you have more control over thread specific attributes such as priority, culture and so forth. Also, you should not do long running tasks on the thread pool as it will force the pool to spawn additional threads.

In addition to the options you mention .NET 4 offers some great abstractions for concurrency. Check out the Task and Parallel classes as well as all the new PLINQ methods.

what is the difference between using ThreadPool.QueueUserWorkItem and using System.Thread?

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.

Force ThreadPool to start the thread sooner

First off, QueueUserWorkItem doesn't create a thread, it merely places a "task" in the ThreadPool's queue for the workers to pick up and execute. In case of saturation (more tasks than available threads), there is no guarantee of when a worker will become available to execute the task. If you want immediate execution use an instance of Thread instead. The only way to improve your odds with the ThreadPool is to increase the number of workers.

Edit: Just to be clear, if thread pool threads are indeed free, they will pick up work and execute it usually faster than starting a fresh thread.

multithreading using threadPool or new thread() in server app

Spawning a thread is a very costly and therefore high-latency operation. If you want to manage threads yourself, which would be reasonable but not required, you have to build a custom pool.

Using thread pool work items is not without danger because it does not guarantee you a concurrency level of 4. If you happen to get 2 or 3 you will have much more latency in your HTTP request.

I'd use the thread-pool and use SetMinThreads to ensure that threads are started without delay and that there are always enough.

Difference between ThreadPool.QueueUserWorkItem and Parallel.ForEach?

The main difference is functional. Parallel.ForEach will block (by design), so it will not return until all of the objects have been processed. Your foreach queuing threadpool thread work will push the work onto background threads, and not block.

Also, the Parallel.ForEach version will have another major advantages - unhandled exceptions will be pushed back to the call site here, instead of left unhandled on a ThreadPool thread.

In general, Parallel.ForEach will be more efficient. Both options use the ThreadPool, but Parallel.ForEach does intelligent partitioning to prevent overthreading and to reduce the amount of overhead required by the scheduler. Individual tasks (which will map to ThreadPool threads) get reused, and effectively "pooled" to lower overhead, especially if SendFilesToClient is a fast operation (which, in this case, will not be true).

Note that you can also, as a third option, use PLINQ:

objClientList.AsParallel().ForAll(SendFilesToClient);

This will be very similar to the Parallel.ForEach method in terms of performance and functionality.

Difference between Thread, ThreadPool & BackgroundWorker

but i do not understand what is the difference between calling any method with the help of thread class or ThreadPool class

The main difference is whether you manage the thread lifetime yourself (Thread), or you take advantage of the "pool" of threads the framework already creates.

Using ThreadPool.QueueUserWorkItem will (often) use a thread that already exists in the system. This means you don't have the overhead of spinning up a new thread - instead, a set of threads is already there, and your work is just run on one of them. This can be especially beneficial if you're doing many operations which are short lived.

When you use new Thread, you actually spin up a new thread that will live until your delegate completes its execution.

Note that, as of .NET 4 and 4.5, I'd recommend using the Task and Task<T> types instead of making your own threads, or using ThreadPool.QueueUserWorkItem. These (by default) use the thread pool to execute, but provide many other useful abstractions, especially with C# 5 and the await/async keywords.

now also tell me what is BackgroundWorker class and how it is different from Thread & ThreadPool class. h

The BackgroundWorker class is an abstraction over the thread pool. It uses the ThreadPool to queue up "work" (your DoWork event handler), but also provides extra functionality which allows progress and completion events to be posted back to the initial SynchronizationContext (which, in a GUI program, will typically be the user interface thread). This simplifies tasks where you want to update a UI for progress or completion notifications as background "work" is running on a background thread.

---

Related Topics