Question

I’ve been reading about the new async and await operators in C# and tried to figure out in which circumstances they would possibly be useful to me. I studied several MSDN articles and here’s what I read between the lines:

You can use async for Windows Forms and WPF event handlers, so they can perform lengthy tasks without blocking the UI thread while the bulk of the operation is being executed.

async void button1_Click(object sender, EventArgs e)
{
    // even though this call takes a while, the UI thread will not block
    // while it is executing, therefore allowing further event handlers to
    // be invoked.
    await SomeLengthyOperationAsync();
}

A method using await must be async, which means that the usage of any async function somewhere in your code ultimately forces all methods in the calling sequence from the UI event handlers up until the lowest-level async method to be async as well.

In other words, if you create a thread with an ordinary good old ThreadStart entry point (or a Console application with good old static int Main(string[] args)), then you cannot use async and await because at one point you would have to use await, and make the method that uses it async, and hence in the calling method you also have to use await and make that one async and so on. But once you reach the thread entry point (or Main()), there’s no caller to which an await would yield control to.

So basically you cannot use async and await without having a GUI that uses the standard WinForms and WPF message loop. I guess all that makes indeed sense, since MSDN states that async programming does not mean multithreading, but using the UI thread’s spare time instead; when using a console application or a thread with a user defined entry point, multithreading would be necessary to perform asynchronous operations (if not using a compatible message loop).

My question is, are these assumptions accurate?

Answer 1

So basically you cannot use async and await without having a GUI that uses the standard WinForms and WPF message loop.

That’s absolutely not the case.

In Windows Forms and WPF, async/await has the handy property of coming back to the UI thread when the asynchronous operation you were awaiting has completed, but that doesn’t mean that’s the only purpose to it.

If an asynchronous method executes on a thread-pool thread – e.g. in a web service – then the continuation (the rest of the asynchronous method) will simply execute in any thread-pool thread, with the context (security etc) preserved appropriately. This is still really useful for keeping the number of threads down.

For example, suppose you have a high traffic web service which mostly proxies requests to other web services. It spends most of its time waiting for other things, whether that’s due to network traffic or genuine time at another service (e.g. a datbase). You shouldn’t need lots of threads for that – but with blocking calls, you naturally end up with a thread per request. With async/await, you’d end up with very few threads, because very few requests would actually need any work performed for them at any one point in time, even if there were a lot of requests “in flight”.

The trouble is that async/await is most easily demonstrated with UI code, because everyone knows the pain of either using background threads properly or doing too much work in the UI thread. That doesn’t mean it’s the only place the feature is useful though – far from it.

Various server-side technologies (MVC and WCF for example) already have support for asynchronous methods, and I’d expect others to follow suit.