It’s been eight years since simultaneous multithreading first appeared in popular processors, when Intel shipped it under the name of Hyper-Threading Technology. Since then, numerous companies have been trying to figure out how to get developers to leverage multiple threads on the desktop, whether in a single CPU or in the now-common multicore processor.

If you have paid no attention to this area during these intervening eight years, you have missed almost nothing—a rare assessment of any technology sector’s progress. Numerous attempts to make multiple threads easier for developers to tame met little interest and even less traction. As a result, only general directions for future advances have come into focus.

There is wide agreement on the limitations of the traditional mainline approach of manual thread management, which relies on a panoply of burdensome techniques: individual threads, mutual exclusion, locks, signals and so forth. These tools work (they are still the primary tool box), but they create situations that are difficult to develop for and, at times, nearly impossible to debug.

One of the problems in debugging is the inability to recreate the exact state of the machine necessary to duplicate a bug. As a result, it’s also difficult to do exhaustive testing of threaded code to ensure that no undesirable interactions among threads are occurring.

Intel is probably the vendor that has most worked in this area, by delivering a set of tools that can examine code, look for places where threads might interact incorrectly, and flag them for the developer. It also sells a C++ platform that diminishes some of the hard manual effort in coding. In addition, Intel offers a thread-safe C++ template library, the Intel Threading Building Blocks, that provides high-level functions for thread management.

Earlier, Intel was an active supporter of OpenMP, a multivendor-sponsored library with C, C++ and Fortran interfaces that very effectively hide thread management. In its principal usage model (although other approaches are widely used), developers mark off parts of their code to be run in parallel, and OpenMP executes them in parallel in the background without further involvement by the developer’s code. While OpenMP takes away some of the headaches, its benefit occurs in programs that alternate between serial and parallel sections. Programs that are mostly parallel, or that are decomposed along functional lines, get less lift from OpenMP.

About Andrew Binstock