8

I have been educating myself on async / await use and I think I understood under-the-hood concept. However, most of Channel 9 tutorials, MSDN articles and Stack overflow answers on async / await use GUI-based applications (Windows Forms application) to demonstrate the power of async / await.

However, I noticed a fundamental difference in async / await use in a UI-thread based application vs. regular ThreadPool thread-based applications (e.g. ASP.NET Web Application, Console Application, etc.).

Since, in UI thread-based application, the UI thread is always available (unless the process is stopped explicitly or by Windows), so the ThreadPool thread responsible for executing the code after "await" in any async method, will guarantee to find the UI thread to post the results back (if any).

However, in a console application or ASP.NET Web application, the main thread (in a console application) or the HTTP request (in an ASP.NET web application) must be waiting (at one point of time) until all async operations are completed. So there should be .Wait() and .Result call somewhere after the Async method call, if there is nothing more to work on.

Is this understanding correct? I am not questioning the benefit of having async for I/O bound or network-bound operations (I understand how it's going to increase application scalability).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
IntelligentBinary
  • 582
  • 1
  • 6
  • 15
  • 1
    It might be worth noting that [`async` and `await` keywords don't cause additional threads to be created](http://msdn.microsoft.com/en-us/library/hh191443.aspx#BKMK_Threads). – GSerg Dec 24 '13 at 19:15
  • 1
    On ASP.Net and async - check out [Using Asynchronous Methods in ASP.NET MVC](http://www.asp.net/mvc/tutorials/mvc-4/using-asynchronous-methods-in-aspnet-mvc-4) - all proper waiting is already wired up for you and your own code don't need to call `Wait`/`Result`. – Alexei Levenkov Dec 24 '13 at 19:39
  • @AlexeiLevenkov - In MVC (also in windows form application, ASP.NET web form application) there is a way to make the event handler "async" and .NET framework knows to wait for some Async operation to be done. In console application, main thread can not be async and it has to wait for some async operation (even fire & forget kind of async operation) to be done before returning. – IntelligentBinary Dec 24 '13 at 23:54

1 Answers1

9

Since, in UI thread based application, the UI thread is always available (unless the process is stopped explicitly or by Windows), so the ThreadPool thread responsible for executing the code after "await" in any async method, will guarantee to find the UI thread to post the results back (if any).

This is slightly confused. There's no indication that a ThreadPool thread will be required at all.

It's up to the awaitable implementation to determine where to run the continuation, but normally the current synchronization context is used to work out where to run it:

  • In a console application, there is no synchronization context, so a thread pool thread is used for the continuation.
  • In a Windows Forms application, when you're running on the UI thread the synchronization context is one which will execute code on the UI thread... so the continuation executes there (unless you use ConfigureAwait, etc...)
  • In an ASP.NET application, there's a synchronization context specific to ASP.NET itself.

See Stephen Cleary's MSDN article for more details.

It's not clear what you mean by your later question about having to call Wait or Result in ASP.NET or a console app... in both scenarios it may be required, but equally it may not be. It depends on what you're doing really. Don't forget that even a console app can start its own threads and do all kinds of other things - you can write an HTTP server in a console app, for example...

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 1
    +1. Side note: I think in regular console application (no timers/message loop/infinite waits) there will (should) be at least one `Wait`/`Result` because main is synchronous and need to wait for completion of asynchronous operation. Indeed if there are other mechanism used in console application (events, timers, or even `Sleep`...) to make sure execution of async method finishes one does not need `Wait`/`Result`. – Alexei Levenkov Dec 24 '13 at 19:31
  • @AlexeiLevenkov: There might be - or there might not be. It really depends on what you're trying to do. I don't like to make too many blanket statements without more context. – Jon Skeet Dec 24 '13 at 19:35
  • Thanks Jon! Wait/Result is required in my case as the main method does not have any other work to do after calling the async method of an assembly it's consuming. This will not be the case in windows form application or even in ASP.NET web form application, as the event handler can be async (or RegisterAsyncTask could be used). – IntelligentBinary Dec 24 '13 at 23:51
  • @JonSkeet People [require](https://stackoverflow.com/q/55845696/11683) official [sources](https://en.wikipedia.org/wiki/Wikipedia:Citation_needed) for "In a console application, there is no synchronization context". I was not able to find anything concrete in the documentation, do you happen to know better? – GSerg Apr 25 '19 at 09:32
  • @GSerg: Is https://devblogs.microsoft.com/pfxteam/await-synchronizationcontext-and-console-apps/ "official" enough for you? It's still a blog post, but by a member of the team responsible... – Jon Skeet Apr 25 '19 at 10:13
  • 1
    @GSerg: Also note that the [SynchronizationContext documentation](https://learn.microsoft.com/en-us/dotnet/api/system.threading.synchronizationcontext?view=netframework-4.8) explicitly references the MSDN article I link to in this answer. – Jon Skeet Apr 25 '19 at 10:14
  • @JonSkeet Yes, thank you very much. I have [added](https://stackoverflow.com/a/55846287/11683) the references. – GSerg Apr 25 '19 at 10:44