1

For weeks, no months I have been baffled by these now seen as simple terms await and async, I feel like I've finally learnt them. I use to think they were such advanced topics, and it really did take me such a long time to come to terms with what they actually meant.

I was wondering, even though I feel confident I understand them, anyone could verify? And sort of chip in if I've got anything wrong or you think I don't quite understand something 100%.

Async - Literally just an access modifier, nothing else, it has no effect other than a naming convention to let the caller know that it has some chance of containing the await keyword. it also allows the visual studio to warn us if we don't add an await keyword.

Await - Waiting for some sort of asynchronous code to complete, while blocking the code after it until it has been completed, ensure we get some kind of result or some work has been done.

How did I do, did I pass the test? I do have 1 question...

If we append the word Async to our method name when including await why do we need the async access modifier, is this for VS/C#'s benefit so it can warn us, or is there something more important I should understand about it.

Jan Edan
  • 69
  • 6
  • 1
    `await` is more like taking a F1 car into the pits. It's no longer in the race, it's no longer running. It returns to the race once its work (I/O) is done. – ProgrammingLlama Mar 15 '18 at 04:08
  • But it blocks all the other code (or in your story, F1 cars) from progressing on the tracks until he has got his damn tiers changed, right? – Jan Edan Mar 15 '18 at 04:14
  • 1
    Other F1 cars are other concurrent work. The idea of async/await is that you can release your thread back to the pool while i/o work is being done. If the racetrack is the thread pool, then the F1 car entering the pits allows that thread to be reused elsewhere until the F1 car rejoins the race. A good scenario to imagine is a web server with many requests from many users. awaiting i/o work allows your server to handle other requests in the meantime. – ProgrammingLlama Mar 15 '18 at 04:27
  • It sounds like you have very little understanding of it. The whole point of async/await is that it’s _not_ blocking anything. Also, why would you expect the method names to bear any relevance? It’s merely a _suggestion_ that you append “Async” to a method name. This has nothing to do with functionality, just makes it easier to discern the sync/async methods. – maccettura Mar 15 '18 at 05:06
  • https://learn.microsoft.com/en-us/dotnet/standard/asynchronous-programming-patterns/task-based-asynchronous-pattern-tap – Paulo Morgado Mar 15 '18 at 07:32
  • @john but when running an async task, that introduces another thread, which adds to the threadpool too. I've seen multiple examples where it uses "await request.GetResponseAsync()", why not just use request.GetResponse() ? The net thread count in the threadpool for both cases should be the same right? – EricChen1248 Mar 15 '18 at 09:01
  • 1
    @EricChen I recommend reading [this](https://stackoverflow.com/q/37419572/3181933) question and the answers. It has been answered by people far smarter than me :) – ProgrammingLlama Mar 15 '18 at 09:11

0 Answers0