Correcting Common Async/Await Mistakes in .NET 8 - Brandon Minnick - Copenhagen DevFest 2023

[@hero3616]

First time seeing someone explaining ConfigureAwait(false) properly in an easy-to-understand manner. Thank you!

[@DerXavia]

Indeed, I actually hated the description in the official documentation, its written like they specifically do not want you to understand it.

[@weicco]

I have a feeling that if people would, instead of diving directly into .NET async and threading, take a bit time to learn how threading works below the hood, below the virtual machine, at the operating system level. I found it really helpful when I spent a few weeks tinkering around with Win32 interface back in 2000. I read about threading and how the "async" methods we had back then worked. Then I tested them myself with few simple lines of code. I finally got so excited that I went and read how threading and process model is implemented in different operating systems, and even helped a friend of mine to implement prioritized task list on his own operating system. You won't have to go that far but maybe spend a day with just reading and testing things. I find that reading is not enough. You need to test it to get "the feeling" of it even if the code is ridiculously small like three lines. But this way you'll learn not just the thing but how to apply the thing to different problems and situations. Just my two cents.

[@oaykac]

I never seen like this explaining for ConfigureAwait and ValueTask. Thanks.

[@serus164]

The laugh kills me every time

[@pmro]

First and second time I'm watching for knowledge but my 3rd time will be for that laugh 😅

[@andrewkaplanovsky571]

Yup, the presenter is slightly hysterical

[@Vladimir-ro7jw]

More like frightening than entertaining

[@tiosatria9919]

me too hahahaha

[@handlez411]

🎯 Key Takeaways for quick navigation: 00:07 🚀 *Overview of the Talk* - Session introduces correcting common mistakes in async and await. - Speaker highlights the growth of the talk since its first presentation in 2018. - Mention of additional resources available for reference. 01:34 🧠 *Understanding Async/Await* - Examining an example method "ReadDataFromURL" with async task. - Explanation of how the async/await mechanism allows for non-blocking execution. - Emphasis on freeing up the main/UI thread during asynchronous operations. 03:55 🔄 *Dive into Compiler-Generated Code* - Insight into the compiler-generated code for async methods. - Discussion on the transformation of async methods into a private sealed class. - Explanation of fields, move next method, and handling exceptions within the generated code. 06:23 📉 *Impact on App Size and Compile Time* - Briefly addresses the negligible impact of async on app size and compile time. - Mention of the generated class and fields contributing to a slight increase in app size. - Contextualizes the impact, highlighting its minimal significance for most projects. 07:30 🕵️ *Async Void and the "move next" State Machine* - Introduction to the challenges of using async void in asynchronous programming. - Explanation of the "move next" method as a state machine. - Caution against using async void in scenarios where exceptions need proper handling. 14:09 ⚠️ *Async Void in Constructors* - Addressing the issue of using async void in constructors. - Explanation of the limitations in constructors for asynchronous operations. - Introducing a workaround using async void but cautioning about potential issues. 16:21 🔄 *The Danger of Non-Awaited Tasks* - Identifying the dangers of not awaiting asynchronous tasks. - Highlighting the potential for simultaneous modifications leading to unexpected behavior. - Illustrating the challenges of catching exceptions in non-awaited tasks. 19:04 🔒 *Safeguarding Against Async Void Issues* - Emphasizing the risks associated with using async void. - Proposing safer alternatives, such as returning a Task or using async Task. - Encouraging developers to be mindful of potential issues with async void. 20:24 🚦 *Asynchronous Void Methods* - Avoid using `async void` methods. - Introduce the concept of "safe fire and forget" using an extension method. - The extension method handles exceptions and provides a clear indication of background execution. 22:58 🔄 *Refactoring the "Refresh" Method* - Discusses the importance of automatically refreshing the app on launch. - Introduces the concept of adding a delay to show an activity indicator, preventing a too-quick UI update. - Highlights the need to use cancellation tokens in async methods and demonstrates the use of `ConfigureAwait(false)`. 26:42 📡 *Calling External APIs* - Examines a method that calls an external API to get top stories. - Points out the issue of potentially blocking the main thread. - Introduces the use of `ConfigureAwait(false)` to avoid returning to the calling thread. 31:17 ⏳ *Handling Minimum Refresh Time* - Discusses the minimum refresh time and the usage of `Task.Delay`. - Warns against using `Task.Wait` due to its potential to freeze the UI thread. - Advocates for using `await` instead of `Wait` for better exception handling. 37:02 🔄 *Utilizing IAsyncEnumerable* - Addresses making multiple API calls serially for top stories. - Introduces the concept of `IAsyncEnumerable` to parallelize API calls. - Compares and contrasts the traditional approach with the improved asynchronous iteration using `await foreach`. 41:37 📱 *Introduction to Async/Await and User Experience* - Importance of considering user experience in async operations. - Introducing the concept of async enumerable. - The need for implementing cancellation tokens for user interaction. 42:05 🔄 *Async Enumerables and Enumerator Cancellation Attribute* - Explanation of parameters in async enumerable methods. - Introduction to the enumerator cancellation attribute for cancellation tokens. - How the async enumerable handles cancellation internally. 44:20 🚀 *Optimizing Async Code with Task.WhenAny* - Transitioning from traditional loops to async enumerable using Task.WhenAny. - Utilizing Task.WhenAny to optimize background task handling. - Benefits of breaking down the iteration on task completion. 47:21 🛠️ *Refactoring Async Methods and Handling Cancellation Tokens* - Refactoring methods using async and configuring for better performance. - Leveraging cancellation tokens for better control over async operations. - Handling cancellation tokens in both async methods and async enumerables. 48:02 ⚙️ *Avoiding Unnecessary Context Switching* - Explaining the impact of async/await on thread switching. - Demonstrating the removal of async/await in specific scenarios. - Utilizing value tasks to defer context switching and improve performance. 49:50 🧯 *Handling Exceptions in Async Methods* - Highlighting the importance of handling exceptions in async methods. - Discussing the necessity of keeping async/await in certain scenarios. - Demonstrating the use of try-catch blocks and potential pitfalls. 53:16 🚦 *Understanding ConfigureAwait(false) and Synchronization Contexts* - Clarifying the role of ConfigureAwait(false) in asynchronous code. - Considering scenarios where ConfigureAwait(false) might not have an effect. - Awareness of synchronization contexts, especially in UI-related scenarios. 56:57 🔄 *Optimizing with ValueTask and Hot Path Considerations* - Introducing the concept of ValueTask for performance optimization. - Guidelines for using ValueTask in methods where the hot path avoids async. - Balancing performance gains with code readability and maintainability. Made with HARPA AI

[@asifbhat3355]

First ever easy explanation of i await with relevant examples, in an interactive way. Hats off!

[@LasseVågsætherKarlsen]

Slightly misleading that the first slide mentions Thread 2, when in fact there is absolutely no guarantee that another thread will be created. Additionally, "Thread 1", executing at that point, will still call into the DownloadDataAsync method, and only at the point when some code, which could be severall call layers deeper, actually ends up creating and returning a not-yet-completed-task, then it returns back. And we're still on thread 1, no thread 2, and if the task is actually related to async I/O, a new thread might still not have been created. At some point, when that yet-to-be-completed task actually completes, at that point some new thread might be created (or a threadpool task created), or the main thread might pick it back up, which means even here we do not guarantee that we have multiple threads. So it is misleading to start off a talk about async/await to say that we get additional threads, at least when the whole video does such a wonderful deepdive on everything else. There are so many people going around believing that async/await creates threads all willy nilly, so it's misleading that this video seems to continue that misrepresentation.

[@withkittens2532]

I too was... surprised by the first slides, I stopped watching at that point. Does the talk get better after that?

[@elliotdematteis7825]

Exactly, the first slide implies that you can't use async/await with 1 thread, which is totally untrue. await just queues a user work item on the threadpool, it's totally possible for same thread that queued the work to get the work.

[@robertschmidt-cisternas8054]

This is completely correct. It's amazing to me that he has not corrected these statements after all these years of doing the same talk. It's actually infuriating that he, with the authority and confidence of a LLM, propagates factually false information to people who are trying to understand and learn a difficult topic.

[@robertmckee9272]

Ugh. I really wish people would stop explaining async/await wrong. And this guy makes one very big mistake that causes a ton of problems. The thread switch DOES NOT HAPPEN AT THE AWAIT KEYWORD. Why he felt he had to call that out @2:20 when that isn't how it works, I don't know. It's plain WRONG. The thread (Thread 1) does indeed go into DownloadDataTaskAsync and only comes out once it (and all of the child method it calls) also return from their very first await AND THEN it goes away. That is a huge difference. It is also why the compiler will warn you whenever you create an async method, but never use await inside of it, that "this method does not await and will run synch" or something very close to it. And then he repeats it @16:53 so it wasn't a mistake, it works differently than he explains.

[@andrewshirley9240]

33:20 - "Every time you use .Wait, you're using 2 threads instead of 1". Not quite. Every time you use .Wait, you're using 1 thread (blocked waiting on IO) instead of 0 (where a thread is given back once the IO has completed). It isn't twice as bad, it is actually just infinitely worse. This is why the difference of async/await alone made the difference between "server crashes if you consistently send 5 requests a second" to "can handle 500+ requests/second easily" on a project I worked on once.

[@romanokeser]

good point, thank you for the explanation because I was also confused by that statement and couldn't find relative info on google, thanks

[@CRBarchager]

So many good pointers in this talk. Way worth the watch if you're doing any async code.

[@DanielTabuenca]

It's worth noting that .WaitAsync(cancelToken) will not actually end or stop the task you are waiting on, it simply lets the code stop waiting by throwing an OperationCanceledException at the await point. If you have a long-running task, the task will continue to run, even after this exception was thrown in the calling "thread".

[@zzzzz2903]

So you are saying the background task will continue to run, but the awaiter will get an exception? So this case the awaiter has to "kill" the long running task?

[@ZackJJones]

@@zzzzz2903 I believe what he means is the system you were awaiting will continue processing, even though the calling system is no longer waiting for it. Eg, lets say you have an abstraction to call a long database operation. This abstraction doesn't have a means to pass a cancellation token, so you slap on waitAsync. If you started the db operation, but then throw the cancellation token, your calling system will stop awaiting the database operation, but the database is unaware of the cancellation and will continue its operation. So you can say waitAsync will only 'cancel' up, but not down in the stack. Whereas, with typical cancellation token usage, the database would recognize the cancellation and halt its operation as well.

[@ragtox]

Great talk! Loved the energy as well.

[@stephenyork7318]

Awesome video. I’ve not seen anyone go into the real reasons behind why things are done. The void return thing was particularly interesting.

[@MyGroo]

38:17 Doesn't seem like a reasonable use case for `FrozenSet`. Isn't the set unordered? Also, according to MSDN: "FrozenSet is immutable and is optimized for situations where a set is created infrequently but is used frequently at run time. It has a relatively high cost to create but provides excellent lookup performance. Thus, it is ideal for cases where a set is created once, potentially at the startup of an application, and is used throughout the remainder of the life of the application."

[@cheebadigga4092]

even so, he's sorting it by points for UI presentation, the set order doesn't matter here

[@earthlingthings]

Thank you bro. You helped me understand and fix totally weird bugs.

[@kamaldesai933]

Very easy to understand. Cheers !

[@antonbegun2319]

Cool video. Many practical cases. It is very useful. I really liked AsyncEnumerable example, it is great. Thanks.

[@Laggie74]

Thanks for the presentation. It was very informative.

[@sgwong513]

really good presentation. its feel short for 1 hour because lots of content and very fun presentation. I really learn some new stuff on async await which I never aware of.

[@TomRaf]

Really enjoyed this, the explanation and also presentation was great! I wish everyone at my work watched this to avoid creating silly (sometimes driving crazy) bugs... Just waiting when I get fired after all that refactoring I've done recently, should see those PRs maaan :D

[@damaddog8065]

Task and Task have a Exception property, if this is NOT NULL and you do not OBSERVE IT, check it when the task goes out of scope or worse when the Garbage Collector comes and calls finalize on the task, it will throw. If you throw in finalizer, you are done. Else, you are probably still done unless you have an application level exception handler.

[@tileq]

Unfortunately, the lecturer does not understand well how async/await works. There is no second or background thread doing the work after the 'await' keyword. For anyone interested in the topic, there is a very famous article about that - ' There is no thread' by Stephen Cleary, a must-read for everyone interested in the topic.

[@PaulSebastianM]

Async/Await Tasks does use a separate thread if available, and if launched with Task.Run and similar methods. So he is not wrong. Just omitted some technical details for the sake of making a point.

[@leotohill3941]

@@PaulSebastianM Task.Run is a special case that yes, Task.Run() explicitly uses a separate thread. But the principal case of await/async, as described in this presentation, does not.

[@aluriramakrishna]

awesome presentation on async/await.

[@shadowthehedgehog2727]

Wouldn't it be better to not call Refresh in the constructor at all? Maybe call it in a initialize override function of the viewmodel? I'm at 22:38 so he may address this in the later part of the video.. will keep watching

[@ppcuser100]

A very useful brief on Async/Await. The awesome lecturer explaining clear and short 👍

[@sanampakuwal]

Learned a lot, thanks!

[@tiosatria9919]

damn good explanation and video. kudos

[@TheAzerue]

Thank you for wonderful talk

[@ZdenoTirc]

Still same misconceptions. For example, first example with WebClient, Thread 2 doesn't run DownloadDataTaskAsync. There is no thread, which is one of the main principle of async code

[@eddypartey1075]

It seems like you misunderstood. Brandon didn't say that there were 2 threads at the same time. Even more he said "thread returns" at 2:30.

[@ZdenoTirc]

@@eddypartey1075 No, Brandon is wrong. Thread1 hits await keyword and returns, but Thread2 doesn't run DownloadDataTaskAsync(there is no thread, it is async).

[@bass-tones]

I had the same exact thought, intuitively. Stephen Cleary has a blog post about this topic called “There is No Thread.” Now it is an old post, and it’s possible something has changed, but I’m almost certain not. There doesn’t need to be a second thread for true async work because it gets handled by the OS. Amazing how even a lecture on async misconceptions opens right out of the gate with a hugely common misconception.

[@bogdan.p]

then how are you able to run 2 pieces of code at the same time if there is no second thread? I mean you can literraly run the UI thread while doing work in the background. They kind of work together even tho concurrency and asyncronous are not the same.

[@ZdenoTirc]

@@bogdan.p DownloadDataTaskAsync in first example is asynchronous operation and If operation is natively asynchronous, then there is no other thread doing something and also UI thread is not blocked during await (if it is app with UI thread).

[@PeacefulMindss]

Super clear and helpful, thank you.

[@haroldpepete]

In my humble opinion, this's one of the best talk i have ever watched, this guy goes straight to the point, Nick Chapsas or whatever his name is, has to be learn something of this guys, Nick talks 90% of things that nothing have to do with the main talk, less nick speakers and more Brandon Minnick

[@mobe6524]

Nick shares some really good stuff actually. He gives advices, talks about incoming features, shows some implementations. Perhaps you were disappointed in his logging talk, there was still great tips there. You may wanna check out his channel, very rich content. But yeah, this presentation was interesting.

[@livingdeathD]

They are different ways, the truth is I enjoy both types of talks

[@eddypartey1075]

Very helpful and lucid, great job!

[@philyjayjohnny]

Something that was not explained or I missed is that when operating on the viewmodel and switching threads, how he prevents race conditions and stuff... Like when ContinueAwait(false) continues on another thread, and the following code modifies some collection. If my memory serves me, using a classic List or an ObservableCollection from different threads, would be considered a dangerous practice, unless he uses some special concurrent collection? I'm confused.

[@kirillxt]

The talk ignores race conditions which is a bit meh. Part of why ConfigureAwait(false) isn't the default is because you're less likely to shoot yourself in the foot that way because your data structure accesses are synchronized across all async methods that are called by the UI thread (unless you access them in something like Task.Run()). That's why it's called SynchonizationContext

[@whitek6532]

Always should use await even if your method just return the task since you will lose stack trace

[@cheebadigga4092]

not in this case, he's calling await from the calling method, so the stack trace will still be clear I think

[@SuperGulamali]

This is literal gold

[@everyonesview]

Awesome!👏👏👏👏

[@FirstLast-gc6ss]

46:38 Why Task.WhenAny ? What about pagination concept and only show first 20 or 30 records and than on page 2 click/scroll (infinite scroll) send 2nd request for another next 20 records?? Why all this fuss of When.Any ??

[@richardhowells5531]

Hi Brandon, I am wondering if I have a misconception about what await does. My understanding is that in… X = await f(); … the call to f is synchronous. There is NO new thread creation at this point. I think that is contrary to what you said in your talk. Unless I misunderstood I believe that you said “…f() would run on some other thread grabbed from the thread pool…”. I understand the await to act as a gatekeeper - “You cannot come past here until the Task is completed.”. If there is an await in f() it returns an uncompleted Task, and this is passed up the call stack until eventually the run-time can allow the thread to be used for other work. AIUI to get a different (not necessarily new) thread for f() you have to use Task.Run(). Even then Task.Run’s behaviour is influenced by the currently active scheduler and so might not give a different thread. I think to guarantee a new thread requires using Task.Factory.StartNew with TaskScheduler.Default. Something like Task.Factory.StartNew(someAction, CancellationToken.None, TaskCreationOptions.DenyChildAttach, TaskScheduler.Default); Do I have this wrong?

[@rafedel-issa6042]

That's also what I'm wondering. From what I understand, after you call await, the code inside of the async function is "switched" on, so the current thread returns after calling await, and it will be able to handle executing other things that are queued up, but when it doesn't have anything to do, it will return back to the code inside of the async and execute that, then execute the remainder of the code after the await. I might have a misconception about this though.

[@robertschmidt-cisternas8054]

You've understood it better than the presenter - after all these years, he's still confusing threads and Tasks. It's a pity that he continues to confuse people with these otherwise engaging and interesting talks.

[@GhostTyper]

Task.Delay() doesn't preserve a thread to wait. XD I think it uses something like TaskCompletionSource and gets kicked of, when time is there, so waiting synchronously via Wait() doesn't consume two threads.

[@divyaprakashjha8389]

Is news service code shown in the video somewhere in GitHub?

[@microtech2448]

Nice explanation. Just wish ConfigureAwait(false) could be default by .Net team 😊

[@ondrejexner3688]

One of the best Async/Await presentation under 1h! Really. I just have one question ... What about a use-case when you would have like 1000 TOP stories instead of just 50. Is it still a good idea to fire all 1000 tasks at once? I think not, because it can lead to treadpool starvation. So maybe fire just 50 tasks and then fire new ones only when one of the running threads returns? Or is there a better way to handle this use-case?

[@S3Kglitches]

are you sure? just in the second minute, there is clearly a mistake. Calling WebClient.xxxAsync does not start a new thread unless it would be Task.Run(WebClient.xxxAsync).

[@bullet9564]

You misunderstood async await! There’s no thread. The idea here is to NOT wait for completion of an IO activity - so, async await was created. You can read more here about it blog.stephencleary.com/2013/11/there-is-no-thread.html

[@sachin36987]

Use chunks

[@S3Kglitches]

This guy got the first thing wrong. Not worth watching the rest if he doesn't know precisely what he's talking about. 2:33 no this does not start a new thread. Assuming it is asynchronous I/O operation, the code will stop there and UI handling will be able to continue (which would be frozen if this weren't async/await but sync code).

[@kingjustink]

He never said it starts a new thread, just that another thread from the thread pool will perform the async operation

[@ZdenoTirc]

@@kingjustink and exactly that is not correct. there is not another thread from thread pool, which will perform async operation. if it is async, then there is no thread.

[@auronedgevicks7739]

@@ZdenoTirc I think he was saying that the thread will be resumed by a different thread in the pool. Don't know if he's right or not but from what I know the thread context is captured so it can be resumed safely. not sure if it's the same thread that resumes or a different one.

[@SamWashkansky]

Please post the link to the source code repo

[@Lioobayoyo]

What about the async naming convention ? Microsoft used to recommend to consistently name every (public) async method by suffixing "Async". e.g.: GOOD: public async Task DoWorkAsync() {} BAD: public async Task DoWork() {}

[@Eupolemos]

51:19 - how does he do that?

[@alirezanet]

Awesome talk 👏🙏💐

[@PinheiroJaime]

Talking about "best practices", CancellationToken as first parameter really hurt me.

[@MrHeavyRunner]

Probably just mistake, not intentional. Also he has them as last parameter in other methods.

[@yohm31]

So cool: I guess there was other ways to achieve progressive results to be yielded from async tasks, but now it's clever.

[@CrisDevDotDot]

OMG so this guys' last breath was at 59:59 . talk about being right on the dot in 1 hour 😅😅

[@martinprohn2433]

Instead of "always avoid 'return await', except …", it would be better to say: "Only avoid 'return await' in very simple statements (oneliners) and never in …".

[@markovcd]

Sad that he moved on from the async in the constructor example as if he arrived at the best solution. This is spreading wrong information. Do not leave async initialization code in your constructors. What I tend to use is to introduce a method with a signature: "async Task Initialize(CancellationToken ct)" and call it from whatever wants to navigate to that view. He also missed other reason why you shouldn't do long running operations in the ctor - you don't always have control when it is called because of dependency injection framework.

[@xybersurfer]

i strongly disagree with the excuse of not running long running operations in the constructor. it's like saying that long running operations can't create anything. it's just a convenient lie, for the C# language designers, that actually harms how generic the language is. let programmers decide whether having a guaranteed initialized object is worth cost of waiting (which has to happen regardless, now it's just in the wrong place). i bet you it's worth it the majority of the time. i have similar but less strong feeling about the lack of async operations in properties

[@spudtaters8419]

@@xybersurfer Agreed, working in a cloud microservice our constructors typically want to load their config data and secrets from a remote service, so just doing Task.Run(...).GetAwaiter().GetResult() in a constructor seems fine to me. Config data is required to fully construct a usable object. Also, a C# Lambda only has a constructor to do its cold start initialization.

[@pepperplume]

first, also i was having async await issues, hopefully after this video, not anymore

[@szeredaiakos]

Safe fire and forget asyncs are nothing new but one cannot have enough talks of the subject.

[@JustinMinnaar]

Except for the incorrect usage of the ConfigureAwait(false); the talk is a nice summary of using async/await.

[@everyonesview]

Please yourself with regard to the incorrect usage of the ConfigureAwait(false)

[@LeducDuSapin]

Do you care to enlighten us, why the usage is incorrect? Or do you just purport it?

[@petrkomarek7249]

Please share what in the presentation was incorrect exactly?

[@anandshindey]

I wish they had a do and don't guide for beginners like me. This video confused me .

[@shreebatta]

Async method/s in constructors cause deadlocks. It's just bad practice. Runtime that runs ctor doesn't know/doesn't care about ansynchronicity

[@tomekkicaj700]

Madman's loughter 😅

[@AmitTaparia]

Just because you are using async and await doesn’t mean that the system will create additional threads like Thread 2 as mentioned in the first slides. It’s really misleading

[@auronedgevicks7739]

I've been watching for 20mins and seriously considering this a waste of time. It's just a comedy of errors by not following how you should use async/await and then complaining about why it's being used the wrong way.

[@unexpectedkAs]

That energy tho

[@georgevolkov8599]

configureAwait(false) in 2024. Ok. Other part was nice)

[@mhalan2198]

How come the unawait void will go back to the constructor? Is this guy from Microsoft? If so then the company has drama

[@mohamedbeyremmakhlouf]

Basic concept for a conference like NDC

[@xybersurfer]

it's good to go over the basics sometimes. but i would say it that this is a bit above the basics. it's not what you would give to a beginning C# programmer

[@fr3ddyfr3sh]

Wow, explaining two things wrong within the first 4 minutes. If you really want to understand async/await: watch a different video. Also he did not mention THE most important issue with async void: uncaught exceptions in async-void will immediately crash your app, you cannot do anything to prevent it. And due their async stack, finding the source of these crashes is difficult.

[@kingjustink]

what were the two things?

[@pejmannikram7349]

At least the first explanation about Async is not 100% correct, the relation of async code and Thread are not 1 to 1 kzbin.info/www/bejne/n52cmJ9ugq1kbdU

[@tanoryjakaperdana1419]

If its common then it isnt mistake 😂

[@GeorgeTsiros]

who let this guy near a keyboard?

[@oislek34]

tiring voice

[@igorspitz]

Very

[@gregh5592]

I keep seeing this talk and it is plain awful. So many inaccuracies.