Await for a task inside an async method [duplicate] - c#
I have a public async void Foo() method that I want to call from 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 sync 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:
A synchronous method calls an async method, obtaining a Task.
The synchronous method does a blocking wait on the Task.
The async method uses await without ConfigureAwait.
The 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, 2019-05-01: The current "least-worst practices" are in an MSDN article here.
Adding a solution that finally solved my problem, hopefully saves somebody's time.
Firstly read a couple articles of Stephen Cleary:
Async and Await
Don't Block on Async Code
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;
}
}
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 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.
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:
https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dotnet-how-to-use-topics-subscriptions
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.
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.
var result = Task.Run(async () => await configManager.GetConfigurationAsync()).ConfigureAwait(false);
OpenIdConnectConfiguration config = result.GetAwaiter().GetResult();
Or use this:
var result=result.GetAwaiter().GetResult().AccessToken
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.
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());
Note that the signature in the original question public async void Foo() is incorrect. It should be public async Task Foo() as you should return Task not void for async methods that don't return a value (yes, there are some rare exceptions).
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.
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;
}
After hours of trying different methods, with more or less success, this is what I ended with. It doesn't end in a deadlock while getting result and it also gets and throws the original exception and not the wrapped one.
private ReturnType RunSync()
{
var task = Task.Run(async () => await myMethodAsync(agency));
if (task.IsFaulted && task.Exception != null)
{
throw task.Exception;
}
return task.Result;
}
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 void FooAsync()
Which will generate Foo method which you can call synchronously.
Those windows async methods have a nifty little method called AsTask(). You can use this to have the method return itself as a task so that you can manually call Wait() on it.
For example, on a Windows Phone 8 Silverlight application, you can do the following:
private void DeleteSynchronous(string path)
{
StorageFolder localFolder = Windows.Storage.ApplicationData.Current.LocalFolder;
Task t = localFolder.DeleteAsync(StorageDeleteOption.PermanentDelete).AsTask();
t.Wait();
}
private void FunctionThatNeedsToBeSynchronous()
{
// Do some work here
// ....
// Delete something in storage synchronously
DeleteSynchronous("pathGoesHere");
// Do other work here
// .....
}
Hope this helps!
If you want to run it Sync
MethodAsync().RunSynchronously()
Related
Is using AutoResetEvent across async block code safe?
I am trying to lock a section of my code that is synchronous and release the lock in an asynchronous code block (after an execution of a task). I have read about 'AutoResetEvent', and wanted to implement its signaling functionality between the caller and the callee of the code implementation. The aim is to lock the code that is responsible for verifying whether the transaction was administered before. After the check is done and the transaction was saved, I release the code. The check and saving operations are asynchronous, and the lock release happens at 'continueWith' delegate function. I have the following abstraction and implementation of AutoResetEvent: public interface IThreadLockKeyProvider { public AutoResetEvent PayLock { get; } } public class ThreadLockKeyProvider : IThreadLockKeyProvider { public static readonly AutoResetEvent _payLock; static ThreadLockKeyProvider() { _payLock = new AutoResetEvent(true); } public AutoResetEvent PayLock { get { return _payLock; } } } The instance is injected as a singleton in .net core dependency injection container. The code of the eventhandler method is the following: public Task<Unit> Handle(ProcessPaymentCommand command, CancellationToken cancellationToken) { _threadLockKeyProvider.PayLock.WaitOne(); var res = _brandDepositStrategy.AdministerDeposit().Result; return Task.FromResult(Unit.Value); } The AdministerDeposit method that releases the lock. public override async Task<Task> AdministerDeposit() { Task<PaymentTransactions> dbOperation = _transactionAdministrationFacade.UpdateDbTransactionAsync(_IPNRequestDto); return await dbOperation.ContinueWith(async x => { _threadLockKeyProvider.PayLock.Set(); if (x.IsFaulted) throw x.Exception; _transactionAdministrationFacade.CallBackDto = await _responseComposer.GetPaymentResponseDto(x.Result, _IPNRequestDto); await CreateDepositSF(); }); } The question is whether the implementation cause any problems? Note: The code does work. It doesnt crash and pass the unit tests that I built.
in theory there's nothing wrong with AutoResetEvent in this scenario, but: it isn't exactly built for async, which means that your WaitOne() blocks a thread - exactly what you're trying to avoid. Likewise, you're using sync-over-async. Since this is basically an async lock, seeing the entry/exit so far apart concerns me - it makes it very easy to introduce errors. Let's try and fix those things: use SemaphoreSlim as an async-friendly lock await our result move the entry/exit of the lock into the same place example: private readonly SemaphoreSlim _lock = new(1, 1); public async Task<int> SomeOuterMethodAsync(CancellationToken cancellationToken) { await _lock.WaitAsync(cancellationToken); try { var s = await SomeInnerMethodAsync(cancellationToken); return s.Length; // just some projection } finally { _lock.Release(); } } // note: this could be in unrelated types/instances/etc private Task<string> SomeInnerMethodAsync(CancellationToken cancellationToken) => throw new InvalidOperationException("not shown");
System.Threading.Channels ReadAsync() method is blocking execution
Overview I am attempting to write an IAsyncEnumerable<T> wrapper around an IObserver<T> interface. At first I used a BufferBlock<T> as the backing data store, but I found out through performance testing and research that it is actually a pretty slow type, so I decided to give the System.Threading.Channels.Channel type a go. I had a similar problem with my BufferBlock implementation as this one but this time I'm not sure how to resolve it. Problem My GetAsyncEnumerator() loop gets blocked by the await _channel.Reader.WaitToRead(token) call if my IObserver<T>.OnNext() method hasn't written to the _channel yet. What is the correct way to wait for a value to be available to yield in this context without blocking program execution? Implementation public sealed class ObserverAsyncEnumerableWrapper<T> : IAsyncEnumerable<T>, IObserver<T>, IDisposable { private readonly IDisposable _unsubscriber; private readonly Channel<T> _channel = Channel.CreateUnbounded<T>(); private bool _producerComplete; public ObserverAsyncEnumerableWrapper(IObservable<T> provider) { _unsubscriber = provider.Subscribe(this); } public async void OnNext(T value) { Log.Logger.Verbose("Adding value to Channel."); await _channel.Writer.WriteAsync(value); } public void OnError(Exception error) { _channel.Writer.Complete(error); } public void OnCompleted() { _producerComplete = true; } public async IAsyncEnumerator<T> GetAsyncEnumerator( [EnumeratorCancellation] CancellationToken token = new CancellationToken()) { Log.Logger.Verbose("Starting async iteration..."); while (await _channel.Reader.WaitToReadAsync(token) || !_producerComplete) { Log.Logger.Verbose("Reading..."); while (_channel.Reader.TryRead(out var item)) { Log.Logger.Verbose("Yielding item."); yield return item; } Log.Logger.Verbose("Awaiting more items."); } Log.Logger.Verbose("Iteration Complete."); _channel.Writer.Complete(); } public void Dispose() { _channel.Writer.Complete(); _unsubscriber?.Dispose(); } } Additional Context It shouldn't matter, but at runtime the IObservable<T> instance passed into the constructor is a CimAsyncResult returned from async calls made to the Microsoft.Management.Infrastructure apis. Those make use of the Observer design pattern which I'm trying to wrap with the fancy new async enumeration pattern. Edit Updated with logging to the debugger output and made my OnNext() method async/await as one commenter suggested. You can see it never enters the while() loop.
Further up the call stack I was calling the async method syncronously via the GetAwaiter().GetResult() methods. Yup, that's a problem. I did this because in once case I wanted to get the data from within a constructor. I changed that implementation to execute the call using Task.Run() and now the iterators run flawlessly with both implementations. There are better solutions than blocking on asynchronous code. Using Task.Run is one way to avoid the deadlock, but you still end up with a sub-par user experience (I'm assuming yours is a UI application, since there is a SynchronizationContext). If the asynchronous enumerator is used to load data for display, then a more proper solution is to (synchronously) initialize the UI to a "Loading..." state, and then update that state as the data is loaded asynchronously. If the asynchronous enumerator is used for something else, you may find some appropriate alternative patterns in my async constructors blog post.
Converting synchrous to asynchrous method in C#
I have gone through several post for converting existing synchronous method to asynchronous. So based on what I have read I am converting the synchronous method to asynchronous like below Synchronous public class SomeClass { public int DoWork() { return DoLongRunningWork(); } public int DoLongRunningWork() { Thread.Sleep(1000); return 1; } } I converted this to Asynchronous version like below public class SomeClass { public async Task<int> DoWorkAsync() { Console.WriteLine(Thread.CurrentThread.ManagedThreadId); return await DoLongRunningWorkAsync(); } public Task<int> DoLongRunningWorkAsync() { Thread.Sleep(1000); Console.WriteLine(Thread.CurrentThread.ManagedThreadId); return Task.Run(() => 1); } } I am calling this from Main() Method static void Main() { Someclass worker = new SomeClass(); Console.WriteLine(Thread.CurrentThread.ManagedThreadId); var result = worker.DoWorkAsync().GetAwaiter().GetResult(); Console.WriteLine(Thread.CurrentThread.ManagedThreadId); Console.WriteLine(result); Console.ReadKey(); } Is this a correct way to convert synchronous to asynchronous method? I was expecting Main method's ManagedThreadId will be different than DoWorkAsync and DoLongRunningWorkAsync method's ManagedThreadId. But they are same, why? I used Thread.Sleep() just to simulate the long running method. As per the suggestions below i should have used Task.Delay() to avoid any confusion. I dont think i have to put my actual business logic here to understand the concept of async. As per Stephen Cleary 1> Identify the naturally-asynchronous operations your code is doing. 2>Change the lowest-level API calls to invoke asynchronous APIs (with await) instead of synchronous APIs. However none of the .Net Libarary methods im using inside LongRunningMethod are naturally-asynchronous or awaitable and also LongRunningMethod is not doing any I/O operation. Requirement I have Web API which takes JSON string as input. The JSON needs to be transformed into some C# object. For transformation I am building a C# library which takes JSON string as input and then Transform that JSON string into C# objects based on some rules. The library may take time ( few milliseconds) for Transformation, during this I DO NOT want Web API's main thread to block. The main thread should be free to take any other request while the transformation is going on background thread (some other thread). public class MyWebApi: ApiController { private ILib _myLibrary public MyWebApi(ILib myLibrary) { _myLibrary = myLibrary } publi async Task<SomeObject> Transform(string jsonString) { // i want to make LongRunningMethod() method awaitable // or at least it needs to execute on different thread so that // main thread will be free. var result = await _myLibrary.LongRunningMethod(jsonString); return result; } } publi class MyLibrary:ILib { // A method that does Transformation public async Task<SomeObject> LongRunningMethod(string jsonString) { var result = new SomeObject(); // parse jsonString here // and based on some complex rules create SomeObject // this operation may takes time (lets say few milliseconds) // i may call some other private methods here or public methods from other library return result } }
based on what I have read I am converting the synchronous method to asynchronous like below The best way to convert synchronous methods to asynchronous (as I describe in my async brownfield article) is the following: Identify the naturally-asynchronous operations your code is doing. This is anything that is not running CPU code, e.g., I/O. Change the lowest-level API calls to invoke asynchronous APIs (with await) instead of synchronous APIs. Note the compiler warning and change your calling method to be async with a proper (Task/Task<T>) return type. Also add an Async suffix. Change calling methods to use await, and repeat step (3). When you run into problems with step (3), check out my articles on async OOP, async MVVM (if applicable), and async brownfield. Applying these to your code: Identify the naturally-asynchronous operations your code is doing. This is anything that is not running CPU code, e.g., I/O. Your lowest-level method has a call to Thread.Sleep, which is not running code. The asynchronous equivalent is Task.Delay. Change the lowest-level API calls to invoke asynchronous APIs (with await) instead of synchronous APIs. public int DoLongRunningWork() { await Task.Delay(1000); Console.WriteLine(Thread.CurrentThread.ManagedThreadId); return 1; } Note the compiler warning and change your calling method to be async with a proper (Task/Task<T>) return type. Also add an Async suffix. public async Task<int> DoLongRunningWorkAsync() { await Task.Delay(1000); Console.WriteLine(Thread.CurrentThread.ManagedThreadId); return 1; } Change calling methods to use await, and repeat step (3). public int DoWork() { return await DoLongRunningWorkAsync(); } Note the compiler warning and change your calling method to be async with a proper (Task/Task<T>) return type. Also add an Async suffix. public async Task<int> DoWorkAsync() { return await DoLongRunningWorkAsync(); } Change calling methods to use await, and repeat step (3). In this case, since Main cannot be async, you'll need to block with GetAwaiter().GetResult(), just like you currently have. Final result: public async Task<int> DoWorkAsync() { return await DoLongRunningWorkAsync(); } public async Task<int> DoLongRunningWorkAsync() { await Task.Delay(1000); Console.WriteLine(Thread.CurrentThread.ManagedThreadId); return 1; } I was expecting Main method's ManagedThreadId will be different than DoWorkAsync and DoLongRunningWorkAsync method's ManagedThreadId. But they are same, why? "Asynchronous" does NOT mean "runs on a different thread." See my async intro for more details about how async/await works.
Call async task method from another class using wpf/C# [duplicate]
I have a public async void Foo() method that I want to call from 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 sync 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: A synchronous method calls an async method, obtaining a Task. The synchronous method does a blocking wait on the Task. The async method uses await without ConfigureAwait. The 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, 2019-05-01: The current "least-worst practices" are in an MSDN article here.
Adding a solution that finally solved my problem, hopefully saves somebody's time. Firstly read a couple articles of Stephen Cleary: Async and Await Don't Block on Async Code 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; } }
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 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.
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: https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dotnet-how-to-use-topics-subscriptions
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.
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.
var result = Task.Run(async () => await configManager.GetConfigurationAsync()).ConfigureAwait(false); OpenIdConnectConfiguration config = result.GetAwaiter().GetResult(); Or use this: var result=result.GetAwaiter().GetResult().AccessToken
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.
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()); Note that the signature in the original question public async void Foo() is incorrect. It should be public async Task Foo() as you should return Task not void for async methods that don't return a value (yes, there are some rare exceptions).
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.
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; }
After hours of trying different methods, with more or less success, this is what I ended with. It doesn't end in a deadlock while getting result and it also gets and throws the original exception and not the wrapped one. private ReturnType RunSync() { var task = Task.Run(async () => await myMethodAsync(agency)); if (task.IsFaulted && task.Exception != null) { throw task.Exception; } return task.Result; }
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 void FooAsync() Which will generate Foo method which you can call synchronously.
Those windows async methods have a nifty little method called AsTask(). You can use this to have the method return itself as a task so that you can manually call Wait() on it. For example, on a Windows Phone 8 Silverlight application, you can do the following: private void DeleteSynchronous(string path) { StorageFolder localFolder = Windows.Storage.ApplicationData.Current.LocalFolder; Task t = localFolder.DeleteAsync(StorageDeleteOption.PermanentDelete).AsTask(); t.Wait(); } private void FunctionThatNeedsToBeSynchronous() { // Do some work here // .... // Delete something in storage synchronously DeleteSynchronous("pathGoesHere"); // Do other work here // ..... } Hope this helps!
If you want to run it Sync MethodAsync().RunSynchronously()
How to create a Task which always yields?
In contrast to Task.Wait() or Task.Result, await’ing a Task in C# 5 prevents the thread which executes the wait from lying fallow. Instead, the method using the await keyword needs to be async so that the call of await just makes the method to return a new task which represents the execution of the async method. But when the await’ed Task completes before the async method has received CPU time again, the await recognizes the Task as finished and thus the async method will return the Task object only at a later time. In some cases this would be later than acceptable because it probably is a common mistake that a developer assumes the await’ing always defers the subsequent statements in his async method. The mistaken async method’s structure could look like the following: async Task doSthAsync() { var a = await getSthAsync(); // perform a long operation } Then sometimes doSthAsync() will return the Task only after a long time. I know it should rather be written like this: async Task doSthAsync() { var a = await getSthAsync(); await Task.Run(() => { // perform a long operation }; } ... or that: async Task doSthAsync() { var a = await getSthAsync(); await Task.Yield(); // perform a long operation } But I do not find the last two patterns pretty and want to prevent the mistake to occur. I am developing a framework which provides getSthAsync and the first structure shall be common. So getSthAsync should return an Awaitable which always yields like the YieldAwaitable returned by Task.Yield() does. Unfortunately most features provided by the Task Parallel Library like Task.WhenAll(IEnumerable<Task> tasks) only operate on Tasks so the result of getSthAsync should be a Task. So is it possible to return a Task which always yields?
First of all, the consumer of an async method shouldn't assume it will "yield" as that's nothing to do with it being async. If the consumer needs to make sure there's an offload to another thread they should use Task.Run to enforce that. Second of all, I don't see how using Task.Run, or Task.Yield is problematic as it's used inside an async method which returns a Task and not a YieldAwaitable. If you want to create a Task that behaves like YieldAwaitable you can just use Task.Yield inside an async method: async Task Yield() { await Task.Yield(); } Edit: As was mentioned in the comments, this has a race condition where it may not always yield. This race condition is inherent with how Task and TaskAwaiter are implemented. To avoid that you can create your own Task and TaskAwaiter: public class YieldTask : Task { public YieldTask() : base(() => {}) { Start(TaskScheduler.Default); } public new TaskAwaiterWrapper GetAwaiter() => new TaskAwaiterWrapper(base.GetAwaiter()); } public struct TaskAwaiterWrapper : INotifyCompletion { private TaskAwaiter _taskAwaiter; public TaskAwaiterWrapper(TaskAwaiter taskAwaiter) { _taskAwaiter = taskAwaiter; } public bool IsCompleted => false; public void OnCompleted(Action continuation) => _taskAwaiter.OnCompleted(continuation); public void GetResult() => _taskAwaiter.GetResult(); } This will create a task that always yields because IsCompleted always returns false. It can be used like this: public static readonly YieldTask YieldTask = new YieldTask(); private static async Task MainAsync() { await YieldTask; // something } Note: I highly discourage anyone from actually doing this kind of thing.
Here is a polished version of i3arnon's YieldTask: public class YieldTask : Task { public YieldTask() : base(() => { }, TaskCreationOptions.RunContinuationsAsynchronously) => RunSynchronously(); public new YieldAwaitable.YieldAwaiter GetAwaiter() => default; public new YieldAwaitable ConfigureAwait(bool continueOnCapturedContext) { if (!continueOnCapturedContext) throw new NotSupportedException(); return default; } } The YieldTask is immediately completed upon creation, but its awaiter says otherwise. The GetAwaiter().IsCompleted always returns false. This mischief makes the await operator to trigger the desirable asynchronous switch, every time it awaits this task. Actually creating multiple YieldTask instances is redundant. A singleton would work just as well. There is a problem with this approach though. The underlying methods of the Task class are not virtual, and hiding them with the new modifier means that polymorphism doesn't work. If you store a YieldTask instance to a Task variable, you'll get the default task behavior. This is a considerable drawback for my use case, but I can't see any solution around it.