Async & multithreading

#Sync vs async: the restaurant analogy

public IActionResult Get(int id)
{
    var order = db.Orders.Find(id);           // thread blocked ~20 ms
    var rate = http.GetStringAsync(ratesUrl).GetAwaiter().GetResult(); // blocks
    return Ok(order);
}

public async Task<IActionResult> Get(int id, CancellationToken ct)
{
    var order = await db.Orders.FindAsync([id], ct);   // thread released while the DB works
    var rate  = await http.GetStringAsync(ratesUrl, ct);
    return Ok(order);
}

The benefit in an API: the same number of threads can handle far more concurrent requests. That's scalability, not speed: a single request doesn't get faster.

#How async/await works under the hood

The compiler rewrites an async method into a state machine: a type with a MoveNext() method and a field that remembers which await it reached.

1. The method runs synchronously until the first await.
2. If the awaited task is already complete, for example a cache hit, execution simply continues on the same thread.
3. Otherwise it registers a continuation, returns an incomplete Task to its caller, and the thread is freed.
4. With true asynchronous network I/O, no thread waits: the OS signals completion through I/O completion ports on Windows or epoll on Linux. Some filesystem or provider async APIs may offload blocking work to a thread.
5. When the operation finishes, the continuation runs on a ThreadPool thread, or the UI thread in desktop apps, and resumes at the same point with all local state.
6. Exceptions are captured in the Task and rethrown at the await.

public async Task<decimal> GetTotalAsync(Guid orderId, CancellationToken ct)
{
    var order = await repo.GetAsync(orderId, ct);         // may suspend here
    var rate  = await fx.GetRateAsync(order.Currency, ct); // and here
    return order.Total * rate;                    // resumes with locals intact
}

#Thread vs Task vs ThreadPool

The ThreadPool is a set of reusable worker threads. ASP.NET Core serves each request on one of them. Blocking those threads with .Result exhausts the pool, which is called thread pool starvation.

#Task.Run, WhenAll and WhenAny

Task.Run queues work to a pool thread. It's useful in UI and console apps for CPU-heavy work. In ASP.NET Core you're already on a pool thread, so wrapping I/O in it only adds overhead.

var order = await Task.Run(() => db.Orders.Find(id));   // still blocks a pool thread

var order = await db.Orders.FindAsync([id], ct);

// WhenAll: start everything first, then wait for ALL → total time ≈ the slowest call
var stockTask   = inventory.GetStockAsync(sku, ct);
var priceTask   = pricing.GetPriceAsync(sku, ct);
var reviewsTask = reviews.GetAsync(sku, ct);
await Task.WhenAll(stockTask, priceTask, reviewsTask);           // (1)
var page = new ProductPage(                                      // (2) all complete
    await stockTask, await priceTask, await reviewsTask);

// WhenAny: continue when the FIRST task finishes
var winner = await Task.WhenAny(primary.GetAsync(ct), replica.GetAsync(ct));
var data = await winner;                       // (3) observe result or exception

// WaitAsync (.NET 6+) times out the wait; the CTS times out the operation
using var timeoutCts = CancellationTokenSource.CreateLinkedTokenSource(ct);
timeoutCts.CancelAfter(TimeSpan.FromSeconds(5));
var receipt = await gateway.ChargeAsync(order, timeoutCts.Token)   // (4)
    .WaitAsync(TimeSpan.FromSeconds(5), ct);

#Cancellation

A user may close a report page, or an HTTP request may end before the database finishes. Instead of doing needless work, the caller passes a cancellation signal and each layer decides how to respond. The code shows passing and checking it; cancellation is cooperative and does not forcibly kill a thread.

[HttpGet("report")]
// (1) ct is cancelled when the client disconnects
public async Task<IActionResult> Report(CancellationToken ct)
{
    // (2) pass it everywhere
    var rows = await db.Sales.Where(s => s.Year == 2026).ToListAsync(ct);
    foreach (var row in rows)
    {
        ct.ThrowIfCancellationRequested();   // (3) check inside long CPU loops
        Process(row);
    }
    return Ok();
}

// combine the request token with your own timeout
using var cts = CancellationTokenSource.CreateLinkedTokenSource(ct);
cts.CancelAfter(TimeSpan.FromSeconds(10));                             // (4)
await partnerApi.SyncAsync(cts.Token);

Cancellation is cooperative: the token doesn't kill code; the code checks it. Cancelling throws OperationCanceledException, which is not an error and shouldn't be logged as one. EF Core passes the token to the database provider, but providers may not honor it.

#Race conditions and synchronization primitives

private int _count;
// NOT atomic: read → add → write, so concurrent updates get lost
public void Hit() => _count++;

// 1) lock: one thread at a time (synchronous code only)
// .NET 9+ Lock type (before: private readonly object _gate = new();)
private readonly Lock _gate = new();
public void Add(Item i) { lock (_gate) { _items.Add(i); _total += i.Price; } }

// 2) Interlocked: atomic operations on a single value
Interlocked.Increment(ref _count);

// 3) SemaphoreSlim: works with await, and can allow N at a time
private readonly SemaphoreSlim _refresh = new(1, 1);
public async Task RefreshTokenAsync(CancellationToken ct)
{
    await _refresh.WaitAsync(ct);
    try { _token = await auth.GetTokenAsync(ct); }
    finally { _refresh.Release(); }                // always release in finally
}

#Deadlocks and common async mistakes

1. .Result and .Wait() (sync over async): block the thread. Under a synchronization context, as in UI apps or classic ASP.NET, this deadlocks: the thread waits for the task while the task waits to resume on that thread. ASP.NET Core has no synchronization context, so it doesn't deadlock, but it causes thread pool starvation.
2. async void: returns nothing awaitable, and exceptions crash the process. Use it only for event handlers.
3. Forgetting await: the operation runs fire-and-forget, exceptions vanish, and the DbContext may be disposed before it finishes.
4. Fire-and-forget inside a request: _ = SendEmailAsync() outlives the DI scope. Use a queue, a background job or an outbox.
5. Two concurrent operations on one DbContext.
6. lock around await: not allowed; use SemaphoreSlim.
7. Not flowing the CancellationToken.

ConfigureAwait(false) tells await it doesn't need to resume on the captured context. It matters in libraries and UI apps; in ASP.NET Core application code it has no effect because there's no synchronization context.

Lock deadlocks: thread 1 holds A and waits for B while thread 2 holds B and waits for A, forever. The fix is a consistent lock order, short critical sections and timeouts. The same applies to database transactions.

#Parallelism vs asynchrony, and Channels

// CPU-bound: spread across cores
Parallel.For(0, images.Length, i => images[i] = Resize(images[i]));

// I/O-bound with a concurrency limit (.NET 6+)
var options = new ParallelOptions { MaxDegreeOfParallelism = 8, CancellationToken = ct };
await Parallel.ForEachAsync(skus, options,
    async (sku, token) => await SyncStockAsync(sku, token));

// Channel: in-memory async queue; bounded = back-pressure when consumers are slow
var channel = Channel.CreateBounded<OrderPlaced>(capacity: 1000);
await channel.Writer.WriteAsync(evt, ct);                                        // producer
await foreach (var e in channel.Reader.ReadAllAsync(ct)) await HandleAsync(e);   // consumer

A line worth remembering: "Concurrency is about dealing with many things at once; parallelism is about doing many things at once."