Hi Amigo, you have to understand that this is really an advanced topic and not everyone can understand easily. I guess that is why there are not too many people like this video :( However, your video is really awesome and very valuable to me. May I sincerely ask for your great help and effort of Part 3 please?
Hi my friend. Thank you a lot for watching my videos and I appreciate the nice words. To be honest Part 3 is just a side note and it doesn't affect your code style in any way. It's just about how the code runs on the synchronization context. I'll consider your request for the next videos...
Thanks, this is really useful. It answered some of my questions although I still have some questions left. But will you continute making the part 3 (it's been 3 years LOL ) ?
This is a good demonstration but speaking from experience having built highly threaded production systems using almost entirely Async / Await.. You definitely should be using Async/Await and Tasks as the default for all functions that do not return a value instantly. This is because Async/await breaks the work up into smaller and smaller pieces that can be run on different threads when ConfigureAwait(false) is used, so it helps to reduce friction caused by blocking operations. If you imagine that CPU threads are like lanes in a freeway and synchronous code blocks are like articulated busses while Async state machines are like groups of electric scooters. Articulated busses can carry more people overall but when a bus stops, everyone on the bus stops and everyone behind them has to stop as well. But if everyone is using electric scooters then when one scooter stops, the other scooters behind them simply switch lanes and go around the blocked scooter. The net result is a much more even traffic flow and a higher throughput overall, even though the initial overhead might be slightly higher.. This not only makes the UI seem more responsive but it also makes better use of all CPU cores by default so your applications become much more scalable. So yes go nuts with Async/Await because it is very robust and it takes a lot of the pain out trying to write code that makes full use of all CPU cores.
Thanks for writing your experience, ConfigureAwait(false) only determines where to continue after finishing the task, but all the task are run on the thread pool threads no matter what... You should always run your long running codes or IO ones on a Task or a dedicated Thread but if you use tasks for small none IO, none blocking code not only the overhead will be high but it will heavily lowers the performance, keep in mind thread pool threads are limited and eventually will run out and OS will need to create a new one if needed which makes it even worse for such small tasks. And you should also add the added amount of memory overhead to all this! Also remember not everyone has a great multi-core CPU! even today! It's absolutely expensive in my country 😁 My advice is to use Tasks and Threads wisely
@@FullStackAmigo The thread pool only spins up a new thread when all existing threads are blocked so using the thread pool is a choice between using slightly more resources or your app UI freezing. Also you can adjust how many threads the thread pool uses.. So if your thread pool is set to 1 then all of your tasks will run on the UI thread.. and if it is set to 1000 then then your tasks will run on as many threads as is necessary to get the job done in the optimum way so even if you have only have a single cpu core with 2 hardware threads, it's still better to use tasks in most cases because it allows your software to scale up and down to match the cores of computer it is running on when is is deployed in production.. For example.. in UNO platform by default compiling to WASM uses only one thread (you can compile it to use more but it is experimental) Android (ARM) is limited to about 100 threads, and windows is limited to 1000 threads so if you use exclusively Tasks, your code will run on all platforms without issue.. but if you use explicit threads or no threads then your code will have serious bottlenecks and have to be rewritten for each platform. So maybe multicore cpus are expensive in your country but I doubt they are as expensive as developers and I doubt that you'd want to write software only for people in your country. I was also very skeptical about using tasks everywhere until I actually tried it and saw it running in production. In my experience, Tasks are equally beneficial for backend processing apps as they are for UI frontend apps and ValueTasks can also be used where optimization is needed.
Hola Amigo Great Video. Thank you (I wish you get likes, subscribes as fast as it can, so I can watch the video about ExecutionContext and SynchronizationContext)
Hi Amigo, you have to understand that this is really an advanced topic and not everyone can understand easily. I guess that is why there are not too many people like this video :( However, your video is really awesome and very valuable to me. May I sincerely ask for your great help and effort of Part 3 please?
Hi my friend. Thank you a lot for watching my videos and I appreciate the nice words. To be honest Part 3 is just a side note and it doesn't affect your code style in any way. It's just about how the code runs on the synchronization context. I'll consider your request for the next videos...
Awesome video of async/await.. Waiting for more videos like this. Hats off to you .. Amigo
Thanks a ton! Happy to have you here!
waiting for the next part...
Thanks
Thanks, this is really useful. It answered some of my questions although I still have some questions left.
But will you continute making the part 3 (it's been 3 years LOL ) ?
Glad that it helped! I'd love to continue making videos, I hope that it happens soon just need to fix a life problem! thanks for watching!
Great job , learned a bunch of things , much appreciated
Thanks Jay, Glad to hear it.
This is a good demonstration but speaking from experience having built highly threaded production systems using almost entirely Async / Await..
You definitely should be using Async/Await and Tasks as the default for all functions that do not return a value instantly.
This is because Async/await breaks the work up into smaller and smaller pieces that can be run on different threads when ConfigureAwait(false) is used, so it helps to reduce friction caused by blocking operations.
If you imagine that CPU threads are like lanes in a freeway and synchronous code blocks are like articulated busses while Async state machines are like groups of electric scooters.
Articulated busses can carry more people overall but when a bus stops, everyone on the bus stops and everyone behind them has to stop as well. But if everyone is using electric scooters then when one scooter stops, the other scooters behind them simply switch lanes and go around the blocked scooter.
The net result is a much more even traffic flow and a higher throughput overall, even though the initial overhead might be slightly higher.. This not only makes the UI seem more responsive but it also makes better use of all CPU cores by default so your applications become much more scalable.
So yes go nuts with Async/Await because it is very robust and it takes a lot of the pain out trying to write code that makes full use of all CPU cores.
Thanks for writing your experience, ConfigureAwait(false) only determines where to continue after finishing the task, but all the task are run on the thread pool threads no matter what... You should always run your long running codes or IO ones on a Task or a dedicated Thread but if you use tasks for small none IO, none blocking code not only the overhead will be high but it will heavily lowers the performance, keep in mind thread pool threads are limited and eventually will run out and OS will need to create a new one if needed which makes it even worse for such small tasks. And you should also add the added amount of memory overhead to all this! Also remember not everyone has a great multi-core CPU! even today! It's absolutely expensive in my country 😁 My advice is to use Tasks and Threads wisely
@@FullStackAmigo
The thread pool only spins up a new thread when all existing threads are blocked so using the thread pool is a choice between using slightly more resources or your app UI freezing.
Also you can adjust how many threads the thread pool uses..
So if your thread pool is set to 1 then all of your tasks will run on the UI thread.. and if it is set to 1000 then then your tasks will run on as many threads as is necessary to get the job done in the optimum way so even if you have only have a single cpu core with 2 hardware threads, it's still better to use tasks in most cases because it allows your software to scale up and down to match the cores of computer it is running on when is is deployed in production..
For example.. in UNO platform by default compiling to WASM uses only one thread (you can compile it to use more but it is experimental) Android (ARM) is limited to about 100 threads, and windows is limited to 1000 threads so if you use exclusively Tasks, your code will run on all platforms without issue.. but if you use explicit threads or no threads then your code will have serious bottlenecks and have to be rewritten for each platform.
So maybe multicore cpus are expensive in your country but I doubt they are as expensive as developers and I doubt that you'd want to write software only for people in your country.
I was also very skeptical about using tasks everywhere until I actually tried it and saw it running in production.
In my experience, Tasks are equally beneficial for backend processing apps as they are for UI frontend apps and ValueTasks can also be used where optimization is needed.
Highest quality!
Thanks!
Please make part 3!
I learned a lot and concept has became little more brighter thanks,
But I think you could explain the state machine some how with some graphicals
Thanks! Yes, it could help a lot ...
Great videos, Thank you!
Thanks Parsa 🤗
Anyone who applies focused effort over a long period of time is bound to succeed in their area. -Pavel Durov
Indeed
👍
🙏
Hola Amigo Great Video. Thank you (I wish you get likes, subscribes as fast as it can, so I can watch the video about ExecutionContext and SynchronizationContext)
Thank you my friend
Dang it, he didn't make part 3!