Multithreaded programming isn't a new idea, but it's currently experiencing a major upswing in attention. That's because many multi-core chip vendors are currently pushing multithreading as the best way to harness their chips' processing horsepower.
But a recent influential paper by Dr. Edward Lee argues that multi-threaded application programming, as commonly practiced, is a flawed methodology that invites a range of nasty, hard-to-identify bugs.
Dr. Lee is a professor of EECS at UC Berkeley and a founder of BDTI. In his paper, "The Problem with Threads", he asserts that multithreaded applications are often wildly non-deterministic and largely unintelligible to their own programmers. That's because in a multithreaded system, the program execution sequence (and processor state) can be switched at any time, thus making it difficult—if not impossible—for the programmer to determine whether every possible sequence will work correctly. As a result, even simple-looking programs may be riddled with potential deadlocks and other hazards.
According to Dr. Lee, thread-based programming has worked reasonably well so far because it has been applied in fairly limited ways, and has typically been used on single-core processors, which offer limited parallelism. But, he argues, as engineers start implementing more aggressive multithreading on highly parallel processors, they can expect severe bugs to show up with alarming frequency.
Dr. Lee acknowledges that there are techniques to help mitigate the problem and allow the programmer to reduce the inherent non-determinism in some multithreaded applications—but he asserts that these techniques are insufficient, and that the approach is fundamentally backwards. His solution? Develop new programming approaches and languages that startwith deterministic behavior and only introduce non-determinism where absolutely necessary. This would not be a quick fix.
Not surprisingly, Dr. Lee's paper has attracted considerable attention in the software engineering world. His point is no less relevant for DSP engineers; in fact, it may be even more important in this realm, since DSP engineers often work on mission-critical systems, and deal with hard real-time constraints that demand a high level of determinism. As DSP system designers increasingly adopt multi-core technologies they will need a robust software development methodology—and I'm starting to wonder whether multithreading is the right approach.
Add new comment