Most of us have read about the philosophers dining with insufficient chopsticks and the curved section of single-track railway in the mountain pass. These are the beginner examples of resource conflict and deadlock that serve as an introduction in comp sci texts to the challenges of parallel execution.

But they are coarse examples, and the world of multiprogramming today is very finely grained indeed.

Applications properly designed for multithreading on a single processor using all the approved locks and semaphors can still misbehave on multiple processors.Reasoning from first causes explains this phenomenon very neatly: Only on multiple processors can A == !A at the same slice of execution. This can never happen in the sequential emulation of parallel processing in which real-world application software evolved, but when two threads can genuinely execute simultaneously, an application can genuinely be in two states at once.

The assumption that your favorite threading library in all its various releases is parallel-safe is not a priori a warranted assumption. Theory can only produce software reliable to the degree the theory can be proven in tested execution. There is a great deal of library code in the world of the software development that is provably quite thread-safe but is not provably parallel-execution-safe.

Libraries and models explicitly designed for parallel execution are thus a good bet even for applications which are not notably parallel in their data processing model.

Erlang is very attractive for those who prefer a complete, self-contained theoretically consistent environment, as one reader posted recently. Perhaps more readily accessible to those of us wedded to more prevalent development languages (C++ of course) is Intel's compiler suite which features OpenMP support.

I will be working with tools such as the above-mentioned in exploring the brave new world of applications conscientiously targeted to multiple processor execution environments.