Parallel Concurrent Processing: Two Different Ideas, Finally Separated

Ask a room of programmers to define parallel concurrent processing and most will describe a single idea with two names: lots of things happening at once. That answer hides the distinction that matters. Concurrency is about structure: a program is concurrent when it is built to deal with many tasks over the same stretch of time, keeping each one moving by switching between them. Parallelism is about execution: tasks run in parallel when the hardware literally performs several of them at the same instant, on different processor cores.

Rob Pike, one of the creators of the Go programming language, gave the sharpest summary in a talk written up on the Go blog: “Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once.” Dealing and doing differ by a syllable and by everything else. A program can deal with a thousand tasks on one core. It can only do several at once if it has several cores.

One barista, four baristas: the coffee shop test

Picture one barista working a busy morning alone. She starts a latte, and while the milk steams she grinds beans for the next order. While the espresso pulls, she takes a payment. While a croissant warms, she wipes the counter and calls out a finished drink. She never performs two actions at the same instant. Her hands do one thing at a time. Yet five orders are in progress at once, because she refuses to stand idle during any wait. That is concurrency: many tasks advancing over the same period, through careful switching.

Now give the shop three more baristas, each with a station. Four drinks are now genuinely being made at the same time, by four pairs of hands. That is parallelism. The menu and the queue did not change. What changed is the number of workers executing at the same moment. In a computer, the baristas are processor cores, and the waits are everywhere: reading a file, asking a database, waiting for the network to answer.

The analogy also shows the limit of juggling: one barista, however skilled, cannot serve a stadium. And four baristas cannot help if all four must wait for the same single oven. Computers hit the same walls: the serial part of a job, and the shared resources tasks fight over. Most confusion about parallel concurrent processing dissolves once you ask two separate questions: how is the program organized, and how many cores are actually executing right now?

The precise difference, and the four combinations

Concurrency lives in the design. When you structure a program as several independent tasks that can start, pause and resume in any order, you have written concurrent code, even on an old laptop with one tired core. Parallelism lives in the run. It describes a moment in time: count the tasks executing at that instant, and if the answer is more than one, you have parallelism. A concurrent program only reveals parallelism when hardware offers spare cores.

The combinations matter in practice. A plain script that reads one file and exits is neither concurrent nor parallel. A chat server built on an event loop is concurrent but, on a single core, not parallel: thousands of conversations advance, one slice at a time. A photo filter that splits one image across eight cores is parallel without much concurrency: one job, no juggling, just slicing. A modern web platform is both, juggling millions of requests and executing on dozens of cores at once. Naming which one you have tells you which problem to solve next: a faster switcher, or more hands.

Processes, threads and async: the three juggling tools

The machinery of parallel concurrent processing rests on three tools, and picking the wrong one is the most common beginner mistake. A process is a running program with its own private memory: your browser, your editor and your music player are separate processes, and one can crash without taking the others down. A thread is a stream of execution inside a process; one program can run many, all sharing the same memory, which makes cooperation fast and accidents contagious.

The third tool is the asynchronous task, usually paired with an event loop. Instead of several streams, there is one thread and a queue. A task runs until it reaches a wait, a file read, a network call, a timer, then it steps aside and the loop runs the next ready task. JavaScript made this model famous: as MDN’s guide to the JavaScript execution model explains, each job in the queue runs to completion before the next one starts, which keeps the reasoning simple and the interface responsive.

Where each pattern shows up at work

Start with the web server, the purest concurrency problem in everyday computing. Most of its thousands of connections are doing nothing at any moment: waiting for a click, a phone to wake, a database to reply. The server’s job is to never let those waits pile up, so it juggles. The same pattern runs inside company plumbing, where enterprise application integration moves orders and invoices between systems that answer at very different speeds, so slow systems never block fast ones.

Interfaces are the second home of concurrency. A phone app has one thread that owns the screen; if that thread stops to download a photo, the whole app appears frozen. So the interface thread delegates: downloads, searches and sorting happen in the background, and results hop back for display. Nothing here needs two cores. It needs one discipline: never make the screen wait.

Parallelism takes over when the work itself is the wait. Resizing ten thousand photos, rendering a video, scanning a giant log file: each piece is independent, so the only question is how many cores you can feed. Machine learning training pushes this furthest. Machine learning models are trained exactly this way: split the data into batches, hand each batch to a different processor, then combine the results. The math inside a neural network is millions of small multiplications with no order between them, which is why graphics processors, built to run thousands of threads at once, became the engines of modern AI. That is parallel concurrent processing at industrial scale: concurrent pipelines feeding parallel math.

Amdahl’s law: the ceiling above every speedup

In 1967 the computer architect Gene Amdahl pointed out the arithmetic that still humbles every parallel project. Every job splits into a part that can spread across cores and a part that cannot: the setup, the ordering, the final write-up. That serial part does not shrink when you add cores. If it is 10 percent of the job, even infinite cores leave you that 10 percent: the best possible speedup is ten times, and real results land well below it. This is the single most useful fact in parallel concurrent processing, and the most ignored.

Run the numbers. A nightly photo export takes 100 minutes on one core. Ninety percent of it, the resizing, splits perfectly. Ten percent, reading the job list and writing the final index, must run in order. On four cores the resizing takes 22.5 minutes and the serial part still takes 10, for a total of 32.5 minutes: about 3.1 times faster, not the 4 times the brochure implies. On one hundred cores the total is about 11 minutes. The serial 10 minutes is the floor. So engineers shrink the serial part before shopping for bigger machines.

The law also explains a common disappointment, the “parallel” program that barely speeds up: the serial fraction was bigger than anyone admitted, or coordination overhead became a second serial part. Measure the split before you parallelize it: the law rewards honest measurement and punishes hope.

The hazards: race conditions and deadlocks

Sharing has a price, and the bill arrives as two classic bugs. A race condition appears when two threads touch the same data and the result depends on who gets there first. Imagine two threads adding 1 to a shared counter that stands at 41. Both read 41, both add, both write 42. Two additions happened; the counter moved once. Nothing crashed, no error appeared, and the answer is simply wrong, some of the time, which is the hardest kind of wrong to hunt. That is the tax on shared memory: it is fast precisely because nothing stands between a thread and the data.

A deadlock is the opposite failure: nobody moves at all. Thread one holds the printer lock and waits for the scanner. Thread two holds the scanner and waits for the printer. Both waits are forever. Kitchens know it too: one cook holds the only tray and waits for the knife; the other holds the knife and waits for the tray. The defenses are unglamorous. Guard shared data with locks, and accept the waiting they cause. Hold locks for the shortest time possible. Take multiple locks in one fixed order everywhere. Or avoid sharing: give each task its own data and pass messages instead, the approach Go’s designers recommend in their proverb, share memory by communicating.

Async code dodges most races, because two tasks never truly run at once and each runs uninterrupted between waits. It pays a different price: a task that computes for ten seconds freezes the whole loop, buttons, timers and all. Every model of parallel concurrent processing trades one failure mode for another. The skill is knowing which failures your system can afford.

The famous exception: Python and the GIL

No discussion of parallel concurrent processing survives contact with Python programmers for long, because Python carries the most famous asterisk in this field. CPython, the standard implementation, has a global interpreter lock, the GIL: a single lock that lets only one thread execute Python code at a time, no matter how many cores the machine has. Python threads therefore deliver concurrency without parallelism for pure Python computation. They still earn their keep, because the GIL releases during waits: a program downloading fifty files with fifty threads genuinely finishes faster, since the threads spend their lives waiting on the network, not computing.

CPU heavy Python has three escapes. The first is multiprocessing: run several processes, each with its own interpreter and its own GIL, and let the system spread them across cores. The second is to hand the heavy math to libraries written in C, such as NumPy, which release the GIL while they crunch. The third is new: a free-threaded build of CPython with the lock removed. It arrived as an experimental option in Python 3.13; Python 3.14 made it officially supported, though still a build you choose, not the default. As Python’s own free threading guide warns, some extension packages are not ready for it yet and can switch the lock back on when loaded.

The GIL is not a scandal; it is a trade. It kept single threaded Python simple and fast for decades, and its cost only became obvious when cores multiplied. Read it as the field in miniature: every concurrency model is a bargain between speed, safety and simplicity.

How to choose: five questions before you write code

Parallel concurrent processing stops being confusing the moment you interrogate your own workload instead of the buzzwords. Five questions do most of the work:

• Where does the time go? If tasks mostly wait on networks, disks or people, you have a concurrency problem: reach for async tasks or threads.
• Is the work heavy arithmetic on independent pieces? You have a parallelism problem. Split the data and feed every core, with processes or native threads.
• How large is the serial part? Do the Amdahl math on paper first. A 20 percent serial fraction caps you at five times, whatever the hardware budget says.
• How much state must be shared? Sharing is where races and deadlocks live. Prefer designs that split the data or pass messages, and lock only what you must.
• Can you measure it? Time the current version, change one thing, time it again. Teams that keep experiments in branches of version control systems can try a parallel design and drop it without drama when the numbers disappoint.

None of the five questions mentions a language or a framework. Tools change yearly. Waits, cores, serial fractions and shared state are the permanent physics of this subject.

Conclusion

Parallel concurrent processing is two ideas sharing a coat. Concurrency is the organization: many tasks in progress, each advancing whenever it can, none allowed to block the rest. Parallelism is the execution: several tasks literally running at the same instant on separate cores. You can have either without the other, most real systems need both, and Amdahl’s law taxes every attempt to combine them. Ask of any system what it spends its time doing, waiting or computing, and the two words will never blur together again.