Як викликати асинхронний метод із синхронного методу в C #?

У мене є public async void Foo()метод, який я хочу викликати з синхронного методу. Поки що все, що я бачив з документації MSDN, - це виклик методів асинхронізації через методи асинхронізації, але вся моя програма не побудована за допомогою методів асинхронізації.

Це навіть можливо?

Ось один приклад виклику цих методів з асинхронного методу: http://msdn.microsoft.com/en-us/library/hh300224(v=vs.110).aspx

Тепер я розглядаю як викликати ці методи асинхронізації із методів синхронізації.

Асинхронне програмування "росте" через базу коду. Його порівнювали з вірусом зомбі . Найкраще рішення - дозволити йому рости, але іноді це неможливо.

Я написав кілька типів у своїй бібліотеці Nito.AsyncEx для роботи з частково-асинхронною базою коду. Однак рішення не працює в будь-якій ситуації.

Рішення А

Якщо у вас є простий асинхронний метод, який не потребує синхронізації назад до його контексту, ви можете використовувати Task.WaitAndUnwrapException:

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

Ви не хочете використовувати Task.Waitабо Task.Resultтому, що вони містять винятки AggregateException.

Це рішення є доцільним лише у тому випадку, якщо MyAsyncMethodвоно не синхронізується з його контекстом. Інакше кажучи, кожен ін awaitв MyAsyncMethodповинен закінчуватися ConfigureAwait(false). Це означає, що він не може оновити будь-які елементи інтерфейсу або отримати доступ до контексту запиту ASP.NET.

Рішення В

Якщо вам MyAsyncMethodпотрібно синхронізуватись назад до її контексту, ви, можливо, зможете скористатися AsyncContext.RunTaskдля надання вкладеного контексту:

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

* Оновлення 14.04.2014: В останніх версіях бібліотеки API такий:

var result = AsyncContext.Run(MyAsyncMethod);

(В Task.Resultцьому прикладі нормально використовувати, оскільки RunTaskпоширюватиме Taskвинятки).

Причина, яка вам може знадобитися AsyncContext.RunTaskзамість цього, Task.WaitAndUnwrapExceptionполягає в досить тонкій можливості тупикової ситуації, що відбувається в WinForms / WPF / SL / ASP.NET:

1. Синхронний метод викликає метод асинхронізації, отримуючи a Task.
2. Синхронний метод робить блокування очікування на Task.
3. asyncМетод використовує awaitбез ConfigureAwait.
4. TaskНе може завершити в цій ситуації , тому що завершується тільки тоді , коли asyncметод закінчений; asyncметод не може завершити , тому що він намагається планувати своє продовження до SynchronizationContextі WinForms / WPF / SL / ASP.NET не дозволить запустити продовження , так як синхронний метод вже працює в цьому контексті.

Це одна з причин, чому корисно використовувати ConfigureAwait(false)в межах кожного asyncметоду якомога більше.

Розчин С

AsyncContext.RunTaskпрацюватиме не в кожному сценарії. Наприклад, якщо asyncметод очікує чогось, що вимагає завершення події інтерфейсу користувача, ви перейдете в тупик навіть із вкладеним контекстом. У цьому випадку ви можете запустити asyncметод у пулі потоків:

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

Однак для цього рішення потрібно MyAsyncMethodте, що буде працювати в контексті пулу потоків. Таким чином, він не може оновити елементи інтерфейсу або отримати доступ до контексту запиту ASP.NET. І в цьому випадку ви можете також додати ConfigureAwait(false)до своїх awaitзаяв і використовувати рішення А.

Оновлення, 2019-05-01: Поточні "найменш-найгірші практики" наведені тут у статті MSDN .

Додавання рішення, яке остаточно вирішило мою проблему, сподіваємось, економить чийсь час.

Спочатку прочитайте пару статей Стівена Клірі :

• Асинхронізація і чекай
• Не блокуйте Асинхронний код

З "двох найкращих практик" у "Не блокуй асинхронний код", перший не працював для мене, а другий не застосовувався (в основному, якщо я можу використовувати await, я це роблю!).

Тож ось мій спосіб вирішення: заверніть виклик всередині Task.Run<>(async () => await FunctionAsync());та, сподіваємось, більше немає тупику .

Ось мій код:

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 побудувала клас (AsyncHelper) (внутрішній) для запуску Async як Sync. Джерело виглядає так:

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

Базові класи Microsoft.AspNet.Identity мають лише методи Async. Для того, щоб викликати їх як Sync, існують класи з методами розширення (наприклад, використання):

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

Для тих, хто стурбований ліцензійними умовами коду, ось посилання на дуже схожий код (просто додає підтримку культури в потоці), у якому є коментарі, які свідчать про те, що це ліцензований MIT Microsoft. https://github.com/aspnet/AspNetIdentity/blob/master/src/Microsoft.AspNet.Identity.Core/AsyncHelper.cs

async Main тепер є частиною C # 7.2 і може бути включений у розширених настройках збірки проектів.

Для C # <7.2 правильний спосіб:

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


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

Ви побачите це в багатьох документах Microsoft, наприклад: https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dotnet-how-to-use- теми-підписки

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

}

Ви читаєте ключове слово "очікувати" як "запустити цю тривалу задачу, потім поверніть контроль до виклику методу". Після того, як виконано тривале завдання, він виконує код після нього. Код після режиму очікування схожий з методами CallBack. Велика різниця в тому, що логічний потік не переривається, що робить його набагато простіше писати та читати.

Я не впевнений на 100%, але я вважаю, що техніка, описана в цьому блозі, повинна працювати в багатьох обставинах:

Таким чином, ви можете використовувати, task.GetAwaiter().GetResult()якщо ви хочете безпосередньо посилатися на цю логіку поширення.

Однак є хороше рішення, яке працює у (майже: див. Коментарі) кожній ситуації: спеціальний насос повідомлення (SynchronizationContext).

Потоковий виклик буде заблокований, як і очікувалося, при цьому все одно гарантуючи, що всі продовження, викликані функцією асинхронізації, не затримуються, оскільки вони будуть переведені на спеціальний синхронізаційний контент (насос повідомлень), що працює на потоці виклику.

Код спеціальної допомоги помічника насоса:

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

Використання:

AsyncPump.Run(() => FooAsync(...));

Більш детальний опис насоса для асинхронізації доступний тут .

Щоб хто більше не звертав увагу на це питання ...

Якщо ви заглянете в Microsoft.VisualStudio.Services.WebApiклас, який називається TaskExtensions. У межах цього класу ви побачите метод статичного розширення Task.SyncResult(), який як би повністю блокує потік, поки завдання не повернеться.

Внутрішній виклик task.GetAwaiter().GetResult()це досить просто, однак він перевантажений роботою над будь-яким asyncметодом, який повертається Task, Task<T>абоTask<HttpResponseMessage> ... синтаксичним цукром, дитино ... тато має солодкий зуб.

Схоже, ...GetAwaiter().GetResult()це офіційний спосіб для MS виконувати асинхронний код у блокувальному контексті. Здається, він працює дуже добре для мого використання.

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

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

Або скористайтеся цим:

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

Ви можете викликати будь-який асинхронний метод із синхронного коду, тобто до тих пір, поки вам не потрібно await, і в такому випадку вони також мають бути позначені async.

Оскільки багато людей пропонують тут, ви можете зателефонувати Wait () або Result за отриманим завданням у вашому синхронному методі, але потім в кінцевому підсумку виклик блокування у тому методі, який перемагає мету асинхронізації.

Якщо ви дійсно не можете зробити свій метод, asyncі ви не хочете заблокувати синхронний метод, тоді вам доведеться використовувати метод зворотного виклику, передаючи його як параметр методу ContinueWith із завданням.

Я знаю, що я запізнився. Але на випадок, коли хтось, як я, захотів вирішити це акуратним, простим способом і не залежно від іншої бібліотеки.

Я знайшов наступний фрагмент коду від Райана

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

то ви можете назвати це так

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

Після декількох годин, пробуючи різні методи, з більшим чи меншим успіхом, це те, що я закінчив. Це не закінчується в глухому куті, отримуючи результат, а також отримує і викидає оригінальне виняток, а не загорнуте.

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

  return task.Result;
}

Його можна викликати з нового потоку (НЕ з пулу ниток!):

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

Ці методи асинхронізації Windows мають чудовий метод, який називається AsTask (). Ви можете використовувати це, щоб метод повертався як завдання, щоб ви могли вручну викликати Wait () на ньому.

Наприклад, додаток для Windows Phone 8 Silverlight, ви можете зробити наступне:

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

Сподіваюся, це допомагає!

Якщо ви хочете запустити його 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;