C# 5 async/await thread mechanics feel wrong?

Question

Why have the calling thread walk into the async method until the inner 'await'?

Isn't it cleaner to just spawn a thread as soon as an async method is called. That way you know for sure that the async method returns immediately. You don't have to worry about not doing anything expensive at the early stages of the async method.

I tend to like to know whether a method is going to execute code on 'my' thread or not. Whether it's blocking or not. This model seems to open a whole spectrum of in-between possibilities.

The designers are much smarter than I am so I'm sure there is a good reason, I'd just like to get my head around it.

Answer 1

Isn't it cleaner to just spawn a thread as soon as an async method is called.

The whole point of "async" methods is to avoid spawning a new thread.

You are confusing asynchrony with concurrency. Asynchronous methods need not run on another thread to be asynchronous. The point of asynchronous methods is that they allow you to break up work into little pieces that need to run in a particular order, but not necessarily without doing other work on the same thread.

Think of a thread as a worker you can hire. Think of a async method as a to-do list with pauses between the items. If your to-do list says "go to the store, buy milk and eggs, go home, make an omelette", then the benefit of async is that when someone calls your cell phone between the "buy eggs" step and the "go home" step and says "can you stop by the pharmacy on your way home and pick up my prescription?" you can take the call and schedule the work before you make the omelette. With non-async methods, your phone keeps ringing until the omelette is done, and then you take the call. The UI blocks until you're done what you're doing.

Your concept is that in order to keep the UI thread responsive, the moment you get the to-do list you go hire some guy to run to the store for you, so that you're free to take the call about the pharmacy. That is expensive and unnecessary. Everything can stay on the same thread with async because the long-running task has built-in points where the UI gets to interrupt and schedule more work.

Answer 2

I like to think of async..await to be syntactic sugar for continuation-passing style programming.

With that in mind it has nothing to do with threads.

Answer 3

I tend to like to know whether a method is going to execute code on 'my' thread or not.

I think that is a peculiar desire, not really a good argument for/against any feature.

The main point of async/await is that the code for starting an async op and handling the results can be kept into one method.

Without it you are forced to break code that logically belongs together into 2 parts.