Threading vs Tasks vs Parallelism — The Complete .NET Concurrency Guide

Source: Dev.to

Thread, ThreadPool, Task, Parallel.For, PLINQ – when to use each

Concurrency is one of the most misunderstood areas of .NET development.
Thread, Task, Parallel, async/await — developers often use these interchangeably without understanding what they actually do. The wrong choice costs you performance, correctness, and scalability.

Note: Another post Async/Await in C# — A Deep Dive Into How Asynchronous Programming Really Works covers the difference between asynchrony and parallelism briefly. This guide goes much deeper into the underlying primitives — Thread, ThreadPool, Task, and Parallel.

The Mental Model

• Concurrency – dealing with multiple things at once (managing)
• Parallelism – doing multiple things at once (executing)
• Asynchrony – starting something and doing other work while waiting

These are not the same thing.

Thread — The Low‑Level Primitive

var thread = new Thread(() =>
{
    Console.WriteLine($"Running on thread {Thread.CurrentThread.ManagedThreadId}");
});

thread.Start();
thread.Join(); // Wait for it to finish

• Full control over the thread lifecycle (priority, name, apartment state)
• Can be foreground or background
• Allocates ~1 MB of stack memory per thread
• OS scheduling overhead on every context switch
• You are responsible for lifecycle management
• Does not integrate with async/await

When to use: Almost never in modern .NET. The only remaining valid use case is COM interop requiring a specific apartment state (STA thread for WinForms/WPF dialogs).

ThreadPool — Reusing Threads

ThreadPool.QueueUserWorkItem(_ =>
{
    Console.WriteLine("Running on a pool thread");
});

• No explicit thread creation – you submit work items and the pool decides which thread handles them.
• No thread‑creation overhead; threads are reused across work items.
• The runtime automatically tunes the pool size.

Task.Run() wraps the ThreadPool and provides a much better API.

Task — The Modern Standard

// CPU‑bound work on the ThreadPool
var task = Task.Run(() => ExpensiveCalculation());

var result = await task;

• A Task is a promise that work will complete at some point.
• Task – work with no return value
• Task<T> – work that returns a value
• ValueTask – lightweight task for high‑frequency paths

// Run two tasks in parallel and wait for both
var t1 = Task.Run(() => DoWork1());
var t2 = Task.Run(() => DoWork2());

await Task.WhenAll(t1, t2);

// Wait for the first one to finish
var winner = await Task.WhenAny(t1, t2);

async/await — Asynchrony Without Blocking

async/await is not about parallelism; it frees threads while waiting for I/O (network calls, database queries, file reads).

// The thread is released while waiting for the HTTP response
var response = await httpClient.GetAsync(url);

Typical Scenarios

Parallel — True CPU Parallelism

Parallel.For(0, 1000, i => ProcessItem(i));

var items = GetLargeCollection();

Parallel.ForEach(items, item => Process(item));

var results = items
    .AsParallel()
    .Where(x => x.IsValid)
    .Select(x => Transform(x))
    .ToList();

• Splits work across multiple CPU cores simultaneously.
• Use only for CPU‑bound work that can be divided into independent chunks.
• Never use Parallel for I/O‑bound work – it wastes threads and can cause thread starvation.

The Decision Framework

Is the work CPU‑bound or I/O‑bound?
│
├── I/O‑bound (network, DB, file)
│   └── Use async/await
│       └── Task.Run is NOT needed here
│
└── CPU‑bound (calculations, image processing)
    │
    ├── Single heavy operation
    │   └── Task.Run(() => HeavyWork())
    │
    └── Many independent items
        └── Parallel.For / Parallel.ForEach / PLINQ

Common Mistakes

Mistake 1: Using Task.Run for I/O‑bound work

// ❌ Wrong — wastes a thread waiting for I/O
var result = await Task.Run(() => httpClient.GetAsync(url));

// ✅ Correct — no thread needed while waiting
var result = await httpClient.GetAsync(url);

Mistake 2: Pretending CPU work is asynchronous

// ❌ Looks async but blocks the thread
public async Task ComputeAsync()
{
    return HeavyCpuWork(); // No await — just pretending to be async
}

// ✅ Offload to ThreadPool
public async Task ComputeAsync()
{
    return await Task.Run(() => HeavyCpuWork());
}

Mistake 3: Blocking inside Parallel.ForEach for I/O

// ❌ Spawns threads and blocks them all waiting for HTTP
Parallel.ForEach(urls, url =>
{
    var result = httpClient.GetAsync(url).Result; // Blocking!
});

// ✅ Use Task.WhenAll for parallel async I/O
var tasks = urls.Select(url => httpClient.GetAsync(url));
var results = await Task.WhenAll(tasks);

Interview‑Ready Summary

• Thread – OS‑level primitive; powerful but expensive, rarely needed directly.
• ThreadPool – Recycles threads; Task.Run wraps it.
• Task – Standard abstraction for concurrent work; supports async/await.
• async/await – Frees threads during I/O; not parallelism.
• Parallel.For / Parallel.ForEach / PLINQ – Distribute CPU work across cores.

Guideline:

• I/O‑bound → async/await (no Task.Run).
• CPU‑bound, single heavy operation → Task.Run.
• CPU‑bound, many independent items → Parallel.For / Parallel.ForEach / PLINQ.

Never use Parallel for I/O‑bound work—it wastes threads.

Concise interview answer

“Threads are the OS‑level unit of execution — expensive to create. Tasks abstract over the ThreadPool and support async/await. async/await is about freeing threads during I/O, not parallelism. Parallelism means actually executing work on multiple cores simultaneously — that’s what Parallel.For and Task.WhenAll are for. The golden rule: use async/await for I/O‑bound work, Task.Run for a single CPU‑bound operation, and Parallel (or PLINQ) for many CPU‑bound operations.”