At times it seems that Intel is playing the part of Chicken Little (from the fable, not the movie) by running around endlessly pushing the "Multithreading is necessary!" mantra.

The other day, Henny Penny, Cocky Locky, and I were rushing around chatting up all the advantages of threading applications to Turkey Lurkey, Goosey Poosey, and anyone else that would listen. When we passed by the Little Red Hen's house, I stopped to smell the freshly baking bread. As I paused there, I remembered the old saying "If all you have is a hammer, everything looks like a nail."

This is a pretty good description of what we appear to be doing now. With multi-core processors, we've been pushing multithreading as the "end all, be all" solution that everyone needs to get on board with or be left behind. Multithreading is this group of hammers, and the software that's out there is just one big, endless field of nails. However, not everything can be made to run in parallel.

My favorite counter-example to illustrate this is a pregnant woman. It takes nine months from conception to birth. Putting 9 women on the job won't allow us to deliver the child in one month. This is an inherently serial process.

So, here's a radical idea: Instead of trying to figure out where threading could be used in your code, try to prove that your code can't be made to run in parallel. The latter may be an easier task that the former. If you can point out the data dependencies or the lack of any potentially concurrent execution, you save yourself all that time and headache from banging your head against the wall trying to accomplish one more impossible thing before breakfast. (A colleague of mine uses this approach, especially for application areas that have, in the past, been shown to not be amenable to threading.)

On the other hand, if you can't show that the code is not parallelizable, approaching it from this end may give you a new perspective, working your way from both sides of the problem to a common middle and, consequently, a threaded app. Finding ways to overcome code that appears inherently serial by reordering loops or shifting variable declarations or replacing entire algorithms with an equivalent ones more amenable to threads, gives you insight into the parallel possibilities and realities of your applications.

Don't get blindly sucked in by Chicken Little's schtick. Approach with caution and see where she can take you. Sometimes the sky is falling and you need to get with the program; other times, it's all just a false alarm and you'll just end up running around or end up in Foxy Loxy's stew pot.

--clay

(Props to Charles Congdon, who used the "nail" analogy before I had the chance to post this entry.)

The opinions expressed by me on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries.