C# - ThreadPool vs Tasks

As some may have seen in .NET 4.0, they've added a new namespace System.Threading.Tasks which basically is what is means, a task. I've only been using it for a few days, from using ThreadPool.

Which one is more efficient and less resource consuming? (Or just better overall?)

The objective of the Tasks namespace is to provide a pluggable architecture to make multi-tasking applications easier to write and more flexible.

The implementation uses a TaskScheduler object to control the handling of tasks. This has virtual methods that you can override to create your own task handling. Methods include for instance

protected virtual void QueueTask(Task task)
public virtual int MaximumConcurrencyLevel

There will be a tiny overhead to using the default implementation as there's a wrapper around the .NET threads implementation, but I'd not expect it to be huge.

There is a (draft) implementation of a custom TaskScheduler that implements multiple tasks on a single thread [here][1].

[1]: http://msdn.microsoft.com/en-us/library/dd997413(VS.100).aspx "here"

> which one is more efficient and less > resource consuming?

Irrelevant, there will be very little difference.

> (Or just better overall)

The Task class will be the easier-to-use as it offers a very clean interface for starting and joining threads, and transfers exceptions. It also supports a (limited) form of load balancing.

"Starting with the .NET Framework 4, the TPL is the preferred way to write multithreaded and parallel code."

http://msdn.microsoft.com/en-us/library/dd460717.aspx

Thread

The bare metal thing, you probably don't need to use it, you probably can use a LongRunning Task and benefit from its facilities.

Tasks

Abstraction above the Threads. It uses the thread pool (unless you specify the task as a LongRunning operation, if so, a new thread is created under the hood for you).

Thread Pool

As the name suggests: a pool of threads. Is the .NET framework handling a limited number of threads for you. Why? Because opening 100 threads to execute expensive CPU operations on a CPU with just 8 cores definitely is not a good idea. The framework will maintain this pool for you, reusing the threads (not creating/killing them at each operation), and executing some of they in parallel in a way that your CPU will not burn.

OK, but when to use each one?

In resume: always use tasks.

Task is an abstratcion, so it is a lot easier to use. I advise you to always try to use Tasks and if you face some problem that makes you need to handle a thread by yourself (probably 1% of the time) then use threads.

BUT be aware that:

• I/O Bound: For I/O bound operations (database calls, read/write files, APIs calls, etc) never use normal tasks, use LongRunning tasks or threads if you need to, but not normal tasks. Because it would lead you to a thread pool with a few threads busy and a lot of another tasks waiting for its turn to take the pool.
• CPU Bound: For CPU bound operations just use the normal tasks and be happy.

Scheduling is an important aspect of parallel tasks.

Unlike threads, new tasks don't necessarily begin executing immediately. Instead, they are placed in a work queue. Tasks run when their associated task scheduler removes them from the queue, usually as cores become available. The task scheduler attempts to optimize overall throughput by controlling the system's degree of concurrency. As long as there are enough tasks and the tasks are sufficiently free of serializing dependencies, the program's performance scales with the number of available cores. In this way, tasks embody the concept of potential parallelism

As I saw on msdn http://msdn.microsoft.com/en-us/library/ff963549.aspx

ThreadPool and Task difference is very simple. To understand task you should know about the threadpool.

> ThreadPool is basically help to manage and reuse the free threads. In > other words a threadpool is the collection of background thread.

Simple definition of task can be:

> Task work asynchronously manages the the unit of work. In easy words > Task doesn’t create new threads. Instead it efficiently manages the > threads of a threadpool.Tasks are executed by TaskScheduler, which queues tasks onto threads.

Another good point to consider about task is, when you use ThreadPool, you don't have any way to abort or wait on the running threads (unless you do it manually in the method of thread), but using task it is possible. Please correct me if I'm wrong