ASP.NET MVC what threadpool is used for custom tasks? - asp.net

Question

In the book Pro ASP.NET MVC 4 there is an example of an asynchronous action:
public class RemoteDataController : AsyncController
{
public async Task<ActionResult> ConsumeAsyncMethod() {
string data = await new RemoteService().GetRemoteDataAsync();
return View("Data", (object)data);
}
}
public class RemoteService
{
public async Task<string> GetRemoteDataAsync() {
return await Task<string>.Factory.StartNew(() => {
Thread.Sleep(2000);
return "Hello from the other side of the world";
});
}
}
My question is: Would the task not just use a thread from the threadpool that is also used for serving requests?
Say I have a synchronous I/O bound method. I think calling this method with Task.Run and await in my action wouldn't lead to more requests that can be handled concurrently because the task for the I/O bound method is not available any longer for request handling. Or is there a separate threadpool only for the requests and using Task.Run in actions automatically uses a different one? What got me thinking is this question: Using ThreadPool.QueueUserWorkItem in ASP.NET in a high traffic scenario where the answer was more or less that only async methods from libraries should be used, where those libraries use their own thread pool.
Is it possible to configure the behavior? Does it work the same way with ASP.NET WebForms?

Answer 1

example
That's a really poor example. There are three things that I see immediately wrong with it, but the major one is as you pointed out:
Would the task not just use a thread from the threadpool that is also used for serving requests?
Yes, that example would.
Please consider this example instead:
public class RemoteDataController : Controller
{
public async Task<ActionResult> ConsumeAsyncMethod() {
string data = await new RemoteService().GetRemoteDataAsync();
return View("Data", data);
}
}
public class RemoteService
{
public async Task<string> GetRemoteDataAsync() {
await Task.Delay(2000);
return "Hello from the other side of the world";
}
}
The original example blocked a thread pool thread using Thread.Sleep. That's completely counterproductive on ASP.NET. As a general rule, do not use Task.Factory.StartNew or Task.Run on ASP.NET.
In contrast, Task.Delay is a naturally-asynchronous operation. By "naturally-asynchronous", I mean asynchronous in the same way that I/O operations are asynchronous (e.g., HttpClient for web calls). Naturally-asynchronous operations do not use threads, hence their appeal for ASP.NET servers (reducing pressure on the thread pool, allowing you to scale more).
It's interesting to think about how this works: when you use naturally-asynchronous methods as in my example, a thread starts the request up until it hits the await; at that point the request thread is returned to the thread pool (!) and for the next two seconds there are no threads processing that request (and yet the request has not completed). I like to call this phenomenon "zero-threaded concurrency". When the Delay finishes, a thread resumes processing the request and completes it.
On a side note, AsyncController is a leftover from MVC3. It is not needed with async/await.