Task.Run() be or not to be with await call together

Question

After reading lot of articles and this forum itself i came to some conclusion i would like to confirm. Please of your answer. Let's assume our example async method presents as below. Please read also comments in code i placed. Let's assume that in this case both getStringTask and DoIndependentWork() takes quick therefore entire async method AccessTheWebAsync() would take quick job:

async Task<int> AccessTheWebAsync()  
{    
   HttpClient client = new HttpClient();   
   Task<string> getStringTask = client.GetStringAsync("https://msdn.microsoft.com"); //assume it is quick job http request
   DoIndependentWork(); //assume it is quick job for loop
   string urlContents = await getStringTask;  
   return urlContents.Length;  
}

Then calls from diffrent places would look like:

//example caller from some UI : either Froms or WPF
private async void StartButton_Click(object sender, RoutedEventArgs e)  
{   
   Task<int> getLengthTask = AccessTheWebAsync(); //it' call from UI but but still no need await Task.Run(AccessTheWebAsync) just await cause AccessTheWebAsync takes quick job
   SomeIndependentWorkMethodHere;.  
   int contentLength = await getLengthTask ();  
} 

//Call from Console application
private async static void Main()  
{   
   Task<int> getLengthTask = AccessTheWebAsync();           
   SomeIndependentWorkMethodHere;.  
   int contentLength = await getLengthTask (); //no need Task.Run() at all just await
} 

//Call from project library or aspnet controller
private static void MyMethod()  
{   
   Task<int> getLengthTask = AccessTheWebAsync();  
   SomeIndependentWorkMethodHere;.  
   int contentLength = await getLengthTask (); //no need Task.Run() at all just await
} 

Is this true that because our async method is taking quick job no matter from where it is called either UI/library/console app it is just need to use call like below means:

await getLengthTask ();  

Let's now consider same situation but consider either both of operations in async method would take long or just one of them:

async Task<int> AccessTheWebAsync()  
{    
   HttpClient client = new HttpClient();   
   Task<string> getStringTask = client.GetStringAsync("https://msdn.microsoft.com"); //assume it is long job http request
   DoIndependentWork();  //assume it is long job for loop
   string urlContents = await getStringTask;  
   return urlContents.Length;  
}  

Does this change situation to this? :

//example caller from some UI : either Froms or WPF
private async void StartButton_Click(object sender, RoutedEventArgs e)  
{     
   SomeIndependentWorkMethodHere;.  
   await Task.Run(() => AccessTheWebAsync()); // <------ NOW additional Task.Run() is placed 
} 

//Call from Console application
private async static void Main()  
{   
   Task<int> getLengthTask = AccessTheWebAsync();  // <------- no need to change it's console even if async method is long (just await)
   SomeIndependentWorkMethodHere;.  
   int contentLength = await getLengthTask ();  
} 

//Call from project library or aspnet controller
private static void MyMethod()  
{   
   Task<int> getLengthTask = AccessTheWebAsync();  // <------- no need to change it's library project (or asp.net controller) even if async method is long (just await)
   SomeIndependentWorkMethodHere;.  
   int contentLength = await getLengthTask ();  
} 

In this case for UI related call Task.Run additionally has been added on await method because it's UI and we operate on long running async method. For rest console app and library project (or even for asp.net controller) signature still not changed.

Is my understanding correct? Summarizing it would mean only from UI related calls i need to add additional Task.Run so await Task.Run(asyncMethod) BUT ONLY IF if the async method as a whole could take a long time otherwise await would be just enough. But for rest library projects, console apps, asp.net controllers it's always just to use withotut Task.Run means await asynMethod() no matter either async method would take quick job or not.

Answer 1

I am sure that @mjwills has answered this to death.

However lets put it simply. You only have 2 concerns :

• Is this method going to going to block the thread
• and do you care.

Since you have CPU and IO mixed operations, the first concern is answered.

Do you care? Well... if you do, and you are in any fear of blocking the UI thread or any other thread, your only sensible option is Wrap in it in a Task (and in some situations await it). If you don't care, then there is no need.

Its rare that you would want to mix IO and CPU. But yeah, we write libraries, and business layers, and this happens. If you are in a context where this is a problem, well there is not much more you can other than wrap it.

Update

IO is defined usually by anything that uses an IO completion port, I.e access a network or the file system, etc, etc.

CPU workload is usually defined, by anything that uses the CPU, calculation, Big for loops of logic. Anything that really isn't IO based.

Update

This question has been down every rabbit whole imaginable

When it all washes-out, the question asks should i wrap an async method which contains a blocking CPU workload in a task and wait for it.

CPU workloads block and will not relinquish the thread unless its fake async, i.e. it has internally wrapped the CPU workload in a task. This is less the optimal design and should be clearly documented.

However,

• If you are in a server environment, there is no point creating a new thread/Task and waiting on it, you achieve no scalabilty points, taken an extra thread, and the caller still has to wait.

• If you are in a UI thread, and you don't want to stall the UI, then yes its more appropriate to spin up a new task to complete this workload and await it (If you don't want to stall the message pump or message queue, meaning you don't want to stall the UI).

• If you are in a console app, the awaited task (IO or CPU) will block no-matter-what. Do you care if it blocks? if you do, then run the method in a thread and give back control to the Console and don't await it, as it doesn't make any sense.