Solutions and Opportunities

The good news is, there's plenty of places to start looking for solutions, and the opportunity in this space is what makes it so exciting. There's OS level plumbing, virtualization (hardware and software), virtual machine plumbing (ala software transactional memory), compilers, languages, libraries, GPU programming and more. Let's look at the 10,000 foot view in some of these areas - hopefully it'll get you as excited as I am about this space.

Languages

Have you seen C# 3.0 lately? Introducing language plumbing that enables data querying libraries like LINQ was genius. Further more, with libraries like Parallel Extensions Framework for .NET, it can leverage the LINQ architecture to perform LINQ queries in parallel across multiple cores. It leverages a parallel programming style called declarative data parallelism (ala functional programming etc). Declarative data parallelism has few or no side-effects. No side effects means high throughput operations over data without the need for "protection". Consider the case of multiplying all elements in an array by 2: for two processors, you could split the array in to two parts, hand one part to one processor and the other part the second processor and ask them to perform the same operation in parallel. Both procs walk their array parts multiplying elements and at the end of it all, we simply join the two parts from each processor for our result. This kind of parallelism is highly scalable (Google's MapReduce API does a very similar thing, and scales across thousands of machines).

Erlang is another parallel enabled programming that's close to my heart. It's a "fit for purpose" highly parallel programming languge that leverages a parallel programming model called the Actor model. From Wikipedia: "The Actor model is a mathematical model of concurrent computation that treats "actors" as the universal primitives of concurrent digital computation: in response to a message that it receives, an actor can make local decisions, create more actors, send more messages, and determine how to respond to the next message received". Erlang kicks ass. The messages that are sent and received are truly first class citizens, and they're light as a feather, weighing in at only a few hundred bytes per message. Those messages are sent in a highly concurrent fashion via Erlang abstraction called 'processes', which are neither OS threads, nor fibres, but rather a lightweight isolated process abstraction that is scheduled and managed by Erlang itself. Really cool stuff.

There's a bunch of other interesting languages that support concurrency features as first class or close to: Concurrent ML, C Omega, F# etc (http://en.wikipedia.org/wiki/Concurrent_computing), and they're worth checking out. F# especially if you live on the .NET platform like I do. My guess is we'll be seeing more and more concurrency features built in to languages as time rolls on.

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