I was tasked with containerizing legacy console worker app, which I rewrote using async\await everywhere. My superior questioned my choice, because saw no reason introducing it in isolated single threaded app, where thread pool exhaustion was unlikely. I had no answer to justify using it, apart from it being a standard way to write code for quite some time. Are there any substantial benefits to it?

CodePudding user response：

async/await primarily help solve scalability, and is particularly useful on massively concurrent systems (web-servers etc). This capability does have some (usually small) overhead (the extra semantics involved in async/await - state machines, reactivation, etc). In a concurrent system, this overhead is paying a tiny amount to reap huge rewards (freeing up threads), so is totally worth it.

However, in a single-threaded console application, there may not be any huge direct benefits, if there isn't anything else useful for the CPU to be doing while it awaits. Whether the additional overhead you've added is important is contextual, and requires measurements to discover. I'd say "probably no impact, but there's a chance it is slightly negative".

However, you may still have some advantages:

• you can now consume APIs that are async, and APIs are increasingly becoming async-first or async-only
• you are in a good position if you ever want to migrate your code to a more congested environment

CodePudding user response：

Yes sure. Asynchrony focuses on tasks. You can handle other tasks while one task is underway. For example, executing code in the background does not stop the UI.