C# Async await deadlock problem gone in .NetCore?

Question

In .NetFramework there was a high risk of a deadlock occuring when synchronizing to the synchronization context using:

var result = asyncMethod().Result; var result = asyncMethod().GetAwaiter().GetResult();

instead of

var result = await asyncMethod();

(read Stephen Cleary blogpost for more info)

Since the synchronization context has been removed in .NetCore. Does this mean that the above methods are now safe to use?

I'd go with "marginally less likely to explode and maim you"... they're still hugely problematic and best avoided, with a slight caveat around "unless you have checked, and already know that they completed successfully" — Marc Gravell
– Marc Gravell, Commented Nov 12, 2018 at 15:37
@MarcGravell: But if you already know that they completed successfully then await does not yield, so in that case you might as well just use await. — Eric Lippert
– Eric Lippert, Commented Nov 12, 2018 at 18:52
@EricLippert there are cases - especially in IO/perf code - where the state machine overhead is very measurable and a lot of the calls turn out to be sync; in those cases, there are demonstrable benefits in having a pure sync fast path with an async fallback; I acknowledge that this is probably a niche area - and certainly one that impacts library/framework authors a lot more than it impacts application authors: but it is a very real thing; as an aside: local functions work nicely for this case, it turns out - but usually in the proposed "static local function" sense (no capture state) — Marc Gravell
– Marc Gravell, Commented Nov 12, 2018 at 19:21

Chris Pratt · Accepted Answer · 2018-11-12 15:22:38Z

7

Yes and no. It's true that there's no synchronization context in .NET Core, and thereby, one of the major sources of deadlock issues has been eliminated. However, this doesn't mean that deadlocks are totally impossible. Regardless, you should not let good programming practices slide, just because it may not be a big issue in one circumstance any more. ASP.NET Core, in particular, is fully async, so there is no reason to ever use a sync version of a method or simply block on an async task. Use await as you always would and should.

answered Nov 12, 2018 at 15:22

Chris Pratt

240k37 gold badges414 silver badges469 bronze badges

Sign up to request clarification or add additional context in comments.

5 Comments

PlebFred Over a year ago

I completely agree with you in regards to best practice. However, to keep on topic: Are there any known deadlock issues with these methods in .NetCore now that the synchronization context is gone?

GSerg Over a year ago

@Lillem4n Well, Stephen Cleary says no.

Kevin Gosse Over a year ago

@Lillem4n While you're mostly safe from deadlocks, you can still experience threadpool starvation labs.criteo.com/2018/10/…

poke Over a year ago

“there's no synchronization context in .NET Core” – This is incorrect: There is no synchronization context in ASP.NET Core but nothing can be said about .NET Core in general.

Chris Pratt Over a year ago

This was posted in 2018. At the time, that statement was true. It was added to support additional workloads like WPF, WinForms, etc. that came in 3.0

PlebFred · Accepted Answer · 2018-11-13 09:03:36Z

You Can Block on Async Code - But You Shouldn’t

The first and most obvious consequence is that there’s no context captured by await. This means that blocking on asynchronous code won’t cause a deadlock. You can use Task.GetAwaiter().GetResult() (or Task.Wait or Task.Result) without fear of deadlock. However, you shouldn’t. Because the moment you block on asynchronous code, you’re giving up every benefit of asynchronous code in the first place. The enhanced scalability of asynchronous handlers is nullified as soon as you block a thread. There were a couple of scenarios in (legacy) ASP.NET where blocking was unfortunately necessary: ASP.NET MVC filters and child actions. However, in ASP.NET Core, the entire pipeline is fully asynchronous; both filters and view components execute asynchronously. In conclusion, ideally you should strive to use async all the way; but if your code needs to, it can block without danger.

-Extract from blogpost by Stephen Cleary

Credit to GSerg for finding the post

However, you might encounter thread pool starvation

http://labs.criteo.com/2018/10/net-threadpool-starvation-and-how-queuing-makes-it-worse/

Collectives™ on Stack Overflow

C# Async await deadlock problem gone in .NetCore?

2 Answers 2

5 Comments

Comments

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

5 Comments

Comments

Related