This is the last post of the series proper, with one bonus post to follow. The previous two posts showed what runtime async does to the IL and to the numbers. This one is about the code you already have. The short version: almost nothing changes, and that is the point. The longer version is worth reading before you turn it on in anything that matters. What does not change Every behaviour this series… [read more]

The previous post showed what runtime async does to the generated IL. This one measures what it does to the numbers. Read the caveats at the bottom before quoting anything here. This is a release candidate runtime, one machine, and microbenchmarks. How it is measured runtime-async is an assembly wide compilation mode, so it cannot be a BenchmarkDotNet job. The benchmark is three projects compiling the… [read more]

Everything in this series so far has rested on one fact: async is a compiler rewrite. The compiler takes your method, moves the body into a generated state machine, and leaves behind a stub that starts it. .NET 11 changes that. The runtime suspends and resumes async methods itself, and the compiler stops generating state machines. Turning it on Runtime async is a preview feature in .NET 11, opted into per… [read more]

This series has measured one thing at a time. This post puts the numbers together, because the interesting question is not "what does an await cost" but "when does any of it show up in my application". It is also the last post before .NET 11, where the runtime takes over and several of these numbers change. The two paths Everything reduces to a single distinction. An async method either completes without… [read more]

These two methods look equivalent: public Task<int> DoSomethingAsync() { return CallDependencyAsync(); } public async Task<int> DoSomethingAsync() { return await CallDependencyAsync(); } The first is called eliding the await. It is faster, and it is usually the wrong choice. This post is about what you actually trade. What eliding saves Without async, the method is an ordinary method that returns a value… [read more]

Once operations run concurrently, they start touching the same state. The synchronous answer is lock, and it does not work here: lock (_gate) { await LoadAsync(); // CS1996: Cannot await in the body of a lock statement } That is a compiler error, and it is protecting you from something worse than a compiler error. Why the compiler refuses lock compiles to Monitor.Enter and Monitor.Exit, and Monitor is… [read more]

Everything so far has been about a single operation. This post is about running several, which is where async stops being a syntax feature and starts changing what your program does. The mechanics are three combinators and one throttle, and each has an exception behaviour that is worth knowing before you meet it in production. Starting is what makes them concurrent Before the combinators, the thing they… [read more]

An async operation that cannot be stopped is a resource leak with good manners. CancellationToken is how .NET stops them, and it is cooperative: nothing is aborted, nothing is interrupted. The operation checks, and gives up. That cooperation is the part people underuse, and the details around it are the part people get wrong. The two halves CancellationTokenSource is the control. CancellationToken is the… [read more]

IDisposable.Dispose returns void. That is fine when cleanup means releasing a handle, and a problem when it means flushing a buffer to disk or sending a close frame over a socket. Those are I/O, and a void method has only two ways to do I/O: block a thread, or fire and forget. IAsyncDisposable exists to give cleanup somewhere to await. The interface public interface IAsyncDisposable { ValueTask… [read more]

An async method produces one value. An iterator produces many values but cannot await. IAsyncEnumerable<T> is what happens when you need both, and the compiler builds it by fusing the two state machines it already knows how to generate. The typical case is paging through an API: each page is a network call, and the caller should not have to know that pages exist. await foreach (var item in… [read more]