.NET Framework Parallel Programming Design Patterns

Physics and new microprocessor architectures are forcing .NET developers to tackle Parallel Programming and rethink how they build responsive applications. My previous article, New C# and VB.NET Async language features, built on the Task Parallel Library (TPL) will eventually supplant the exiting Asynchronous Programming model and TPL will permeate all areas in the .NET Framework.

.NET developers trying to understand the new Parallel Programming classes and concepts face some challenges. For many .NET developers the greatest challenge is understanding conventions and patterns around the new technologies.

There is a buffet of Parallel Programming patterns and conventions documentation. A good approach to digesting all the available information is to ingest a little bit at a time. Developers looking for a Parallel Programming Patterns and Conventions appetizer will find it in this article.

Starting with Patterns

Narrowing a TPL Pattern introduction is not easy. Applications can leverage TPL in a variety of ways and application architecture can assume many forms. Still there is a core set of patterns that a developer will consider no matter the architecture. Below is a summary of the core patterns. Each will be examined in this article.

Shared State is the Parallel Pattern most developers are already familiar with. Concurrency requires disciplined access to shared data structures.

Parallel Loops are an easy way to leverage the Task Parallel Library. Parallel loops look a lot like regular loops. As you may have guessed there are differences, and usage requires understanding the differences.

Producer/Consumer is a pattern most developers will be familiar with when introduced to it.B Some objects create other objects and some objects consume objects (some objects do both). Often operating on objects or producing objects will leverage components like the .NET ThreadPool. Aside from components for executing work, TPL includes data structures for mediating between producers and consumers.

When tapping Concurrency for the first time, Shared State is the first pattern most developers will deal with so it's the first Pattern covered.

Shared State

As mentioned earlier, concurrency requires disciplined access to shared data structures. There are three basic ways a developer works with shared data structures.

Synchronization is managing access using things like mutexes or monitors. The sample code below demonstrates one of these techniques.

Immutability is somewhat new to.NET developers. Most developers are accustomed to passing references around an application. Truly immutable data never changes once it is initialized and references are avoided. Instead, operating on data structures requires making or cloning a copy. Immutable classes work a lot like the String class. String classes are mostly immutable. String methods return a copy of a completely different string rather than a mutated version of the existing string.

Synchronization and immutability can be thought of as the two extremes. Isolation exists between the two. There are a number of ways a developer can implement isolation. One common way is to take an Agent based approach to Concurrency and pass messages (chunks of data) between Agents executing their work on a ThreadPool. Task Parallel Library Dataflow is a library suited to implementing the message/Agent based approach to isolation.

As you may have guessed there are tradeoffs between each approach. Synchronization can create contention and bottlenecks in concurrent code. Immutable data structures may not be practical. Isolation can be hard to achieve.

For developers who are new to the Task Parallel Library, parallel loops are a good place to start introducing concurrency. As you can see, the coding conventions are already familiar. The most important part of understanding Parallel loops is understanding that each iteration must be independent.

Each iteration is dispatched onto the ThreadPool much like the graphic below depicts.

Figure 1: Looping iterations

When running the sample code above, one surprising outcome is the output doesn't execute in an ordered fashion. Later parts execute before earlier parts. Yet, the loop doesn't terminate until all iterations have executed.

Parallel Loops fall under another pattern category called Fork/Join.

By far, the most common TPL Pattern is the Producer/Consumer.

Producer/Consumer

Producer/Consumer assumes many faces; though every implementation will follow these guidelines.

A class or group of classes creates data structure instances.

Another class or group of classes consumes instances.

Some form of channel or mediation exists between producers and the consumers. Often the mediation is a queue-based data structure.

Pipelines (another pattern) are often a series of Producer/Consumers strung together. I always think of Pipelines and the Producer/Consumer as a sort of assembly line. Producer/Consumer is probably the most common TPL pattern. For example: the ThreadPool/TaskScheduler is implemented using a Producer/Consumer pattern.

Conclusion

Shared State, Parallel Loops, and Producer/Consumer Patterns are just a few Parallel Patterns that leverage the Task Parallel Library. This article gives a developer a taste of the Patterns that must be mastered. For further study, delve into the resources at the end of this article.

About the Author

Jeffrey Juday

Jeff is a software developer specializing in enterprise application integration solutions utilizing BizTalk, SharePoint, WCF, WF, and SQL Server.
Jeff has been developing software with Microsoft tools for more than 15 years in a variety of industries including: military, manufacturing, financial services, management consulting, and computer security.
Jeff is a Microsoft BizTalk MVP.
Jeff spends his spare time with his wife Sherrill and daughter Alexandra.

Top White Papers and Webcasts

When individual departments procure cloud service for their own use, they usually don't consider the hazardous organization-wide implications. Read this paper to learn best practices for setting up an internal, IT-based cloud brokerage function that service the entire organization. Find out how this approach enables you to retain top-down visibility and control of network security and manage the impact of cloud traffic on your WAN.

U.S. companies are desperately trying to recruit and hire skilled software engineers and developers, but there is simply not enough quality talent to go around. Tiempo Development is a nearshore software development company. Our headquarters are in AZ, but we are a pioneer and leader in outsourcing to Mexico, based on our three software development centers there. We have a proven process and we are experts at providing our customers with powerful solutions. We transform ideas into reality.