Synchronous vs Asynchronous

Every line of code you have written so far has run on a thread. A thread is a worker: it picks up your instructions and carries them out one after another. Your program gets one to start with, and can be given more.

Most methods finish by doing work. Some methods finish by waiting. When you ask a database for a row, or an API for a price, or a disk for a file, your code sends the request and then does nothing at all until the answer comes back. The thread is still assigned to you. It is still consuming memory. It is producing nothing.

That is blocking, and it is what asynchronous code exists to avoid.

Before you reach for anything, decide which kind of slow you have. Asynchronous code helps with one of them and does nothing at all for the other.

Two summary sentences worth keeping: asynchronous code is about not occupying a thread while something else works. Parallelism is about occupying several threads on purpose, because you have work for all of them.

They are different tools for different problems, and using one where the other belongs is the most common source of disappointment with async.

public class RateService
{
    private readonly HttpClient _httpClient;

    public RateService(HttpClient httpClient) => _httpClient = httpClient;

    // Synchronous. The calling thread is held for the whole round trip.
    public decimal GetRate(string currencyCode)
    {
        string body = _httpClient
            .GetStringAsync($"rates/{currencyCode}")
            .GetAwaiter()
            .GetResult();                       // blocks here

        return decimal.Parse(body);
    }

    // Asynchronous. The thread is released while the network does its work.
    public async Task<decimal> GetRateAsync(string currencyCode)
    {
        string body = await _httpClient.GetStringAsync($"rates/{currencyCode}");

        return decimal.Parse(body);
    }
}

• Both methods do the same amount of network work and take about the same wall-clock time. Nothing here is faster.
• In GetRate, .GetAwaiter().GetResult() means "stand here until the answer arrives". The thread that called GetRate cannot do anything else until then. The next lesson but one explains why this form is dangerous as well as wasteful.
• In GetRateAsync, await hands the thread back. Your remaining code — the decimal.Parse line — is recorded as the thing to run once the response arrives.
• The return type changes from decimal to Task<decimal>, and the convention is to suffix the name with Async. Both of those signal to a caller that this method finishes later.
• Nothing in the asynchronous version creates a thread. That is worth saying out loud, because the mental picture of "async starts a background thread" is both common and wrong.

On a server, requests are served by threads from a shared pool. The pool is finite, and when it runs short it adds threads slowly rather than all at once.

Picture an API endpoint that spends 300 milliseconds waiting on a database. Written synchronously, each in-flight request holds a thread for that whole 300 milliseconds. Once every thread in the pool is parked in front of the database, new requests queue. Response times climb even though the database is barely working and the processor is close to idle.

Written asynchronously, each request gives its thread back during the wait. The same pool serves far more concurrent requests, because threads are only held while there is something to do. The word for what improved is throughput: requests handled per second, not the speed of any one request.