DEV Community

How YOU can make your .NET programs more responsive with async/await in .NET Core, C# and VS Code

Chris Noring on November 12, 2019

Follow me on Twitter, happy to take your suggestions on topics or improvements /Chris When we run synchronous code we block the main Thread from ...

Read full post

Oleksii Holub • Nov 13 '19 • Edited

await Task.FromResult that's a good one 😂
You're confusing Task.Run with Task.Result. The latter doesn't do any calculations, it just returns a completed task that you don't need to await. In fact, awaiting it just creates an unnecessary state machine that can hurt throughput.

Chris Noring • Nov 13 '19

Well the Task result is immediately known, i.e 1+2, which is what I 'm using it for docs.microsoft.com/en-us/dotnet/ap.... Is it the best use of it? Probably not. Could I have been using Task.Run? Probably. The whole point of that method is generally to showcase the async/await combination. I think you are reading too much into a first sample method Alexey. I was making an analogy to Promise.resolve in the JavaScript world...

Oleksii Holub • Nov 13 '19

The point here was that using await with Task.FromResult is unnecessary and counterproductive.

Chris Noring • Nov 13 '19

That I agree with.. I was showcasing async/await .. I will update the text to talk about the difference of Task.Run and Task.FromResult

Slavius • Mar 4 '20

TPL and async/await have nothing in common. I can write code like:

// Calculate prime numbers using a simple (unoptimized) algorithm.

IEnumerable<int> numbers = Enumerable.Range (3, 100000-3);

var parallelQuery = 
  from n in numbers.AsParallel()
  where Enumerable.Range (2, (int) Math.Sqrt (n)).All (i => n % i > 0)
  select n;

int[] primes = parallelQuery.ToArray();
);

and converting it to async/await will not make it any faster if not the opposite.

Async/await has its specialized use cases when calling a method actually needs to spawn another thread (be it a networking or filesystem thread) that pre-empting your own thread within the operating system actually allows for other threads to run.
Please do not make async/await a golden hammer when it is clearly not.

Chris Noring • Mar 4 '20

I appreciate your feedback. Yes, the article is about making programs be more responsive in those specific use cases, i.e File system operations, Web Request.. My examples should have been about that. I also wanted to show how Tasks and async/await worked together, which is why I opted for simpler tasks that didn't do those things. But you are right, it's not a golden hammer, but used correctly can greatly improve your program

Slavius • Mar 5 '20

I didn't want to be rude but IMHO each article should start with a preface where there is mentioned for what it is discussed technology/framework best suited and where it is not.
I appreciate you bringing this topic into focus as it is important. It is rare to see a server with single core nowdays, and parallel programming should be understood by most programmers.

Davide Bellone • Mar 31 '20

Cool! Thanks for sharing :)
Just a tip for who is approaching async programming for the first time: in general it's not a good idea to use .Result since it wraps exceptions into an inner field.
code4it.dev/blog/asynchronous-prog...

Honestly, I haven't tried what happens if an exception occurs while using Task.WaitAny() :)

Jamil Siam • Nov 13 '19

Just to clarify, "Task.WaitAll(...)" is essentially same as "await Task.WhenAll(...)". Please correct me if I am missing something.

If I am correct in my above statement, then shouldn't latter be the best approach to wait for all the tasks to complete?

Chris Noring • Nov 13 '19

WaitAll and WhenAll is very different. WaitAll blocks the code on that line. WhenAll returns directly with a Task.. As for await Task.WhenAll(), yes you can do that... As for one approach is better than another, not sure tbh.. I do know that when I get a task back I have the capability check it's state, cancel it and so on.. With that said, I suppose WhenAll gives us more fine-grained control to affect all three Tasks like cancel all, cancel one etc... With WaitAll I'm stuck at that line so it might be tricky to do anything but just wait. So if we ar talking about more fine-grained control I lean on agreeing with you.

Carlos Caballero • Nov 12 '19

Thanks Chris for this post!

Chris Noring • Nov 12 '19

Thanks Carlos :)

Dean • Nov 13 '19

Hi Chris, awesome article! I have a question. When either WhenAny or WhenAll returns with a task, are the tasks already executing at that point and could finish before interacting with it?

Chris Noring • Nov 13 '19

I would say yes. They are already running.. You can check that on task.Status for a specific Task or var taskWhenAll = Task.WhenAll(t1,t2,t3) and taskWhenAll.Status

amul047 • Nov 12 '19 • Edited

Are you meant to say WaitAll to WaitAny in this section? thepracticaldev.s3.amazonaws.com/i...

Chris Noring • Nov 13 '19

hi... No I mean WhenAll. So WhenAll returns right away, it returns a Task, which means it carries out the next line of code which is to calculate time taken. WaitAll blocks and this why we get a higher time taken.. (We wait until the slowest task in WaitAll have finished until we continue with the next line of code)

amul047 • Nov 13 '19

Awesome, thanks for the clarification

Henry Nitz • Nov 13 '19

Any thoughts on continuations with tasks? I haven't yet had a need to use them, but it seems like a easy way to ensure behaviour executes after a task is completed.

Chris Noring • Nov 13 '19

they are good.. definitely use them. I am linking to them in the references section. I just thought the article was long enough.. :)