Question

I have an application which performs 30 independent tasks simultaneously using multithreading,
each task retrieves data over http, performs a calculation and returns a result to the ui thread.

Can I use TPL to perform the same tasks?

Does TPL create 30 new threads and spread them over all the available cores, or does it just split the tasks over the available cores and use one thread per core?

Will there be a performance boost using TPL over multithreading in this case?

Answer 1

I believe TPL will usually use one thread per core unless you specifically tell it to use more. It’s possible that it will detect when that’s not enough – e.g. in your case, where your tasks are going to spend most of their time waiting for data.

Is there any reason you can’t use asynchronous web fetching? I suspect there’s no need to have a thread per task or even a thread per core here. TPL makes various aspects of asynchronous programming easier, with things like continuations.

In terms of efficiency, is your application actually CPU bound? It sounds like you need to be getting the maximum appropriate level of parallelism at the network side – that’s the bit to concentrate on, unless the calculations are really heavyweight.

---

UPDATES – NOT FROM ORIGINAL AUTHOR

The answer above is great as always but could be misleading as it does not have some important changes in .NET 4.0 CLR.

As Andras says, current TPL implementation uses the thread pool hence will use as many threads as required (number of cores is irrelevant now):

The Task Parallel Library (TPL) is a collection of new classes
specifically designed to make it easier and more efficient to execute
very fine-grained parallel workloads on modern hardware. TPL has been
available separately as a CTP for some time now, and was included in
the Visual Studio 2010 CTP, but in those releases it was built on its
own dedicated work scheduler. For Beta 1 of CLR 4.0, the default
scheduler for TPL will be the CLR thread pool, which allows TPL-style
workloads to “play nice” with existing, QUWI-based code, and allows us
to reuse much of the underlying technology in the thread pool – in
particular, the thread-injection algorithm, which we will discuss in a
future post.

From:

Link