Concurrency is not parallelism — excerpts from the marriage chronicles

What can he possibly have to say that hasn’t already been said on this topic, you wonder? Endless articles, lectures, papers, authors covering all the details, the highs and the lows, in all known formats and languages, including English, German, French, Italian, Chinese, Bosnian, Klingon, etc. Is there really anything new to say on this topic?

Well, not really. The materials have got so much better over the years it can be summed up in couple of sentences. Check out this excerpt from the Golang blog:

- “In programming, concurrency is the composition of independently executing processes, while parallelism is the simultaneous execution of (possibly related) computations. Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once.”

And, a couple of conclusions:

• Concurrency is not parallelism.
• Concurrency enables parallelism.
• Concurrency makes parallelism easy.

I could throw in a couple of “Hello, world” examples to further explain the subject in more detail, but I’m not going to. I would rather you went and checked out the Golang blog and a great lecture by Rob Pike on the subject, or go find some prominent lecturer in your programming language of choosing that is addressing this topic.

Instead, this article will address my observation on why some people still use these terms interchangeably. And believe me, some still do, in spite of so many resources out there saying otherwise. Also, I will try to give some advice on how to tackle the understanding of the topic. At least, how I managed to get some grasp on this conundrum.

People will be people

First of all, a note to people who actually care about this topic. Don’t cringe every time you hear these terms being misused. A lot of programmers don’t care about it. There are tools, libraries and practices that abstract and encapsulate away the concurrency and parallelism, and some people just want to get through the task of implementing it to go and do what they actually enjoy. There is nothing we can do for these programmers, and that is that.

Try it out

Now, for the ones that actually want to understand these concepts and terms, there are few things you might want to try out. First thing, already hinted, is to actually try it out. It really makes a huge difference just reading about it versus reading about it and trying out the examples. Remember those examples I said I wouldn’t give you? Well, they are kinda important. They are not there just to fill up the space and make the article longer. These examples are there for authors as a help aid, but they are not there to help them. Authors can probably talk for days on about this subject, they don’t need additional help. The examples are there to help you with these concepts, they are there for you to try them out. To play with them and break them apart, all in quest for understanding the subject. There are very few people in the world that can get a firm grasp on this subject just from reading. For the rest of us, the examples that are provided are a welcomed help.

However, not all examples of concurrency and parallelism come in the form of code samples and excerpts. Although they are not the case of true parallelism, some examples can even be found in nature, mainly in the observations of human behavior. This is where the “marriage” part of the title comes in. By now, you probably wonder what that was about. It wasn’t my intention to leave you hanging, but there is something called story build-up.

I was thinking…

It was a quiet, rainy Sunday afternoon. I was watching TV. Right across me was my wife and she was playing a game on her iPad. All of a sudden, she started off with “I was thinking…”, the words every husband likes to hear. I don’t know about you, but in my experience, this is a start of some plan elaboration that, in 70% of the cases, includes me doing something. Also, this was my cue to stop watching TV and start listening.

I’m glad I did, because I noticed something that had always amazed me about my wife, that was an inspiration for this article. While laying out these future plan elaborations, she didn’t stop playing the game. This wasn’t some static game like solitaire or memory, this was a game with a character running and jumping around, a game that requires a good hand-eye coordination. On top of that, she was talking without any pause about a subject completely unrelated to the game. To add to this, she was looking at me from time to time (this will be important later in the article).

I appreciated this moment of parallelism occurrence. This, something I have always struggled with and could do on very rare occasions, came naturally to her. I consider myself a “concurrent” being, so parallelism comes with a great amount of focus and practice. For most of the time I can do things concurrently that look to be done in parallel, but really, they’re not. To say the least, I was amused and appreciative of this moment. This is how it looks like in a diagram:

Let’s break it down. If we observe my wife as a process, playing the game and looking at me from time to time are tasks done concurrently (T1 and T3, respectively), because these tasks share eyes as a resource and cannot be done in parallel. Talking is another task (T2) that is working separately from the other two. Her ability to do these tasks separately is what is makes the tasks work in parallel. When you go back to that definition, parallelism is about doing lots of things at once, you see that’s the case here. Well, two is not “lots of”, but it sure serves as a pretty good example.

She was right to look at me from time to time. As a mostly “concurrent” being, I run things concurrently, of course. So, while appreciating and thinking about the parallel nature of my wife, I actually pressed pause on listening to her. And, she picked up on that, because, apparently I was grinning like an idiot. For reference, I don’t consider grinning a separate task, the same as I don’t consider watching TV and nodding as separate tasks either. Involuntary actions are not separate tasks. Anyway, here’s how that looks like in a diagram:

T1 is watching TV, T2 is listening to my wife. T3 is, well, not listening, but thinking about what I have witnessed. Let’s go back to the definition again: “Concurrency is about dealing with lots of things at once”. Here we have my attention as a shared resource and my inability to process information in parallel. The result is that tasks are executed concurrently, but not in parallel.

By the way, if you are wondering, that black line is an “Aaand you’re not even listening to me!” task interrupt. It brought me back to the listening task’s context.

The provided examples are strictly from the observing perspective. They are not measured results. I’m well aware that humans are not capable of achieving true parallelism, but it sure looks like that from the observing perspective.

Conclusion

All jokes and anecdotes aside, if you want to get a firm grasp on this topic, or any topic for that matter, my advice would be to try out the provided examples for yourself. Find as many as you can, run them, dissect them, break them apart. Don’t forget to ask questions. As you get better, you will have less trouble differentiating between concurrency and parallelism. You will even be able to find and appreciate the occurrences in everyday life.

Note: In most of the cases, I am a great listener. Also, my wife is aware of both my shortcomings and qualities. And yes, I do have qualities, you know.

My wife is also a developer and she understands my “concurrent” nature all too well, so she approves of this article. However, she pointed out that plan inclusion percentages are not 95%. My bad. ❤