How to justify using await instead of .Result() or .Wait() in .NET Core?

Question

Since the inception of .NET Core, console apps, function apps, ASP.NET etc. are not using synchronization context in async methods (so they're synchronizing straight to Thread Pool).

This means that using .Result() or .Wait() after async method doesn't cause deadlock any more, and only affects performance (reserving a thread), which is mostly not a concern in small single-threaded business applications that only read and write data from one place to another.

Now most of our developers are happily using .Result() and .Wait() because it looks much nicer than the separate await keyword. And the project sizes are so small that they are the sole developers in those projects.

How can I justify using await keyword when other developers do not see any incentives in using it? I can see that this behaviour can lead to problems in larger projects.

EDITED the question. See the comments.

Answer 1

You have missed the point of async/await

It wasn't created to frustrate developers with deadlocks. It was created to free up Processing power while we wait for a non CPU based task to complete.

The lack of synchronisation context in dotnetcore might save you from unexpected deadlocks, but it also means you have to worry about thread starvation.

Everytime you block a thread with task.Wait() or task.Result() thats one less Thread that your app could be using to do stuff with.

Using await frees up that Thread to be used on other tasks.

Where you would have got a deadlock before, you now run out of threads.

https://docs.microsoft.com/en-us/aspnet/core/performance/performance-best-practices?view=aspnetcore-3.0

I'm going to risk a thought experiment to demonstrate the point without actually testing the code. Always a risk because things are never as simple as they seem.

Let's say we have an ecommerce site. customer places orders via an api call to the backend. the api saves the order to a database, but some orders need fraud checking via an external api which is sometimes v slow, say 60sec.

During normal operation you get a couple of orders a minute and the site operates fine. During your christmas sale however you get an order per second.

You are running on a 4 core machine, if your API blocks on the fraud check you are down to 3 threads, if another 3 fraud check orders come in before the first completes the orders start queuing up. The API is locked.

A slow order completes and frees up a thread, but now you have a backlog of requests to catch up with and each one of those requests has a timeout.

So at peak times customers starts seeing "Error could not place order : timeout"

If you await the fraud call instead then the thread is immediately freed up when the call is made and can be servicing requests until the response comes back. You only have 1 order a second and 4 threads are plenty.

Answer 2

The biggest factor, in my opinion, is that using the Result/Wait members causes the method you're writing to be synchronous rather than asynchronous. That is, you are explicitly deciding to write a synchronous function and changing the semantics of methods you're calling to fit that model. Doing that means every method that might ever need to call your method will need to do it in a synchronous way, rather than being able to do it asynchronously, which it could if you used the await keyword and allowed the asynchronous behavior of the other functions you're calling to propagate.

This is important because you never know how a method you write, especially a public one, might be used later by another developer. It may not be in a place where threading and performance are of any concern now, but they may well be relevant somewhere that a future consumer is using the method, and you won't know that at the time you're writing it. Unless you absolutely need your method to be synchronous for some reason, the best option is to allow the asynchronous nature of other methods you're calling to propagate via your method as well, by using await and making your method async.

Answer 3

The "obvious benefit", as you note, is that it does effect performance. It's not clear from your question what async methods you are using, but if performance is not a concern, you could simply use the the synchronous versions of those methods (which are available in many APIs) and not deal with asynchrony at all. If this is in the context of ASP.NET however, where there is implicit concurrency happening (handling multiple requests), it would be advisable to go with the async/await to not impede performance of request handling.