Let's Get Parallel

I think it's time we start moving toward a more parallel style of programming. I'm not referring to academia (which has been working on the parallel problem for decades) or the educated individuals who study things like Lisp or Erlang. I'm speaking to the other 80% of programmers who are embedded in a Java/PHP world where parallelism is unheard of. OK, Java has threads, and a rather good threading model to boot, especially with that nice little synchronized keyword.

However, the threading model itself is flawed. When working with shared mutable values, there are huge issues when it comes to parallelism. First, we have race conditions. So we create things like mutexes to prevent race conditions. Then, we have deadlocks. So we have things to fix deadlocks, leading to livelocks. It seems like no matter how many times we fix something, new problems crop up.

Functional languages, having no mutable values - unless of course you're programming in a functional language with an imperative accent and use set! - do not have this problem. They are inherently parallelizable. However, functional languages confuse a lot of people, so they aren't the best for business. How much easier is it to find someone who can program in Java or PHP than in Lisp or Haskell? Yikes.

The most promising of what I've seen is the actor model. This is sorta like object-oriented programming, except when one actor makes a method call (called sending a message in actor-speak) the caller doesn't block. The method is sent out and then the actor continues what it was doing. This is similar to programming as part of a team using an instant messenger, where each programmer is working independently and when they need to talk to another programmer, they send them a message.

One cool thing about the actor model is that it is pretty easy to scale. You could put all the actors on one machine, or across several machines. If the language or platform or whatever that you're using supports it, you could have network transparency from the programmer perspective. I actually worked on a project on this called RTSync that used an actor-synchronizer model where there were synchronizers included that managed timing among the actors, thus allowing for real-time programming with timing constraints and what-not.

Why should we be reconsidering our parallel programming? Because computers are going parallel. Now there are dual-cores, I'll bet in a few years we'll have quad-cores in people's houses, maybe oct-cores (is that a word?). So I can imagine that in 10 years if you don't have some good parallel programming experience, you're not going to be a very marketable programmer. So get on it.