Eric Campbell 6 min read Engineering

Concurrency vs Parallelism: Understanding the Difference

Developers often use 'concurrency' and 'parallelism' interchangeably. This confusion leads to poor architectural decisions—applying parallelism to I/O-bound problems or using concurrency patterns...

Key Insights

  • Concurrency is about structure—designing programs to handle multiple tasks by interleaving their execution—while parallelism is about execution—actually running multiple tasks simultaneously across CPU cores.
  • Choose concurrency for I/O-bound workloads (network requests, file operations, database queries) and parallelism for CPU-bound workloads (data processing, image manipulation, mathematical computations).
  • Adding more threads or processes doesn’t automatically improve performance; understanding your workload characteristics and language runtime constraints (like Python’s GIL) is essential for making the right choice.

Introduction: Why the Distinction Matters

Developers often use “concurrency” and “parallelism” interchangeably. This confusion leads to poor architectural decisions—applying parallelism to I/O-bound problems or using concurrency patterns when you need raw computational throughput.

Here’s a simple analogy: imagine a restaurant kitchen. A single chef juggling multiple dishes—checking the oven, stirring a sauce, plating an appetizer—is concurrency. The chef isn’t doing everything simultaneously; they’re rapidly switching between tasks during natural wait times. Now imagine five chefs, each preparing a different dish at the exact same moment. That’s parallelism.

Understanding this distinction will fundamentally change how you design systems, choose libraries, and debug performance issues.

Concurrency Defined: Managing Multiple Tasks

Concurrency is a structural property of your program. It’s about dealing with multiple things at once, not necessarily doing them at once. A concurrent program can make progress on multiple tasks by interleaving their execution, typically switching between them during blocking operations.

The key insight: concurrency excels when tasks spend time waiting. Network requests, file I/O, and database queries all involve waiting for external resources. Instead of blocking the entire program, a concurrent design lets other tasks proceed during those wait times.

Here’s a practical example using Python’s asyncio to fetch multiple URLs concurrently:

import asyncio
import aiohttp
import time

async def fetch_url(session: aiohttp.ClientSession, url: str) -> dict:
    """Fetch a single URL and return response info."""
    async with session.get(url) as response:
        content = await response.text()
        return {
            "url": url,
            "status": response.status,
            "length": len(content)
        }

async def fetch_all_urls(urls: list[str]) -> list[dict]:
    """Fetch all URLs concurrently."""
    async with aiohttp.ClientSession() as session:
        tasks = [fetch_url(session, url) for url in urls]
        return await asyncio.gather(*tasks)

def main():
    urls = [
        "https://httpbin.org/delay/1",
        "https://httpbin.org/delay/1",
        "https://httpbin.org/delay/1",
        "https://httpbin.org/delay/1",
    ]
    
    start = time.perf_counter()
    results = asyncio.run(fetch_all_urls(urls))
    elapsed = time.perf_counter() - start
    
    for result in results:
        print(f"{result['url']}: {result['status']} ({result['length']} bytes)")
    
    print(f"\nFetched {len(urls)} URLs in {elapsed:.2f} seconds")
    # Output: ~1 second total, not 4 seconds

if __name__ == "__main__":
    main()

This code fetches four URLs that each take one second to respond, but completes in roughly one second total. The single-threaded event loop switches between requests during network wait times. No parallelism required.

Parallelism Defined: Simultaneous Execution

Parallelism is about doing multiple things at the exact same time. This requires multiple execution units—CPU cores—running computations simultaneously. Parallelism addresses CPU-bound problems where the bottleneck is computational work, not waiting.

When your program spends its time calculating, transforming, or processing data, parallelism can dramatically reduce execution time by distributing work across cores.

Here’s an example using Python’s multiprocessing for CPU-intensive image processing:

import multiprocessing as mp
from pathlib import Path
import time

def process_image(image_path: str) -> dict:
    """Simulate CPU-intensive image processing."""
    # Simulate heavy computation (resize, filter, encode)
    total = 0
    for i in range(10_000_000):
        total += i * i % 1000
    
    return {
        "path": image_path,
        "processed": True,
        "checksum": total % 10000
    }

def process_sequential(image_paths: list[str]) -> list[dict]:
    """Process images one at a time."""
    return [process_image(path) for path in image_paths]

def process_parallel(image_paths: list[str]) -> list[dict]:
    """Process images in parallel across CPU cores."""
    with mp.Pool(processes=mp.cpu_count()) as pool:
        return pool.map(process_image, image_paths)

def main():
    images = [f"image_{i}.jpg" for i in range(8)]
    
    # Sequential processing
    start = time.perf_counter()
    results_seq = process_sequential(images)
    sequential_time = time.perf_counter() - start
    
    # Parallel processing
    start = time.perf_counter()
    results_par = process_parallel(images)
    parallel_time = time.perf_counter() - start
    
    print(f"Sequential: {sequential_time:.2f}s")
    print(f"Parallel:   {parallel_time:.2f}s")
    print(f"Speedup:    {sequential_time / parallel_time:.1f}x")

if __name__ == "__main__":
    main()

On an 8-core machine, the parallel version runs approximately 8x faster because each core processes a different image simultaneously. This is true parallelism.

Key Differences Illustrated

Let’s make the distinction concrete with a side-by-side comparison in Go, where we can explicitly control parallelism:

package main

import (
    "fmt"
    "runtime"
    "sync"
    "time"
)

func cpuIntensiveWork(id int) int {
    // Simulate CPU-bound computation
    result := 0
    for i := 0; i < 50_000_000; i++ {
        result += i % 1000
    }
    return result
}

func runWithProcs(maxProcs int, taskCount int) time.Duration {
    runtime.GOMAXPROCS(maxProcs)
    
    var wg sync.WaitGroup
    start := time.Now()
    
    for i := 0; i < taskCount; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            cpuIntensiveWork(id)
        }(i)
    }
    
    wg.Wait()
    return time.Since(start)
}

func main() {
    taskCount := 8
    
    // Concurrent but not parallel: single OS thread
    duration1 := runWithProcs(1, taskCount)
    fmt.Printf("GOMAXPROCS=1 (concurrent):  %v\n", duration1)
    
    // Concurrent AND parallel: multiple OS threads
    duration8 := runWithProcs(8, taskCount)
    fmt.Printf("GOMAXPROCS=8 (parallel):    %v\n", duration8)
    
    fmt.Printf("Speedup: %.1fx\n", float64(duration1)/float64(duration8))
}

With GOMAXPROCS=1, all goroutines run concurrently on a single OS thread. The Go scheduler interleaves their execution, but only one runs at any moment. With GOMAXPROCS=8, goroutines execute in parallel across eight OS threads, achieving real speedup for CPU-bound work.

Same goroutines, same code structure—but fundamentally different execution characteristics.

When to Use Which Approach

Use concurrency when:

  • Tasks spend significant time waiting (network I/O, disk I/O, database queries)
  • You need to handle many simultaneous connections (web servers, chat applications)
  • Memory efficiency matters (threads/processes are expensive; async tasks are cheap)
  • You’re building responsive UIs that shouldn’t block on background operations

Use parallelism when:

  • Tasks are CPU-bound (mathematical computations, data transformation, encoding)
  • Work can be cleanly partitioned (batch processing, map-reduce patterns)
  • You need to maximize throughput on multi-core hardware
  • Each task is independent and doesn’t require shared mutable state

Decision framework:

Is your bottleneck I/O or CPU?
├── I/O-bound → Use concurrency (async/await, event loops, green threads)
└── CPU-bound → Use parallelism (multiprocessing, worker threads, parallel streams)
    └── Can work be partitioned cleanly?
        ├── Yes → Parallel map/reduce patterns
        └── No → Consider algorithmic improvements first

Common Pitfalls and Misconceptions

The “more threads = faster” fallacy. Adding threads to an I/O-bound application might help, but adding threads to a CPU-bound application beyond your core count creates overhead without benefit. Context switching between threads costs CPU cycles.

Python’s Global Interpreter Lock (GIL). In CPython, the GIL prevents multiple threads from executing Python bytecode simultaneously. This means threading doesn’t provide parallelism for CPU-bound Python code. Use multiprocessing for true parallelism, or asyncio for I/O-bound concurrency.

Race conditions exist in both models. Whether you’re using concurrent or parallel execution, shared mutable state creates race conditions:

import threading
import multiprocessing as mp

# BROKEN: Race condition with shared counter
counter = 0

def increment_unsafe():
    global counter
    for _ in range(100_000):
        counter += 1  # Read-modify-write is not atomic

# FIXED: Using a lock
counter_safe = 0
lock = threading.Lock()

def increment_safe():
    global counter_safe
    for _ in range(100_000):
        with lock:
            counter_safe += 1

def demonstrate_race_condition():
    global counter, counter_safe
    
    # Unsafe version
    counter = 0
    threads = [threading.Thread(target=increment_unsafe) for _ in range(4)]
    for t in threads:
        t.start()
    for t in threads:
        t.join()
    print(f"Unsafe counter (expected 400000): {counter}")
    
    # Safe version
    counter_safe = 0
    threads = [threading.Thread(target=increment_safe) for _ in range(4)]
    for t in threads:
        t.start()
    for t in threads:
        t.join()
    print(f"Safe counter (expected 400000):   {counter_safe}")

if __name__ == "__main__":
    demonstrate_race_condition()

The unsafe version will almost certainly produce a value less than 400,000 because concurrent read-modify-write operations interleave unpredictably. The lock ensures atomic access to the shared counter.

Conclusion: Choosing the Right Tool

Concurrency and parallelism solve different problems. Concurrency is a design approach for managing multiple tasks, particularly when those tasks involve waiting. Parallelism is an execution strategy for performing multiple computations simultaneously.

Modern systems often combine both: a web server might use concurrency to handle thousands of simultaneous connections while dispatching CPU-intensive work to a parallel processing pool. Understanding when to apply each—and when to combine them—is a fundamental skill for building performant systems.

Start by profiling your workload. Identify whether you’re I/O-bound or CPU-bound. Then choose the appropriate tool: async/await and event loops for I/O-bound concurrency, multiprocessing and worker pools for CPU-bound parallelism. And always remember that the simplest correct solution beats a complex fast one.

Liked this? There's more.

Every week: one practical technique, explained simply, with code you can use immediately.