Understanding Async Await in AspNet 6
1. After playing with Async Await in Asp.net Application I found that when you use Await on a function, it waits until that function completes executing, I know what you are thinking, this sounds like the exact opposite from what the documentation states? Yes, at least to my experience.
I tested this theory using Microsoft Asp.Net Channels API and try to await for a Channel.WriteAsync() function then move on to Await the Channel.ReadAsync().
What I found was that the Await Channels.WriteAsync() function blocked the Main Thread even when I indicated to the function to run in the background.
e.g. Await Channel.WriteAsync().ConfigureAwait(false);//This function call blocked the UI Thread resulting in no rendering until it finished executing
Await Channel.ReadAsync().ConfigureAwait(false);//This function call did not execute until the Channel.WriteAsync() completed writing
Best Solution:
I also found out that if you want the UI Thread to go on rendering the UI or Page while the Channel.WriteAsync() and Channel.ReadAsync() executed in the background then prifix you code by:
_= Channel.WriteAsync().ConfigureAwait(false);
_= Channel.ReadAsync().ConfigureAwait(false);
Did you know you could edit this article?
When you await a task on a UI thread, this blocks the UI thread from processing new tasks I.E. returning back the response to the caller (in this case the Browser).
[Rule of Thumb]
Do less on the UI thread mainly in the Controller Function that returns a View. This is your bread and butter in terms of performance and responsiveness.
If you are writing App Level Code DO NOT USE ConfigurerWait(false). This might cause problems when the tasks run a little longer than expected, as the Task will not return to the caller Awaiting the result or the Task will be scheduled to be run on a different thread but will not report back to the caller Main Thread (UI thread) which might cause a bug.
On the other side, if Code does not need to be called back on and bind data to the UI component then it is safe to use the ConfigurerWait(false). This way, you are telling the RunTime to process the Task on a different Thread and never mind reporting back to the caller.
ConfigurerAwait(false) makes the code execution run faster as it is the same as Fire and Forget. In some cases, ConfigurerWait(false) might not be processed on a different thread, it might end up getting processed on the Main Thread (UI) considering how fast or overloaded the UI Thread is. In this case, then you should be okay to use ConfigurerWait(false). However, make sure you understand what it does before using it that might introduce a bug.
On the brighter side, use ConfigurerWait(false) in the Library (UI Agnostic) project that does not know of the Caller. This way the IO or Database bound request can be processed using an Async Await and even ConfigurerAwait(false) added to the request call.
I followed this programming paradigm and my code started to run faster. Leave a comment below if this is of any help to you.
You should never use Async Await for UI Bound Calls, use them when calling the Database, or a Backend Service.
+1 888-688-2939 
Mark said:
Async Await is never for Performance but for Scalability, when you talk scaling up the Application, code execution on different threads makes sense.