Libraries

Clearly the most exciting announcement for the parallel programming .NET world comes from the Microsoft Parallel Extensions for .NET library that was dropped in a CTP a few days ago. Joe Duffy and Stephen Toub have been super busy lately getting this stuff out the door, and after toying with it in the past few days, I must say they've done a great job.

The PFX framework can be leveraged through a few different API surface areas: PLINQ (or Parallel LINQ), which is essentially LINQ on concurrency crack; a small set of imperative programming constructs that express parallelism over data sets (parallel for loops, parallel foreach loops etc); and a parallel abstraction over task based programming (a task abstraction is simply a series of actions) which is lighter weight than its ThreadPool cousin.

This stuff is goodness. I know a lot of work has gone on behind the scenes to make this API surface area cheap and efficient, however, at the end of the day, we're only a little further ahead of where we were before. A wise man once told me that in order to win hearts and minds, we need to make people fall in to the pit of success, and I'm not totally convinced that your average programmer can go from a single threaded client side forms app to a fully multithreaded concurrent app via API's like PLINQ and PFX, no matter how simple they are.

The issue here is the fundamental mismatch between a forms style programming model (imperative OO + Forms API surface area + events + UI thread) and a declarative functional style of data parallelism. And while the PFX task library is more suited to the forms style common denominator, it's still not a "pit of success" answer - a lot of work and care needs to be done on behalf of the programmer to get it 'right'. Not only that, there's a bunch of moving parts in your typical forms app that just aren't architecturally suited to being split up in to abstractions.

The good news here is that PFX is not a play for a new world order in .NET concurrency, it's about the building blocks. Once you have that foundation coupled with a small discrete surface area (even if it does have a small amount of learning curve), you enable a virtuous cycle which helps drive programmers to a better place. Building blocks enable libraries (MapReduce.NET anyone?), community involvement, partnerships (WPF team talks to PFX team who talk to Dynamic Languages team) and so on. We've done it before with OO, so it's definitely possible to move the masses to a more data driven task/actor oriented approach so long as we take baby steps. So while you could say that these libraries are evolutionary, I'm convinced it's going to help enable the 'revolutionary'.

Platforms

ASP.NET/IIS has done a great job at abstracting away concurrency issues for years. Of course, the mental model for programmers is fairly simple: autonomous users piped through a HTTP request with all "shared" data accesses done through a backend database somewhere. Perhaps we can plug that mental model in to client side application programming?

• The World's Eight Most Excellent Software Adventures, Part One
• The World's Eight Most Excellent Software Adventures - Part Two