2

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?

Alexander Kozachenko
  • 885
  • 2
  • 13
  • 26
  • 1
    Yeah, familiar experience here. This is caused by so-called "superiors" not keeping up to date with developments... for many years in a row. It's usually a sign that that person should not be a superior (but somehow got promoted to that position probably because all good people left). Once you realize you know more then your superior, but there's no way you'll ever get that position, it's time to look for a different job. – JHBonarius Apr 30 '22 at 07:26
  • 1
    @JHBonarius Or, the "superior" may have a much deeper understanding of the subject than you, so they can see when a tool is fit or not. – GSerg Apr 30 '22 at 07:31
  • 2
    @GSerg in any case: then he/she/they should motivate their decision and teach it to the junior. If somebody has to come here in attempt to understand a superior's decision, that superior isn't doing their job properly. – JHBonarius Apr 30 '22 at 07:40
  • I said that this pattern is standard and blocking on Result or Wait() are anipatterns, also writing it makes my eyes bleed, so I was allowed to do as I deemed necessary. – Alexander Kozachenko Apr 30 '22 at 11:11
  • @AlexanderKozachenko oh, absolutely: if the old code was using `.Result` or `.Wait()`: switch to `async`/`await`, 120% – Marc Gravell May 01 '22 at 14:26

1 Answers1

7

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
Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900