and it makes sense in case of console application or winforms application . main thread returns back and long running method can execute on a separate thread ..
Now my questions is for web app like MVC or web API .
web scenario :
-suppose browser sends request that IIS/ASP.net framework is executing on a thread called T1.
-in one of the controller/action executing on T1 , it calls another method "longRunningMethd " , this long running method is using async await .
question :
is it possible that response will come back to browser before "longRunningMethd " is complete ? in others words , can thread T1 complete before "longRunningMethd " is complete?
i have more follow up questions but i would ask that based on answer to this first question.
The async/await programming pattern works the same in a console application as it does running on a web server.
sidd2526
is it possible that response will come back to browser before "longRunningMethd " is complete ? in others words , can thread T1 complete before "longRunningMethd " is complete?
In a typical ASP.NET Core application all async methods are awaited within an action because the UI is usually dependent on the results of the async operations. These are generally non CPU intensive operations like calling a service or invoking a query.
If you do not await an async method then yes the action can return before the async method completes which is usually not what you want.
The example link is not a good example of async methods IMHO. Task.Run is for CPU intensive tasks and it blocks which is very bad in a web applications. Remember a web application is a single programming that server many users. If you block one of the
actions then others request may have to wait depending on load. I recommend reading the official C# documentation to understand async/await.
If you use await then the request will complete after "longRunningMethod" finishes. (The sort of thing you do if the method needs to get remote data in order to build the response)
If you do not use await but rather just start a thread and ignore it then the request will probably complete
before "longRunningMethod" finishes. (The sort of thing you do if the method updates statistics or stock levels that is not needed to build the response).
So, the answer is … what do you want to happen and what are you asking it to do?
Yes, If a small task begin before long task then it can come back with result when job finished.
async method with await yield the result.
------------------------------------------------
Actually in action method you have to await for the result of another method and then you return View() as response,for a particular case where you get result of SyncMethod() you need to write it to response explicitly if you want to see result on
UI.
------------------------------------------------
Task.Run() is expensive in web application and it take thread from thread pool to do some operation in web application and as respected mgebhard said that its not best practice to use in web
apps.
We cannot solve our problems with the same thinking we used when we created them.
No it doesn't tell anything about how it is implemented and actually my understanding is that most if not all I/O operations are using an efficient OS mechanism to wait for I/O completion ("completion port"). At the await, the current method is exited so
that so that the CPU could do something else and once the IO completed, it will resume execution after the await. In short, this is an easy way to perform async I/O with synchronous like code and won't change the overall execution timing (unless you don't
"await").
while async / await can be used with multiple threads, async operation can also be on the same thread. asp.net core has a limited number of request processing threads (cpu count - 1). it depends on async operations on the same thread for performance. (its
model was node.js which has only one request processing thread).
when orchestrating threads, often the controlling thread wants to block until the other threads complete. for this you use thread.Join(). but if the controlling thread wants to do concurrent processing with the other thread, it can use an await or continue.
awaits don't block, but perform a callback when completed. async / await is syntax sugar to make the callback chain simpler.
in MVC action there is a request / response. once the response is sent (action return), no more data can be sent to the browser. if the requests starts a background thread, then it has tow options. fire and forget, that start the thread and don't worry about
the response. if the response must include data from the background thread, then it must await for completion before the actions returns. while thread.Join() would logical work, this blocks the current thread and would affect performance. in asp.net core you
need to awaits, so the request thread can process another request while waiting for the background process.
Member
4 Points
24 Posts
Understanding async/await - thread.join in context of a web request , thread.background =true...
Oct 28, 2019 09:12 PM|sidd2526|LINK
Guys ,
my understanding is that async /await will execute request on a separate thread so that main thread is not blocked .
this 5 minute video explain it pretty well .
https://www.youtube.com/watch?v=V2sMXJnDEjM
and it makes sense in case of console application or winforms application . main thread returns back and long running method can execute on a separate thread ..
Now my questions is for web app like MVC or web API .
web scenario :
-suppose browser sends request that IIS/ASP.net framework is executing on a thread called T1.
-in one of the controller/action executing on T1 , it calls another method "longRunningMethd " , this long running method is using async await .
question :
i have more follow up questions but i would ask that based on answer to this first question.
Thanks in advance!!
All-Star
44341 Points
19129 Posts
Re: Understanding async/await - thread.join in context of a web request , thread.background =t...
Oct 28, 2019 09:48 PM|mgebhard|LINK
The async/await programming pattern works the same in a console application as it does running on a web server.
In a typical ASP.NET Core application all async methods are awaited within an action because the UI is usually dependent on the results of the async operations. These are generally non CPU intensive operations like calling a service or invoking a query. If you do not await an async method then yes the action can return before the async method completes which is usually not what you want.
The example link is not a good example of async methods IMHO. Task.Run is for CPU intensive tasks and it blocks which is very bad in a web applications. Remember a web application is a single programming that server many users. If you block one of the actions then others request may have to wait depending on load. I recommend reading the official C# documentation to understand async/await.
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/
Participant
1070 Points
569 Posts
Re: Understanding async/await - thread.join in context of a web request , thread.background =t...
Oct 28, 2019 09:53 PM|PaulTheSmith|LINK
"It calls another method"
or is it that
"It awaits another method"?
If you use await then the request will complete after "longRunningMethod" finishes. (The sort of thing you do if the method needs to get remote data in order to build the response)
If you do not use await but rather just start a thread and ignore it then the request will probably complete before "longRunningMethod" finishes. (The sort of thing you do if the method updates statistics or stock levels that is not needed to build the response).
So, the answer is … what do you want to happen and what are you asking it to do?
Contributor
2016 Points
1024 Posts
Re: Understanding async/await - thread.join in context of a web request , thread.background =t...
Oct 29, 2019 04:09 AM|Khuram.Shahzad|LINK
Yes, If a small task begin before long task then it can come back with result when job finished.
async method with await yield the result.
------------------------------------------------
Actually in action method you have to await for the result of another method and then you return View() as response,for a particular case where you get result of SyncMethod() you need to write it to response explicitly if you want to see result on UI.
------------------------------------------------
Task.Run() is expensive in web application and it take thread from thread pool to do some operation in web application and as respected mgebhard said that its not best practice to use in web apps.
All-Star
46040 Points
16771 Posts
Re: Understanding async/await - thread.join in context of a web request , thread.background =t...
Oct 29, 2019 09:39 AM|PatriceSc|LINK
Hi,
No it doesn't tell anything about how it is implemented and actually my understanding is that most if not all I/O operations are using an efficient OS mechanism to wait for I/O completion ("completion port"). At the await, the current method is exited so that so that the CPU could do something else and once the IO completed, it will resume execution after the await. In short, this is an easy way to perform async I/O with synchronous like code and won't change the overall execution timing (unless you don't "await").
All-Star
53954 Points
13506 Posts
Re: Understanding async/await - thread.join in context of a web request , thread.background =t...
Oct 29, 2019 03:33 PM|bruce (sqlwork.com)|LINK
while async / await can be used with multiple threads, async operation can also be on the same thread. asp.net core has a limited number of request processing threads (cpu count - 1). it depends on async operations on the same thread for performance. (its model was node.js which has only one request processing thread).
when orchestrating threads, often the controlling thread wants to block until the other threads complete. for this you use thread.Join(). but if the controlling thread wants to do concurrent processing with the other thread, it can use an await or continue. awaits don't block, but perform a callback when completed. async / await is syntax sugar to make the callback chain simpler.
in MVC action there is a request / response. once the response is sent (action return), no more data can be sent to the browser. if the requests starts a background thread, then it has tow options. fire and forget, that start the thread and don't worry about the response. if the response must include data from the background thread, then it must await for completion before the actions returns. while thread.Join() would logical work, this blocks the current thread and would affect performance. in asp.net core you need to awaits, so the request thread can process another request while waiting for the background process.