Concurrency describes program structure: several operations can be in progress during the same period. Parallelism describes execution: several operations run at the same instant. A single core can interleave concurrent work but cannot execute it in parallel.

That distinction drives the .NET choices in this folder. Asynchronous composition keeps I/O waits from occupying threads. Controlled parallelism gives CPU work access to multiple cores. Mixing the two models usually adds threads without making the workload finish sooner.

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. The thread still executed one continuation at a time because the overlap came from the operating system and network.

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.

Diagram caveat

The “not concurrent, parallel” quadrant does not fit these definitions. Simultaneous execution is necessarily concurrent. The visual is useful only for contrasting interleaving with simultaneous execution.

Choosing the Execution Model

Mental Model

• I/O-bound work usually needs asynchronous APIs rather than more worker threads.
• CPU-bound work may benefit from partitioning across a measured degree of parallelism.
• Cancellation belongs to the operation’s full ownership chain.
• Shared mutable state needs an ownership rule before it needs a faster lock.

Choosing Options for the Same Requirement

The workload and failure boundary come first. The primitive comes after that.

Coordination Patterns

A coordination mechanism must make ownership and failure visible. Merely removing the immediate race is not enough.

`SemaphoreSlim` fits a concurrency limit rather than exclusive ownership. Mutex pays for an operating-system handle when ownership must cross a process boundary. Neither provides durable queueing or removes deadlock risk from a multi-lock design.

Decision Walkthroughs

Fan out 500 HTTP calls

The dependency’s capacity sets the useful fan-out, not the size of the input collection. The cap starts conservative and is tuned from latency and rejection data. When output order matters, Task.WhenAll already preserves it: its results follow the order of the supplied tasks even though completion order will vary.

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);
}

Improve throughput of CPU transforms

Parallel.For or Parallel.ForEach fits synchronous CPU work. Parallel.ForEachAsync earns its async machinery only when each body awaits. PLINQ can keep a pure batch transform readable.

In a server, an in-process bounded queue limits admission but still consumes the same CPU and memory as request handling. Sustained CPU work needs an isolated worker process or service when request-serving capacity must be protected.

Protect shared state in an async flow

A short synchronous critical section belongs behind a lock. If ownership must span an await, SemaphoreSlim.WaitAsync can represent the gate, though holding any gate across I/O widens the contention window. A single-consumer channel is often clearer when ordered mutation and buffering are both part of the requirement.

Questions

What is the difference between concurrency and parallelism in practice?

Concurrency means several operations are in progress during the same period, even if only one runs at any instant. Parallelism means several operations run at the same instant on different cores. Parallel execution is always concurrent, but concurrent work need not be parallel.

Aspect	Concurrency	Parallelism
What it describes	How work is structured: operations overlap in time, and their steps can interleave	How work executes: operations run simultaneously
Hardware required	Possible on a single thread or core	Requires multiple cores
Typical .NET use	Asynchronous I/O: a thread starts an operation, yields at await and runs other work while the operating system waits	CPU-bound work split across cores, such as Parallel.For over independent items
What it improves	Progress continues during waits, without a thread held for each wait	Elapsed time of computation that divides into independent parts

For example, one thread can start two HTTP requests, yield at each await and resume each request when its response arrives. Both requests are in flight together, yet the thread runs one continuation at a time. Extra threads would not make the remote service respond sooner. Parallelism pays off only when there is enough independent CPU work to repay the cost of partitioning and scheduling it.

Microsoft: Asynchronous programming · Microsoft: Parallel programming in .NET · Microsoft: Task-based asynchronous programming

What should be checked before choosing Task, lock, Parallel, or Channel?

Three checks drive the choice: whether the work waits on I/O or uses CPU, whether threads share mutable state, and which code owns completion, cancellation and failure.

Check	Fits	Reason
The work mostly waits on I/O	Task with await	The thread is released while the operation waits; more threads would not make the I/O finish sooner
The work is independent CPU computation large enough to split	Parallel with a measured degree of parallelism	Several cores compute at once, but small or contended work may not repay partitioning and scheduling
Threads change shared mutable state in a short synchronous step	lock	Only one thread at a time performs the change; a lock cannot be held across await
Producers hand work to separate consumers	Bounded Channel<T>	It buffers items and fixes an overload policy: producers wait or items are dropped

Ownership applies to every option. Some code must await or otherwise observe each task so that its exceptions surface. That code also passes a cancellation token into the operation and, for a channel, calls Complete after the last write. Without such an owner, a task can fail unnoticed and a channel reader can wait forever for items that will never arrive.

Microsoft: Asynchronous programming · Microsoft: Task-based asynchronous programming · Microsoft: Parallel programming in .NET · Microsoft: lock statement · Microsoft: Channels

References

• Concurrency Is Not Parallelism
• Managed threading best practices
• Threading in C#