By Robert B.K. Dewar
The recent introduction of multicore architectures has caused a surprising amount of uproar. Multiprocessing has been around for decades. The original CDC 6000, for instance, was an interestingly designed multiprocessor machine first put into use in the early 1960s. Since that time, the use of multiprocessing architecture has been routine in many fields; tens of millions of dollars of research went into understanding the requirements of multiprocessing in the 1980s and 1990s alone.
But it took the introduction of multicore chips by Intel and other manufacturers to bring multiprocessing to the attention of the public.
Now that it's becoming hard to buy even an inexpensive notebook computer that doesn't have a multicore chip, everyone is suddenly worrying about how to program multicore machines-- which is a fancy way of saying that they are suddenly worrying about multiprocessing. And people are shocked to find out that many mainstream languages, including C and C++, are entirely ill-equipped for the task.
Multithreading is not a feature that can be glued on as an afterthought. In a recent discussion thread on the gcc (GNU Compiler Collection) development forum, the problem of optimizations that are unsafe for threading drew hundreds of posts, as experts on C argued whether compilers can validly optimize in manners that severely discombobulate multithreading semantics. The languages of the 1960s, including PL/I, Algol 68 and Simula 67, all contained features for handling parallel execution on multi- processing machines.
Another important player in multiprocessing is Ada. Even the original Ada 83 version of the language has a well-developed notion of multithreading (termed "tasking" in Ada) with high-level constructs that are easy to use and analyze. The subsequent Ada 95 and Ada 2005 versions of the language substantially improved and extended this functionality, and decades of experience have been accumulated in using Ada to deal with the problem of writing programs that run effectively on machines using more than one processor.
This knowledge is immediately at home in the world of multicore processors. At AdaCore, which is in the business of producing Ada compiler systems for many architectures, the only thing that needed to be done for multicore systems was to update the marketing literature.
Java has some facilities for multithreading, but these are low-level and error-prone. I might not go so far as to agree with Per Brinch-Hansen's paper, "Java's Insecure Parallelism," which accuses the designers of Java of throwing out 30 years of research and experience in concurrency; but Java's facilities in that area are certainly disappointing.
Is Ada the final answer to the challenge of programming for multicore chips? No one would claim that. There will undoubtedly be further advances in the field of language design, and I expect that Ada 2015 (standard languages by convention are revised every decade) will incorporate new and important features in this area.
But it seems fair to say that Ada is decades ahead of many competing languages in providing a workable solution here and now.
Robert B.K. Dewar (
