Concurrency vs. Parallelism

Concurrency and parallelism are related, but they answer different questions. Java developers often learn both concepts around threads and executors, then carry the habit of using the terms interchangeably. In Clojure, it helps to separate them clearly because the language gives you different tools for coordination and for raw parallel execution.

The short version

• Concurrency is about managing multiple tasks that may overlap in time.
• Parallelism is about actually doing work at the same time on multiple cores.

A program can be concurrent without being parallel, and parallel without having complicated coordination.

What concurrency means

Concurrency is mainly a design problem. It asks: how do different activities interact without corrupting shared state or blocking each other unnecessarily?

For example:

• a web service handles many requests in flight
• one part of the system updates state while another reads it
• background jobs and request handlers coexist safely

This is where Clojure’s emphasis on immutable data and explicit state tools matters most.

What parallelism means

Parallelism is mainly an execution problem. It asks: can independent work run simultaneously and finish faster by using more than one CPU core?

For example:

• process many large values independently
• run separate calculations at the same time
• divide CPU-heavy tasks into chunks

This is useful only when the work is independent enough and heavy enough to justify the coordination overhead.

Why the distinction matters in Clojure

Clojure is strong at concurrency because immutable values and explicit state references reduce the usual shared-mutation hazards.

That means you often solve concurrency problems by:

• sharing immutable values safely
• isolating state changes behind atoms, refs, or agents
• designing functions that compute new values instead of mutating old ones

Parallelism is a separate question. Once the data flow is safe, you can ask whether some part of the work should also run in parallel.

A practical example

This is a concurrency-oriented pattern:

1(def request-count (atom 0))
2
3(defn record-request! []
4  (swap! request-count inc))

The point here is coordinated state change. You are not trying to make the increment “parallel” in any interesting sense. You are trying to keep shared state correct.

This is a parallelism-oriented pattern:

1(doall (pmap #(* % %) (range 1 20)))

Here the point is independent computation across many values. There is no shared state problem to solve first; the question is whether multiple cores can help.

Java comparison that helps

In Java, concurrency and parallelism often get discussed together because both show up in thread APIs, executors, locks, futures, and streams.

In Clojure, a better split is:

• concurrency: safe coordination of changing program activity
• parallelism: simultaneous execution of independent work

That split usually leads to better design decisions.

Common mistakes

Treating every thread-related problem as parallelism

If the real issue is shared state or task coordination, you have a concurrency problem first.

Adding parallelism before fixing data flow

If your state model is messy, adding parallel execution usually makes the problem worse rather than faster.

Using parallel tools for tiny tasks

Parallelism has overhead. Small or cheap operations often run slower when parallelized.

A practical rule

Ask these questions in order:

1. do I need safe coordination between activities?
2. once that is solved, is there enough independent CPU-heavy work to justify parallel execution?

That order keeps the design grounded.

Knowledge Check