Parallel FX

Tuesday was the local .NET User Group meeting (padnug.org). Nick Muhonen gave a great demonstration of the Parallel FX library from Microsoft. Included in the demo of using the library to execute parallel actions directly Nick also demonstrated the extensions to LINQ (aptly named PLINQ) for executing LINQ queries in parallel. (Isn't PLINQ a children's game...)

All in all it was very slick and super easy to achieve. Now naturally there was a constant caveat that Nick repeated several times and that was the requirement that the code that is being executed in parallel does not share state with any of the other code. This is, of course, one of the key components of multi-threaded application development. Once you start sharing state across threads there is no telling for sure what the end result might be or whether you may enter a race condition and end up in a deadlock situation. One difference of note that makes the Parallel FX stuff different than spinning up your own thread and waiting on an event is that the Parallel FX stuff blocked until all of its threads completed. If this is okay, and for complex calculations that you need to wait on maybe it is, you're fine, otherwise you may still need to handle threading yourself. So, essentially, it is a blocking multi-threading library. Wow, weird, eh?

This made me think of some of the fundamentals to F# that Microsoft is working on as well wherein the language is designed (as far as I know) to address some of those concerns by not having much of a concept of shared state between objects. Everything starts to become immutable in the same way as strings are today in Java and .NET.

Another interesting aspect that Nick brought up by way of his introduction was regarding processor speeds and how they have leveled off. In fact in some cases the actual speed of a processor in a computer today may be less than it was a few years ago. Multi-cores are now the way to go but unless your application can take advantage of a multi-core chip it may actually run slower than before.

So now that we are facing a world of multiple core computers rather than simply faster computers do we need to start to rethink how we right code? If F# shares little (if any) state between objects (and I really don't know enough about it to say) and yet still compiles to the same CLR as C# does can we not start to gain some of these benefits in other .NET languages (C# and VB) by using more static classes and singletons? Should we be considering passing new instances of our objects in and out of every method making everything available to parallel execution much more readily? I know what you're thinking, "Holy cow! My memory usage will go through the roof!" Maybe, maybe not, is the garbage collector running on it's own thread? Is it cleaning things up just as fast as we are disposing of them? (Well, not a single core machine for sure...)

As we move towards more service orientation and stateless services doesn't this fit the same model?

These are some of the considerations that have been jumbling around in my head since Nick's presentation. Interesting stuff that is going to require a bit of time and effort to determine the approaches that will work in our ever changing technical world.

Here's the address of the Parallel FX team's blog: http://blogs.msdn.com/pfxteam/