When Parallelism Beats Concurrency

These two are not the same thing

I’m aware that for many of you, these two concepts probably mean the same thing, or maybe you’d struggle to explain the differences between them. However, they’re actually two very different concepts. This is quite important to understand the way in which we process data nowadays.

In both cases, we try to solve a problem faster by increasing the number of workers dedicated to a given task, but the way in which they distribute the work to do is where their biggest difference stands.

You’ll be able to see why it’s so important to understand their differences for an efficient, safe, and error-free processing of data.

Let’s start by explaining these concepts!

Introduction

To start with, let’s take a brief look at what we should be understanding as concurrency and parallelism.

Concurrency

In layman’s terms, concurrency is the situation where, in order to solve a problem, we process it in a way that one single task gets processed concurrently by multiple workers; that said, let’s imagine a big array where we have multiple workers and each worker does some work on the next element to be processed in the array, until we reach the end of the array.

When concurrency takes place, some synchronisation is required in order to access the resource that gets shared among all the existing workers (in our example, this is the array).

The complexity and performance overhead involved in this approach could be very significant in some cases; we’ll try to demonstrate this later on in this article.

Parallelism

On the other hand, parallelism is the situation where, in order to solve a problem, we decide to take a “ Divide and Conquer” approach and split the problem into multiple small problems. This allows us to solve multiple smaller problems in parallel.

How would it look like using the same example we’ve shown above? Let’s imagine that we…