Prologue
Every .NET framework version surprises us with a bunch of new features, and for each of us there’s at least one that steals our heart. It happened to me with the introduction of Generics in framework 2.0, extension methods and LINQ in versions 3.0 and 3.5, and it happened again with the Task Parallel Library in version 4.0.
Thinking about it carefully, it’s not that weird actually. After all, I’ve always been drawn to asynchronous programming (something that if you told any of my early computer science teachers, they would’ve died laughing). However, over the years, this guy has managed - more through stubbornness than natural talent - to get to know a bit about the ins and outs of async programming. It’s a discipline where knowing what to do is just as important as knowing what NOT to do.
So when I got my hands on the first preview of Visual Studio 2010, one of the first things I did was check out what the hell this Task Parallel Library thing was all about. First, because I’d been hearing for a while about the predicted death of Moore’s law. And second, because anything that would make the job of building and debugging multithreaded applications easier was going to be more than welcome.
Since then, I’ve been lucky enough to dedicate some time to this marvel, so I’ve decided to create a pretty long series of posts on the topic. Mainly because I think there’s not enough documentation out there, and something this cool can’t just be forgotten. The thing is, on countless occasions when I explain to someone why the TPL is important and what it’s all about, they usually say: “That’s awesome! I had no idea…” And that just kills me.
The Birth of the Parallel Series
In the upcoming posts, I’ll be defining the table of contents for the series, though as the series grows it’s more than likely to be modified and expanded. We’ll also look at some history to put things in context, clarify basic concepts that we’ll need later on, and break down the main components of the Task Parallel Library.
The idea is to start from the bottom and work our way up, until we reach the more complex aspects like concurrency problems or debugging these types of applications. In each section, I promise to include at least one example, and more if I can, because us humans - and developers inherit from this base class - learn theoretical concepts much better when they come with hands-on practice.
See you very soon ;-)
Coming up next… In the next post we’ll review the history of parallel programming and see how we got here.
Resistance is futile.