Multi-threaded development joins Gates as yesterday's man

“To me, it looks more or less like the hardware designers have run out of ideas, and that they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks! I won’t be surprised at all if the whole multi threading idea turns out to be a flop, worse than the ‘Titanium’ approach that was supposed to be so terrific - until it turned out that the wished-for compilers were basically impossible to write," Knuth said.

Knuth - the author of the seminal programmers' manual The Art of Computer Programming and a Turing Award winner - has to be taken seriously on this. And he is not alone. Sun Microsystems' director of web technologies Tim Bray, one of the team that created XML, has also criticized multi threading. Bray said that, while he once favored the approach, he had now turned away from it. Elsewhere the criticism of multi threading is even more direct.

There appear to be two schools of thought emerging on how future software developers should cope with the challenge of programming multiple processor systems.

One school says the complexities should be hidden by the tools leaving programmers to concentrate on their applications. Compilers and operating systems should take care of issues such as synchronization and load balancing. This is in essence the aim of multi-threading strategies such as Intel's TBB and similar approaches by AMD.

The other school argues that programmers should be educated in functional languages such as Lisp and Erlang. Jack Dennis, professor of computer science and engineering at MIT, believes a combination of education in functional languages and exposure to the problems of synchronization could help. He also argues that functional languages effectively avoid some of the problems of programming multiple processor systems.

Devil in the details

Like the two lead characters in Robert Pirsig's Zen and the Art of Motor Cycle Maintenance one school sees the underlying complexity of the machine as something to be avoided at all costs and the other relishes the intricacies of its internal workings.

Clearly there's a lot more work left to do. Both from a practical and a philosophical perspective, as the industry must agree not just to take action on programming for parallel systems, but also decide what is the best approach to take. And achieving lasting consensus could be the hardest part of the puzzle. As we are discovering on multi threading, what was once considered "right" can fall out of favor and be branded as "wrong".®