Comment appeler une méthode asynchrone à partir d'une méthode synchrone en C #?

J'ai une public async void Foo()méthode que je veux appeler à partir d'une méthode synchrone. Jusqu'à présent, tout ce que j'ai vu de la documentation MSDN appelle des méthodes asynchrones via des méthodes asynchrones, mais tout mon programme n'est pas construit avec des méthodes asynchrones.

Est-ce seulement possible?

Voici un exemple d'appel de ces méthodes à partir d'une méthode asynchrone: http://msdn.microsoft.com/en-us/library/hh300224(v=vs.110).aspx

Maintenant, je cherche à appeler ces méthodes asynchrones à partir de méthodes de synchronisation.

La programmation asynchrone "grandit" à travers la base de code. Il a été comparé à un virus zombie . La meilleure solution est de lui permettre de se développer, mais parfois ce n'est pas possible.

J'ai écrit quelques types dans ma bibliothèque Nito.AsyncEx pour gérer une base de code partiellement asynchrone. Il n'y a cependant pas de solution qui fonctionne dans toutes les situations.

Solution A

Si vous avez une méthode asynchrone simple qui n'a pas besoin de se synchroniser avec son contexte, vous pouvez utiliser Task.WaitAndUnwrapException:

var task = MyAsyncMethod();
var result = task.WaitAndUnwrapException();

Vous ne pas à utiliser Task.Waitou Task.Resultparce qu'ils enveloppent exceptions AggregateException.

Cette solution n'est appropriée que si elle MyAsyncMethodne se synchronise pas avec son contexte. En d'autres termes, chaque awaitentrée MyAsyncMethoddoit se terminer par ConfigureAwait(false). Cela signifie qu'il ne peut pas mettre à jour les éléments de l'interface utilisateur ni accéder au contexte de demande ASP.NET.

Solution B

Si vous MyAsyncMethoddevez vous synchroniser avec son contexte, vous pouvez utiliser AsyncContext.RunTaskpour fournir un contexte imbriqué:

var result = AsyncContext.RunTask(MyAsyncMethod).Result;

* Mise à jour du 14/04/2014: dans les versions plus récentes de la bibliothèque, l'API est la suivante:

var result = AsyncContext.Run(MyAsyncMethod);

(Il est correct d'utiliser Task.Resultdans cet exemple car RunTaskpropage des Taskexceptions).

La raison pour laquelle vous pourriez avoir besoin à la AsyncContext.RunTaskplace Task.WaitAndUnwrapExceptionest à cause d'une possibilité de blocage plutôt subtile qui se produit sur WinForms / WPF / SL / ASP.NET:

1. Une méthode synchrone appelle une méthode asynchrone, obtenant un Task.
2. La méthode synchrone fait une attente de blocage sur le Task.
3. La asyncméthode utilise awaitsans ConfigureAwait.
4. Le Taskne peut pas terminer dans cette situation car il se termine uniquement lorsque la asyncméthode est terminée; la asyncméthode ne peut pas se terminer car elle tente de planifier sa continuation vers le SynchronizationContext, et WinForms / WPF / SL / ASP.NET n'autorisera pas la poursuite à s'exécuter car la méthode synchrone s'exécute déjà dans ce contexte.

C'est une des raisons pour lesquelles c'est une bonne idée d'utiliser autant que possible ConfigureAwait(false)dans chaque asyncméthode.

Solution C

AsyncContext.RunTaskne fonctionnera pas dans tous les scénarios. Par exemple, si la asyncméthode attend quelque chose qui nécessite un événement d'interface utilisateur, vous bloquerez même avec le contexte imbriqué. Dans ce cas, vous pouvez démarrer la asyncméthode sur le pool de threads:

var task = Task.Run(async () => await MyAsyncMethod());
var result = task.WaitAndUnwrapException();

Cependant, cette solution nécessite un MyAsyncMethodqui fonctionnera dans le contexte du pool de threads. Il ne peut donc pas mettre à jour les éléments de l'interface utilisateur ni accéder au contexte de demande ASP.NET. Et dans ce cas, vous pouvez tout aussi bien compléter ConfigureAwait(false)ses awaitdéclarations et utiliser la solution A.

Mise à jour, 2019-05-01: Les "pratiques les moins pires" actuelles sont dans un article MSDN ici .

L'ajout d'une solution qui a finalement résolu mon problème permet, je l'espère, de gagner du temps à quelqu'un.

Lisez d'abord quelques articles de Stephen Cleary :

• Async and Await
• Ne bloquez pas le code asynchrone

Parmi les "deux meilleures pratiques" dans "Ne pas bloquer sur le code asynchrone", la première ne fonctionnait pas pour moi et la seconde n'était pas applicable (essentiellement si je peux utiliser await, je le fais!).

Voici donc ma solution de contournement: envelopper l'appel dans un Task.Run<>(async () => await FunctionAsync());et, espérons-le, plus aucune impasse .

Voici mon 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 a créé une classe AsyncHelper (interne) pour exécuter Async en tant que Sync. La source ressemble à:

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();
    }
}

Les classes de base Microsoft.AspNet.Identity n'ont que des méthodes Async et pour les appeler Sync, il existe des classes avec des méthodes d'extension qui ressemblent à (exemple d'utilisation):

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));
}

Pour ceux qui sont préoccupés par les termes du code de licence, voici un lien vers un code très similaire (ajoute simplement la prise en charge de la culture sur le fil) qui a des commentaires pour indiquer qu'il est sous licence MIT par Microsoft. https://github.com/aspnet/AspNetIdentity/blob/master/src/Microsoft.AspNet.Identity.Core/AsyncHelper.cs

async Main fait maintenant partie de C # 7.2 et peut être activé dans les paramètres de construction avancés du projet.

Pour C # <7.2, la bonne façon est:

static void Main(string[] args)
{
   MainAsync().GetAwaiter().GetResult();
}


static async Task MainAsync()
{
   /*await stuff here*/
}

Vous verrez cela utilisé dans de nombreuses documentations Microsoft, par exemple: https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dotnet-how-to-use- sujets-abonnements

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

}

Vous lisez le mot-clé «attendre» comme «démarrer cette tâche longue, puis retourner le contrôle à la méthode appelante». Une fois la tâche de longue durée terminée, il exécute ensuite le code. Le code après l'attente est similaire à ce qui était auparavant des méthodes CallBack. La grande différence étant que le flux logique n'est pas interrompu, ce qui facilite grandement l'écriture et la lecture.

Je ne suis pas sûr à 100%, mais je pense que la technique décrite dans ce blog devrait fonctionner dans de nombreuses circonstances:

Vous pouvez donc l'utiliser task.GetAwaiter().GetResult()si vous souhaitez invoquer directement cette logique de propagation.

Il existe cependant une bonne solution qui fonctionne dans (presque: voir commentaires) toutes les situations: une pompe à messages ad-hoc (SynchronizationContext).

Le thread appelant sera bloqué comme prévu, tout en garantissant que toutes les continuations appelées à partir de la fonction asynchrone ne se bloquent pas car elles seront marshalées vers le SynchronizationContext ad hoc (pompe de messages) exécuté sur le thread appelant.

Le code de l'assistant de pompe de message ad hoc:

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(...));

Une description plus détaillée de la pompe asynchrone est disponible ici .

À quiconque prête attention à cette question ...

Si vous regardez, Microsoft.VisualStudio.Services.WebApiil y a une classe appelée TaskExtensions. Dans cette classe, vous verrez la méthode d'extension statique Task.SyncResult(), qui comme bloque totalement le thread jusqu'au retour de la tâche.

En interne, il appelle task.GetAwaiter().GetResult()ce qui est assez simple, mais il est surchargé pour fonctionner sur n'importe quelle asyncméthode qui retourne Task, Task<T>ou Task<HttpResponseMessage>... du sucre syntaxique, bébé ... papa a le goût sucré.

Il semble que ...GetAwaiter().GetResult()c'est la manière officielle de MS d'exécuter du code asynchrone dans un contexte de blocage. Semble fonctionner très bien pour mon cas d'utilisation.

var result = Task.Run(async () => await configManager.GetConfigurationAsync()).ConfigureAwait(false);

OpenIdConnectConfiguration config = result.GetAwaiter().GetResult();

Ou utilisez ceci:

var result=result.GetAwaiter().GetResult().AccessToken

Vous pouvez appeler n'importe quelle méthode asynchrone à partir du code synchrone, c'est-à-dire jusqu'à ce que vous en ayez besoin await, auquel cas elles doivent également être marquées async.

Comme beaucoup de gens le suggèrent ici, vous pouvez appeler Wait () ou Result sur la tâche résultante dans votre méthode synchrone, mais vous vous retrouvez avec un appel de blocage dans cette méthode, ce qui va à l'encontre du but de l'async.

Si vous ne pouvez vraiment pas créer votre méthode asyncet que vous ne voulez pas verrouiller la méthode synchrone, vous devrez utiliser une méthode de rappel en la passant en paramètre à la méthode ContinueWith sur la tâche.

Je sais que je suis tellement en retard. Mais au cas où quelqu'un comme moi voudrait résoudre ce problème d'une manière ordonnée, facile et sans dépendre d'une autre bibliothèque.

J'ai trouvé le morceau de code suivant de Ryan

public static class AsyncHelpers
{
    private static readonly TaskFactory taskFactory = new
        TaskFactory(CancellationToken.None,
            TaskCreationOptions.None,
            TaskContinuationOptions.None,
            TaskScheduler.Default);

    /// <summary>
    /// Executes an async Task method which has a void return value synchronously
    /// USAGE: AsyncUtil.RunSync(() => AsyncMethod());
    /// </summary>
    /// <param name="task">Task method to execute</param>
    public static void RunSync(Func<Task> task)
        => taskFactory
            .StartNew(task)
            .Unwrap()
            .GetAwaiter()
            .GetResult();

    /// <summary>
    /// Executes an async Task<T> method which has a T return type synchronously
    /// USAGE: T result = AsyncUtil.RunSync(() => AsyncMethod<T>());
    /// </summary>
    /// <typeparam name="TResult">Return Type</typeparam>
    /// <param name="task">Task<T> method to execute</param>
    /// <returns></returns>
    public static TResult RunSync<TResult>(Func<Task<TResult>> task)
        => taskFactory
            .StartNew(task)
            .Unwrap()
            .GetAwaiter()
            .GetResult();
}

alors vous pouvez l'appeler comme ça

var t = AsyncUtil.RunSync<T>(() => AsyncMethod<T>());

Après des heures à essayer différentes méthodes, avec plus ou moins de succès, c'est ce que j'ai fini avec. Il ne se termine pas dans une impasse tout en obtenant le résultat et il obtient et lève également l'exception d'origine et non celle encapsulée.

private ReturnType RunSync()
{
  var task = Task.Run(async () => await myMethodAsync(agency));
  if (task.IsFaulted && task.Exception != null)
  {
    throw task.Exception;
  }

  return task.Result;
}

Il pourrait être appelé depuis un nouveau thread (PAS depuis le pool de threads!):

public static class SomeHelperClass
{ 
       public static T Result<T>(Func<T> func)
        {
            return Task.Factory.StartNew<T>(
                  () => func()
                , TaskCreationOptions.LongRunning
                ).Result;
        }
}
...
content = SomeHelperClass.Result<string>(
  () => response.Content.ReadAsStringAsync().Result
  );

Ces méthodes asynchrones Windows ont une astucieuse petite méthode appelée AsTask (). Vous pouvez l'utiliser pour que la méthode se retourne en tant que tâche afin que vous puissiez appeler manuellement Wait () dessus.

Par exemple, sur une application Silverlight Windows Phone 8, vous pouvez effectuer les opérations suivantes:

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 
    // .....
}

J'espère que cela t'aides!

Si vous voulez l'exécuter Sync

MethodAsync().RunSynchronously()

   //Example from non UI thread -    
   private void SaveAssetAsDraft()
    {
        SaveAssetDataAsDraft();
    }
    private async Task<bool> SaveAssetDataAsDraft()
    {
       var id = await _assetServiceManager.SavePendingAssetAsDraft();
       return true;   
    }
   //UI Thread - 
   var result = Task.Run(() => SaveAssetDataAsDraft().Result).Result;