The C# await keyword lets you pick up where you left off after an asynchronous call. But did you know you can select which thread you'll be running on?
Source code available at: github.com/JasperKent/Async-C...
Topics include:
- Different threading models for Console, Web and UI apps
- Thread safety in WPF and WinForms
- Using async and await
- Managing threads with Task.ConfigureAwait
- Improving responsiveness
Best explanation yet on this topic I've seen
What a lovely, professional, but most important: what a useful video. Thank you, more people should know about this.
Want more on async/await? Let me know. Source code available at: github.com/JasperKent/Async-Context Remember to subscribe at kzhead.info/tools/qWQzlUDdllnLmtgfSgYTCA.html And if you liked the video, click the 👍.
NOTE: Console apps and Web apps may behave differently when it comes to what thread runs after the await. An MVC app uses Synchronization context for the await. When the await returns, you return back to the original thread that initiated the async operation. This is also true for WebForm applications. Therefore, it can be summarized, the thread that will run after await will depend if the application has specific Synchronization context. The synchronization context then is used to select the right thread to run after await completes. UI apps: Return back to the UI thread MVC/Webform apps: Return back to the thread that made the original request Console: Use available thread from the thread pool
As always a beautiful and easy explanation. Documentation has much more complicated, this simple example shows what it's all about. Thanks! Edit: What's more my co-worker says we will be using this on monday (We have some problems with our WPF app). I didn't know how this works but now i feel that i have this knowledge. Brilliant timing! Thanks again!
Excellent excellent excellent! Exactly what I need!! Leaving aside the main theme, I discovered the local method. I didn't even know this concept exists! Thank you!!
I love your videos. I'm surprised how come u have less views. One suggestion anyways, a little better voice (clear mic) will really help
Very nice video !! I would love to see more. Just for clarification, it is quite difficult to follow from where "ReportThread" is called while looking at the output. Could you add maybe do something like: void ReportCall([CallerMemberName]string methodName = null, [CallerLineNumber]int lineNumber = -1) { Console.WriteLine($"Thread ID: {Thread.Id} at {methodName} line {lineNumber}"); } That would make is easier (at least for me) to follow.
Definitely best tutorial. Keep filming tutorials.
Excellent! Very helpful. Easily followed along. It all made sense to me. Yay. Thank you very much. 😃
best explanation ....
Very informative thanks... 👏
Thanks for the video, very helpful and well explained. Off to make so soft
I dont know how to say Thanks to you Sir!!!
Nicely Explained
Thanks for the explanation. I read about ConfigureAwait() in a book but didn't completely understand it and the .Net Docs aren't very helpful. I have been using at the "end of the line" as the book recommended (basically, the last "async" call you make in that process, eg. an async query to a database or an HTTP request like in your example) but the book didn't mention it for UI usability. I wonder if there's a use case where it would be beneficial to use ConfigureAwait() for non-GUI apps, like Console or Web APIs. Is there a scenario where we would want to return control back to the Main thread in those apps? Thanks again for the video!
It only makes sense in application types which have a thing called a SynchronizationContext. Otherwise, the behaviour is always the equivalent of ConfigureAwait(false). UI apps do have a SynchronizationContext, but console apps don't. In ASP.NET, it's more confusing. Framework apps do, Core apps don't. blog.stephencleary.com/2017/03/aspnetcore-synchronization-context.html
@@CodingTutorialsAreGo Thanks for the reply & clarification. Makes sense to me. I hope having it in there even though it's not needed won't be detrimental to performance (or do I have a lot of refactoring to do? 😁).
@@shooob As ever with performance, the answer is 'suck it and see'. That said, the recommendation in the article I link is to use it in libraries where you don't know what kind of app you're actually in, so I guess the performance hit isn't significant.
@@CodingTutorialsAreGo Great advice. These are in reusable libraries so they *could* be used in a GUI app I suppose; unlikely, but I'll just leave it in there and say I planned ahead all along. haha.
Your videos are so damn good. I just plugged you (again) in my discord server.
THANK YOU!! ✌
eng\Jasper... I want to ask a question? I heard someone say that asynchronous programming does not create multiple threads, and that it only uses one thread. I see here that a new thread other than the main thread has been created, and I trust you to answer this question. My sincere regards to you.😊
The await and async keywords to not of themselves create threads. The await keyword is applied to a Task and waits until that Task is complete. In many cases, that Task may be running code in a separate thread, but not always. For example, if the Task caches a result, it may run in a separate thread the first time to get the data, but not subsequent times when it simply returns the cached result. It's worth noting that in JavaScript things are very different, and we don't have separate threads when using async/await.
sotNice tutorialng either - I assu that works with Edison too) and I never thought about after that. Now, at tNice tutorials mont, I am inspired! I am
hello Jasper, it will be nice when you refer to another video if you place the link somewhere. thanks
The links should appear in the top righthand corner of the video. Sorry if I've missed any.
Have you considered authoring Pluralsight courses? You are really good!
I'll wait till they ask me.
Thank you for the video! God save the king!
So we can seperate UI logics vs Thread logics backend can serve us a data with async method and ui can await it with configureawait true
That's right.
But there is a fix i found
Thanks, could you please cover Task.FromResult?
I'll put it on the list.
That's there now: kzhead.info/sun/dcp6oZaSoJd5dYk/bejne.html
Thanks a lot. 🙂