{"id":1423,"date":"2012-10-18T00:00:00","date_gmt":"2012-10-18T00:00:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/syntactic-sugar-and-the-async-pill\/"},"modified":"2021-05-17T18:36:11","modified_gmt":"2021-05-17T18:36:11","slug":"syntactic-sugar-and-the-async-pill","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/development\/dotnet-development\/syntactic-sugar-and-the-async-pill\/","title":{"rendered":"Syntactic Sugar and the Async Pill"},"content":{"rendered":"
\n

If you have read my article “Go Async or Sink<\/a>“, then you should already be convinced that asynchrony is essential for providing scalability and actual performance for any modern (server-side) software. Any developers would agree that asynchronous software is important yet will do whatever he can to avoid writing async methods. Why? The reason is obvious: writing asynchronous code is boring, annoying and error prone. <\/p>\n

For the most part, when working with asynchronous code, the developer is forced to focus on the technical details of the implementation rather than the workflow they’re setting up. I don’t think that any developers would have ever bothered writing a method asynchronously if that method was the only call of a procedure. <\/p>\n

If your web site needs to download an RSS feed, for example, it will not make any significant difference to performance whether the operation is coded synchronously or asynchronously. It’s a single operation and, probably, you’re also having a caching layer around results. The chances are that the request will complete in just a few milliseconds. At any rate, coding a single operation with an async pattern doesn’t significantly raise the level of complexity of your code. <\/p>\n

It’s a different story when results of multiple network (or file-based) operations are to be retrieved and then combined together through the steps of a workflow. In this case, there’s a stronger business case for coding the logic asynchronously. When implementing a chain of async operations, it is difficult to avoid writing code that is an intricate mess of nested calls and lambdas, not much different from the classic and notorious spaghetti code. <\/p>\n

The .NET Framework has always had support for async operation: However, Microsoft devoted much time to trying to make async more digestible to developers. So we first had Async Web Forms page in the .NET Framework 2.0 and then async controllers in ASP.NET MVC 2. We also had several scattered general purpose APIs to deal more effectively with tasks and their combination. What developers really wanted, but never loudly demanded, was a spoonful of syntactic sugar to help the medicine go down. This async pill was given enough sugar only in the latest .NET Framework 4.5. <\/p>\n

Go Async as You Would Go Sync<\/h2>\n

With the release of the .NET Framework 4.5, the main .NET languages, C# and Visual Basic, now feature a couple of new keywords: async<\/strong> and await<\/strong>. The use of these two new keywords in combination radically simplifies the writing of asynchronous code. The most characteristic aspect of async<\/strong> and await<\/strong> keywords is the fact that their use makes apparently synchronous code work asynchronously. Or, from another perspective, it makes asynchronously-working code as easy to read and understand as if it was written to run synchronously. <\/p>\n

Of the two keywords, await<\/strong> is the most important in the sense that it is the marker that compilers look for and transform into “classic” async patterns just like the ones you have had to implement yourself up until .NET Framework 4.0. The other keyword, async<\/strong>, is used mostly to identify a method that is making use internally of async functionality. Let’s have a look at some code. <\/p>\n

The signature of an async method looks like the following: <\/p>\n

public async Task<String> DoSomething()\n{\n    ...\n} <\/pre>\n
The signature has the async modifier and returns a Task<<\/strong>T<\/strong>Result<\/strong>><\/strong> object, a Task <\/strong>object or simply void. The method will return a Task<<\/strong>TResult<\/strong>><\/strong> object if the method is actually expected to return a TResult<\/strong><\/strong>value or Task<\/strong> (or void) if the method is void. It turns out that Task<\/strong> is a kind of wrapper that represents a pending task expected to return void or a value of type TResult<\/strong>.<\/strong> <\/p>\n
A method marked async<\/strong> must contain a call to method marked await<\/strong>. If not, the method will be run synchronously. In addition, you can use<\/strong>await<\/strong> only on method calls that return a Task<\/strong> object. Calling await<\/strong><\/strong>on a method that returns void is not permitted (and doesn’t make sense at all). The point is that await<\/strong> tells the compiler to perform some magic on a task. This task may return a value (Task<T><\/strong>) or be void (Task<\/strong>) but it needs be something concrete. So a method like below … <\/p>\n
public async void DoSomething()\n{\n    \/\/ Must have here a call to an asynchronously running method\n    \/\/ marked with the await keyword.\n} <\/pre>\n
… is only useful for event handlers or external wrappers of async operations that don’t need to return data to their own callers and are invoked synchronously by their callers. <\/p>\n
Await\/Async in ASP.NET MVC<\/h2>\n
Let’s move on and consider what it takes to write asynchronous code in ASP.NET MVC. As mentioned, you have been able to have asynchronous controllers since version 2 of the ASP.NET MVC framework. As we’ve seen in the article “Go Async or Sink<\/a>“, an async controller needs two physical methods to implement one logical method. The first method serves to start the operation (on a selected thread); the second method serves to complete the operation and generates the action result for the ASP.NET MVC runtime. In ASP.NET MVC 4 you need the following: <\/p>\n
public class HomeController : AsyncController\n{\n    private readonly HomeOrchestrator _service;\n    public HomeController()\n    {\n        _service = new HomeOrchestrator();\n    }\n\n    public ActionResult Index()\n    {\n        return View();\n    }\n\n    public async Task<ActionResult> Demo1()\n    {\n        var model = await _service.GetDataForIndexScreen();\n        return View(model);\n    }\n} <\/pre>\n
As expected, the controller class inherits from AsyncController<\/strong> and can contain synchronous and asynchronous methods. Demo1 is clearly the asynchronous method-it is marked with async<\/strong><\/strong>and returns Task<<\/strong>ActionResult<\/strong>>.<\/strong> The implementation of the method is centered on a worker service as discussed in another article of mine “Never Mind the Controller, Here is the Orchestrator<\/a>“. The real asynchronous job is done by the GetDataForIndexScreen<\/strong> method which is expected to make calls around and collect and format data properly. The execution of the method is controlled by await<\/strong> meaning that the actual execution is split in two parts as it was the case in earlier versions of ASP.NET MVC. Let’s turn our attention to the body of the GetDataForIndexScreen<\/strong> method. <\/p>\n
public class HomeOrchestrator\n{\n    public async Task<HomeIndexModel> GetDataForIndexScreen()\n    {\n        const String rssUrl = \"...\";\n        var client = new HttpClient();\n        var rss = await client.GetStringAsync(rssUrl);\n        var model = new HomeIndexModel();\n        model.News = ParseRssInternal(rss);\n        return model;\n    }\n\n    private IList<String> ParseRssInternal(String rss)\n    {\n        var items = GetItems(rss);\n        return (from item in items select item.Title.Text).ToList();\n    }\n\n    \/\/ Requires a reference to the System.ServiceModel assembly\n    private IList<SyndicationItem> GetItems(String xml)\n    {\n        var textReader = new StringReader(xml);\n        var xmlReader = XmlReader.Create(textReader);\n        var feed = SyndicationFeed.Load(xmlReader);\n        return feed == null ? null : new List<SyndicationItem>(feed.Items);\n    }\n} <\/pre>\n
Besides the internal helper methods to manipulate RSS, the core of the code revolves around the role of the new HttpClient<\/strong> class. Introduced with the .NET Framework 4.5 this class exists specifically to support asynchronous code through await<\/strong>\/async<\/strong> and the related new Task-oriented pattern. As we’ll see in a moment, in fact, the biggest benefit of using<\/strong>HttpClient<\/strong> and async<\/strong>\/await<\/strong> is particularly apparent when it comes to manage and coordinate multiple pending requests. <\/p>\n
As a side note, consider also that HttpClient<\/strong> is not limited to async\/await. According to Microsoft there are several other interesting reasons to prefer HttpClient<\/strong> over WebClient<\/strong> and HttpWebRequest<\/strong>. You can read more here: http:\/\/blogs.msdn.com\/b\/henrikn\/archive\/2012\/02\/16\/httpclient-is-here.aspx<\/a>. <\/p>\n
HttpClient<\/strong> offers a method GetStringAsync<\/strong> through which you can download text from a remote URL. For developers who are used to WebClient<\/strong>, this method is analogous to DownloadStringAsync<\/strong>. HttpClient<\/strong> also offers a few other methods ending with the Async suffix-GetAsync<\/strong>, GetStreamAsync<\/strong> plus a variety of Put-style methods. <\/p>\n
Some classes of the .NET Framework have also been updated to include new Async methods that work well with the async\/await pattern. It should be noted that not just any method with an Async suffix works with the task-based pattern necessary for using async\/await keywords. Check the documentation carefully before you leap. The task-pattern for async<\/strong>\/await<\/strong> is .NET Framework 4.5 only. <\/p>\n
The Magic of Await<\/h2>\n
How does the spoonful of sugar help the medicine go down? Or rather what happens under the hood of the await <\/strong>keyword? <\/p>\n
When the C# (or Visual Basic) compiler meets the await<\/strong> keyword it understands that the current method-necessarily one marked as async<\/strong>-can’t continue past that point until the method following the await<\/strong> keyword has completed. This is precisely the behavior one would expect in plain old synchronous code-except that the combination of async<\/strong>\/await<\/strong> keywords make it happen asynchronously! It’s the compiler, not you, to take care of all the annoying and fairly sophisticated code that is necessary here. And again complexity is not given by a single standalone call, but comes when you need to coordinate multiple calls. <\/p>\n
The compiler replaces await<\/strong> with some code that sets up a special object-called the awaiter-to wait for the completion of the awaited operation. The generated code keeps track of location where execution was suspended and takes a note of where to jump once the awaited operation has terminated. The generated code yields to the caller of the awaited method so that execution can proceed if there’s any code up the stack that can be executed while we wait for the completion of the operation. <\/p>\n
In the context of ASP.NET MVC this means that execution first encounters an await call in the controller method Demo1. This creates a first awaiter for GetDataForIndexScreen<\/strong>. Internally,<\/strong>GetDataForIndexScreen<\/strong> creates a second awaiter to wait for the download of the RSS data. Both blocks centered on the await keyword return to respective caller meaning the execution bubbles up from the controller class and returns to the action invoker-part of the ASP.NET MVC machinery. The action invoker on the AsyncController<\/strong> base class knows what to do and does what’s in its power to split the processing of the request in two part freeing the current ASP.NET thread. <\/p>\n
At some point-asynchronously-the RSS download ends. The innermost awaiter (the one in GetDataForIndexScreen<\/strong>) resumes execution from the line past the await<\/strong> keyword. The RSS feed is parsed, the view model object is filled and returned. This signals the outermost awaiter-the one in the controller method. At this point execution ends in the controller and bubbles up to the action invoker. In turn, the invoker manages to have the ASP.NET request completed through a currently available thread in the pool. (See Figure 1.) <\/p>\n
\"1580-c86b28c1-8680-47a7-8129-a7b46ea45df\"<\/p>\n
FIGURE 1. From the action invoker down to innermost awaiter and back. <\/p>\n
Coordinating Tasks<\/h2>\n
So far we considered the simplest scenario when a single potentially lengthy task is run asynchronously. What if you need to retrieve data from, say, two or more RSS feeds? You probably want to run these tasks in parallel. Here’s how you do that with async\/await. <\/p>\n
public async Task<HomeIndexModel> GetDataForIndexScreen()\n{\n    var client = new HttpClient();\n    var step1 = client.GetStringAsync(...);\n    var step2 = client.GetStringAsync(...);\n\n    \/\/ Assuming that return types from operations are HOMOGENEOUS\n    var results = await Task.WhenAll(step1, step2);\n\n    var model = new HomeIndexModel();\n    model.News1 = ParseRssInternal(results[0]);\n    model.News2 = ParseRssInternal(results[1]);\n    return model;\n} <\/pre>\n
You define two or more Task objects by simply saving the return value of awaitable methods. Variables step1 and step2 are of type Task<String> as String<\/strong> is the type returned by GetStringAsync<\/strong>. Awaiting on the method Task.WhenAll<\/strong> has the effect of resuming execution only when both tasks completed-either successfully or not. Variable results is Task<<\/strong>TResult<\/strong>[<\/strong>]><\/strong> where<\/strong>TResult<\/strong> is the type returned by both operations. If operations return non homogeneous data, or one is just void, you proceed as follows: <\/p>\n
public async Task<HomeIndexModel> GetDataForIndexScreen(){ var client = new HttpClient(); var step1 = client.GetStringAsync(…); var step2 = client.GetAsync(…); await Task.WhenAll(step1, step2); var model = new HomeIndexModel(); \/\/ As return types are not homogeneous need to acquire results separately. \/\/ However, as the operation is COMPLETED, await(s) below return immediately. model.News = ParseRssInternal(await step1); model.Data = ParseRssInternal(await step2); return model;} <\/p>\n
As you can see, await is used twice, but the second time it is used past operations completed. In this case, the code emitted by the compiler doesn’t cause a suspension but returns immediately. <\/p>\n
Finally, there’s the scenario when the results of a previous operation should be used in a subsequent step. You code it in the same way you would do in a synchronous world, except that you wrap it up in an async method and use await modifiers for any step: <\/p>\n
\/\/ First get a list of URL to process from a remote URL\nvar listOfUrls = await client.GetStringAsync(url_to_get_the_list);\n\n\/\/ Next, loop over the list and process URLs separately\nforeach(var url in listOfUrls) {\n    var news = await client.GetStringAsync(url);\n    :\n} <\/pre>\n
One important note: if you use IntelliSense on Task<\/strong> you find two similar looking methods: WaitAll<\/strong> and WhenAll<\/strong>. Only the second works with the async\/await pattern. The former stops execution and waits but doesn’t free up the thread. Put another way, only WhenAll<\/strong><\/strong>is truly asynchronous and leverages the magic of the newest compilers. <\/p>\n
Summary<\/h2>\n
Asynchrony becomes very important when you have to set up complex workflows that consist of several chained\/parallel steps. How many times did you say “if only I could code this synchronously as I always did…”. Now this dream has come true thanks to async<\/strong>\/await<\/strong>. If you’re interested in understanding more about the internal mechanics and find out about corner cases, here’s an article you must read<\/a>. <\/p>\n
\n
 \t\"1555-ANTS_60x60_Logo_CP.gif\"<\/a> \tInterested in how your async code performs? ANTS Performance Profiler 9 has an async profiling mode to help you understand where applications spend their time while doing async work. Try it out now<\/a>.<\/p>\n<\/p><\/div>\n<\/p><\/div>\n","protected":false},"excerpt":{"rendered":"
Asynchrony is essential  for scalability and performance on the server side. Although it has always been possible to write asynchronous code, there has, up to now, been a downside: it is difficult to understand and maintain. Now, with the async\/await. keywords, the whole approach is radically simplified for the programmer.…<\/p>\n","protected":false},"author":221911,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143538],"tags":[4143,4229,4157,5709,5734,4178],"coauthors":[],"class_list":["post-1423","post","type-post","status-publish","format-standard","hentry","category-dotnet-development","tag-net","tag-net-framework","tag-asp-net","tag-async","tag-await","tag-bi"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/1423","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/221911"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=1423"}],"version-history":[{"count":6,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/1423\/revisions"}],"predecessor-version":[{"id":91101,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/1423\/revisions\/91101"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=1423"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=1423"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=1423"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=1423"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}