Settling the Biggest Await Async Debate in .NET
Vložit
- čas přidán 21. 12. 2022
- Join the NDC Conferences Giveaway: mailchi.mp/nickchapsas/ndc
Check out my courses: dometrain.com
Become a Patreon and get source code access: / nickchapsas
Hello everybody I'm Nick and in this video I will take a look at one of the biggest await async debates in .NET and try to find the best answer for each usecase.
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: bit.ly/ChapsasGitHub
Follow me on Twitter: bit.ly/ChapsasTwitter
Connect on LinkedIn: bit.ly/ChapsasLinkedIn
Keep coding merch: keepcoding.shop
#csharp #dotnet
![[실시간] 전철에서 찍힌 기생생물 감염 장면 | 기생수: 더 그레이](http://i.ytimg.com/vi/4nkFvwxGAfA/mqdefault.jpg)
Yes, please make a video on ConfigureAwait! Great video, thank you
I have only one question to "ConfigureAwait", why they didn't make false as default?!))
This is one of the worst things about async in legacy code..
Would love to also get your thoughts on legacy code, specifically .NET Framework 4.7.1
yes yes, we do need this topic in detail please thank youuu.
Actually my interest on ConfigureAwait extends to MAUI where they only ever load libs as either singleton or transient (concept of scope is a bit irrelevant on a single user app) but specifically the impact of async on a UI app where a lot of this stemmed from (if my memory serves)
Unless you have measured this is a hot path, avoiding async/await is a premature optimization in my opinion. Some people think many tiny performance gains will add up. But I think in most cases the bottleneck will be something else and the impact of async/await will be negligible. On the other hand, even if a method simply forwards the async call, losing the stack frame can result in losing time when debugging the code later. Especially if there are many layers of "forwarded async methods", it may be very hard to tell how execution ended up in a certain method.
Of course, this doesn't apply to well-tested libraries that we wouldn't want to debug at all. That's why HttpClient doesn't use async/await where possible for example. Another reason is that library code doesn't "know" how it will be used, so it has to be optimized just in case.
Note that I have encountered cases where a hot path actually benefited from removing async/await. But these cases are very rare from my experience. And I always had to measure performance before deciding how to optimize such cases anyway.
I literally can’t get enough of these videos. And I actually use all this knowledge for my job.
Thank you for all your content!
Only for your job?
ALSO for their job 😉
Use of async/await for sure. Even though the use of disposable is a big deal, the debugging problem is away bigger than that. Getting a more accurate exception stack is, in the majority of the scenarios, much more important than performance.
Great video!! I'm typically in the return Task camp myself. And I'd LOVE a video on ConfigureAwait as I've seen/read different things about whether or not it is needed in APIs.
I definitely prefer async/await personally. It's clearer to support and understand, especially on a large team of contributors, and the loss of performance in negligible in the vast majority of use cases.
I used to use Task returns myself and also recommended doing the same to others because it looked slightly more clear and I thought it would make fewer calls in the framework. However, once we struggled to diagnose and troubleshoot exceptions efficiently, I quickly switched to using 'await' everywhere. There is no debate, Task returns are evil.
This is video is SO TIMELY. We're currently implementing async to our entire codebase. THANK YOU!
Great video, I've followed the rule of eliding await for "forwarding methods" and middleware, otherwise always await (unless it's performance critical). I like that you are sharing the nuance, not dogmatism
Amazing video (again) thanks! 👍
I've had colleagues bashing me for using async/await rather than returning the task. However I think I now have some great arguments for keeping it!
- An error shows in the stacktrace where awaited.
- Potential gotchas with disposed variables.
- Not that much slower.
For majority of problems I sit with, performance has less priority than, potentially introducing bugs.
The dispose one is particularly scary, cause it might only fail once in a while!
I'd go with async/await all the time (unless I have a special case).
The only benefit of eliding the await is performance gain which I would guess is negligible in the majority of cases. If you get bashed again just turn the question around and ask for benchmarks to prove why eliding the await is beneficial in your use case against the more idiomatic usage of async/await (factoring in the gotchas e.g. exceptions, disposing, additional cognitive load of more junior members of the team understanding the nuance)
I would love to see a ConfigureAwait video.
A video about the pros/cons of Task vs ValueTask would also be great
I already have that
@@nickchapsas Apparently I already watched it :D Your videos are great to point our juniors to. Keep it up :)
Yep I was thinking the same because curious about that too in this context (being used with async/await versus directly returned). I was thinking about it at the point about Task.FromResult being based on a value type versus reference type.
with better enunciation
A fair rule of thumb is, if your function returns a value task, don’t do the unnecessary await, as the use of value task suggests the function will be called in a tight loop where the overhead of the state machine will start to matter more.
Thank you very much Nick, great video! You uploaded this video just in time when I was looking at David's guidance, after watching your older video about async await 😄
This is exactly what I've been considering in my async heavy applications that run through multiple layers of calls, thank you for the clarity. And yes, a video on ConfigureAwait would be much appreciated. So many things I thought I understood properly until you made a video on it.
The most tricky part about C# is multi threading. It even makes code reviews considerably longer,
So i would appreciate more videos on the topic.
I hope you're not thinking that this video was about multithreading?? Because it really isn't. Because async await is not multi-threading.
Read "Concurrency in C# Cookbook: Asynchronous, Parallel, and Multithreaded Programming" by Stephen Cleary
I have mostly used the version that does not use async and await. But interestingly enough in the last couple of weeks at work we experience some issues around tasks with deadlocks and one of my co workers found out that if we use async and await in the places that deadlock the deadlock disappears. So on the new year we will have an interesting week trying to decipher that. Your video helps shed some light.
PS: fun fact that is the second time now where you publish a video that I was searching for. Such a nice coincidence
Thank you for your time.
When I came over from old Fx WebForms days, I was taught to use async/await all the way. Today I don’t know any better 🤓 I would rather be safe and use it all the way to avoid confusion. Dunno how much perf hit would hurt in my typical LoB projects 🤔.
And yes, a video about ConfgureAwait would be useful.
Thank you Nick for your videos and Courses, they are really useful :)
I'd like to see a video about ConfigureAwaiter as well.
Happy Holidays!
This was a deep dive I really needed. Thank you for this content.
Outstanding explanation of returning task vs async-await...
I just got into habit of using async-await without actually thinking about the difference.
Thank you Nick!
great insights Nick. I usually use async/await in most cases but I came across some code for writing a proxy application which would forward a client request to another external service, and they were using Tasks but wrapped in Task.Run() I kept wondering why they wouldn't just use async/await watching this video I now understand why that was the case very eye opening
Always inspired by your videos. Thank you for all the lessons. 🙃
Great video Nick, thank you! I have been using async/await more for the neatness and structure it brings to the code, without realizing the fact that it would create all those stacked up state machines. Will definitely have an impact on my future coding :)
Super great video! I usually use without await, i guessed that it would affect the stacktrace but wasn't 100% until now.
Another thing to consider is if your method has guard clauses. If you use the async/await keywords, the guard clauses won't throw until the caller calls await on the resulting task. Usually you would want guard clauses to throw immediately when the method is called. To get around this, you can move the work to another method that does use async/await, then have your main method (no async/await) just contain the guard clauses then call the second method and return it's task.
A video on ConfigureAwait would be great! I had so many discussions with other developers when or when not to use it. At one point someone claimed that it should be used for literally every async call.. It would be amazing to be able to refer them to your video 😁
Configure await is used to refer to the main thread. So important to know when to use it coz it’s a performance impact and deadlock on certain cases. Useful for Maui app for ex but not in backend app.
@@maxime4047 Isn't this standard false in .Net Core (just continue on a free thread)? Thought this was only relevant in .Net framework?
@@FXK23 the standard is true to make sure you don’t get dead lock even if in majority you will use false.
And configure await true doesn’t mean you get for sure a new thread. It’s just meant that the thread that we continue can be another one
Great explanation! I usually return the task itself when I need to await multiple tasks afterwards with task.whenall, but this gets me thinking there are many other use cases
I've always used the await way. It seems simple and of course doesn't have using/disposing issue.
Excellent video as always! A video on ConfigureAwait would be greatly appreciated from my perspective but also going by a lot of the comments posted here! Thanks
I use both. I return a Task whenever I'm developing a reusable library, and async/await in any other case.
I thought from the thumbnail you were going to weigh up the pros and cons of making API calls using an async vs a sync method like the RestSharp synchronous methods vs HttpClient's async methods. It would be interesting to know what implications for the application both have.
You probably shouldn't be calling external API's (or internal, for that matter) synchronously because all that time between the start of the request till the end of the response, you are basically blocking your "thread" (whether that be an HTTP Request Thread for ASPNET.Core or the UI thread for WPF/UWP etc). Async/await is exactly for cases like these, where your thread can not do anything for a given time (reading the file, reading some data from some network etc.), and you do not want your thread (essentially the amount of processing power the CPU/OS gives you) just waiting for stuff.
I've always used flexible approach like in your final summary, I call it "make Rider happy". Often changing from async to returning tasks contaminating code with many Task.FromResult(...) / Task.CompletedTask, but I am ok with it. In most cases classes that have such "do something sync and then pass through" logic are abstract base classes, or static helpers/extensions.
Very good analysis with all the pros and cons of both alternatives.
I've always been using explicit async/await approach. Recently I've used Task approach for extension methods that implement a functional pattern.
Yes, please make a video on ConfigureAwait! Great video, thank you!
And another great video, thank you so much Nick!
We follow a simple rule: if your method it's a one-liner do not use async await, for everything else async await all the way.
I’d love the ConfigureAwait video, explaining synchronization context. I’ve never felt confident with that.
Thanks so much for this important video, Nick! I've gone back and forth on returning a Task, and it's great to feel like the debate is settled. Do you know of any Code Analyzers which can make suggestions which follow your guidelines? I only know of "AsyncFixer" which goes the "return a Task" direction.
I like to mix it. The default is to include async await, but sometimes within Linq or fluent APIs, it is nice to elide the async await ceremony for more concise syntax. Sometimes it is also a good thing to be able to modify the call stack by hiding passthrough methods for example. For performance reason alone I would never use it, chances are one line of unoptimized user code amounts to thousands of occurences of eliding async / await in performance drag.
Great video! Lot of things to learn from you. Yes make video on ConfigureAwait 👍
The program with files tests is that the os may cache the file access so second access to the same file will be faster.
I generally do return Task because I get suspicious of too much compiler-generated cruft in my assemblies but I'll keep the issue with disposal in mind, thanks!
this also alters the behavior on the calling side, say you have two methods A and B that take some value and do the validation. 'A' after validation does an awaited db query, 'B' similar, but not awaited, just returns the task. Now caller can invoke this methods sequentially and await each, but it can also execute them without awaiting and do the awaiting a bit later. If validation fails for either of those methods then exception will be thrown at different stages: or execution or on await.
A link for the two articles mentioned would be great in the description.
I use direct Task return when possible, but I burned myself previously with the using stuff, so I can understand the other camp too. I never had problems with debugging or stack traces with this approach.
Async await is a long subject with a lot of details, reading a ton of things on the internet helped me out, including pages shown by Nick in the video.
I have also been writing my own async state machine in order to get better understanding of it (after seeing those decompiled examples from ILSpy and Sharplab io) much like I have manually written IEnumerator iterator implementations for same reasons.
I can almost recommend other people doing those things. Deep understanding of things you use every day can help a lot. Also a lot of experimenting with deadlock situations and high threadpool load.
All to get a better idea what those smart people on the internet are talking about.
Good video... I can say I wasn't surprised when file reading doesn't change much with async since it still has to read the file line by line... I found that even the TPL doesn't make file reading faster... I am careful as to what gets an ASYNC call. I can remember old style async with BeginInvoke...
So amazing topic...,. It could be so interesting discusing about this and the relation with pool starvation & concurrency. Thank you for your time and share your knowelge with all of us, greetings.
I understand it well so I tend to pass through to the underlying task when it makes sense.
When I don't need to await something in the middle of a method that returns Task (the last thing it does is call an async method that return a Task but nowhere else), I will not turn that method to async/await, but if anything in the middle of the method does require await (2 or more promise chaining), I will do async/await. Reason is... promise style ContinueWith(...) callback is a bit of a pain. I guess need to add another thing for the async/await which is when you use using statement in the method that calls an async method.
Thank you for this video.
Please make a video about ConfigureAwait
Great video as always! I personally prefer to simplify code and return task itself rather await it. As for me await should be used right in the exact place where the result is truly needed, not just return it from function. For this approach you should write your stack of methods in a functional style (like a middleware pipeline). But if you have a task which relies on an external service, e.g. file, db or api, it’s better to await the result in the same method as it calls to avoid disposal issue. Overusing async/await may be dangerous especially when you want to pass them with lambda as a parameter. For example using Parallel For/Foreach with async lambda leads to conversion of lambda to async void method.
P.S. ConfigureAwait(false) is a rudiment from the ui apps where there is only one thread that must call and process awaited result to update ui, so for api .net application it’s just redundant
I have been awaiting ever since you told us to Nick
Great video! It'd be nice to have the ConfigureAwait video :)
Great video! Very useful!
Be consistent. Await always!
When he says "debugging hangs", he didn't mean that debugging hangs in the IDE, he meant debugging code which causes the application to hang. (Its a subtlety of English.) Because when you debug pause the application, you'll pause at the await of the internal task, not at the await of the calling task.
👏 Exactly
yes! more info configureAwait please. I learnt a bit about it when using Unity engine and never again. I generally always declare "false" except for rare UI cases
Yes please do a deep dive on ConfigureAwait
async and await are implementation details. I think letting the caller decide how and when they want to await something is an important case that many haven't brought up. If you're awaiting immediately, you're making a decision for the caller, and therefore the caller would lose that control.
Yes please make a video on Configure Await. I sort of understand, but I know this would help me and all other software developers to understand.
I was hoping to see ValueTask compared in the benchmarks as well as that sounds like the intended compromise between async performance and functionality for tight-loop code
Previously I would return the Task whenever possible. This does mean you need to refactor when adding a second async operation so that is a downside. Because of stacktrace and dispose issues I changed my default to 'async unless'
Nick. Great video again. Definitely since there is so much older stuff saying use ConfigureAwait it would be a good video. It would help to explain what it does (all that stuff out there mentions the SynchronizationContext but doesn't explain what that is, why you might care and when using ConfigureAwait(false) would actually be bad). Emphasize why Core is different, why doesn't it has this SynchronizationContext thing whatever it is?
Yes please make a video on configure await :)
Yes, please make a video on ConfigureAwait!, thank you
Great video! Thank you! 🙂
Yes, please make a video on ConfigureAwait!
Nick, I believe you have misunderstood David Fowler's point about exceptions in async methods being "wrapped in Task instead of surprising the caller with an actual exception". What David meant is this difference in behavior:
async Task Main()
{
var task = this.Throw(); // Throw() causes an UnreachableException to be THROWN here
while (!task.IsCompleted);
Console.WriteLine(task.Exception); // ThrowAsync() causes task.Exception to be populated with an AggregateException that contains the UnreachableException
}
public Task Throw() =>
throw new UnreachableException();
public async Task ThrowAsync() =>
throw new UnreachableException();
Your content is among the best, Nick
Pleeeease do the video on ConfigureAwait.
I just don't get it.
Absolutely do a video on ConfigureAwait let's end the confusion once and for all.
Yes Please make a one for ConfigureAwait too.
Danke!
Yes please. Make a nice video on the synchronization context and configureawait
Great video, but be careful when benchmarking file access from disk, as you need to take into account any underlying caching mechanism such as those afforded by the operating system. In this case, it's probably not a deciding factor, as only the first call of the method doing the very first read would hit the disk and thus have have a higher latency.
Edit: Depending on the size of the file and on how slow of a disk you read from, the initial latency could skew the benchmark result quite a bit (though, I suspect that this is not the case here)
Very good point. Thanks for mentioning that
also, that probably explains the relatively high standard deviation
I am curious, what Benchmark measures while a test returns Task? Logically, in tests we have to await result of tested methods. IMHO
Please make a video on ConfigureAwait! Great video, thank you
Yes, please make a Video on ConfigureAwait - or put it in your next course :)
Yes, please make a video on ConfigureAwait
Thanks!
Can't wait for the ConfigureAwait video!
Great video!
I'm using only await/async just because of debugging and stack tracing. Though I had one project where some performance was increased just by failing debugability.
I once got a stack overflow form forwarding to many async methods,
Very good video, i use to use it depending on the case.
I'm confused, is it recommended to use Async await if you are using a Using statement? Or is it the other way around (do not use async/await)?
Depends. If the call is part of a complex Api with may levels I prefer returning tasks. Also if the tasks can be combined or the caller has the option to wait for all of them or not. Returning the task is much more flexible from the caller's perspective.
Now, in the usual case I prefer to do exactly as you, mostly await and avoid it in trivial forwarding methods.
Yes! ConfigureAwait video please!
One of the other issues that I faced returning Task without an await, in the calling method it does not report anything if I miss await and async, while in the other case, it is reported with green squiggly. Former resulted in some difficult to debug bugs and wasted hours.
We program a lot in the WPF world, therefore we often need to do work without blocking the UI, so in the view-model we create a core method that returns a Task and then create an async method that awaits that core method. Sometimes we even create a raw method, that is called from the async method as a simple wrapper task, but this is rare. If i ever see async methods called in a chain, i collapse them down to just one async method. Sometimes i prevent the usage of async entirely and use tasks and wait for them instead - it depends on the use-case.
But i find it hard to properly secure the methods, so that it wont be called multiple times or can be canceled. Most of the time a simple Interlocked.CompareExchange() and one Exchange() can solve that, but in some cases where multiple calls are actually allowed, that requires much stronger syncronisations.
A video about configure await and use scenarios would be really helpfull :)
Oh yes, a video on ConfigureAwait would be greatly appreciated.
Please make a video on configure await. Thanks.
yes make a video on ConfigureAwait please. Thanks
I typically only use async/await if I either need the result of the task or want to handle the exception within that method. Otherwise, it seems pretty unnecessary to do so.
You wouldn't call .ToList() on every IEnumerable you find just because it's easier and to avoid having to enumerate it to an array or list later on, right?
It would've been great if ValueTask is mentioned as well. Their behaviour is slightly different as well when comparing async vs just returning.
In hotpath code, I will write a non-async method that just returns the task (such as reading from a pipe) if it is already completed successfully (as it usually is). But if the task to be returned is not completed, the method will call an inner, async method that awaits it. So you get the benefit of hotpath not using async machinery most of the time, only using to it when the task hasn't completed successfully.
Yes to the ConfigureAwait video 👍
Please link your sources in the description. It really helps.
Our company just added a rule to our set of analysers to require async, to improve readability on leaf methods that would otherwise have to return Task.FromResult, and to help avoid returning a null Task, tho #nullable enable helps there too. They also suppressed the suggestion that async without any await could be removed.