This is poorly advertised in the documentation, but the way async / await works in a console application is very different from how it works in a user interface application due to the lack of synchronization context in the console application. This article describes the details and gives sample code on how to add one so that the asynchronous / waiting behaves in a more predictable way.
As a rule, you are absolutely right in async / await, which does not necessarily entail multithreading (although things like Task.Run actually lead to the fact that the code in question runs in the thread pool), but (as described in the article I'm connected with ) in async / await console application can work anywhere.
My usual analogy to how async works when working on the same thread is to think of going to a restaurant with 9 other people (10 in total). When the waiter arrives, 9 people are ready, but 10 are not. In this case, the waiter will first take the remaining 9 people, and then return to the 10th person. If for some reason the 10th person is really slow, the waiter can always return orders to the kitchen and return when the 10th person is ready.
It is clear that it makes no sense to attract a second waiter to wait until the 10th guy is ready to order, and it would be clearly ineffective to make everyone else wait until one guy is ready. Adding additional waiters to the situation will not accelerate the situation, because the delay is not caused by the shortage of waiters, due to the fact that the 10-year-old guy slowly decides (and there is nothing that can wait until the waiting staff can do this).
source share