I have a public async Task Foo() method that I want to call from a synchronous method. So far all I have seen from MSDN documentation is calling async methods via async methods, but my whole program is not built with async methods.
Is this even possible?
Here's one example of calling these methods from an asynchronous method:
Walkthrough: Accessing the Web by Using Async and Await (C# and Visual Basic)
Now I'm looking into calling these async methods from synchronous methods.
Asynchronous programming does "grow" through the code base. It has been compared to a zombie virus. The best solution is to allow it to grow, but sometimes that's not possible.
I have written a few types in my Nito.AsyncEx library for dealing with a partially-asynchronous code base. There's no solution that works in every situation, though.
Solution A
If you have a simple asynchronous method that doesn't need to synchronize back to its context, then you can use Task.WaitAndUnwrapException:
var task = MyAsyncMethod();
var result = task.WaitAndUnwrapException();
You do not want to use Task.Wait or Task.Result because they wrap exceptions in AggregateException.
This solution is only appropriate if MyAsyncMethod does not synchronize back to its context. In other words, every await in MyAsyncMethod should end with ConfigureAwait(false). This means it can't update any UI elements or access the ASP.NET request context.
Solution B
If MyAsyncMethod does need to synchronize back to its context, then you may be able to use AsyncContext.RunTask to provide a nested context:
var result = AsyncContext.RunTask(MyAsyncMethod).Result;
*Update 4/14/2014: In more recent versions of the library the API is as follows:
var result = AsyncContext.Run(MyAsyncMethod);
(It's OK to use Task.Result in this example because RunTask will propagate Task exceptions).
The reason you may need AsyncContext.RunTask instead of Task.WaitAndUnwrapException is because of a rather subtle deadlock possibility that happens on WinForms/WPF/SL/ASP.NET:
Task.Task.async method uses await without ConfigureAwait.Task cannot complete in this situation because it only completes when the async method is finished; the async method cannot complete because it is attempting to schedule its continuation to the SynchronizationContext, and WinForms/WPF/SL/ASP.NET will not allow the continuation to run because the synchronous method is already running in that context.This is one reason why it's a good idea to use ConfigureAwait(false) within every async method as much as possible.
Solution C
AsyncContext.RunTask won't work in every scenario. For example, if the async method awaits something that requires a UI event to complete, then you'll deadlock even with the nested context. In that case, you could start the async method on the thread pool:
var task = Task.Run(async () => await MyAsyncMethod());
var result = task.WaitAndUnwrapException();
However, this solution requires a MyAsyncMethod that will work in the thread pool context. So it can't update UI elements or access the ASP.NET request context. And in that case, you may as well add ConfigureAwait(false) to its await statements, and use solution A.
Update: 2015 MSDN article 'Async Programming - Brownfield Async Development' by Stephen Cleary.
WaitAndUnwrapException is my own method from my AsyncEx library. The official .NET libs don't provide much help for mixing sync and async code (and in general, you shouldn't do it!). I'm waiting for .NET 4.5 RTW and a new non-XP laptop before updating AsyncEx to run on 4.5 (I cannot currently develop for 4.5 because I'm stuck on XP for a few more weeks). –
Escutcheon Task Method gives me an ambiguity error... (It doesn't have RunkTask) How do I solve it? –
Peggi AsyncContext now has a Run method that takes a lambda expression, so you should use var result = AsyncContext.Run(() => MyAsyncMethod()); –
Escutcheon RunTask method. Closest thing I could find was Run, but that doesn't have a Result property. –
Jonis var result = AsyncContext.Run(MyAsyncMethod); –
Escutcheon .Result. It works fine when called via wcf or REST. But it fails when invoked via NUnit. How is this possible, if you could provide your comments. Thanks –
Sandrasandro ExecuteSynchronously flag; I explore this more on my blog. –
Escutcheon T UnAsync<T>(Task<T> task) { ` while (!task.IsCompleted)` ` {` ` Thread.Yield();` ` }` ` return task.Result;` } used like this: var result = UnAsync(MyAsyncMethod()) ? –
Tate Result will wrap exceptions in an AggregateException. –
Escutcheon while loop or whether it's doing something else, it'll always do something. –
Escutcheon !task.IsCompleted when there are other things to do, so we won't starve other threads inside our process. –
Tate var semaphore = new SemaphoreSlim(0); task.ContinueWith(t => { semaphore.Release(); }, cancel); semaphore.Wait(cancel); task.Wait(cancel); ? Any danger doing this if there is an await somewhere before in the call stack? –
Tate while(!task.IsCompleted) loop and letting the semaphore quit waiting every, say, 100ms, using semaphore.Wait(100). This would avoid the 100% CPU thing, while avoiding deadlock, at the price of a possible 100ms "temporary deadlock". Thanks again! –
Tate Nito.AsyncEx library. Alternatively, use .GetAwaiter().GetResult() instead of .WaitAndUnwrapException(). –
Escutcheon await is the most modern form of then. Is there some reason you can't use await? –
Escutcheon await and then attach continuations. await is a more modern syntax for attaching continuations that handles corner cases well and results in more maintainable code. Calling then and then discarding the resulting continuation Task is functionally equivalent to calling an async method and discarding the returned Task (and neither is recommended). –
Escutcheon protected T DoTheSync<T>(Task<T> task) { try { return task.Result; } catch (AggregateException e) when (e.InnerException != null) { ExceptionDispatchInfo.Capture(e.InnerException).Throw(); throw; } } (sorry for not being able to post properly indented code here :-) ) –
Hammertoe RunSynchronously is for delegate tasks; it doesn't work with tasks returned from asynchronous methods. –
Escutcheon Adding a solution that finally solved my problem, hopefully saves somebody's time.
Firstly read a couple articles of Stephen Cleary:
From the "two best practices" in "Don't Block on Async Code", the first one didn't work for me and the second one wasn't applicable (basically if I can use await, I do!).
So here is my workaround: wrap the call inside a Task.Run<>(async () => await FunctionAsync()); and hopefully no deadlock anymore.
Here is my code:
public class LogReader
{
ILogger _logger;
public LogReader(ILogger logger)
{
_logger = logger;
}
public LogEntity GetLog()
{
Task<LogEntity> task = Task.Run<LogEntity>(async () => await GetLogAsync());
return task.Result;
}
public async Task<LogEntity> GetLogAsync()
{
var result = await _logger.GetAsync();
// more code here...
return result as LogEntity;
}
}
GetLog() -- does it throw an AggregateException? –
Shippee GetLog() itself, it raises as a normal exception. But if it raises inside GetLogAsync(), you can get it from task.Exception property. The document is here: msdn.microsoft.com/en-us/library/… –
Spontaneous Task.Run() is not a best practice in an async code. But, again, what's the answer to the original question? Never call an async method synchronously? We wish, but in a real world, sometimes we have to. –
Spontaneous Task.Run(async () => await command.ExecuteNonQueryAsync()); Adding assignments as you did solved the problem: Task<int> task = Task.Run(async () => await command.ExecuteNonQueryAsync()); var result = task.Result; –
Retake Parallel.ForEach abuse won't have an effect in 'the real world' and eventually it took down the servers. This code is OK for Console apps but as @ChrisPratt says, shouldn't be used in Web Apps. It might work "now" but isn't scalable. –
Linden GetLogAsync() throws an exception we can't simply catch it using a try / catch in GetLog(). I mean, it will catch the exception, but it won't be the original one. –
Mcgannon Task<LogEntity> task = Task.Run<LogEntity>(async () => await GetLogAsync()); return task.Result; and simply return GetLogAsync().Result;? –
Logogram Result property. In the second case, the task is performed on the same context and will lead to a deadlock if that context is the UI Thread. –
Corse Microsoft built an AsyncHelper (internal) class to run Async as Sync. The source looks like:
internal static class AsyncHelper
{
private static readonly TaskFactory _myTaskFactory = new
TaskFactory(CancellationToken.None,
TaskCreationOptions.None,
TaskContinuationOptions.None,
TaskScheduler.Default);
public static TResult RunSync<TResult>(Func<Task<TResult>> func)
{
return AsyncHelper._myTaskFactory
.StartNew<Task<TResult>>(func)
.Unwrap<TResult>()
.GetAwaiter()
.GetResult();
}
public static void RunSync(Func<Task> func)
{
AsyncHelper._myTaskFactory
.StartNew<Task>(func)
.Unwrap()
.GetAwaiter()
.GetResult();
}
}
The Microsoft.AspNet.Identity base classes only have Async methods and in order to call them as Sync there are classes with extension methods that look like (example usage):
public static TUser FindById<TUser, TKey>(this UserManager<TUser, TKey> manager, TKey userId) where TUser : class, IUser<TKey> where TKey : IEquatable<TKey>
{
if (manager == null)
{
throw new ArgumentNullException("manager");
}
return AsyncHelper.RunSync<TUser>(() => manager.FindByIdAsync(userId));
}
public static bool IsInRole<TUser, TKey>(this UserManager<TUser, TKey> manager, TKey userId, string role) where TUser : class, IUser<TKey> where TKey : IEquatable<TKey>
{
if (manager == null)
{
throw new ArgumentNullException("manager");
}
return AsyncHelper.RunSync<bool>(() => manager.IsInRoleAsync(userId, role));
}
For those concerned about the licensing terms of code, here is a link to very similar code (just adds support for culture on the thread) that has comments to indicate that it is MIT Licensed by Microsoft. https://github.com/aspnet/AspNetIdentity/blob/master/src/Microsoft.AspNet.Identity.Core/AsyncHelper.cs
Wouldn't this be the same as just calling Task.Run(async ()=> await AsyncFunc()).Result? AFAIK, Microsoft is now discouraging from calling TaskFactory.StartNew, since they are both equivalent and one is more readable than the other.
Absolutely not.
The easy answer is that
.Unwrap().GetAwaiter().GetResult() != .Result
First off the
Is Task.Result the same as .GetAwaiter.GetResult()?
Secondly .Unwrap() causes the setup of the Task not to block the wrapped task.
Which should lead anyone to ask
Wouldn't this be the same as just calling Task.Run(async ()=> await AsyncFunc()).GetAwaiter().GetResult()
Which would then be a It Depends.
Regarding usage of Task.Start() , Task.Run() and Task.Factory.StartNew()
Excerpt:
Task.Run uses TaskCreationOptions.DenyChildAttach which means that children's tasks can not be attached to the parent and it uses TaskScheduler.Default which means that the one that runs tasks on Thread Pool will always be used to run tasks.
Task.Factory.StartNew uses TaskScheduler.Current which means scheduler of the current thread, it might be TaskScheduler.Default but not always.
Additional Reading:
Specifying a synchronization context
ASP.NET Core SynchronizationContext
For extra safety, wouldn't it be better to call it like this
AsyncHelper.RunSync(async () => await AsyncMethod().ConfigureAwait(false));This way we're telling the "inner" method "please don't try to sync to upper context and dealock"
Really great point by alex-from-jitbit and as most object architectural questions go it depends.
As an extension method do you want to force that for absolutely every call, or do you let the programmer using the function configure that on their own async calls? I could see a use case for call three scenarios; it most likely is not something you want in WPF, certainly makes sense in most cases, but considering there is no Context in ASP.Net Core if you could guarantee it was say internal for a ASP.Net Core, then it wouldn't matter.
await calls with ConfigureAwait(false). I tried using AsyncHelper.RunSync to call an async function from the Application_Start() function in Global.asax and it seems to work. Does this mean that AsyncHelper.RunSync is reliably not prone to the "marshal back to the caller's context" deadlock issue I read about elsewhere in this posting? –
Autoclave GetAwaiter does not exist, anyone? –
Abiosis Task.Run(async ()=> await AsyncFunc()).Result? AFAIK, Microsoft is now discouraging from calling TaskFactory.StartNew, since they are both equivalent and one is more readable than the other. Source: devblogs.microsoft.com/pfxteam/… –
Corse async Main() is now part of C# 7.2 and can be enabled in the projects advanced build settings.
For C# < 7.2, the correct way is:
static void Main(string[] args)
{
MainAsync().GetAwaiter().GetResult();
}
static async Task MainAsync()
{
/*await stuff here*/
}
You'll see this used in a lot of Microsoft documentation, for example: Get started with Azure Service Bus topics and subscriptions.
MainAsync().Wait()? –
Concentrate Task.Run. Of course you can use async, and in ASP.NET Core, you should virtually always use async. –
Superload .Result, which can cause Deadlocks. Agree with you guys, in a void Method, call Wait(). –
Illuminism I'm not 100% sure, but I believe the technique described in this blog should work in many circumstances:
You can thus use
task.GetAwaiter().GetResult()if you want to directly invoke this propagation logic.
public async Task<string> StartMyTask()
{
await Foo()
// code to execute once foo is done
}
static void Main()
{
var myTask = StartMyTask(); // call your method which will return control once it hits await
// now you can continue executing code here
string result = myTask.Result; // wait for the task to complete to continue
// use result
}
You read the 'await' keyword as "start this long running task, then return control to the calling method". Once the long-running task is done, then it executes the code after it. The code after the await is similar to what used to be CallBack methods. The big difference being the logical flow is not interrupted which makes it much easier to write and read.
Wait wraps exceptions and has the possibility of a deadlock. –
Escutcheon await, it would be executed synchronously. At least that works for me (without calling myTask.Wait). Actually, I got an exception when I tried to call myTask.RunSynchronously() because it had already been executed! –
Overlong T by calling myTask.Result() after the Wait() –
Godderd Wait() to Result since this will also block until the task is finished. –
Cortisol .Result. –
Doublejointed await, basically - it wasn't asynchronous at all. RunSynchronously doesn't really do what most people think it does - you shouldn't really need it, ever. Result (and Wait) is the thing that synchronously waits for the task to complete - but it gets you in trouble if there's marshalling to the original synchronization context that you're blocking now with your Wait :) –
Truncate Result call at the time, so it never gets there. And Result never ends, because it's waiting for someone who's waiting for the Result to end, basically :D –
Truncate There is, however, a good solution that works in (almost: see comments) every situation: an ad-hoc message pump (SynchronizationContext).
The calling thread will be blocked as expected, while still ensuring that all continuations called from the async function don't deadlock as they'll be marshaled to the ad-hoc SynchronizationContext (message pump) running on the calling thread.
The code of the ad-hoc message pump helper:
using System;
using System.Collections.Concurrent;
using System.Collections.Generic;
using System.Threading;
using System.Threading.Tasks;
namespace Microsoft.Threading
{
/// <summary>Provides a pump that supports running asynchronous methods on the current thread.</summary>
public static class AsyncPump
{
/// <summary>Runs the specified asynchronous method.</summary>
/// <param name="asyncMethod">The asynchronous method to execute.</param>
public static void Run(Action asyncMethod)
{
if (asyncMethod == null) throw new ArgumentNullException("asyncMethod");
var prevCtx = SynchronizationContext.Current;
try
{
// Establish the new context
var syncCtx = new SingleThreadSynchronizationContext(true);
SynchronizationContext.SetSynchronizationContext(syncCtx);
// Invoke the function
syncCtx.OperationStarted();
asyncMethod();
syncCtx.OperationCompleted();
// Pump continuations and propagate any exceptions
syncCtx.RunOnCurrentThread();
}
finally { SynchronizationContext.SetSynchronizationContext(prevCtx); }
}
/// <summary>Runs the specified asynchronous method.</summary>
/// <param name="asyncMethod">The asynchronous method to execute.</param>
public static void Run(Func<Task> asyncMethod)
{
if (asyncMethod == null) throw new ArgumentNullException("asyncMethod");
var prevCtx = SynchronizationContext.Current;
try
{
// Establish the new context
var syncCtx = new SingleThreadSynchronizationContext(false);
SynchronizationContext.SetSynchronizationContext(syncCtx);
// Invoke the function and alert the context to when it completes
var t = asyncMethod();
if (t == null) throw new InvalidOperationException("No task provided.");
t.ContinueWith(delegate { syncCtx.Complete(); }, TaskScheduler.Default);
// Pump continuations and propagate any exceptions
syncCtx.RunOnCurrentThread();
t.GetAwaiter().GetResult();
}
finally { SynchronizationContext.SetSynchronizationContext(prevCtx); }
}
/// <summary>Runs the specified asynchronous method.</summary>
/// <param name="asyncMethod">The asynchronous method to execute.</param>
public static T Run<T>(Func<Task<T>> asyncMethod)
{
if (asyncMethod == null) throw new ArgumentNullException("asyncMethod");
var prevCtx = SynchronizationContext.Current;
try
{
// Establish the new context
var syncCtx = new SingleThreadSynchronizationContext(false);
SynchronizationContext.SetSynchronizationContext(syncCtx);
// Invoke the function and alert the context to when it completes
var t = asyncMethod();
if (t == null) throw new InvalidOperationException("No task provided.");
t.ContinueWith(delegate { syncCtx.Complete(); }, TaskScheduler.Default);
// Pump continuations and propagate any exceptions
syncCtx.RunOnCurrentThread();
return t.GetAwaiter().GetResult();
}
finally { SynchronizationContext.SetSynchronizationContext(prevCtx); }
}
/// <summary>Provides a SynchronizationContext that's single-threaded.</summary>
private sealed class SingleThreadSynchronizationContext : SynchronizationContext
{
/// <summary>The queue of work items.</summary>
private readonly BlockingCollection<KeyValuePair<SendOrPostCallback, object>> m_queue =
new BlockingCollection<KeyValuePair<SendOrPostCallback, object>>();
/// <summary>The processing thread.</summary>
private readonly Thread m_thread = Thread.CurrentThread;
/// <summary>The number of outstanding operations.</summary>
private int m_operationCount = 0;
/// <summary>Whether to track operations m_operationCount.</summary>
private readonly bool m_trackOperations;
/// <summary>Initializes the context.</summary>
/// <param name="trackOperations">Whether to track operation count.</param>
internal SingleThreadSynchronizationContext(bool trackOperations)
{
m_trackOperations = trackOperations;
}
/// <summary>Dispatches an asynchronous message to the synchronization context.</summary>
/// <param name="d">The System.Threading.SendOrPostCallback delegate to call.</param>
/// <param name="state">The object passed to the delegate.</param>
public override void Post(SendOrPostCallback d, object state)
{
if (d == null) throw new ArgumentNullException("d");
m_queue.Add(new KeyValuePair<SendOrPostCallback, object>(d, state));
}
/// <summary>Not supported.</summary>
public override void Send(SendOrPostCallback d, object state)
{
throw new NotSupportedException("Synchronously sending is not supported.");
}
/// <summary>Runs an loop to process all queued work items.</summary>
public void RunOnCurrentThread()
{
foreach (var workItem in m_queue.GetConsumingEnumerable())
workItem.Key(workItem.Value);
}
/// <summary>Notifies the context that no more work will arrive.</summary>
public void Complete() { m_queue.CompleteAdding(); }
/// <summary>Invoked when an async operation is started.</summary>
public override void OperationStarted()
{
if (m_trackOperations)
Interlocked.Increment(ref m_operationCount);
}
/// <summary>Invoked when an async operation is completed.</summary>
public override void OperationCompleted()
{
if (m_trackOperations &&
Interlocked.Decrement(ref m_operationCount) == 0)
Complete();
}
}
}
}
Usage:
AsyncPump.Run(() => FooAsync(...));
More detailed description of the async pump is available here.
To anyone paying attention to this question anymore...
If you look in Microsoft.VisualStudio.Services.WebApi there's a class called TaskExtensions. Within that class you'll see the static extension method Task.SyncResult(), which like totally just blocks the thread till the task returns.
Internally it calls task.GetAwaiter().GetResult() which is pretty simple, however it's overloaded to work on any async method that return Task, Task<T> or Task<HttpResponseMessage>... syntactic sugar, baby... daddy's got a sweet tooth.
It looks like ...GetAwaiter().GetResult() is the MS-official way to execute async code in a blocking context. Seems to work very fine for my use case.
You can call any asynchronous method from synchronous code, that is, until you need to await on them, in which case they have to be marked as async too.
As a lot of people are suggesting here, you could call Wait() or Result on the resulting task in your synchronous method, but then you end up with a blocking call in that method, which sort of defeats the purpose of async.
If you really can't make your method async and you don't want to lock up the synchronous method, then you're going to have to use a callback method by passing it as parameter to the ContinueWith() method on task.
async too" drew my attention away from what you were really saying. –
Panthia var result = Task.Run(async () => await configManager.GetConfigurationAsync()).ConfigureAwait(false);
OpenIdConnectConfiguration config = result.GetAwaiter().GetResult();
Or use this:
var result=result.GetAwaiter().GetResult().AccessToken
Here is the simplest solution. I saw it somewhere on the Internet, I didn't remember where, but I have been using it successfully. It will not deadlock the calling thread.
void SynchronousFunction()
{
Task.Run(Foo).Wait();
}
string SynchronousFunctionReturnsString()
{
return Task.Run(Foo).Result;
}
string SynchronousFunctionReturnsStringWithParam(int id)
{
return Task.Run(() => Foo(id)).Result;
}
Stephen Cleary's Answer;
That approach shouldn't cause a deadlock (assuming that ProblemMethodAsync doesn't send updates to the UI thread or anything like that). It does assume that ProblemMethodAsync can be called on a thread pool thread, which is not always the case.
https://blog.stephencleary.com/2012/07/dont-block-on-async-code.html
And here is the approach;
The Thread Pool Hack A similar approach to the Blocking Hack is to offload the asynchronous work to the thread pool, then block on the resulting task. The code using this hack would look like the code shown in Figure 7.
Figure 7 Code for the Thread Pool Hack
C#
public sealed class WebDataService : IDataService
{
public string Get(int id)
{
return Task.Run(() => GetAsync(id)).GetAwaiter().GetResult();
}
public async Task<string> GetAsync(int id)
{
using (var client = new WebClient())
return await client.DownloadStringTaskAsync(
"https://www.example.com/api/values/" + id);
}
}
The call to Task.Run executes the asynchronous method on a thread pool thread. Here it will run without a context, thus avoiding the deadlock. One of the problems with this approach is the asynchronous method can’t depend on executing within a specific context. So, it can’t use UI elements or the ASP.NET HttpContext.Current.
Inspired by some of the other answers, I created the following simple helper methods:
public static TResult RunSync<TResult>(Func<Task<TResult>> method)
{
var task = method();
return task.GetAwaiter().GetResult();
}
public static void RunSync(Func<Task> method)
{
var task = method();
task.GetAwaiter().GetResult();
}
They can be called as follows (depending on whether you are returning a value or not):
RunSync(() => Foo());
var result = RunSync(() => FooWithResult());
return Task.Run(async () => await method()).GetAwaiter().GetResult(); –
Viccora method() is actually an asyncrounous method itself - while in @Metalogic's example foo() is a syncrounous method that he is calling asyncrounously. In your case simply method().GetAwaiter().GetResult(); should sufice –
Hirai Well I was using this approach for years, which also handles and propagates exceptions from the underlying async task. Which works flawlessly.
private string RunSync()
{
var task = Task.Run(async () => await GenerateCodeService.GenerateCodeAsync());
if (task.IsFaulted && task.Exception != null)
{
throw task.Exception;
}
return task.Result;
}
But since that Microsoft created this async helper: https://github.com/aspnet/AspNetIdentity/blob/main/src/Microsoft.AspNet.Identity.Core/AsyncHelper.cs
Here is also their source:
public static void RunSync(Func<Task> func)
{
var cultureUi = CultureInfo.CurrentUICulture;
var culture = CultureInfo.CurrentCulture;
_myTaskFactory.StartNew(() =>
{
Thread.CurrentThread.CurrentCulture = culture;
Thread.CurrentThread.CurrentUICulture = cultureUi;
return func();
}).Unwrap().GetAwaiter().GetResult();
}
You can now use source generators to create a sync version of your method using Sync Method Generator library (nuget).
Use it as follows:
[Zomp.SyncMethodGenerator.CreateSyncVersion]
public async Task FooAsync()
Which will generate Foo method which you can call synchronously.
Remove asynchronous invocations without the Async suffix) from the main GitHub page because you're not the author this feature can definitely introduce bugs. Since there are APIs out there that only support Async API this unfortunately is not a universal solution to OP's question. –
Mutule Everyone seems to presuppose that there is a need to wait for the result. I often have to update data from synchronous methods where I don't care about the result. I just use a discard:
_ = UpdateAsync();
© 2022 - 2024 — McMap. All rights reserved.
async void Foo()method does not return aTaskit means a caller cannot know when it completes, it must returnTaskinstead. – Smilacaceous