Have You Ever Signaled async/await Progress in These Three Ways?
ฝัง
- เผยแพร่เมื่อ 9 พ.ค. 2024
- Tasks have greatly simplified synchronization and data marshaling, which we can use quite effectively to transfer progress information back from the running task. There is always a ton of synchronization code at the back, but we shall never have to write that code. That is the beauty of working with .NET tasks.
But the story does not end at the basic scenario. Have you ever thought of what data can be the progress? Is that only the byte count or a percentage, or can we use some less conventional pieces of information? I will ask you to approach this video with an open mind. I will then show you how to hijack the built-in progress marshaling mechanism to inform the outer world about all kinds of events that happen during the task's execution. That will be useful, but above all - it will be fun.
Download source code ► / zoranhorvat
Join Discord server with topics on C# ► codinghelmet.com/go/discord
Enroll course Beginning Object-Oriented Programming with C# ► codinghelmet.com/go/beginning...
Subscribe ► / @zoran-horvat
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
👨 About Me 👨
Hi, I’m Zoran, I have more than 20 years of experience as a software developer, architect, team lead, and more. I have been programming in C# since its inception in the early 2000s. Since 2017 I have started publishing professional video courses at Pluralsight and Udemy and by this point, there are over 100 hours of the highest-quality videos you can watch on those platforms. On my TH-cam channel, you can find shorter video forms focused on clarifying practical issues in coding, design, and architecture of .NET applications.❤️
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⚡️COPYRIGHT NOTICE:
The Copyright Laws of the United States recognize a “fair use” of copyrighted content. Section 107 of the U.S. Copyright Act states: “Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phono records or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright." This video and our TH-cam channel, in general, may contain certain copyrighted works that were not specifically authorized to be used by the copyright holder(s) but which we believe in good faith are protected by federal law and the Fair use doctrine for one or more of the reasons noted above.
#csharp #dotnet #objectorientedprogramming - วิทยาศาสตร์และเทคโนโลยี
![[안방1열 풀캠4K] 베이비몬스터 'FOREVER' (BABYMONSTER FullCam)│@SBS Inkigayo 240707](http://i.ytimg.com/vi/_2HL-ogzzBU/mqdefault.jpg)
This is not code, this is art. Thank you sir.
Exactly
Thank you for this! No frills, no boilerplate, just clean code with succinct explanation 😊
Zorane, samo jedna riječ : hvala !
6:00 - throttling progress report. Thumbs up for that
There was a joke back in my C++ days, over 20 years ago: You know you did a good job when you have to throttle your code or everything else will die.
@@zoran-horvat ahah
As always, Zoran makes everything look effortless. :)
Very nice. TIL Progress class and interface. I really must get back to the habit of RTM.
You are a phenomenon I've found lately. Besides the rich content I especially love the passion for coding coming out of your voice!
Never heard of progress before - seems really cool!
Very useful for UI programming winform/wpf
This one was particularly useful. I had used Progress before, but not in these ways...
Stahp, you're convoluting my mind. This is awesome.
He is a legend! Cheers Mr Z ! :)🍺🍻🍺
you are truly underrated my man
He's really not.
Thank you so much for this video! I just found your channel and everything is so well explained and useful.
I have one question. Within the "try" block we await for the "GenerateTextFile()" method to end. Makes sense, we don't want the program to end before finishing the task. However, why do we await "keyboard" and "ticker" tasks at the "finally" block? We just canceled them, they aren't supposed to be running anymore, are they?
Great example. Thanks for video
Cool content mate!
Very nice video. Interestin stuff 👍
Really cool, thanks.
Amazing.
Your video always holds me down to the beginner, which is a great joy in boring day lives.
This video leads me to MS blog titled "Async in 4.5: Enabling Progress and Cancellation in Async APIs".
It would be highly appreciated if you could recommend a better or up-to-date one.
I read a few articles, but they were nothing special. However, be aware that TPL is a decade old and any article you find will still be accurate from the Tasks point of view.
Nice!
Very nice explaination. What system are you running this on. I tried to replicate the code and the progress was about 10 times slower than your video. When reducing to the size of fil from 700 to 70 I got about the same result (runtime) as in the video.. Running this code in Vistual Studio gives alot of warnings like CA1068: Method should take CancellationToken as last parameter in the FileServices class. I know you have some videoes on naming but what's your take on parameter ordering? Thank you again, Zoran.
Ah parameter ordering! I have already mentioned that issue in an earlier video and I will get back to it again. I am forcing functional design, where it is common to configure the operation first, and then to parameterize it. It works oppositely from object-oriented design. I guess I will have to talk more about that...
Speed in my demo comes mostly from SSD. Slower the disk, slower the operation. The CPU is mostly idle. It is interesting that I couldn't reproduce the clog in the last demo on my MacBook M2 Pro, but had to run it in a virtual machine on a 3-4 years old Windows desktop to cause the performance issue.
So, is progress kind of similar to Subject?
Does Progress do anything Subject wouldn't?
From what I know, Subject's primary purpose is to be observable, which doesn't care about threads.
Progress, on the other hand, is spanning Tasks. It is aware of the synchronisation context (if any) within which it is constructed, and it will use that context to execute the callback. It will only run on a random thread if there was no synchronisation context when it was constructed. Therefore, Progress is safe for use in UI applications, but it is also guaranteed to work safely in any other multithreaded application.
Even though use cases may look similar, these two classes are not interchangeable.
I am a bit confused about the statement "work safe in other multithreaded applications". As far as I understand if sc is null, report callback will be simply pushed to thread pool. There is no thread safe guaranty beetween two subsequent report callback calls and they have a chance to run simultaneously.
@@user-bf8kx6us2x The guarantee is required to marshal the underlying value from one thread to another. Once done, the callback is all you have, and it only executes on one thread.
@@zoran-horvat Yes, I am agreed that progress arguments are safely marshalled. However my point is two subsequent callback calls are not thread safe in general case. If the callbacks share some state, access to it must be synchronized, because the thread pool does not give sequential execution guarantee for two subsequently queued callbacks.
In your example, console is that shared state. There is a chance you see 48% status update before 47%.
@@user-bf8kx6us2x I see your point, but that is what synchronization contexts are meant for. If you play by the book, the Progress object will just work. For example, using the progress object to share a mutable state is not played by the book, and so is when the multithreaded application's main thread operates outside the synchronization context.
This video feels like a fever dream 😂
Is that good or bad? :)
@@zoran-horvat in this case, good ;)
This morning I was looking for a raw code like this, I didn't want to use e.g. Spectre Console, which is awesome BTW, and... then I have found this treasure. Thank you, @zoran-horvat, today you are my Santa Clause.
Any time!