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?

  • 4
    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 ( 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 26 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("");
  • 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.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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