I just started playing around with async/await in .Net 4.5. One thing I'm initially curious about, why is the async keyword necessary? The explanation I read was that it is a marker so the compiler knows a method awaits something. But it seems like the compiler should be able to figure this out without a keyword. So what else does it do?


There are several answers here, and all of them talk about what async methods do, but none of them answer the question, which is why async is needed as a keyword that goes in the function declaration.

It's not "to direct the compiler to transform the function in a special way"; await alone could do that. Why? Because C# already has another mechanism where the presence of a special keyword in the method body causes the compiler to perform extreme (and very similar to async/await) transformations on the method body: yield.

Except that yield isn't its own keyword in C#, and understanding why will explain async as well. Unlike in most languages that support this mechanism, in C# you can't say yield value; You have to say yield return value; instead. Why? Because it was added in to the language after C# already existed, and it was quite reasonable to assume that someone, somewhere, might have used yield as the name of a variable. But because there was no pre-existing scenario in which <variable name> return was syntactically correct, yield return got added to the language to make it possible to introduce generators while maintaining 100% backwards compatibility with existing code.

And this is why async was added as a function modifier: to avoid breaking existing code that used await as a variable name. Since no async methods already existed, no old code is invalidated, and in new code, the compiler can use the presence of the async tag to know that await should be treated as a keyword and not an identifier.

  • 2
    This is pretty much what this article says too (originally posted by @svick in the comments), but no one ever posted it as an answer. Only took two and a half years! Thanks :) – ConditionRacer Nov 5 '15 at 16:28

it changes the method from a normal method to a object with callback which requires a totally different approach for code generation

and when something drastic like that happens it is customary to signify it clearly (we learned that lesson from C++)

  • So this is really something for the reader/programmer, and not so much for the compiler? – ConditionRacer Feb 18 '13 at 21:34
  • @Justin984 it definitely helps to signal to the compiler something special needs to happen – ratchet freak Feb 18 '13 at 21:37
  • I guess I'm curious why the compiler needs it. Couldn't it just parse the method and see that await is somewhere in the method body? – ConditionRacer Feb 18 '13 at 21:39
  • it helps when you want to schedule multiple asyncs at the same time so they don't run one after another but concurrently (if threads are available at least) – ratchet freak Feb 18 '13 at 21:45
  • @Justin984: Not every method returning Task<T> actually has the characteristics of an async method - for example, you might just run through some business/factory logic and then delegate to some other method returning Task<T>. async methods have a return type of Task<T> in the signature but don't actually return a Task<T>, they just return a T. In order to figure all of this out without the async keyword, the C# compiler would have to do all sorts of deep inspection of the method, which would probably slow it down quite a bit, and lead to all manner of ambiguities. – Aaronaught Feb 18 '13 at 23:58

The whole idea with keywords like "async" or "unsafe" is to remove ambiguity as to how the code they modify should be treated. In the case of the async keyword, it tells the compiler to treat the method modified as something that does not need to return immediately. This allows for the thread where this method is used to continue without having to wait on the results of that method. It's effectively a code optimization.

  • I'm tempted to downvote because while the first paragraph is correct, the comparison to interrupts is incorrect (in my informed opinion). – paul Feb 18 '13 at 22:01
  • I see them as somewhat analogous in terms of purpose but I'll remove it for the sake of clarity. – World Engineer Feb 18 '13 at 22:04
  • Interrupts are more like events than async code in my mind -- they cause a context switch and run to completion before normal code is resumed (and the normal code might be completely ignorant of it running, too), whereas with async code the method might not have completed before the calling thread is resumed. I see what you were trying to say w.r.t. different mechanisms requiring different implementations under the hood, but interrupts just didn't jibe with me to illustrate this point. (+1 for the remainder, btw.) – paul Feb 19 '13 at 14:11

OK, here is my take on it.

There is something called coroutines that has been known for decades. ("Knuth and Hopper"-class "for decades") They are generalizations of subroutines, in such as not only do they get and release control at function start and return statement, but they also do it at specific points (suspension points). A subroutine is a coroutine with no suspension points.

They are PLAIN EASY to implement with C macros, as shown in the following paper about "protothreads". (http://dunkels.com/adam/dunkels06protothreads.pdf) Read it. I'll wait...

The bottom line of this is that the macros create a big switch, and a case label at each suspension point. At each suspension point, the function stores the value of the immediately following case label, so that it knows where to resume execution next time it is called. And it returns control to the caller.

This is done without modifying the apparent flow of control of the code described in the "protothread".

Imagine now that you have a big loop calling all these "protothreads" in turn, and you get concurrently executing "protothreads" on a single thread.

This approach has two drawbacks:

  1. You cannot keep state in local variables between resumptions.
  2. You cannot suspend the "protothread" from an arbitrary call depth. (all suspension points must be at level 0)

There are workarounds for both:

  1. All local variables must be pulled up to the context of the protothread (context which is already needed by the fact the protothread must store its next resumption point)
  2. If you feel you really need to call another protothread from a protothread, "spawn" a child protothread and suspend until completion of the child.

And if you had compiler support to do the rewrite work that the macros and workaround do, well, you could just write your protothread code just as you intend and insert suspension points with a keyword.

And this is what async and await are all about: creating (stackless) coroutines.

The coroutines in C# are reified as objects of (generic or non-generic) class Task.

I find these keywords very misleading. My mental reading is:

  • async as "suspensible"
  • await as "suspend until completion of"
  • Task as "future …"

Now. Do we really need to mark the function async? Apart from saying that it should trigger the code rewrite mechanisms to make the function a coroutine, it resolves some ambiguities. Consider this code.

public Task<object> AmIACoroutine() {
    var tcs = new TaskCompletionSource<object>();
    return tcs.Task;

Assuming that async is not mandatory, is this a coroutine or a normal function? Should the compiler rewrite it as a coroutine or not? Both could be possible with different eventual semantics.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.