5.9. Danny Shih

I talked to Danny Shih (program manager on parallel extensions for the .NET team) about his thoughts on the parallel extensions:

The underlying architecture of the Task Scheduler changed during development to use the thread pool; can you say a bit more about this decision?

Our managed scheduler (on which TPL was originally built) and the ThreadPool basically served the same purpose, and in Dev10, the two teams were working on different enhancements. The ThreadPool team was working on things like hill-climbing (an algorithm to determine and adjust to the optimal number of threads for a given workload), and we had added things like work-stealing queues to our managed scheduler. So to avoid duplicating code and to take advantage of all new enhancements, we wanted to either build the ThreadPool on TPL or build TPL on the ThreadPool. For various reasons, we took the latter approach.

What do you see as the potential pitfalls when using the new parallel enhancements?

I think the major one is adding parallelism to an application when it's unsafe to do so. New APIs like Parallel.For() make it extremely easy introduce concurrency, both correctly and incorrectly. A common scenario is parallelizing a serial loop that has iterations that depend on other iterations (possibly resulting in deadlock) or that has iterations that access shared state without synchronization (possible race conditions resulting in incorrect results).

Where do you see the .NET parallelization/threading APIs heading in the future?

In future versions, we're definitely trying to refine our APIs (adding stuff we think we missed, mainly). We're also discussing cluster and GPG support, but there's nothing to announce there yet.