Copyright 2008-2009, Paul Jackson, all rights reserved
So, what does Joe know about Parallel Programming? Well, he’s the development lead, architect and founder of the Parallel Extensions to the .Net Framework team at Microsoft. The team that developed all the cool, new parallel stuff being built into .Net 4.0. That would be impressive enough, but he was also the developer for Parallel LINQ (PLINQ) and the concurrency program manager for the Common Language Runtime (CLR), so when it comes to multiple threads, we can assume Joe knows of what he speaks.
At 930 pages (not counting the index), Concurrent Programming on Windows is comprehensive on the subject (long), but the writing style is easy and flows well. The book is well-organized, with chapters taking the reader from the basics to more complex topics in a logical progression. If you’re new to concurrent programming, the layout ensures that the you’ll have the fundamental understanding necessary to understand new concepts as they’re introduced. For those more experienced with the topic, this makes it easy to find specific topics for review or reference.
Followed by appendices on Designing Reusable Libraries for Concurrent .Net Programs and the Parallel Extensions to .Net.
Of particular importance, I think, is Chapter 11 – Concurrency Hazards. I’m a firm believer that while the Parallel Extensions are going to make concurrent programming much more accessible for the average .Net developer, they’re also going to increase the accessibility of getting into threading trouble. The closer we get to the release of .Net 4.0, the more important it will be to educate developers new to threading on not just the cool new capabilities and the syntax to use them, but the dangers they’ll encounter in the parallel world.
The chapter on concurrency hazards does a good job of this, ending with a list of three significant events that were all caused by concurrency errors:
- Issues with the Mars Pathfinder mission. (priority inversion)
- The 2003 blackout of the northeast, midwest and Canada. (race condition)
- The Therac-25 radiation overdoses. (race condition)
Now most of us are writing line-of-business applications, so a concurrency defect in one of our applications isn’t going to impact a space mission, cause an international blackout or kill people, but it’s good to know the risks, possible consequences and, most importantly, how to avoid them.
The code examples in Concurrent Programming on Windows alternate between C++ and C#. For the most part this works and it lets the author choose the language that best demonstrates the technique or feature in question, but I found it a little disconcerting at times. Although I know both, there are places in the book where the example code alternates between one page and another and the constant need to transition was disruptive. On the other hand, to pick one language would have probably meant C++, as there are things that can’t be demonstrated in C# easily, so it’s something we should live with.
The book will also give the reader a good understanding of the differences between user-mode and kernel-mode with regard to threading, and the expense of transitioning to kernel-mode. This understanding is useful once the subject turns to the .Net Parallel Extensions and their design goal of keeping the application in user-mode as much as possible. It’s also useful in understanding the importance and utility of fibers, but fibers aren’t available in managed-code yet. Even so, I do recommend that .Net developers read the Fibers chapter. Why? Once enough managed-code developers see the utility of fibers and ask why we can’t have them in managed-code, we may get them.
Overall, Concurrent Programming on Windows is an excellent resource for Windows developers, regardless of their concurrent programming experience.