Should .Net 4.0 Tasks always be the preferred method for multi-threaded applications?

Question

I was reading about the Task Parallel Library and the article said:

In the .NET Framework 4, tasks are the preferred API for writing multi-threaded, asynchronous, and parallel code

But it also says they use the ThreadPool behind the scenes. What I'm having difficulty figuring out is if Tasks should only be used when you'd use a ThreadPool (and so "Thread versus Task" would be equivalent to "Thread versus ThreadPool"), or if Microsoft intended for Tasks to be used anywhere multiple threads are required, without the considerations inherent to the "Thread versus ThreadPool" dilemma.

So, should Tasks be used anywhere multiple threads are required?

Answer 1

The design advantage of using tasks is that you hand over the nitty-gritty of threading to the runtime, which presumably could accomplish the threading tasks using a less buggy, more optimal solution. I know certain Task-based paradigms, such as PLINQ, allow you to hint at which strategy the runtime should adopt, so that the question of "to Threadpool or not to Threadpool" could be handled directly.

The switch to this model is analogous to the switch to a Managed GC-ed language versus a language that requires you to clean up your own memory. There will always be arguments in favour of the latter, but Garbage Collection is getting so optimized now that it's practically a non-issue. Ideally, the runtime switching mechanism for Tasks will evolve and get better. So in theory, your application written and compiled for .NET 4 could get faster with better implementations of the runtime, without further recompilation. Also, threading code is notoriously hard to get right, so any mechanism that hides those details is good for the programmer.

Whether those benefits outweigh potential detriments, such as edge cases that the runtime doesn't deal with well, is something that should be considered case-by-case. I would certainly try to not optimize early here, though.