In-Depth

.NET Survival Guide: Multi-Core and Parallel Development

• By Mark Michaelis
• 01/01/2011

Multi-Core and Parallel Development
In 2011 even low-end laptops come with two cores and, at the high end, eight and even 16 cores aren't uncommon. Similarly, you would be hard-pressed to find a server that didn't have at least support for two CPUs and a minimum of four cores in each CPU. In other words, the hardware today's applications run on include multiple processors by default. Despite this fact, programming languages today don't take advantage of the computing power implicitly. Whether you're writing a WPF application or a command-line console, the default is for your code to execute in a single thread. Admittedly, when hosting in IIS (or AppFabric), there will be multiple threads running for each session or call. Even so, any CPU-intensive task that your code engages in won't be multithreaded or executed asynchronously by default.

Although not implicitly invoked, the .NET Framework 4 provides significant improvement in the multithreading APIs available by introducing two entirely new API sets: Task Parallel Library (TPL) and Parallel LINQ (PLINQ). These APIs are so significant -- both in the usability of the API and in the underlying implementation improvements -- that access to the earlier .NET multithreading APIs (those from System.Threading) can essentially be ignored unless you're required to support legacy platforms or code. The only exception worth mentioning is the API call to System.Threading.Thread.Sleep, but even this should be avoided where possible, as the milliseconds parameter is unlikely to remain accurate across myriad machines.

TPL provides a new primary threading class called System.Threading.Tasks.Task that essentially replaces System.Threading.Thread for the vast majority of scenarios in the .NET Framework version 3.0 and 4. Even those running 3.0 have access to TPL and PLINQ through the unsupported release, by Microsoft, of the Reactive Extensions to

.NET. Similarly, PLINQ provides a compelling solution for executing LINQ to Objects (in memory queries that use LINQ with IEnumerable<t>l rather than a LINQ provider that implements queries with IQueriable<t>l). With only a call to the System.Threading.Tasks.ParallelEnumerable.AsParallel extension method, LINQ queries are transformed to run in parallel.

One question that surfaces is: Why don't the multithreaded APIs get invoked implicitly by the runtime or language compiler? The core reason is that there's still a fundamental programming problem around race conditions and dead-locks: multithreading bugs. Without intentional thread synchronization, the likelihood of these bugs occurring is too high. This, combined with the complexity involved in testing for and reproducing multithreading bugs, makes both language and API designers shy away from multithreading implicitly.

The .NET Framework 4 does provide some new collection classes that support synchronization by default, but the complexities around even just knowing when to use these collections in place of their non-threadsafe cousins is still a niche skill. The result is that TPL and PLINQ are fantastic additions to the .NET Framework 4, but caution is still called for, and developers must expend significant effort to do quality multithreaded programming.

In Summary
Task Parallel Library and Parallel LINQ are significant and important advancements in parallel programming, but the risks and challenges involved in creating multithreaded apps remains.