Parallel Concurrency

I always hear software guys complaining that it is difficult to write parallel software and exploit concurrency because of all the inherent problems related to parallelism. Personally, I don’t quite get the gripe, either because – i have no idea what parallelism is; or software guys are dumb. Maybe I am just being harsh or maybe I am not. I think that the trouble is the kind of training that a software guy is generally given today, does not prepare someone for the world of concurrency.

In the classical world of computing, software was generally written as a series of instructions, stored using binary symbols, that are meant to be executed by a machine in strict sequence. As a result, most programmers who have begin their training in the old world of computing, would have been trained with this one-threaded way of thinking. In a parallel world of computing, one needs to have a different paradigm of thought, which is multi-threaded. I say that humans are most certainly capable of concurrent design and thinking. Software people are not born dumb but are merely trained to think that way.

Let me use an analogy, that of sheet music. In many ways, it is just like software programming. A sheet music is a series of instructions, written down in symbolic notation, that are meant to tell the musician what notes to hit and when, in strict sequence.

A beginner student who just started piano lessons, would only be taught to play a single line of melody consisting of only single notes with one hand. This is your classical single-threaded software programme with only a single sequence of instructions being executed. Then, the student moves on to play a single line of melody consisting of only single notes, with each hand separately. This is your classical multi-tasking software programme, where multiple tasks are scheduled and run at different times but with only one instruction being executed at any instant in time.

This is roughly where we are in terms of software programming. We have mastered the art of writing software (playing music) this way. However, I’m sure that you have realised by now that Mozart did not play music like this, except maybe when he was 3 years old. In fact, the only students who play music this way are those who have only had the benefit of a few weeks of musical training.

After a month or two, the student begins to play two single melodies, one with each hand, together. You can think of this as your super-scalar system executing more than one set of instructions at a time. Then, as the student progresses, the student goes on to play multiple melodies, several with each hand, together. This is your classic multi-threaded software. And you know what, we are still only talking about a single individual with ten fingers and two hands – or a single super-scalar multi-threaded core.

Now, try thinking of an orchestra. You get my point.

So, you see. Humans have been capable of programming massively multi-core, multi-threaded software for hundreds if not thousands of years. All that we need is the right rule-set, training and tools. I tend to see a lot of simile between sheet music and software systems. In fact, there are various synchronisation mechanisms built into music as well. I think of musical beats as synchronous clock ticks and chords as thread synchronisation mechanisms.

We just need to start training people to think multi-threaded concurrency from the onset. While we can be lazy and leave things to the compiler to figure out, Beethoven did not leave the writing of his 5th symphony to automatons. The following is a good graphical representation that any computer geek (hardware and software) can appreciate. Let us all take our inspiration from the maestro.