The challenge of concurrency

This month’s copy of ACM Queue has got a really amazing interview in it with John Hennessy and David Patterson, authors of the very popular textbook, "Computer Architecture: A Quantitative Approach"

"...From my perspective, parallelism is the biggest challenge since high-level programming languages. It’s the biggest thing in 50 years because industry is betting its future that parallel programming will be useful.

Industry is building parallel hardware, assuming people can
use it. And I think there’s a chance they’ll fail since the software is
not necessarily in place. So this is a gigantic challenge facing the
computer science community. If we miss this opportunity, it’s going to be bad for the industry.

Imagine if processors stop getting faster, which is not impossible. Parallel programming has proven to be a really hard concept. Just because you need a solution doesn’t mean you’re going to find it." - David Patterson

I find this quote extremely interesting because it never occurred to me that the software development community would not rise to the challenge. While I agree that it is a major paradigm shift for many developers, there are pockets of developers who have been building parallel applications for years. I suppose one of the key questions is, can we help our colleagues make the shift?

I agree with Dr. Patterson’s statement that parallel programming is hard. Engineers are required to really know the systems that they are building software on and the tools they are using. As I’ve traveled around giving my presentation on concurrent software development, I’ve found that there are a large number of developers that are not aware of what is really happening in their code. These developers are accustomed to using only the high-level languages they commonly write in and rarely, if ever, dig down into the real bits and bytes that are actually being executed. This lack of low-level knowledge handicaps them when it comes time to track down multi-threading bugs. Remember that threads are a kernel tool and while high-level languages wrap threads to fit their development paradigm, you can’t escape the reality that they are still kernel tools.

"Hey, the world has changed. The La-Z-Boy approach isn’t going to work anymore. You can’t just sit there, waiting for your single processor to get a lot faster and your software to get faster, and then you can add the feature sets. That era is over. If you want things to go faster, you’re going to have to do parallel computing." - David Patterson

There are a lot of folks working on the problem of making concurrent software development easier. By defining technologies and standards: OpenMP, MPI; parallel languages; and new products: Digipede Framework SDK, Intel Threading Analysis Tools, Coverity’s Concurrency Defect Manager.

But at the end of the day the important thing is that people are learning how to think in parallel. Whichever tools they decide to use, right now, isn’t as important as the journey that they are going on. Because if they were paying attention...when they come out the other side they will have a natural and intuitive understanding of how to add concurrency to their applications.

As a developer and an optimist, I'm going to hope that we succeed at this and I'll continue to do my part to help that happen. But we will fail if the engineering community doesn't wake up and realize that times have changed. We have to put a little more thought and effort into adding concurrency to our applications; we have to learn.