1. Hold up, wait a minute, let me put some async in it
Hello everyone! Thanks for coming to my talk. My name is Matthew, and this is Hold Up, Wait A Minute, Let Me Put Some Async In It.
Now, I need to be honest with you all for second. I submitting the abstract for this class to CodeMash partially because I wanted to do a talk on asynchronous programming in .NET and C#, which is indeed what this talk is about, but mostly because I could not stop giggling at this ridiculous title. I seem to have fits of the giggles around stupid puns, so if I randomly start giggling while I’m talking, you’ll know why.
Matthew Jones
U-Haul
exceptionnotfound.net

2. assumptions
I am making a couple of assumptions about you, my audience.
First, that you are familiar with ASP.NET MVC and at least somewhat familiar with the idea of Dependency Injection. My sample apps use these, and I will not be explaining how they work. If you don’t know DI, that’s probably fine, but familiarity with ASP.NET MVC is pretty much a requirement.
Second, that you have an app that you believe might benefit from being refactored toward asynchronous. This class aims to show you why, or why not, it would help you.
And that’s it! Let’s jump right in.

3. The app
Let’s take a quick walkthough of the app we’re going to refactor.
Quick demo for Users, Posts, Albums, and Photos.
All data is coming from an external API, which makes this a fantastic candidate for refactoring to an async/await architecture.

4. The plan
We need a plan, a plan to help us refactor our app into a workable asynchronous solution. There is one principle refactoring guideline we need to keep in mind.

5. Fundamentals of async Async != Multithreading I/O-Bound, not CPU-bound
Spreads like a virus
Does NOT make code faster
Improves throughput

6. Task Task<T> void Return types
There are three return types in asynchronous code in .NET. Task, which represents work being done. Task<T>, which represents work being done and that will return a type T, and void, which is true fire-and-forget.

7. Refactoring guideline
Refactor “bottom up”
Less dependencies
Easier testing
Promotes “async all the way down”
Who here has an app that, they believe would benefit from using async? Would anyone like to volunteer why they think that

8. Object model
User
Post
Album
Where should we start? Photo!
Photo

9. Live code warning
LIVE CODE WARNING! There is a LOT of live code in this session. That means things could go wrong, break, etc. Be patient. I could very easily end up as that guy.

10. Async-over-sync 1
Remember that async programming does not improve performance; it improves throughput. It allows less threads to handle more requests by freeing those threads up when they are waiting on something.
A thread is used to enter the GetAll method.
Another thread is called over to run the contents of the Task.Run method.
The first thread now blocks on photoTask.Result, because it cannot continue processing until that result is available.
In other words, we’ve used two threads, and blocked one, to do the work it formerly took only one thread to do.
Granted, you probably don’t need to worry about this at small scales. But at large scales, it becomes a problem. 2 3

11. Code time!
Let’s see the code!

12. DEadlock 1 5 7 DEADLOCK 2 4 3 6 The top-level method calls GetAll().
GetAll starts an async request to the specified URL by calling GetStringAsync (still within the context).
GetStringAsync returns an uncompleted Task, specifying that the task is not yet done and there’s nothing to return, so the thread can go to process something else.
We are now awaiting the result of GetStringAsync. The context is captured at this point and will be used to restore the task once processing is complete.
The controller method is now synchronously blocking on the result. This blocks the context thread.
At some point in the future, the call to GetStringAsync finishes. This completes the task returned by GetStringAsync.
The continuation for GetAll is now ready to run, and must wait for the context to be available to do so.
DEADLOCK! At Step 5, the controller method blocks the context thread. At Step 7, the continuation is forced to wait for the context. The context will not be freed, 2 4 3 6

13. solution Async all the way down
What you will find, as you do more asynchronous programming, is that many of the problems that people run into can be solved by making everything asynchronous. In this way, asynchronous code is like a virus, albeit a benevolent and helpful one; you want it as many places as possible in order to not have problems like deadlock.
This can mean quite a bit of work, though.

14. Code time!
Let’s see the code!

15. Cancellation tokens Allow for tasks to be cancelled at any time
Must periodically check for cancellation.
If native methods support tokens, use them.
Tokens created by CancellationTokenSource
We need to learn a few basics of cancellation tokens before we can use them.

16. Cancellation tokens
You should notice several things about the above code.
The first is that we aren’t using GetStringAsync, because that method does not support cancellation tokens natively. If a method supports cancellation tokens natively, use that before trying to use them manually.
The second is that there is no error handling. In real system, there would need to be, but for this demo, we’ll skip it.

17. Code time!
Let’s see the code!

18. Questions?
Let’s see the code!

19. Thanks!! exceptionnotfound.net / @ExceptionFound
github.com/exceptionnotfound/
Repository: AsyncAwaitRefactoringDemo
Feedback appreciated!
Ask me about working at U-Haul!