Concurrency is a property of program structure — composing a program out of independently executing tasks that can be dealt with in overlapping time periods. Parallelism is a property of execution — actually doing several of them in the same instant, which requires multiple cores. A single-core machine runs concurrent programs perfectly well by interleaving them, with zero parallelism; concurrent design enables parallelism without requiring it. The practical consequence is the split this hub is organized around: concurrency is what keeps I/O-bound work from blocking threads, and parallelism is what makes CPU-bound work finish faster on multiple cores.

Composition versus simultaneous execution

A single thread can compose overlapping I/O without running two instructions at once:

1. At 0 ms, request A sends an HTTP call and registers its continuation with await; the thread returns to the scheduler.
2. At 1 ms, the same thread starts request B and yields at its await.
3. At 40 ms, B’s socket completion makes its continuation runnable; the thread processes it.
4. At 52 ms, A becomes runnable and the thread resumes it.

Both requests were in flight together, but the thread executed only one continuation at a time. The overlap came from the operating system and network, not another CPU core.

CPU work crosses a different boundary. This loop partitions the pixels and schedules workers through the ThreadPool; multiple workers can execute Sharpen simultaneously on different cores:

Parallel.For(
    fromInclusive: 0,
    toExclusive: pixels.Length,
    new ParallelOptions { MaxDegreeOfParallelism = Environment.ProcessorCount },
    i => pixels[i] = Sharpen(pixels[i]));

That is useful only when Sharpen does enough computation to repay partitioning and scheduling overhead. For socket waits, adding worker threads consumes resources without making the remote service respond sooner.

Non-normative source visual

The “not concurrent, parallel” quadrant is invalid under these definitions: work executing simultaneously on multiple cores is necessarily concurrent. Use the visual only to contrast interleaved composition with simultaneous execution, not as a four-state taxonomy.

Deeper Explanation

Mental model

• If work waits on I/O, prefer async (Task, await) to avoid blocking threads.
• If work burns CPU, use controlled parallelism (Parallel.ForEachAsync, PLINQ, partitioning).
• If work can be canceled, thread cancellation through the full call chain.
• If shared state exists, design locking strategy first, then optimize.

Choosing options for the same requirement

Use requirement-first decisions instead of primitive-first decisions.

Coordination Patterns

The mechanism should expose the workload’s ownership and failure boundary, not just make a race disappear.

`SemaphoreSlim` belongs beside this table when the requirement is a concurrency limit rather than exclusive ownership. Mutex pays an operating-system handle cost when ownership must cross a process boundary. Neither adds queue durability or makes a multi-lock design safe from deadlock.

Decision walkthroughs

Same requirement: “fan out 500 HTTP calls quickly”

• If dependency and infrastructure allow high concurrency, use bounded Task.WhenAll with an explicit limit.
• If each call is tiny and independent, start with a conservative cap (for example 16-64), then tune with telemetry.
• If strict ordering is needed, preserve original index and reorder results after completion.

public async Task<IReadOnlyList<UserDto>> LoadUsersBoundedAsync(
    IReadOnlyList<int> ids,
    int maxConcurrency,
    CancellationToken cancellationToken)
{
    using var gate = new SemaphoreSlim(maxConcurrency);
 
    var tasks = ids.Select(async id =>
    {
        await gate.WaitAsync(cancellationToken);
        try
        {
            return await _client.GetUserAsync(id, cancellationToken);
        }
        finally
        {
            gate.Release();
        }
    });
 
    return await Task.WhenAll(tasks);
}

Same requirement: “improve throughput of CPU transforms”

• Use Parallel.ForEachAsync when you need bounded workers and cancellation with straightforward code.
• Use PLINQ for pure data transforms where query readability is better than imperative loops.
• If CPU work competes with request handling, move it to background workers with queue-based backpressure.

Same requirement: “protect state and stay async”

• For tiny in-memory critical sections, a lock is simplest.
• For async sections that must await, prefer SemaphoreSlim.WaitAsync.
• If contention is high and order matters, move state mutation behind a single-consumer channel.

Questions

What is the difference between concurrency and parallelism in practice?

Concurrency is structure — a program composed of independently executing tasks that can be dealt with in overlapping time periods. Parallelism is execution — those tasks actually running in the same instant, which takes multiple cores. A single-core machine is perfectly capable of concurrency (it interleaves) and incapable of parallelism. In practice the structural choice buys responsiveness and non-blocking progress for I/O-bound work, and separately enables the throughput gain that parallelism delivers for CPU-bound work. Concurrent design permits parallelism; it does not require it.

Why do many production outages in .NET systems look like "performance" but are actually concurrency bugs?

Because thread starvation, deadlocks, lock contention, and unbounded fan-out all manifest as latency spikes and timeouts before obvious crashes.

What is the first decision before choosing a primitive ( Task, lock, Parallel, Channel)?

Classify the workload as I/O-bound vs CPU-bound and define cancellation/error boundaries. Primitive choice follows that classification.

Why is unbounded Task.WhenAll often a bad first choice when calling around 300 external APIs in one request?

Because it can overload downstream dependencies, saturate connection pools, and create timeout storms. Bounded fan-out keeps latency gains while preserving system stability.

For one requirement ("update shared state safely"), when do you choose lock vs SemaphoreSlim vs Channel<T>?

Use lock for short synchronous sections, SemaphoreSlim for async flows that need awaiting, and Channel<T> when you also need queueing, ordering, or backpressure.

References

• Concurrency Is Not Parallelism (Rob Pike, 2012) — the talk this distinction comes from; argues concurrency is about program structure, parallelism about execution.
• Asynchronous programming with async and await (Microsoft Learn) — the C# task-based asynchronous model, continuations, and guidance for I/O-bound work.
• Task Parallel Library (Microsoft Learn) — the .NET task scheduler and data/task parallelism APIs.
• Managed threading best practices (Microsoft Learn) — runtime guidance on synchronization, blocking, deadlocks, and shared state.
• Threading in C# (Joe Albahari) — a practitioner-oriented map of .NET threading, synchronization, tasks, and parallel execution.
• Threading in C#: Basic synchronization and deadlocks (Joe Albahari) — concrete monitor, mutex, semaphore, reader-writer lock, and deadlock mechanics.
• Threading in C#: Parallel programming and tasks (Joe Albahari) — task composition, continuations, parallel loops, PLINQ, and concurrent collections.
• Concurrency is not parallelism (ByteByteGo, pinned source) — source of the visual comparison; its labels are editorial framing, not .NET runtime authority.
• Top 6 multithreading design patterns (ByteByteGo, pinned source) — taxonomy adapted to .NET ownership and failure semantics; the source visual is omitted because it equates tasks with threads and callback streams with futures.