8

I had a situation recently where I had an ASP.NET WebAPI controller that needed to perform two web requests to another REST service inside its action method. I had written my code to have functionality separated cleanly into separate methods, which looked a little like this example:

public class FooController : ApiController
{

    public IHttpActionResult Post(string value)
    {
        var results = PerformWebRequests();
        // Do something else here...
    }

    private IEnumerable<string> PerformWebRequests()
    {
        var result1 = PerformWebRequest("service1/api/foo");
        var result = PerformWebRequest("service2/api/foo");

        return new string[] { result1, result2 };
    }

    private string PerformWebRequest(string api)
    {
        using (HttpClient client = new HttpClient())
        {
            // Call other web API and return value here...
        }
    }

}

Because I was using HttpClient all web requests had to be async. I've never used async/await before so I started naively adding in the keywords. First I added the async keyword to the PerformWebRequest(string api) method but then the caller complained that the PerformWebRequests() method has to be async too in order to use await. So I made that async but now the caller of that method must be async too, and so on.

What I want to know is how far down the rabbit hole must everything be marked async to just work? Surely there would come a point where something has to run synchronously, in which case how is that handled safely? I've already read that calling Task.Result is a bad idea because it could cause deadlocks.

Yuval Itzchakov
  • 146,575
  • 32
  • 257
  • 321
Peter Monks
  • 4,219
  • 2
  • 22
  • 38
  • I'm debating whether this qualifies as a duplicate: http://stackoverflow.com/questions/9208921/async-on-main-method-of-console-app – spender Aug 28 '14 at 16:35
  • 1
    you could watch this great video about async on channel9 - http://channel9.msdn.com/events/TechDays/Techdays-2014-the-Netherlands/Async-programming-deep-dive – terrybozzio Aug 28 '14 at 16:36
  • 1
    Another excellent resource is the Eduasync series of blog posts by Jon Skeet http://codeblog.jonskeet.uk/category/eduasync/ – softveda Aug 29 '14 at 11:13

2 Answers2

13

What I want to know is how far down the rabbit hole must everything be marked async to just work? Surely there would come a point where something has to run synchronously

No, there shouldn't be a point where anything runs synchronously, and that is what async is all about. The phrase "async all the way" actually means all the way up the call stack.

When you process a message asynchronously, you're letting your message loop process requests while your truly asynchronous method runs, because when you go deep down the rabit hole, There is no Thread.

For example, when you have an async button click event handler:

private async void Button_Click(object sender, RoutedEventArgs e)
{
    await DoWorkAsync();
    // Do more stuff here
}

private Task DoWorkAsync()
{
    return Task.Delay(2000); // Fake work.
}

When the button is clicked, runs synchronously until hitting the first await. Once hit, the method will yield control back to the caller, which means the button event handler will free the UI thread, which will free the message loop to process more requests in the meanwhile.

The same goes for your use of HttpClient. For example, when you have:

public async Task<IHttpActionResult> Post(string value)
{
    var results = await PerformWebRequests();
    // Do something else here...
}

private async Task<IEnumerable<string>> PerformWebRequests()
{
    var result1 = await PerformWebRequestAsync("service1/api/foo");
    var result = await PerformWebRequestAsync("service2/api/foo");

    return new string[] { result1, result2 };
}

private async string PerformWebRequestAsync(string api)
{
    using (HttpClient client = new HttpClient())
    {
        await client.GetAsync(api);
    }

    // More work..
}

See how the async keyword went up all the way to the main method processing the POST request. That way, while the async http request is handled by the network device driver, your thread returns to the ASP.NET ThreadPool and is free to process more requests in the meanwhile.

A Console Application is a special case, since when the Main method terminates, unless you spin a new foreground thread, the app will terminate. There, you have to make sure that if the only call is an async call, you'll have to explicitly use Task.Wait or Task.Result. But in that case the default SynchronizationContext is the ThreadPoolSynchronizationContext, where there isn't a chance to cause a deadlock.

To conclude, async methods shouldn't be processed synchronously at the top of the stack, unless there is an exotic use case (such as a Console App), they should flow asynchronously all the way allowing the thread to be freed when possible.

Community
  • 1
  • 1
Yuval Itzchakov
  • 146,575
  • 32
  • 257
  • 321
  • Good answer. As an optimization, one could also make the case that the two calls to `PerformWebRequestAsync` could be made in parallel and awaited with `Task.WhenAll`. Of course, this assumes that the result of the first call is not needed by the request of the second call. – Matt Johnson-Pint Aug 28 '14 at 17:53
  • @MattJohnson Thanks matt, i thought of that, but didn't want to change the OP's original code too much, to put him in context inside the answer. – Yuval Itzchakov Aug 28 '14 at 18:11
  • 1
    Thank you @YuvalItzchakov, that explains a lot to me, especially when used in a `Main()` method (which I was also wondering about). Sounds to me that while `async/await` makes this all a lot easier there are design considerations to think too about before just bolting it in - like understanding how much code you might have to change to add even one `async` method. – Peter Monks Sep 01 '14 at 12:15
0

You need to "async all the way up" to the very top of the call stack, where you reach a message loop that can process all of the asynchronous requests.

Servy
  • 202,030
  • 26
  • 332
  • 449