News and New Products

Multicore software problems edging toward center stage

By Ron Wilson, Executive Editor -- EDN, 4/6/2007

From meetings and conversations on the floor at the Embedded Systems Conference, it is becoming clear that the engineering issue of the year for embedded designers—or at least for the engineering press and the marketing community—is going to be multicore architectures. And the best candidate for the center of this discussion is going to be the problem of programming multicore devices. This appears to be independent of whether the device in questions is a multicore x86 CPU, a multiplecore DSP chip or and SoC scattered with processors. And the problem is so severe that it has a chance of stopping the multicore movement in its tracks.

Much of the current discussion emanates from a single paper by professor Edward Lee at the University of California, Berkeley, entitled simply "The problem with threads." In his paper, Lee argues that the thread-based model with which systems developers are attempting to extend conventional programming techniques—meaning C programs—to multicore environments is inherently so problematic that it should be abandoned in favor of as yet unidentified languages that deterministically express concurrent behavior. Without such a language, Lee says, software designers will be reduced to pruning away at nondeterministic parts of the state space in an attempt to make the code understandable and verifiable.

Unfortunately, it appears for the moment that Lee is exactly correct. A large number of discussions of the multicore programming problem at Embedded Systems described the beginnings of exactly this pruning process. Perhaps the most sophisticated such effort, and in some ways the most self-aware, was described by Frank Schirrmeister, vice president of marketing at software start-up Imperas. Without being specific about particular tools under development, Schirrmeister described an incremental process of building around current programming techniques a methodology  that could cope with multiprocessing hardware.

While he has no faith that a new programming language can be imposed on the software community any time soon, Schirrmeister does believe that for progress to be made, there must be a way to express task-level parallelism explicitly at the source-code level. The approach Imperas has in mind appears to be one of gradually adding point tools to the conventional C-language flow to help programmers identify tasks and parallelism, restrict the domain of those tasks with assertions, help them map the tasks onto multiprocessing hardware, and then automate the optimization iterations necessary to meet computing deadlines and remove dynamic problems such as deadlocks.

“We can help with the pain of multicore programming, but we have to be realistic,” Schirrmeister said. “For now, help has to come without imposing a new programming model. At some point in the future we will have built up to the point where people will be ready to accept a new model that can produce correct-by-construction code. But not now.”

Coming at the problem from an entirely different point of view, CriticalBlue CEO David Stewart suggests that the company’s existing tool, Cascade, may be a route into the multicore space. Cascade examines a single-thread application source deck and derives from it a hardware accelerator implemented as an array of arithmetic/logic units, control units and interconnect links based on a standard architecture. One of the outputs of the system is a SystemC model that can be used for system-level modeling and exploration.

Stewart suggests that this methodology, starting with a single-thread expression of the necessary algorithms and deriving hardware processing sites from the code, may be a way to constrain the development of multiprocessing systems in an orderly way. It certainly avoids the Procrustean problem of trying to fit an implicitly threaded application onto an existing cluster of hardware processors, interconnect elements and memory structures. But it also appears to assume very loose coupling between the presumably parallel tasks.

Yet another point of view entirely, and one even more heavily reliant on independence of the processing tasks, comes from National Instruments founder James Truchard. Truchard observed that the LabView system National uses to construct instrumentation and control systems is in fact a graphical abstraction based on a parallel programming language. As such, LabView is capable of generating systems of hardware and software involving moderate numbers of processing sites executing separate tasks in parallel. Once again, there are serious restrictions on the kinds of applications, the nature of the tasks and the level of coupling between them. But for a specific range of measurement and real-time control problems LabView, as well as other extremely application-bound programming environments, may very well provide a solution.

What seems clear at this point is that there is no general solution in view to the problem of programming multicore architectures. There are success stories with conventional C-level programming flows in problems where the parallelism is explicit and rich in the structure of the data. Mentor Graphics’ ability to move their lithography simulation tool onto the IBM Cell processor is a case in point. There are also cases in which largely independent tasks can be set in motion and allowed to run to completion in compete bliss on multicore architectures, at least until memory contention becomes an issue. But in the larger space of problems where neither task nor data parallelism is obvious, where any partitioning of tasks produces tight coupling between them, and where it is not feasible to avoid sharing communications links and memory structures, the problem remains a very formidable one solvable only by trial and error.