January 15, 2007
Multithreading Invites String of Nasty BugsJeff Bier
Multithreaded programming isn't a new idea, but it's experiencing a major upswing in attention. That's because many multicore- chip vendors are pushing multithreading as the best way to harness their chips' processing horsepower.
Multithreaded programming isn't a new idea, but it's experiencing a major upswing in attention. That's because many multicore- chip vendors are pushing multithreading as the best way to harness their chips' processing horsepower.
But a recent paper by Edward Lee argues that multithreaded application programming, as commonly practiced, is a flawed methodology that invites a range of nasty, hard-to-identify bugs.
Lee is a professor of EECS at the University of California, Berkeley, and a founder of Berkeley Design Technology Inc. In "The Problem with Threads" (www.eecs.berkeley.edu), he asserts that multithreaded applications are often wildly nondeterministic and largely unintelligible to their own programmers. That's because in a multihreaded 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 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 as engineers implement more-aggressive multithreading on highly parallel processors, they can expect severe bugs to show up with alarming frequency, he argues.
Lee acknowledges that there are techniques to mitigate the problem and allow the programmer to reduce the inherent nondeterminism in some multithreaded applications. But he asserts that the techniques are insufficient. Indeed, he goes so far as to say that the current approach is fundamentally backward.
His solution? Develop programming approaches and languages that start with deterministic behavior and only introduce nondeterminism where abso- lutely necessary. That would not be a quick fix.
Not surprisingly, Lee's paper has attracted considerable attention in the software-engineering world. But his point is no less relevant for DSP engineers; in fact, it may be even more important in that 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 multicore technologies, they will need a robust software development methodology--and I'm starting to wonder whether multithreading is the right approach. Jeff Bier is president of Berkeley Design Technology Inc. (www. BDTI.com), a consulting firm providing analysis and advice on DSP technology. Jennifer Eyre of BDTI contributed to this column.
|
 |
|
|||||||||||||||||||||||||||
|
|
 |
||||
 |
|
|||
 |
||||
 |
|
|||
|
||||
 |
|
|||
|
||||
 |
|
|||
|
||||
 |
|
|||
|
||||
