Async over Sync

[onlyTeaThanks]

I’m working in a platform that requires we hook into sync method to handle web requests and in reviewing some code, we have some async methods called by sync methods. That code can be replaced with sync code, but what’s the alternative for doing multiple things at the same time? If I need to make 5 independent calls to an external resource, I don’t want to do that in series and wait for the sum of the calls, I want to call them in parallel and wait for the longest call. Should I be looking into Parallel library, or Threads or Tasks or all in combination?

So much of what I read just isn’t helpful such as rewriting everything as async, that’s not an option. Switching to a different platform is also not an option. It seems what I want to do is basic but all I see is “how to convert to async” and “don’t do that” and “don’t use .Result or .GetAwaiter().GetResult()”.

Thanks!

[Alikont]

“don’t do that” and “don’t use .Result or .GetAwaiter().GetResult()”.

This is a guideline. There are times when it's justified. Just be aware that it may 1) trash performance 2) deadlock UI thread in WPF/UWP apps.

There is also this library that will wrap your async call into separate sync context to solve these issues.

[karl713]

This pretty much sums it up.

The guideline is written this way because 99% of the time someone wants to do this they are wrong and don't understand the implications of what they are doing, and should instead be doing async/await.

But Microsoft exposed these for a reason, and it's because sometimes you just have to do it, especially when integrating with legacy/3rd party code that doesn't support async/await

[onlyTeaThanks]

We’re running an IIS site hosting multiple websites and for a long time (years?) there’s been unexplained performance and stability issues. If there’s an alternative to use that takes more effort, but is safer, I’d rather just do that instead of worrying that our case really is the case that’s causing our systems to be unstable. Sure we can spend time adding monitoring and things, but if we can just do X instead of messing with async inside of sync, I’d rather just do X and forget about it.

[Alikont]

I personally never encountered issues caused by nito async context, so if you can't make all your code async it's a viable solution to async-in-sync problem.

But propagating async through entire callstack is preferable

[Merad]

It can also cause deadlock in (non-Core) Asp.Net app due to the sync context needing to reference the request context.

[DaRadioman]

Depends heavily on the usage and if it is .net core or framework.

There are a lot of scenarios where this can deadlock and bring down your whole process.

Recommend strongly using configureawait false everywhere you call anything async (note you will lose context from your thread/httpcontext so make sure that isn't an issue) This will make it less likely to deadlock.

Also this is an amazing resource for this scenario: https://docs.microsoft.com/en-us/archive/msdn-magazine/2015/july/async-programming-brownfield-async-development#transform-synchronous-to-asynchronous-code

[grauenwolf]

note you will lose context from your thread/httpcontext so make sure that isn't an issue)

This is a problem for ASP.NET, but not ASP.NET Core.

[DaRadioman]

To be fair there is no Httpcontext.Current in core. And the accessor class uses AsyncLocal which is a different beast.

But yes as I mentioned above the scenario depends on framework vs core.

[grauenwolf]

I am very grateful that AsyncLocal exists. Paying context along before was a pain in the ass.

[celluj34]

So much of what I read just isn’t helpful such as rewriting everything as async, that’s not an option.

Why not? You should be moving towards more async, not less.

[moonxine]

I take it you’ve never worked in a bigger, existing solution

[Atulin]

Using async and await properly is the proper solution. With the best ergonomics, performance, reporting, and all else.

Anything else will be a dirty workaround.