Real world analogies to understanding Concurrency versus Parallelism

TLDR:
Concurrency is about dealing with lots of things at once.
Parallelism is about doing lots of things at once.

Concurrency: A condition that exists when, during a given period of time, two threads are making progress
Parallelism: A condition that arises when, given a particular point in time, two threads are executing simultaneously

Concurrency is two lines of customers ordering from a single cashier
(lines take turns ordering);
Parallelism is two lines of customers ordering from two cashiers
(each line gets its own cashier)

While looking at these stackoverflow threads on concurrency and parallelism, I got wondering about the real world analogies to make better sense of the paradigm.

What is the difference between concurrency and parallelism?

What is the difference between concurrency, parallelism and asynchronous methods?

The country I live in gives me great opportunities to find real world analogies about system design.

Due to high density of population and high growth, systems, flows and processes in daily life here that are designed without scalability and peak load in mind tend to break rather soon.

Before we get into concurrency and parallelism, lets look at the age-old simple to implement, a.k.a. serial system flow.

People lined up at an cashier counter waiting for their turn without being able to do anything else until they are served is a classic example of a serial flow.

src: https://www.theguardian.com/world/2016/nov/28/india-bank-lines-controversy-cash-for-queuing

The no-brainer solution to make the experience better for consumers here is to deploy more counters to make things happen in parallel.

However, parallelism needs more than one serving counter. Since deploying every new counter needs more employees and more real-estate space, its easier said than done, in a place, where real-estate is at a real premium. Instead, things automatically fall in place to convert serial into a concurrent processing flow. Imagine an enquiry desk where multiple folks get served without any specific order.

The waiting time for each consumer reduces somewhat. Its less than ideal but it still can be better for the majority of consumers. The enquiry desk can just dispatch the first consumer by guiding them on where to fill their name, residence details and signatures and then go on to serve the others while the first consumer goes about filling his / her form.

Consumer needs addressed intermittently getting served by just one server. That is concurrency but without parallelism.

src: https://www.123rf.com/photo_89296886_delhi-india-october-22-2016-people-wait-in-a-queue-at-baggage-enquiry-desk-at-indira-gandhi-internat.html

Then we have the panacea to what might solve all these problems — the hero flow called parallelism.

Have many counters, to serve multiple folks in parallel and voila problem solved.

Real world problems with classic parallelism

Issue 1: Unbalanced load

What system designers often miss about what will happen when they design parallel systems. Here certain counters with long queues bear the brunt of the load whereas other counters can be free.

src:https://www.deccanherald.com/city/bengaluru-infrastructure/kia-second-terminal-to-be-delayed-by-6-to-12-months-844968.html

Solution to Issue 1 of unbalanced load can be solved by creating a common queue without affinity to any counter.

Issue 2: When the fertilizer hits the ceiling

When regardless of the number of servers, you have just too many consumers. Typically happens when you are trying to recover from an outage or a if its a blue moon day / black swan event / Bloody Sunday / whatever fancy term comes to mind.

src: https://www.airlive.net/wp-content/uploads/2018/08/terminal-1-e1533678780320.jpg

Solution to Issue 2: ‘When the fertilizer hits the ceiling’ : well there’s no real quick-fix to this one other then prevention or unless your design has the superpowers to super-scale up whenever such an event happens. Easier said than done.

Issue 3: Lean periods with unused capacity

Nearly free boarding counters at the airport when at no load. But counter space still needs to be paid for. viz. during the early days of the pandemic.

Solution to Issue 3: “Lean periods with unused capacity’ is to have the ability to scale-down as and when needed.

Other analogies:

Serial blocking analogies

1. One rest room for many people
2. Patients waiting in a clinic with a single doctor.
3. Any government clearing window.

Concurrency analogies

Concurrency can be achieved with a single processor or processing resource

Can serve multiple consumers that are interruptible

1. Triaging nurse periodically replacing IV for all patients one by one in the medical ward
2. A chess GM playing many opponents at the same time
3. An enquiry front desk helping multiple customers fill up their forms
4. A teacher trying to manage 2 classes of students at the same time by giving short assignments
5. A relation ship manager for multiple customers
6. A single cpu system allowing more than one program to run eg. Lotus123 and Word at the same time.
7. A cook making a three course meal like rice, vegetable and curry at the same time.
8. One waiter serving many diners in a small restaurant
9. A common printer that allows multiple employees to print documents

Parallelism examples

Needs multiple processors

1. Multiple fast tag lanes on a toll Highway
2. Multiple cooks preparing multiple dishes at the same time.
3. Multiple valets at a car park

FTW, here’s a quick diagram that technically illustrates Concurrency vs Parallelism.

src : Go Coroutines in GoLang

Other References:

1. https://www.baeldung.com/cs/concurrency-vs-parallelism
2. https://www.thecrazyprogrammer.com/2021/02/concurrency-vs-parallelism.html
3. https://www.tutorialspoint.com/difference-between-concurrency-and-parallelism
4. https://stackoverflow.com/questions/14130266/is-there-a-difference-between-concurrency-and-parallelism-in-java
5. https://stackoverflow.com/questions/72270177/about-multithreading-concurrency-and-parallelism