Technologies: Multithreading

The multicore "revolution" is upon us, and we're all going to have to adapt or die - at least those of us who have ambitions beyond the 8051! Unfortunately, writing threads is a pain in the ass. It's platform-specific, error-prone, and the most common interface (pthreads) is a steaming pile of...well, you get the point. Technology to the rescue!

The goal of multithreading technology, as usual for software, is to raise the level of abstraction. Instead of starting, joining, and stopping threads, locking mutexes, and signaling semaphores, you'd like to be able to express yourself at a higher level, like "run this operation in parallel". You don't want to have to worry about figuring out how many free processors the machine has, load-balancing your threads across those processors, synchronizing the processing results of your threads, etc etc ad nauseum.

The most common technology right now for high-level threading is OpenMP. This is an industry standard for extensions to the C and C++ languages, implemented by compilers. It's a fairly successful standard, in that most major compilers these days actually support it. It provides a small function library and a set of pragmas that allow you to specify the intended parallel behavior of your code, and then the compiler generates the threading behind the scenes.

An up-and-coming contender is Intel's Threading Building Blocks library. This is a pure library, with no compiler dependencies. By means of generic (template-based) classes in the style of the standard C++ library, it provides powerful parallel-processing primitives (sorry, couldn't resist the alliteration), and handles all the threading itself.

The common factor between these two technologies is that both of them relieve you of ever having to deal with threads directly, and both of them gracefully degrade to the single-threaded case, which is extremely useful for debugging ("let me turn off the threading and see if the bug still happens").

Conveniently enough, I recently had to rewrite some OpenMP code in TBB, which gave me a great chance to compare their strengths and weaknesses. Bottom line, OpenMP is easier and results in clearer code, as long as you're dealing with a fairly simple problem. TBB is much more powerful, and scales much better when your problem is not so simple. For example, here's the same code written both ways:

float a[100], b[100], c[100];
// ... initialize a and b

OpenMP

#pragma omp parallel for
for (int cnt = 0; cnt < 100; ++cnt)
c = a + b;

TBB

using namespace tbb;

classAdder {
const int myA, myB, myC;
public:
Adder(const int *a, const int *b, int *c) : myA(a), myB(b), myC(c) {}
void operator(const blocked_range& r) const {
for (int cnt = r.begin(); cnt != r.end(); ++cnt)
myC[cnt] = myA[cnt] + myB[cnt];
}
};

task_scheduler_init init;
parallel_for(blocked_range(0, 100), Adder(a, b, c), auto_partitioner());

A bit more complicated in the TBB case, no? However, all that complexity means that if I suddenly decide to change the for loop, say, to a do-while loop, it's pretty easy with TBB. With OpenMP, not so much - in fact, some very simple things (such as breaking out of a loop being executed in parallel) are virtually impossible. That's the price you pay for a simple syntax.

Overall, if all you want is to decompose a processing step using data parallelism, OpenMP is the better bet. However, as your problem becomes more complicated, you may find that you need to switch over to TBB for its greater expressiveness and power.