0

The await operator suspends evaluation of the enclosing async method until the asynchronous operation represented by its operand completes

But according to this post:

//You can access the Result property of the task, 
//which will cause your thread to block until the result is available:

string code = GenerateCodeAsync().Result;

Does that mean that we don't need await anymore? Because if we use await, we have to change the function to async which complicates the logic. But accessing the result property of a task doesn't require this

camino
  • 10,085
  • 20
  • 64
  • 115
  • 2
    as the comment is hinting, the use of await/async makes this code _not blocking the current thread. This can be of importance, for instance if you get this function called on a server, then you risk experiencing thread starvation. (The server will have to refuse new connection if no thread is available because they are just waiting). Or if the UI thread is being used, your UI will freeze while waiting for the result. I – Pac0 Dec 28 '21 at 20:58
  • Hmm, by putting in the word 'still', is it no longer a duplicate? – Poul Bak Dec 28 '21 at 21:05
  • 1
    Using `.Result` basically smashes the entire point of async on the ground, then does a dance on it, singing "neh neh neh". It is incredibly harmful, and can also in some scenarios cause deadlocks. Do not do that, ever (there is a tiny caveat around "except when you know it has already completed successfully", but that doesn't apply in the general case). So yes: you need `await` – Marc Gravell Dec 28 '21 at 21:14

3 Answers3

9

100x yes - await is important. .Result will block the calling thread until the result is produced. await allows the runtime to suspend and wake up subsequent code only when needed, not blocking any thread. In practice, the await can wake up on a completely different thread.

A little tidbit of history: Task<T> and its .Result were added as part of the C# 4.0 and the Task Parallel Library, well before async & await.

Daniel A. White
  • 187,200
  • 47
  • 362
  • 445
2

I think a common misconception with the async/await pattern is that suspending execution == blocking for the result. This however is not true. When you call await your program doesn't actually stop execution, it pushes the thread into a waiting queue which will be resurrected upon IO completion. This allows other tasks to run in the meantime. While technically you could always block for the result and have the same code output, your code will run a lot faster by using await.

Jordan Bonecutter
  • 160
  • 7
  • 1
    "faster" isn't the right word; usually, a *single* operation will be slightly faster **without** async. Async isn't about "faster" - it is about "scalable". When you have *lots* of things happening, that's when you reap the performance rewards. – Marc Gravell Dec 28 '21 at 21:17
  • If you have a lot of concurrent IO bound tasks, your code will (almost certainly) run faster – Jordan Bonecutter Dec 28 '21 at 21:24
  • Thanks for clarify the misconception – camino Dec 28 '21 at 21:29
0

GenerateCodeAsync().Result in this case just removes asynchronous from your code.

NightmareZ
  • 41
  • 5