TechEd 2006 -- "parallelism is the new OO"

["Andrew Delin" <Andrew.Delin@xxxxxxxxxxxxx>]

I recently sat through a session at Microsoft's TechEd event in Sydney, Australia. A young ex-Redmond guy was talking about concurrency "being the new OO". He gave lots of reasons why programmers needed to embrace this 'new' direction in computing and how multicore technologies will drive thinking about parallelism in applications in future.

 

Sadly, he then proceeded to give lots of technical examples of how to do parallelism in .NET -- while this was obviously a new topic for many programmers in the large audience, I found it rather revealing. Instead of raising parallelism as a powerful way to decompose problems, his angle was about using threads in conventional object-based code. As I watched his slides, I could just see the complexity increasing in front of me. If people follow this stuff, there will be a whole new world of instability added to applications, ostensibly to "take advantage of multicore". The reason for this complexity is because of a mismatch of levels: the code gets 'noisy thread plumbing' added to it, such as locks, semaphores, monitors, flags... Isn't this one of the fundamentals of computing -- abstraction? Sometimes that abstraction needs a new language -- it can't be added by more objects & classes.

 

I was also surprised to find that JVM and .NET CLR applications are poorly suited for parallel execution, because the intermediate code gets interpreted and optimised in ways that can interfere with your statement sequencing intentions (ie re-ordering). The presenter gave examples where perfectly correct semaphore-based code would fail due to run-time modifications by the executive. The 'fix' was to add more locking litter around your statements because of knowledge of the system below. Very nasty! (I'd be interested to hear from JCSP people on this -- is the implementation clean, or does it have similar problems described above?)

 

All of this made me realise how important it is for the language to express the primitives of concurrency natively, rather than being some call to an API or OO class method.

 

It is hard to own an opinion that says, "we're going in the wrong direction!" I am inclined to email the TechEd presenter and suggest that three new primitives -- ALTernation, CHANnel, and PARallel -- would be a huge step in the right direction. These remove the thread plumbing and semaphore wiring concerns, and put the programmer in a space where they start to think about parallel design proper.

 

I find all of this doubly ironic because Microsoft Research is working on several initiatives in the field of parallel languages. And they employ Tony Hoare, inventor of CSP...

 

 

-AD

 

Andrew Delin

Microsoft Consulting Services

South Australia

+61 (0)8  8217 7417

mailto:adelin@xxxxxxxxxxxxx

http://blogs.msdn.com/andrewdelin