I get in a lot of fights.
async/await anyway. Despite async/await being over 5 years old (AOTW), there still remains a lot of confusion regarding some basic functionality.
I do not presume to be an in-depth expert. Some of the things I read from Stephen Cleary or Jon Skeet make my eyes go crossed. But for your average, everyday usage, it doesn’t need to be so misunderstood.
I am not going to rehash the excellent articles that explain these things. I am going to share a WPF application that demonstrates some of the commonly misunderstood pitfalls so you can actually observe the things you read about by the experts like Stephen Cleary, Stephen Toub, Jon Skeet.
Introducing “WPFGui”…. This is a simple Windows Presentation Foundation application that will attempt to update the UI on each of the button clicks. Of course I don’t need to update the UI directly with MVVM, but this is a contrived example after all….
Async programming has become ubiquitous and the standard tool for making async HTTP requests with C# is
HttpClient from the
System.Net.Http namespace. Examples are aplenty, but good examples are few and far between. Because
IDisposable we are conditioned to new it up in a using statement, make the call and get out as fast as possible.
This is WRONG.
This blog post will pull together advice from the few good resources online that touch on various aspects of why you are using it wrong, and how to use it correctly.
The async and await keywords have been around for a while (since .Net 4.5) yet there still remains a fair amount of confusion regarding how it works. First off, while the compiler is arguably doing something akin to magic, you could achieve much the same results with BeginInvoke and EndInvoke. The async/await way of doing things makes the code more natural to write and reason about but there is nothing new in the operating system to make this magic.
A basic thing async/await does for you is to allow scalability by allowing your thread to go off and do other work while you wait on some asynchronous activity. It does not mean you spin up new threads and do processing in parallel (though, you could). I’ll describe this in non-technical terms to make it clear.
Suppose you have a butler and we will say he is a synchronous butler. Your butler has been tasked with folding your underwear but you decide to order pizza so you tell your butler to stop folding and go wait at the door for the delivery. Your butler is effectively blocked from doing anything while the pizza is cooked and delivered. When the doorbell rings he will open the door, pay the driver, serve your pizza then get back to folding your spiderman underoos.
What a waste. Why can’t your butler keep folding clothes while the pizza is on its way? If you got the asynchronous model he easily could. He would call to order your pizza, put the task of answering the doorbell on hold, then go do other work. When the doorbell rings, he will pick up his task of serving you pizza where he left off and get the door.
That is the very basics of async/await. When you await a task the thread is free to do other work but it will come back and finish up when it needs to. This provides scalability by not wasting threads and forcing them to sit around idle. You are allowing your application and the operating system to operate more efficiently.