For everybody that brings the authority argument that the picture is from the Microsoft docs. Please note that in the Microsoft docs, the picture is used in a sub-section called "Start tasks concurrently", so it's used to describe concurrency/parralelization, not to illustrate the the difference between sync and async programming.
I’m not concerned about the rights or wrongs of the article - Dan’s video is clearing up common misconceptions about async/await and is useful in its own right.
@Codewrinkles Following question may sound like stupid one for seasoned developer. I m a just a Devops engineer, currently learning .NET and exploring the concepts of asynchronous programming in C# and have a few questions that might seem basic, but I'm eager to gain a clear understanding. Async/Await and Background Threads: Does using async/await in C# inherently involve background threads from the .NET thread pool? I've heard about async operations leveraging the thread pool, and I'm curious about how this works exactly. Is a Task running with async/await always executing on a separate thread? Task.WhenAll vs Async/Await: What is the fundamental difference between using Task.WhenAll and async/await? Is Task.WhenAll employed for executing multiple tasks on separate threads? In the example when you you used Task.WhenAll it completed in less time, also you mention about fire and forgot (which I heard somewhere associated with threading) Task.WhenAll vs Parallel.ForEach: How does Task.WhenAll differ from Parallel.ForEach in practical terms? My understanding is that Parallel.ForEach is used for parallel programming, focusing on CPU-bound tasks, whereas Task.WhenAll deals with concurrency, primarily for I/O-bound tasks. Could you please elaborate on this distinction? Hope community help me with this.
One more question => Thread Pool Access in IIS: When a .NET web application is hosted on IIS and uses async/await tasks, does IIS provide access to the entire server's thread pool, or is the thread pool segregated based on the number of applications hosted? How does IIS manage thread allocation in such scenarios? Using Parallel.ForEach in Web Applications: In the context of web applications, is it considered a good practice to use Parallel.ForEach for operations? My concern is about the potential risk of overloading the server and affecting the stability of the web application. How does IIS handle such intensive parallel operations, and what are the best practices to ensure application reliability?
@@jojify Quick answer from my point of view: you should not think that when you see async/await that it is running on another thread by default. There might not be another thread at all. The "job" might be running on another hardware, e.g. your network card, so your CPU might not need to spin up another thread to do that work, and the job could resume on the same thread (UI thread for example). Do a quick Google search for a great article from Stephen Cleary called "There is no thread", and don't forget to also read the comments in that article. It's a great source of info on this subject. Running jobs on another hardware devices to me is "true" asynchronous work (such as Async methods that talk with the file system). Spinning up threadpool threads with Task.Run() is "fake" asynchronousity.
Good points! I would summarize that async programming is about keeping CPU cores as much busy as possible without waiting for background tasks, in a application that can process many asynchronous requests/events.
So you're saying Microsoft is fundamentally wrong about async/await? Because the image at the start of the clip is from a Microsoft article titled: "Asynchronous programming with async and await"
If that's the case, then yes. it wouldn't be the first time. Although I'm sure it's about context and I'm sure that in the mentioned article they explain the difference and give more context. Just posting the image on Linkedin without any real context just confuses people and make them have a wrong understanding of async vs parallel programming.
@@Codewrinkles@Codewrinkles I'm sure you know the image wasn't posted without context and that most LN infographics come with a decent-sized wall of text explaining the infographic.
@@Codewrinkles Exactly - it's your fault for not reading it. The creator tried to explain it. It's the same with your TH-cam videos. There's the thumbnail to attract attention. And then the video to explain the topic. It's like learning programming by watching coding thumbnails. It must be the creators fault, those pesky thumbnails...
Sorry, but I don't agree with you on this one. In the post the there was some text comparing sync vs async programming with text (mostly extracted from the same article you mentioned, I guess) that didn't match the picture at all. There is no single word about task paralelization, even tough the graphic is cleary showing that concept. Anybody inexperienced dev that watches that picture and reads the text will result in having a totally wrong idea about async and wait, because the picture is what will mostly stick to the brain. And the text didn't do anything to clarify things. I know you two are friends, but I still think you are in the wrong with this one.
Great post, I think it's worth mentioning, that async leverages managing IO operations(external processes) to not block the main execution thread, while Parallelism is used for CPU-heavy tasks(in-process).
Thanks for pointing this out. I would also add maybe that you might want to use parallelization (combined with asynchrony) in a lot of scenarios, like data migrations or similar stuff.
Good explanation! Async await is extremly important in client-side web apps where we only have one thread, for example in Blazor. If we perform some calculations that take a lot of time, we will have a frozen UI. By awaiting some of these things we can allow the UI to refresh and update in between long calculations, for example for showing progress. In blazor this is actually that common that we manually add some await Task.Delay(1); in between to give the UI some time to catch up. Without these calls the browser will just act frozen and may even report "not responding"
@@kipchickensout yes StateHasChanged forces a re-render of the component but if you for example have a progressbar and just call statehaschanged in between updates and continue work, it is not enough time for the component to update. The main thread has to kind of "idle" a bit to fully get the UI refreshed.
@@kipchickensout Yeah I can't say my explanation is the best, nor my understanding tbh. But from experience I know this is what we do currently at work, if we don't we basically have a frozen UI for so long (when doing a 3d model build), that the browser even thinks that the site is not responding etc. We can work around it with these small delays that allow the UI to catch up when we update the progress bar
Thank you for this visual code explanation. I saw the post and something kept bothering me. I'm not the best coder by any means. This clears things up for me.❤
Oh finally! Thanks for clarifying this! From some benchmarking I did a while ago, using async-await can also make the code slower than using sync programming. That's because whenever you use these keywords, you create a sort of state machine that can make the *single* execution slower. However, async programming makes it faster to execute multiple incoming requests since it does not block the threads.
THIS is great because when i googled async /await i too saw that visual. this is very useful for a beginner . can you do a project that walks us thru real world handyness of these async/await functions for those who dont get to use it at work or havent found a job yet where they need to use it
Thank you so much! I happened upon that Breakfast Code example and was stuck trying to figure out why it didn't work asynchronously for me. Again, much appreciated!
The one problem I'm still having is, when I declare the function variables, it executes them immediately upon declaration-no matter which way I have them setup. Sure, I can use threads, and threads seamlessly run concurrently, but I'm writing a WebSocket program, so I was hoping to use Tasks. @@Codewrinkles
It just seems like Tasks are pointless. No matter what you do-despite the async labeling, tasks don't run concurrently. And you get a warning every time you fail to use the await. It seems like they should be called "group" instead of async. The only thing I can see that a task does is it groups the results of a list of functions into one - pointless... Thank you again so much for pointing out the fallacy of the Breakfast Code example. @@Codewrinkles
" I happened upon that Breakfast Code example and was stuck trying to figure out why it didn't work asynchronously for me. " - Because you did not understand the concepts described in the article. The article is fine, concurrency is about threads that are freed to do other things concurrently while waiting for other things to happen, from applications point of view.
It was a great explanation. Thanks for sharing it. I want to mention that understanding how exactly async/await is handled by the state machine underhood in .Net can help in understanding it better.
Concurrency is doing other tasks while we are waiting for a given task. So in this case, the docs are right, a not-a-blocked thread can do other tasks concurrently while given task completes.
All separated defined async methods are non blocking and program continues with next line. But having a bunch async methods together as a parallel in the main thread then the program will wait until all methods are completed, but are running async in the main thread. Therefor the next line after parallel invocation will not start until all parallel async methods are completed.
Program doesn’t run the next line after await call.. execution control returned to the caller of the method where await call is present. After await call finishes execution, process will try to run the next line with the same thread originally used or a new thread if that’s not necessary
Yeah, u'r totally right, parallel programming is not for noobs! You have to design ur business logic carefully and check which results depend on others before u begin to await everything.
Your videos are great, it's always good to hear and learn from you. But I can't comment in chat in your live stream videos, it says subscriber only mode. What does that mean?
The article does a good job explaining the same thing, just simplifies it for a beginner. If you read the entire article from start to finish it is correct. Sorry Code wrinkles you got this one wrong. See my other comment on concurrency. And btw, you video on concurrency is correct, but the article explains the same concept at more beginner level. You are both correct on how concurrency works.
Yep, it's possible to have async working in single threaded environment. Async is about yielding the execution (Hello MoveNext() method of async state machine or Unity coroutines with IEnumerable). Everything else is the details of how TaskScheduler and SynchronizationContext work.
Initially, I had the plan to also show how asynchrony is implemented in Javascript. Precisely to point out that the problem of asynchrony was solved differently in different programming languages, based on what they had at their disposal. Something like "if life gives you lemons, make a lemonade". Great insight! Thanks.
@everyone It looks like this video did more bad then good ... By reading comments seems like lots people still don't know how async await works and what problem it solves. Please watch recent video that explains aysnc/await in detail: Writing async/await from scratch in C# with Stephen Toub This video will answer all your questions about concurrency, async/await and threading, which in the docs is mentioned and explained correctly, if you bother reading the docs from start to finish.
Good job on raising awareness. Many posts try to simplify things that aren't simple at all under the hood leading to misconceptions and misinterpretations.
Why do I need asynchrony at all if the application is interface less and interrupt-free, and the standard threads are interrupted at any time as it is?
I think you're confusing about async and parallel here 😁. Correct me if I'm wrong but, Synchronize programming is when you execute some sort of IO operation and Wait for the IO Thread to finish and the continue. Parallel programming is handled using Parallel library it's the fact that you shank a big workload into different CPUs to be executed at the same time then collect the result and return it or what ever. Async programming in the other hand, is the fact that you fire something in a Task and don't wait for the IO Thread to finish its work the Thread actually returns into the ThreadPool, the big difference with Parallel programming, async programming can be executed if your compute have one single CPU and parallel programming is executed into multiple CPUs.
Are you saying that asincronous programming is not making you gain time? Aren't you gaining timen when your UI is still being responsive while you wait for the HTTP call?
"Are you saying that asincronous programming is not making you gain time" => Yes , asynchronous mean non-blocking, not concurency. If you want the result to return, you still have to wait (hence the await keyword), but meantime, your main thread is not blocked. If your application is a window app, you can move the window around, etc. If your app is a web application, it can take other requests. "Aren't you gaining timen when your UI is still being responsive while you wait for the HTTP call?" how can you gain time when you still have to wait for the response.
So my understanding is that there is basically no benefit to opting to use an Async method over a synchronous counterpart when working with a service that exposes both as part of its API and when using that service on a web server that is doing things synchronously for each request anyway. Am I correct in that line of thinking? Should I be opting for using Async controllers and using the Async API even though I'm always going to immediately await that async call to the service? In this particular case, I'm also not worried about the load issue that using async controller methods would fix.
As I mentioned in the video, there is definitely a benefit of using async and await since each webserver has only a limited number of available threads to work with. If you block them all (due to high load) then you'll have a problem.
Using async for web methods/apis comes with one massive benefit: the ability to pass Cancellation Tokens around. Should something happen, like the connection getting closed or the user cancelling the request, you can bail out without having to waste time finishing potentially slow and time consuming work that the user is no longer concerned with.
Please, you are doing yourself a total disservice. In the Microsoft docs, the picture is used in a sub-section called "Start tasks concurrently", so it's used to describe concurrency/parralelization, not to illustrate the the difference between sync and async programming.
Seriously section!! I believe you were in hurry, that you didn't even read complete article. Look carefully from which *SECTION* each picture is coming
Briefly: Async prevents blocking of other processes. Here's a good example to try: Create a desktop app in Visual Studio with a single form. Add a button to the form and a function that calls a delay, of like, 8 seconds Delay(8000) or something long enough to see what is going on. Add another button to the form that calls another function that is async, but does the same delay. Run the program, click the first button and immediately try to move the window around the screen, you can't until 8 seconds has passed. Try again and this time, click the second button and immediately try to move the window around the screen - you can do so with ease, even though there's a delay in the function. The first case will block the GUI, specifically the ability for Windows to redraw the form as you move it. The second (async/await delay) will not.
Main takeaway from all this is to use async/await everywhere as a good practice. There are other examples showing similar gotchas with files, db and api calls with synchronous vs asynchronous procedures.
@@davestorm6718 When I use await before method call, the method will be executed in a new thread and the main thread of the program will not be blocked? Is it right? So code in main function will be being executed simultaneously?
There is some useful stuff as well, let's admit it. On the other hand, I think it's technically hard, if not impossible, to transmit accurate information (that is often context based) in just one shiny infographic. I think the main problem is the overall way of creating content excessively tailored for views and engagement instead of real education.
From what I understood, threads are used for heavy computation, for example, you have array of objects that needs to be processed, and you can split this array between different threads, so it will be faster. Tasks are for I/O operations, database or API communication (usually async stuff). The reason to use threads for computation is because CPU usually has several cores, it will divide work between them, but tasks work in the same thread. So whole picture looks like this: Process has many threads, thread can have many tasks
Tasks are a C# thing, in other languages you can see them named as Futures. Threads however, are workers, that run the tasks inside them, they are like smaller programs within the larger one that is currently running. I am not entirely sure about CLR using real threads or "green" (virtual) threads, but there isn't a requirement to run N threads for N tasks, you can have 1 thread running N tasks and so on. For the video analogy, you can have one cook, doing 10 dishes, and you can have 10 cooks doing 10 dishes, but if they are available then there isn't a need to have any more cooks. You can read more about "multitasking vs parallelism".
As many answered before, no, they are not the same thing. And that's actually why .NET right now is so powerful. Because you don't need to care about the low level stuff. Thread utilization is handled by the runtime. Task is just a class that represents a long running operation which at some point will return a result. How that task is run, how many threads are involved and so on, is handled by the runtime.
Like for all videos, you'll find instructions on how to get the source code for each video on the Membership Tab if you are an ambassador member. If you are a Supporter, on the Membership tab you will see only instructions for the source code of the live streams: www.youtube.com/@Codewrinkles/membership
If so many people are angry about it, there's a good chance there's something fishy. There's no smoke without a fire. My point is that creators, myself included, should take a little bit more responsibility and accountability about what they are posting. The worst thing you can do to more inexperienced devs is to plant wrong ideas in their heads. Sometimes you can do it unintentionally. My point is: this type of responsibility should come before the drive for views and engagement.
Seems very easy to be a youtube expert these days. If a developer lack this basic understanding, maybe it's time to realize you have no idea about what you are doing?
You are conflating "asynchronous" with the async keyword. Asynchronous does not mean concurrent or parallel, but it doesn't mean just async keywords either. But lets assume it does. Of course if you await every asynchronous function it behaves synchronously that's what the await keyword is for (to synchronously wait on an asynchronous function which is why you can't await unless you're also in an asynchronous function). That image is exactly correct explaining asynchronous behaviors (as they exist in .net) when you don't do something like await every async function to force it to behave synchronous (something you would only do if the API is only provided as async but you don't need the extra asynchronicity because for example you're already in a worker thread and synchronizing simplifies the code). And awaiting every async function IS a code smell (unless you're in that specific situation), because if that's how you're going to use them they probably never needed to be async to begin with. if it's okay to hold up the current thread until the async function finishes inline, then it could have just been a synchronous function. In .net the async keyword is implemented with a Task object that is submitted to the implicit threadpool. So when you use async you're using a thread pool. the await keyword is implemented as a Task.wait() witch is a thread join. The same as if you did a waitAll on a single Task. You do not seem to understand the thing you are attempting to explain. TLDR: Async doesn't have to imply concurrency, async just means that things can more or less happen out of order (async in javascript for example means queued to a async task list that happens with the main loop is idle) but async in C# does imply concurrency because its implemented with Tasks (which use a thread pool which can be green or logical threads). though you can mostly thwart that concurrency with await chaining which is only ok because you're likely already in a task that is ok to block.
That is such a convoluted explanation. Async makes code non-blocking, but the benefit of that only arises, if you batch up multiple tasks, before checking on them. That way the task can fill-in each others waiting sections (like delays), where nothing would get done otherwise. If there are no waiting sections, then there are no potential performance improvements. If there is no batching, then tasks cannot run concurrently.
@@realedna explanation is not trying to say why async await exists or when it’s useful. It’s explaining its implemented in c# and that the video is make assumptions based on the concept and not based on the code that’s actually running. Async as a concept and async as how it works in c# are different things. That aside, using non blocking code is most often beneficial not just when you have a lot of things to do, but when you don’t want to wait on any one thing or even if you want to do it later. In some single threaded languages async puts tasks In the main threads idle loop, so it’s done later when the program isn’t busy not in parallel. In languages like c# it’s always done in a separate thread. Details matter.
I don't think you quite understand asynchronous programming. “async just means that things can more or less happen out of order” No Asynchronous usually means that we do not block our threads and I/O tasks release the thread again. Therefore, your example that code that is always awaited is a codemell is wrong. There is a difference between pure synchronous code and asynchronous code that is always awaited. Because depending on the context, the thread is always blocked in one case and not in the other.
So if a server has 2 threads and you execute something on them and they are busy and another request comes in, and you use async How are they not blocked ? Like, you have 2 threads and they are both busy doing work. Why would async make a difference ? The way I understood async is that if you have to wait for external data, for example a database call, that is on another server, using await means that the thread will not be blocked waiting (doing nothing) for the response from outside and it will be redistributed to do work somewhere else within the app.
Maybe I'm missing something but I don't see any difference to what I said in the videeo. The only thing is that it concentrated only on the scenario when working with external resources, or generally things that are long running but not due to computational use.
![[TH] 2024 PMGC League | Survival Stage วันที่ 1 | PUBG MOBILE Global Championship](http://i.ytimg.com/vi/FVFT-PFwU80/mqdefault.jpg)
For everybody that brings the authority argument that the picture is from the Microsoft docs. Please note that in the Microsoft docs, the picture is used in a sub-section called "Start tasks concurrently", so it's used to describe concurrency/parralelization, not to illustrate the the difference between sync and async programming.
Everybody before deciding this, please read complete article.
I’m not concerned about the rights or wrongs of the article - Dan’s video is clearing up common misconceptions about async/await and is useful in its own right.
@Codewrinkles Following question may sound like stupid one for seasoned developer. I m a just a Devops engineer, currently learning .NET and exploring the concepts of asynchronous programming in C# and have a few questions that might seem basic, but I'm eager to gain a clear understanding.
Async/Await and Background Threads:
Does using async/await in C# inherently involve background threads from the .NET thread pool? I've heard about async operations leveraging the thread pool, and I'm curious about how this works exactly. Is a Task running with async/await always executing on a separate thread?
Task.WhenAll vs Async/Await:
What is the fundamental difference between using Task.WhenAll and async/await? Is Task.WhenAll employed for executing multiple tasks on separate threads? In the example when you you used Task.WhenAll it completed in less time, also you mention about fire and forgot (which I heard somewhere associated with threading)
Task.WhenAll vs Parallel.ForEach:
How does Task.WhenAll differ from Parallel.ForEach in practical terms? My understanding is that Parallel.ForEach is used for parallel programming, focusing on CPU-bound tasks, whereas Task.WhenAll deals with concurrency, primarily for I/O-bound tasks. Could you please elaborate on this distinction? Hope community help me with this.
One more question => Thread Pool Access in IIS:
When a .NET web application is hosted on IIS and uses async/await tasks, does IIS provide access to the entire server's thread pool, or is the thread pool segregated based on the number of applications hosted? How does IIS manage thread allocation in such scenarios?
Using Parallel.ForEach in Web Applications:
In the context of web applications, is it considered a good practice to use Parallel.ForEach for operations? My concern is about the potential risk of overloading the server and affecting the stability of the web application. How does IIS handle such intensive parallel operations, and what are the best practices to ensure application reliability?
@@jojify Quick answer from my point of view: you should not think that when you see async/await that it is running on another thread by default. There might not be another thread at all. The "job" might be running on another hardware, e.g. your network card, so your CPU might not need to spin up another thread to do that work, and the job could resume on the same thread (UI thread for example). Do a quick Google search for a great article from Stephen Cleary called "There is no thread", and don't forget to also read the comments in that article. It's a great source of info on this subject.
Running jobs on another hardware devices to me is "true" asynchronous work (such as Async methods that talk with the file system). Spinning up threadpool threads with Task.Run() is "fake" asynchronousity.
Good points! I would summarize that async programming is about keeping CPU cores as much busy as possible without waiting for background tasks, in a application that can process many asynchronous requests/events.
That's a better summary then I was able to articulate in the video. Thank you!
I was trying to come up with an explanation as good as this. Great comment
So you're saying Microsoft is fundamentally wrong about async/await? Because the image at the start of the clip is from a Microsoft article titled: "Asynchronous programming with async and await"
If that's the case, then yes. it wouldn't be the first time. Although I'm sure it's about context and I'm sure that in the mentioned article they explain the difference and give more context. Just posting the image on Linkedin without any real context just confuses people and make them have a wrong understanding of async vs parallel programming.
@@Codewrinkles@Codewrinkles I'm sure you know the image wasn't posted without context and that most LN infographics come with a decent-sized wall of text explaining the infographic.
That virtually nobody reads.... That's why mostly everybody are using shiny images and not just posting text.
@@Codewrinkles Exactly - it's your fault for not reading it. The creator tried to explain it.
It's the same with your TH-cam videos. There's the thumbnail to attract attention. And then the video to explain the topic.
It's like learning programming by watching coding thumbnails. It must be the creators fault, those pesky thumbnails...
Sorry, but I don't agree with you on this one. In the post the there was some text comparing sync vs async programming with text (mostly extracted from the same article you mentioned, I guess) that didn't match the picture at all. There is no single word about task paralelization, even tough the graphic is cleary showing that concept. Anybody inexperienced dev that watches that picture and reads the text will result in having a totally wrong idea about async and wait, because the picture is what will mostly stick to the brain. And the text didn't do anything to clarify things. I know you two are friends, but I still think you are in the wrong with this one.
Great post, I think it's worth mentioning, that async leverages managing IO operations(external processes) to not block the main execution thread, while Parallelism is used for CPU-heavy tasks(in-process).
Thanks for pointing this out. I would also add maybe that you might want to use parallelization (combined with asynchrony) in a lot of scenarios, like data migrations or similar stuff.
Good explanation!
Async await is extremly important in client-side web apps where we only have one thread, for example in Blazor. If we perform some calculations that take a lot of time, we will have a frozen UI. By awaiting some of these things we can allow the UI to refresh and update in between long calculations, for example for showing progress. In blazor this is actually that common that we manually add some await Task.Delay(1); in between to give the UI some time to catch up. Without these calls the browser will just act frozen and may even report "not responding"
Really? I thought that's what StateHasChanged can be used for
@@kipchickensout yes StateHasChanged forces a re-render of the component but if you for example have a progressbar and just call statehaschanged in between updates and continue work, it is not enough time for the component to update. The main thread has to kind of "idle" a bit to fully get the UI refreshed.
@@matheosmattsson2811 Ah, because the progress bar has a built in timer or takes too long to update?
@@matheosmattsson2811 I don't understand the inner workings enough to get that I guess
@@kipchickensout Yeah I can't say my explanation is the best, nor my understanding tbh. But from experience I know this is what we do currently at work, if we don't we basically have a frozen UI for so long (when doing a 3d model build), that the browser even thinks that the site is not responding etc. We can work around it with these small delays that allow the UI to catch up when we update the progress bar
Thank you for this visual code explanation. I saw the post and something kept bothering me. I'm not the best coder by any means. This clears things up for me.❤
I'm glad you found it useful.
It's like going to a restaurant and placing a large order and customers who ordered after you with small orders get their food before you do.
Oh finally! Thanks for clarifying this!
From some benchmarking I did a while ago, using async-await can also make the code slower than using sync programming. That's because whenever you use these keywords, you create a sort of state machine that can make the *single* execution slower.
However, async programming makes it faster to execute multiple incoming requests since it does not block the threads.
Exactly.
THIS is great because when i googled async /await i too saw that visual. this is very useful for a beginner . can you do a project that walks us thru real world handyness of these async/await functions for those who dont get to use it at work or havent found a job yet where they need to use it
Thank you so much! I happened upon that Breakfast Code example and was stuck trying to figure out why it didn't work asynchronously for me. Again, much appreciated!
I'm glad you found it useful. Thanks for tuning in
The one problem I'm still having is, when I declare the function variables, it executes them immediately upon declaration-no matter which way I have them setup. Sure, I can use threads, and threads seamlessly run concurrently, but I'm writing a WebSocket program, so I was hoping to use Tasks. @@Codewrinkles
It just seems like Tasks are pointless. No matter what you do-despite the async labeling, tasks don't run concurrently. And you get a warning every time you fail to use the await. It seems like they should be called "group" instead of async. The only thing I can see that a task does is it groups the results of a list of functions into one - pointless... Thank you again so much for pointing out the fallacy of the Breakfast Code example. @@Codewrinkles
" I happened upon that Breakfast Code example and was stuck trying to figure out why it didn't work asynchronously for me. " - Because you did not understand the concepts described in the article. The article is fine, concurrency is about threads that are freed to do other things concurrently while waiting for other things to happen, from applications point of view.
Thank you so much for clarifying that. It's a tricky technology@@activex7327
It was a great explanation. Thanks for sharing it. I want to mention that understanding how exactly async/await is handled by the state machine underhood in .Net can help in understanding it better.
Concurrency is doing other tasks while we are waiting for a given task. So in this case, the docs are right, a not-a-blocked thread can do other tasks concurrently while given task completes.
All separated defined async methods are non blocking and program continues with next line. But having a bunch async methods together as a parallel in the main thread then the program will wait until all methods are completed, but are running async in the main thread. Therefor the next line after parallel invocation will not start until all parallel async methods are completed.
Program doesn’t run the next line after await call.. execution control returned to the caller of the method where await call is present. After await call finishes execution, process will try to run the next line with the same thread originally used or a new thread if that’s not necessary
Yeah, u'r totally right, parallel programming is not for noobs! You have to design ur business logic carefully and check which results depend on others before u begin to await everything.
Your videos are great, it's always good to hear and learn from you. But I can't comment in chat in your live stream videos, it says subscriber only mode. What does that mean?
One of the best explanations of the topic I've ever seen. Wish that I had seen it a few years ago.
Glad you found it useful!
The article does a good job explaining the same thing, just simplifies it for a beginner. If you read the entire article from start to finish it is correct. Sorry Code wrinkles you got this one wrong. See my other comment on concurrency. And btw, you video on concurrency is correct, but the article explains the same concept at more beginner level. You are both correct on how concurrency works.
Yep, it's possible to have async working in single threaded environment. Async is about yielding the execution (Hello MoveNext() method of async state machine or Unity coroutines with IEnumerable). Everything else is the details of how TaskScheduler and SynchronizationContext work.
Initially, I had the plan to also show how asynchrony is implemented in Javascript. Precisely to point out that the problem of asynchrony was solved differently in different programming languages, based on what they had at their disposal. Something like "if life gives you lemons, make a lemonade". Great insight! Thanks.
Please make video about typical scenarious , where we should user Task.WhenAll !
@everyone
It looks like this video did more bad then good ... By reading comments seems like lots people still don't know how async await works and what problem it solves. Please watch recent video that explains aysnc/await in detail:
Writing async/await from scratch in C# with Stephen Toub
This video will answer all your questions about concurrency, async/await and threading, which in the docs is mentioned and explained correctly, if you bother reading the docs from start to finish.
Good job on raising awareness. Many posts try to simplify things that aren't simple at all under the hood leading to misconceptions and misinterpretations.
Thank you very much! Only after YOU i understand this theme! I love you! Thank you again!😘
i understand your anger. Thanks for this.
Why do I need asynchrony at all if the application is interface less and interrupt-free, and the standard threads are interrupted at any time as it is?
how do i is this when i don't want to use the buildin database and use my own database, where I use roles and useraccounts ?
I think you're confusing about async and parallel here 😁. Correct me if I'm wrong but,
Synchronize programming is when you execute some sort of IO operation and Wait for the IO Thread to finish and the continue.
Parallel programming is handled using Parallel library it's the fact that you shank a big workload into different CPUs to be executed at the same time then collect the result and return it or what ever.
Async programming in the other hand, is the fact that you fire something in a Task and don't wait for the IO Thread to finish its work the Thread actually returns into the ThreadPool, the big difference with Parallel programming, async programming can be executed if your compute have one single CPU and parallel programming is executed into multiple CPUs.
Great video! Thank you for clarifying this topic and telling the true story!
What's a good way to deal with Task.WhenAll exceptions?
Are you saying that asincronous programming is not making you gain time?
Aren't you gaining timen when your UI is still being responsive while you wait for the HTTP call?
"Are you saying that asincronous programming is not making you gain time" => Yes , asynchronous mean non-blocking, not concurency. If you want the result to return, you still have to wait (hence the await keyword), but meantime, your main thread is not blocked. If your application is a window app, you can move the window around, etc. If your app is a web application, it can take other requests. "Aren't you gaining timen when your UI is still being responsive while you wait for the HTTP call?" how can you gain time when you still have to wait for the response.
So my understanding is that there is basically no benefit to opting to use an Async method over a synchronous counterpart when working with a service that exposes both as part of its API and when using that service on a web server that is doing things synchronously for each request anyway. Am I correct in that line of thinking? Should I be opting for using Async controllers and using the Async API even though I'm always going to immediately await that async call to the service? In this particular case, I'm also not worried about the load issue that using async controller methods would fix.
As I mentioned in the video, there is definitely a benefit of using async and await since each webserver has only a limited number of available threads to work with. If you block them all (due to high load) then you'll have a problem.
Using async for web methods/apis comes with one massive benefit: the ability to pass Cancellation Tokens around.
Should something happen, like the connection getting closed or the user cancelling the request, you can bail out without having to waste time finishing potentially slow and time consuming work that the user is no longer concerned with.
@@billy65bob hey that's a really neat thing I didn't think about! Thanks for letting me know about that feature.
Come on Dan! That picture was taken from Microsoft Docs!
So we should stop reading Microsoft Docs now because those are wrong.
Please, you are doing yourself a total disservice. In the Microsoft docs, the picture is used in a sub-section called "Start tasks concurrently", so it's used to describe concurrency/parralelization, not to illustrate the the difference between sync and async programming.
Seriously section!!
I believe you were in hurry, that you didn't even read complete article.
Look carefully from which *SECTION* each picture is coming
@@mwaseemzakir🤦
The force is strong on this one
@@Codewrinkles Yet, ofc you create async code to allow for concurrency. Non-blocking code (=async) makes no sense without concurrency in mind.
Very usefull video, but you didn't actually explain how async/await works
Briefly: Async prevents blocking of other processes. Here's a good example to try: Create a desktop app in Visual Studio with a single form. Add a button to the form and a function that calls a delay, of like, 8 seconds Delay(8000) or something long enough to see what is going on. Add another button to the form that calls another function that is async, but does the same delay.
Run the program, click the first button and immediately try to move the window around the screen, you can't until 8 seconds has passed.
Try again and this time, click the second button and immediately try to move the window around the screen - you can do so with ease, even though there's a delay in the function.
The first case will block the GUI, specifically the ability for Windows to redraw the form as you move it. The second (async/await delay) will not.
in the windows form code:
private void button1_Click(object sender, EventArgs e)
{
Task.Delay(8000).Wait();
}
private async void button2_Click(object sender, EventArgs e)
{
await Task.Delay(8000);
}
Main takeaway from all this is to use async/await everywhere as a good practice. There are other examples showing similar gotchas with files, db and api calls with synchronous vs asynchronous procedures.
@@davestorm6718 When I use await before method call, the method will be executed in a new thread and the main thread of the program will not be blocked? Is it right? So code in main function will be being executed simultaneously?
th-cam.com/video/R-z2Hv-7nxk/w-d-xo.html
The better example is the preparing of 10k breakfasts step by step or in async mode )))
Thank you. Clear, to the point. Just what I needed. Thank you.
Great to hear!
I dislike Linkedin "experts" with passion...
Great video :)
There is some useful stuff as well, let's admit it. On the other hand, I think it's technically hard, if not impossible, to transmit accurate information (that is often context based) in just one shiny infographic. I think the main problem is the overall way of creating content excessively tailored for views and engagement instead of real education.
Thank for the excellent explanation! Very helpful.
I also keep hearing the term "code smell" more and more. lol
Probably "code smell" is not as popular as "anti-pattern". The problem is when people use it without having a proper understanding of the word.
Are the task and threads are the same thing?
From what I understood, threads are used for heavy computation, for example, you have array of objects that needs to be processed, and you can split this array between different threads, so it will be faster. Tasks are for I/O operations, database or API communication (usually async stuff). The reason to use threads for computation is because CPU usually has several cores, it will divide work between them, but tasks work in the same thread. So whole picture looks like this: Process has many threads, thread can have many tasks
Nope. 2 completely different things
Tasks are a C# thing, in other languages you can see them named as Futures. Threads however, are workers, that run the tasks inside them, they are like smaller programs within the larger one that is currently running. I am not entirely sure about CLR using real threads or "green" (virtual) threads, but there isn't a requirement to run N threads for N tasks, you can have 1 thread running N tasks and so on. For the video analogy, you can have one cook, doing 10 dishes, and you can have 10 cooks doing 10 dishes, but if they are available then there isn't a need to have any more cooks. You can read more about "multitasking vs parallelism".
As many answered before, no, they are not the same thing. And that's actually why .NET right now is so powerful. Because you don't need to care about the low level stuff. Thread utilization is handled by the runtime.
Task is just a class that represents a long running operation which at some point will return a result. How that task is run, how many threads are involved and so on, is handled by the runtime.
where is source code?
Like for all videos, you'll find instructions on how to get the source code for each video on the Membership Tab if you are an ambassador member. If you are a Supporter, on the Membership tab you will see only instructions for the source code of the live streams: www.youtube.com/@Codewrinkles/membership
As I see, everybody are angry about LinkedIn posts 😅
If so many people are angry about it, there's a good chance there's something fishy. There's no smoke without a fire.
My point is that creators, myself included, should take a little bit more responsibility and accountability about what they are posting. The worst thing you can do to more inexperienced devs is to plant wrong ideas in their heads. Sometimes you can do it unintentionally. My point is: this type of responsibility should come before the drive for views and engagement.
@@Codewrinkles agree
Relax brother! Life is too short to get angry at LinkedIn influencers.
THANK YOU. New subscriber here. I hope you get to see more posts that make you angry :)
Seems very easy to be a youtube expert these days. If a developer lack this basic understanding, maybe it's time to realize you have no idea about what you are doing?
Thank you so much for this vdo.
You are most welcome
Aaj pata chal gaya Neha ke manager ko kuch nahi aata
You are conflating "asynchronous" with the async keyword. Asynchronous does not mean concurrent or parallel, but it doesn't mean just async keywords either. But lets assume it does. Of course if you await every asynchronous function it behaves synchronously that's what the await keyword is for (to synchronously wait on an asynchronous function which is why you can't await unless you're also in an asynchronous function). That image is exactly correct explaining asynchronous behaviors (as they exist in .net) when you don't do something like await every async function to force it to behave synchronous (something you would only do if the API is only provided as async but you don't need the extra asynchronicity because for example you're already in a worker thread and synchronizing simplifies the code). And awaiting every async function IS a code smell (unless you're in that specific situation), because if that's how you're going to use them they probably never needed to be async to begin with. if it's okay to hold up the current thread until the async function finishes inline, then it could have just been a synchronous function. In .net the async keyword is implemented with a Task object that is submitted to the implicit threadpool. So when you use async you're using a thread pool. the await keyword is implemented as a Task.wait() witch is a thread join. The same as if you did a waitAll on a single Task. You do not seem to understand the thing you are attempting to explain.
TLDR: Async doesn't have to imply concurrency, async just means that things can more or less happen out of order (async in javascript for example means queued to a async task list that happens with the main loop is idle) but async in C# does imply concurrency because its implemented with Tasks (which use a thread pool which can be green or logical threads). though you can mostly thwart that concurrency with await chaining which is only ok because you're likely already in a task that is ok to block.
That is such a convoluted explanation.
Async makes code non-blocking, but the benefit of that only arises, if you batch up multiple tasks, before checking on them. That way the task can fill-in each others waiting sections (like delays), where nothing would get done otherwise. If there are no waiting sections, then there are no potential performance improvements. If there is no batching, then tasks cannot run concurrently.
@@realedna explanation is not trying to say why async await exists or when it’s useful. It’s explaining its implemented in c# and that the video is make assumptions based on the concept and not based on the code that’s actually running. Async as a concept and async as how it works in c# are different things.
That aside, using non blocking code is most often beneficial not just when you have a lot of things to do, but when you don’t want to wait on any one thing or even if you want to do it later. In some single threaded languages async puts tasks In the main threads idle loop, so it’s done later when the program isn’t busy not in parallel. In languages like c# it’s always done in a separate thread. Details matter.
I don't think you quite understand asynchronous programming.
“async just means that things can more or less happen out of order”
No Asynchronous usually means that we do not block our threads and I/O tasks release the thread again. Therefore, your example that code that is always awaited is a codemell is wrong. There is a difference between pure synchronous code and asynchronous code that is always awaited. Because depending on the context, the thread is always blocked in one case and not in the other.
🔥🔥🔥
Just awesome
Good video thanks
Glad you enjoyed it
So if a server has 2 threads and you execute something on them and they are busy and another request comes in, and you use async How are they not blocked ? Like, you have 2 threads and they are both busy doing work. Why would async make a difference ?
The way I understood async is that if you have to wait for external data, for example a database call, that is on another server, using await means that the thread will not be blocked waiting (doing nothing) for the response from outside and it will be redistributed to do work somewhere else within the app.
Maybe I'm missing something but I don't see any difference to what I said in the videeo. The only thing is that it concentrated only on the scenario when working with external resources, or generally things that are long running but not due to computational use.
Today I realised Neha's Manager knows nothinggggg