Even though Microsoft has been working on .NET’s Parallel Extensions since 2007, there are still many features that they didn’t have time to fully implement for .NET 4.0. Some features were “too application-specific to be included in the core of the Framework” while others simply needed for testing and user feedback. Stephen Toub continues,
Luckily, in the vast majority of these cases, we’ve been able to build this functionality on top of the parallelizatino constructs provided in .NET 4, in some cases simply containing .NET 4 types and methods, and in other cases taking advantage of extensibility points provided in .NET 4 for the explicit purpose of enabling developers to provide their own customized functionality where the Framework leaves off. Over time, we’ve amassed a wealth of code of this ilk, and we’ve chosen to expose most of it through the ParallelExtensionsExtras project available as part of our .NET 4 samples, which can be downloaded at http://code.msdn.microsoft.com/ParExtSamples.
The code samples cover a wide range of functionality. Some of the highlights include:
An IProducerConsumerCollection implementation for the BlockingCollection wrapper. This interface is for thread-safe collections in traditional producer/consumer scenarios. This wasn’t included in .NET 4.0 because the correct semantics for a BlockingCollection version could vary depending on the application’s needs.
For working with COM components that require single-threaded apartments there is the StaTaskScheduler. The base version of the StaTaskScheduler is pretty simple, it simply spins up a predefined number of STA threads and waits for tasks to perform. A suggested variant is to use thread-local storage to instantiate one instance of a COM object for each worker thread.
For those interested in the Reactive Extensions Framework, there is the Task.ToObservable extension method. This allows a subscription to be attached to the result of a Task. If the subscription is dropped before the task is completed, then the task will be cancelled.
A rather complex scenario is the ReductionVariable. This contains a set of values, one per instance per thread, for use in reduction operations. Based on thread-local storage, it requires very little synchronization between worker threads and thus scales up well. Once the reduction operation is complete, the values can be enumerated over to generate the final result.