Stumbled upon this post that talks about making async web requests.

Now simplicity aside, if in real world, all you do is make an async request and wait for it in the very next line, isn't that the same as making a sync call in the first place?

  • 5
    Not exactly. Your code is synchronous in a sense that nothing happens until you get a result. However underneath, you probably gave up the thread you were running on until the async method returned, then got assigned another thread to continue executing. – R0MANARMY Jan 14 '13 at 16:31
  • 2
    it is but with async you can do another async at the same time and then await the 2, with sync this is not possible – ratchet freak Jan 14 '13 at 16:32
  • Here's an article (tomasp.net/blog/async-compilation-internals.aspx) discussing some of the under-the-hood of async in C# -- it's part of a series covering asynchronous programming in C# and F#. – paul Jan 14 '13 at 16:49
  • @ratchetfreak: Yes, that goes without saying if you're doing multiple calls. – Mrchief Jan 14 '13 at 19:09
  • @R0MANARMY: If your app is doing other things, then yes and async + await enables that. Akim says it best! But imagine the code not being in button_click handler, or any such event handler for that matter. If someone blindly copies the code (async+await lines), to any method, it can lead to fals impression that your code is async but in effect may not be. – Mrchief Jan 14 '13 at 19:12
up vote 27 down vote accepted

No, async + await != sync, because of continuation

From MSDN 'Asynchronous Programming with Async and Await (C# and Visual Basic)'

Async methods are intended to be non-blocking operations. An await expression in an async method doesn’t block the current thread while the awaited task is running. Instead, the expression signs up the rest of the method as a continuation and returns control to the caller of the async method.

For example async execution will not block UI thread, and Some TextBox.Text will be updated after download has finished

private async void OnButtonClick()
{
   SomeTextBox.Text = await new WebClient().DownloadStringTaskAsync("http://stackoverflow.com/");
}
  • Very nicely said! – Mrchief Jan 14 '13 at 19:13
  • Could you explain in more detail. Are you saying... that without this... you would not be able to interact with the UI... as this would be on the main thread. So does this mean that this only become applicable in a application type program apposed to web where interaction is separate from the web server thread. So in a nut shell this only become important i.e. not sync* when your main thread is the running thread. Wouldn't this create unexpected behavior, i.e. in a App(1 main thread) two buttons clicked.. but you should be able to click the 1 without the first completing? – Seabizkit Dec 7 '16 at 9:38

No it's not the same.

Your async code block is waiting for the await call to return to continue, however the rest of your application isn't waiting and can still continue like normal.

In contrast, a synchronous call would make your entire application or thread wait until the code finished executing to continue on with anything else.

  • couldn't the sync call be implemented as async+await? – ratchet freak Jan 14 '13 at 16:35
  • @ratchetfreak I think there's some overhead to setting up await/async, so I don't think you'd want to code your entire application with it. I only use it for executing potentially long-running blocks of code so it doesn't lock up my applications. :) – Rachel Jan 14 '13 at 16:39

Please allow me to clarify things in regards to async/await.

When await is encountered the underlying state machine allows control to be returned immediately. Then, when the awaited call is completed, the underlying state machine allows execution to resume at the line after the awaited call.

Therefore, the async block is not blocked nor is it waiting for the awaited call to finish; Control is returned immediately when the await command is encountered.

The underlying state machine is part of the "magic" behind the use of async/await that is not disused and missed.

I stumbled on this with the same question in mind, yet after reading the responses the question seems to linger, confused by references to "magic under the hood".

From the above-mentioned Asynchronous Programming :

  • The async keyword turns a method into an async method, which allows you to use the await keyword in its body.
  • When the await keyword is applied, it suspends the calling method and yields control back to its caller until the awaited task is complete.
  • await can only be used inside an async method.

Does the context that encounters await get blocked?

  • Yes. That's essentially a local sync barrier to maintain a known state in the context of the execution; except that other contexts, if any, are not joined.

Does the rest of the application block at the await?

  • It depends on how your application is written. If it's a series of dependent awaited tasks launched sequentially in the same context (see: Trying to understand some async/await behavior)

    await asyncCall1();
    await asyncCall2();  // waits for asyncCall1() to complete
    

    this way each await would block spawning of the next one.

    On the other hand, the same dependent tasks launched in parallel would execute in parallel and the context would only block at the resp. await:

    Task<int> t1 = asyncCall1();
    Task<string> t2 = asyncCall2();  // runs in parallel with asyncCall1()
    int val = await t1;
    string str = await t2;  // waits for asyncCall1() to complete
    

    In general, the await yields execution to the outer context, from where the current context is called. However, if the outer context itself is awaiting for the current, then it's like a sequential awaits in the same context.

So, to reap the async benefits, one needs to design the application to run several parallel contexts (UI, data-client etc.), then await in one context yields execution to other contexts, so the whole application would not block on an individual await.

protected by gnat Aug 26 at 19:19

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.