1

I do not understand , i have seen that there are many methods provided by the .Net Framework that have both async and non-async variants.

My question is what advantage does an async method provide me given the following constraints: - I will not fetch the Task.Result multiple times in the same method
- I am not using CPU-bound tasks (Task.Run(...))

I am in a MVC controller and i want to process a post request:

 [HttPost]
 [Route(..)]
 public async Task DoSomething(MyModel model)
 {  
    var asyncResult=await NETMethodAsync(model); //PostAsync,WriteAsync....
    var nonAsyncResult= NETMethod(model); //Post,Write,....etc..
    return result;
 }

In this case i will use the result only once in my method and i will not demand it multiple times ( where await would just give me the completed task-result) what is the difference ? I am basically creating a StateMachine in my MethodAsync for what? I could do the operation non-async faster i suppose.

If i am not delegating the method on a separate Task (like below) why would i use the async version ? I am asking because even the MVC Controller templates by default provide all CRUD operations using the async versions.

Task tsk=Task.Run(async()=> await MethodAsync() );

P.S In my scenario is it something that i missed.Is it faster to use the async (that internally spins a state-machine) ,then the non-async version ?

Bercovici Adrian
  • 8,794
  • 17
  • 73
  • 152
  • 2
    It's *precisely* when you have IO-bound tasks that you don't want to wait until the disk, database or remote site responds. Whether that `MethodAsync` is justified or not is impossible to say since you didn't post the code. – Panagiotis Kanavos Feb 22 '19 at 11:18
  • But the act of `await`-ing is blocking the calling thread (while the `Result` has not been computed) – Bercovici Adrian Feb 22 '19 at 11:19
  • 1
    No it's not. The original thread is *released* and can server other requests. `await` awaits already asynchronous operations and resumes execution in the original synchronization context. For an ASP.NET Core application `async/await` means that fewer threads can service more requests. Or, if you have a high traffic site, *fewer servers* are needed to handle the same volume – Panagiotis Kanavos Feb 22 '19 at 11:20
  • Also note that `await Task.Run(...)` doesn't help at all - the original thread is released only for execution to continue on a *new* thread. Might as well stay in the original thread in this case and avoid switching. – Panagiotis Kanavos Feb 22 '19 at 11:23
  • 1
    Check [Why your ASP.NET Core application won't scale - Damian Edwards, David Fowler](https://www.youtube.com/watch?v=-cJjnVTJ5og). They explain the various things that can harm scalability in an ASP.NET Core application. – Panagiotis Kanavos Feb 22 '19 at 11:23
  • Possible duplicate of [Why use Async/await all the way down](https://stackoverflow.com/questions/29808915/why-use-async-await-all-the-way-down) – Peter B Feb 22 '19 at 14:15
  • Possible duplicate of [How and when to use ‘async’ and ‘await’](https://stackoverflow.com/questions/14455293/how-and-when-to-use-async-and-await) – maracuja-juice Feb 22 '19 at 21:02

1 Answers1

11

what is the difference?

Scalability. Specifically, synchronous methods block the calling thread, and asynchronous methods do not.

What this means (for an ASP.NET application) is that synchronous action methods block the request thread for the duration of the request, and that asynchronous action methods do not block that thread.

This, in turn, yields greater scalability. Since the thread pool is a limited resource (and in particular, since it has a limited thread injection rate), asynchronous code allows your app to handle greater load with fewer threads.

For more information, see the "Synchronous vs. Asynchronous Request Handling" section in my article on async ASP.NET; that section of the article applies to all server technologies, including ASP.NET Core. You can also check out this gist which demonstrates the scalability difference by limiting the thread pool growth rate. I haven't ported that example to ASP.NET Core, but it should be straightforward to do.

Stephen Cleary
  • 437,863
  • 77
  • 675
  • 810
  • But when you say `await something(); somethingElse();` ,you can't pass to `somethingElse` ,so basically your thread `blocks` at that command. It's not like putting `something()` in another thread. – Bercovici Adrian Feb 22 '19 at 14:21
  • @BercoviciAdrian: If your async action method does `await something();`, then the request thread is returned to the thread pool. Later, when `something` completes, *another* request thread is taken and resumes executing the async action method, calling `somethingElse();` on that thread. – Stephen Cleary Feb 22 '19 at 14:25
  • So whenever i am `await`-ing the i won't be able to pass through to the next `instruction` but the thread that reached that point is basically freed, while another thread will return my result and continue the method where it was left (pre-await). – Bercovici Adrian Feb 22 '19 at 14:35
  • Yes, [`await` pauses the method and returns to the calling code](https://blog.stephencleary.com/2012/02/async-and-await.html). – Stephen Cleary Feb 22 '19 at 14:36