Как мне запустить синхронный асинхронный метод Task <T>?

Имейте в виду, что этому ответу три года. Я написал это, основываясь в основном на опыте с .Net 4.0, и очень мало на 4.5, особенно с async-await. Вообще говоря, это хорошее простое решение, но оно иногда ломает вещи. Пожалуйста, прочитайте обсуждение в комментариях.

.Net 4.5

Просто используйте это:

// For Task<T>: will block until the task is completed...
var result = task.Result; 

// For Task (not Task<T>): will block until the task is completed...
task2.RunSynchronously();

Смотрите: TaskAwaiter, Task.Result, Task.RunSynchronously

.Net 4.0

Использовать этот:

var x = (IAsyncResult)task;
task.Start();

x.AsyncWaitHandle.WaitOne();

...или это:

task.Start();
task.Wait();

Удивлен, никто не упомянул это:

public Task<int> BlahAsync()
{
    // ...
}

int result = BlahAsync().GetAwaiter().GetResult();

Не так красиво, как некоторые другие методы, но имеет следующие преимущества:

• он не глотает исключения (например, Wait)
• он не будет переносить исключения, сгенерированные в AggregateException (например, Result)
• работает как для Task и для Task<T> (il/K4Zwlgdg5gBAygTxAFwKYFsDcAoUlaIoYB0AKgBYBOqAhgCb5k0gDWIO2ADsAEYA2YAMYxBfZiBgAFSgHsolGumwBvbDHUxu/ITGYIIw0sxYwAcjIgBxVBFSUhACgCUajao0wAvq/U/NvAWE9AxgjVgAeSGQAPhhrW3tBZz93Dw1qZGBKCBgABhwPbw8/LUCYADcZMDoYADEZGWSPVLSzC3i7Rydia2QAQQB3GjA0Smce1GQAJVQQYD5kZwLWmCiYAC87GRgAXjibTqTu3sHh0fHembmFpb9vTyAAA==#f:>il/K4Zwlgdg5gBAygTxAFwKYFsDcAoUlaIoYB0AKgBYBOqAhgCb5k0gDWIO2ADsAEYA2YAMYxBfZiBgAFSgHsolGumwBvbDHUxu/ITGYIIw0sxYwAcjIgBxVBFSUhACgCUajao0wAvq/U/NvAWE9AxgjVgAeSGQAPhhrW3tBZz93Dw1qZGBKCBgABhwPbw8/LUCYADcZMDoYADEZGWSPVLSzC3i7Rydia2QAQQB3GjA0Smce1GQAJVQQYD5kZwLWmCiYAC87GRgAXjibTqTu3sHh0fHembmFpb9vTyAAA== rel=noreferrer>попробуйте сами!)

Кроме того, так как GetAwaiter типизирован по GetAwaiter утки, это должно работать для любого объекта, возвращаемого из асинхронного метода (например, ConfiguredAwaitable или YieldAwaitable), а не только для задач.

edit: Обратите внимание, что для этого подхода (или с помощью .Result) .Result взаимоблокировка, если только вы не уверены, что добавляете .ConfigureAwait(false) каждый раз, когда ожидаете, для всех асинхронных методов, которые могут быть BlahAsync() из BlahAsync() (не только те, которые он вызывает напрямую). Пояснение

// In BlahAsync() body
await FooAsync(); // BAD!
await FooAsync().ConfigureAwait(false); // Good... but make sure FooAsync() and
                                        // all its descendants use ConfigureAwait(false)
                                        // too. Then you can be sure that
                                        // BlahAsync().GetAwaiter().GetResult()
                                        // won't deadlock.

Если вам лень добавлять .ConfigureAwait(false), и вы не заботитесь о производительности, вы можете сделать это альтернативно.

Task.Run(() => BlahAsync()).GetAwaiter().GetResult()

Гораздо проще запустить задачу в пуле потоков, а не пытаться обмануть планировщика для его синхронного запуска. Таким образом, вы можете быть уверены, что это не затормозит. Из-за контекстного переключателя влияет производительность.

Task<MyResult> DoSomethingAsync() { ... }

// Starts the asynchronous task on a thread-pool thread.
// Returns a proxy to the original task.
Task<MyResult> task = Task.Run(() => DoSomethingAsync());

// Will block until the task is completed...
MyResult result = task.Result; 

Я узнал об async/await и столкнулся с ситуацией, когда мне нужно синхронно вызывать метод async. Как я могу это сделать?

Лучший ответ вы не, детали зависят от того, что такое "ситуация".

Это свойство getter/setter? В большинстве случаев лучше иметь асинхронные методы, чем "асинхронные свойства". (Для получения дополнительной информации см. мой пост в блоге по асинхронным свойствам).

Это приложение MVVM, и вы хотите выполнить привязку асинхронных данных? Затем используйте что-то вроде NotifyTask, как описано в моей статье блога в асинхронных конструкторах).

Там почти всегда есть лучший ответ, чем делать sync-over-async.

Если это не возможно для вашей ситуации (и вы знаете это, задавая здесь вопрос, описывающий ситуацию), я бы рекомендовал просто использовать синхронный код. Асинк всего наилучшего; синхронизация полностью наилучшая. Sync-over-async не рекомендуется.

Тем не менее, существует несколько ситуаций, когда требуется синхронизация по-асинхронному. В частности, вы ограничены вызывающим кодом, так что вам нужно синхронизировать (и не иметь абсолютно никакого способа переосмыслить или переструктурировать свой код, чтобы разрешить асинхронность), и вам нужно вызвать async код. Это редкая ситуация очень, но время от времени она возникает.

В этом случае вам нужно будет использовать один из хаков, описанный в моей статье, в brownfield async development, в частности:

• Блокировка (например, GetAwaiter().GetResult()). Обратите внимание, что это может вызвать взаимоблокировки (как я описываю в своем блоге).
• Запуск кода в потоке пула потоков (например, Task.Run(..).GetAwaiter().GetResult()). Обратите внимание, что это будет работать, только если асинхронный код может быть запущен в потоке пула потоков (т.е. Не зависит от контекста пользовательского интерфейса или ASP.NET).
• Вложенные петли сообщений. Обратите внимание, что это будет работать только в том случае, если асинхронный код предполагает только однопоточный контекст, а не определенный тип контекста (много UI и ASP.NET-кода ожидают определенного контекста).

Вложенные петли сообщений являются наиболее опасными из всех хаков, потому что это вызывает re-entrancy. Re-entrancy чрезвычайно сложно понять, и (IMO) является причиной большинства ошибок приложений в Windows. В частности, если вы находитесь в потоке пользовательского интерфейса и блокируете рабочую очередь (ожидая завершения работы async), тогда CLR на самом деле выполняет некоторую пересылку сообщений для вас - она ​​фактически обрабатывает некоторые сообщения Win32 из вашего код. О, и вы не знаете, какие сообщения - когда Крис Брумме говорит: "Было бы здорово точно знать, что будет накачано? К сожалению, перекачка - это черное искусство, которое находится вне смертного понимания" ., тогда мы действительно не надеемся узнать.

Итак, когда вы блокируете это в потоке пользовательского интерфейса, вы просите о проблемах. Другая цитата из одной статьи: "Время от времени клиенты внутри компании или за ее пределами обнаруживают, что мы перекачиваем сообщения во время управляемой блокировки на STA [поток пользовательского интерфейса]. Это законная проблема, потому что они знают, что ее очень сложно для написания кода, надежного перед лицом повторного входа".

Да, это так. Очень трудно писать код, который устойчив перед лицом реентерации. И вложенные петли сообщений заставляют вас писать код, надежный перед лицом повторной установки. Вот почему принятый (и самый высокий) ответ на этот вопрос на практике чрезвычайно опасен.

Если вы полностью исключены из других опций - вы не можете переконфигурировать свой код, вы не можете реструктурировать его как асинхронный - вы вынуждены сменить код вызова для синхронизации - вы не можете изменить код вниз для синхронизации - вы не можете блокировать - вы не можете запускать асинхронный код в отдельном потоке - тогда и только тогда вы должны рассмотреть возможность включения реентерации.

Если вы окажетесь в этом углу, я бы рекомендовал использовать что-то вроде Dispatcher.PushFrame для приложений WPF, зацикливая с помощью Application.DoEvents для WinForm, и для общего случая, мой собственный AsyncContext.Run.

Это хорошо работает для меня

public static class TaskHelper
{
    public static void RunTaskSynchronously(this Task t)
    {
        var task = Task.Run(async () => await t);
        task.Wait();
    }

    public static T RunTaskSynchronously<T>(this Task<T> t)
    {
        T res = default(T);
        var task = Task.Run(async () => res = await t);
        task.Wait();
        return res;
    }
}

Если я правильно читаю ваш вопрос - код, который хочет синхронный вызов асинхронного метода, выполняется в приостановленном потоке диспетчера. И вы хотите на самом деле синхронно блокировать этот поток, пока не будет завершен асинхронный метод.

Асинхронные методы в С# 5 основаны на эффективном разделении метода на части под капотом и возвращении Task которая может отслеживать полное завершение всего шабанга. Однако то, как выполняются прерванные методы, может зависеть от типа выражения, передаваемого оператору await.

Большую часть времени вы будете использовать await для выражения типа Task. Реализация задачи шаблона await является "умной" в том смысле, что она подчиняется SynchronizationContext, что в основном приводит к следующему:

1. Если поток, входящий в await находится в потоке цикла сообщений Dispatcher или WinForms, он гарантирует, что фрагменты асинхронного метода происходят как часть обработки очереди сообщений.
2. Если поток, входящий в await находится в потоке пула потоков, то остальные фрагменты асинхронного метода происходят в любом месте пула потоков.

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

.... резервное копирование!...

Я должен задать вопрос, почему вы пытаетесь синхронно заблокировать асинхронный метод? Это отрицательно скажется на том, почему метод должен вызываться асинхронно. В общем, когда вы начинаете использовать await в методе Dispatcher или UI, вам нужно включить асинхронность всего потока UI. Например, если ваш стек вызовов был примерно таким:

1. [Top] WebRequest.GetResponse()
2. YourCode.HelperMethod()
3. YourCode.AnotherMethod()
4. YourCode.EventHandlerMethod()
5. [UI Code].Plumbing() - код WPF или WinForms
6. [Цикл сообщений] - Цикл сообщений WPF или WinForms

Затем, как только код был преобразован в асинхронный режим, вы, как правило, получите

1. [Top] WebRequest.GetResponseAsync()
2. YourCode.HelperMethodAsync()
3. YourCode.AnotherMethodAsync()
4. YourCode.EventHandlerMethodAsync()
5. [UI Code].Plumbing() - код WPF или WinForms
6. [Цикл сообщений] - Цикл сообщений WPF или WinForms

На самом деле отвечая

Класс AsyncHelpers, приведенный выше, на самом деле работает, потому что он ведет себя как вложенный цикл обработки сообщений, но он устанавливает свою собственную параллельную механику для Dispatcher, а не пытается выполнить ее на самом Dispatcher. Это обходной путь для вашей проблемы.

Другим обходным решением является выполнение вашего асинхронного метода в потоке потоков и ожидание его завершения. Сделать это легко - вы можете сделать это с помощью следующего фрагмента:

var customerList = TaskEx.RunEx(GetCustomers).Result;

Конечным API будет Task.Run(...), но с CTP вам понадобятся суффиксы Ex (объяснение здесь).

Самый простой способ, который я нашел для запуска задачи синхронно и без блокировки потока пользовательского интерфейса, - использовать RunSynchronously() как:

Task t = new Task(() => 
{ 
   //.... YOUR CODE ....
});
t.RunSynchronously();

В моем случае у меня есть событие, которое срабатывает, когда что-то происходит. Я не знаю, сколько раз это произойдет. Таким образом, я использую код выше в моем случае, поэтому всякий раз, когда он срабатывает, он создает задачу. Задачи выполняются синхронно, и это отлично работает для меня. Я был просто удивлен, что мне потребовалось столько времени, чтобы выяснить, насколько это просто. Обычно рекомендации намного сложнее и подвержены ошибкам. Это было просто и чисто.

Я столкнулся с этим несколько раз, в основном в модульном тестировании или в разработке Windows-сервисов. В настоящее время я всегда использую эту функцию:

        var runSync = Task.Factory.StartNew(new Func<Task>(async () =>
        {
            Trace.WriteLine("Task runSync Start");
            await TaskEx.Delay(2000); // Simulates a method that returns a task and
                                      // inside it is possible that there
                                      // async keywords or anothers tasks
            Trace.WriteLine("Task runSync Completed");
        })).Unwrap();
        Trace.WriteLine("Before runSync Wait");
        runSync.Wait();
        Trace.WriteLine("After runSync Waited");

Это просто, легко, и у меня не было проблем.

Я нашел этот код в компоненте Microsoft.AspNet.Identity.Core, и он работает.

private static readonly TaskFactory _myTaskFactory = new 
     TaskFactory(CancellationToken.None, TaskCreationOptions.None, 
     TaskContinuationOptions.None, TaskScheduler.Default);

// Microsoft.AspNet.Identity.AsyncHelper
public static TResult RunSync<TResult>(Func<Task<TResult>> func)
{
    CultureInfo cultureUi = CultureInfo.CurrentUICulture;
    CultureInfo culture = CultureInfo.CurrentCulture;
    return AsyncHelper._myTaskFactory.StartNew<Task<TResult>>(delegate
    {
        Thread.CurrentThread.CurrentCulture = culture;
        Thread.CurrentThread.CurrentUICulture = cultureUi;
        return func();
    }).Unwrap<TResult>().GetAwaiter().GetResult();
}

Небольшая заметка - этот подход:

Task<Customer> task = GetCustomers();
task.Wait()

работает для WinRT.

Позвольте мне объяснить:

private void TestMethod()
{
    Task<Customer> task = GetCustomers(); // call async method as sync and get task as result
    task.Wait(); // wait executing the method
    var customer = task.Result; // get result.
    Debug.WriteLine(customer.Name); //print customer name
}
public class Customer
{
    public Customer()
    {
        new ManualResetEvent(false).WaitOne(TimeSpan.FromSeconds(5));//wait 5 second (long term operation)
    }
    public string Name { get; set; }
}
private Task<Customer> GetCustomers()
{
    return Task.Run(() => new Customer
    {
        Name = "MyName"
    });
}

Кроме того, этот подход работает только для решений Windows Store!

Примечание.. Этот способ не является потокобезопасным, если вы вызываете свой метод внутри другого метода async (согласно комментариям @Servy)

В вашем коде ваше первое ожидание выполнения задачи, но вы еще не запустили ее, поэтому она ждет бесконечно. Попробуй это:

Task<Customer> task = GetCustomers();
task.RunSynchronously();

Редактировать:

Вы говорите, что получаете исключение. Пожалуйста, опубликуйте более подробную информацию, включая трассировку стека.
Mono содержит следующий контрольный пример:

[Test]
public void ExecuteSynchronouslyTest ()
{
        var val = 0;
        Task t = new Task (() => { Thread.Sleep (100); val = 1; });
        t.RunSynchronously ();

        Assert.AreEqual (1, val);
}

Проверьте, работает ли это для вас. Если это не так, хотя очень маловероятно, у вас может быть какая-то странная сборка Async CTP. Если это работает, вы можете проверить, что именно генерирует компилятор, и чем создание экземпляра Task отличается от этого примера.

Редактировать № 2:

Я проверил с помощью Reflector, что описанное вами исключение возникает, когда m_action имеет значение null. Это немного странно, но я не эксперт по Async CTP. Как я уже сказал, вы должны декомпилировать свой код и посмотреть, как именно создается экземпляр Task, каким образом его m_action имеет значение null.

PS Какое дело со случайными понижениями? Хотите разработать?

Почему бы не создать такой вызов, как:

Service.GetCustomers();

который не является асинхронным.

используйте ниже код snip

Task.WaitAll(Task.Run(async () => await service.myAsyncMethod()));

Просто вызов .Result; или .Wait() - это риск для тупиков, о которых многие говорили в комментариях. Поскольку большинство из нас, как oneliners, вы можете использовать их для .Net 4.5<

Приобретение значения через метод async:

var result = Task.Run(() => asyncGetValue()).Result;

Синхронно вызов метода асинхронного копирования

Task.Run(() => asyncMethod()).Wait();

Никаких проблем с блокировкой не произойдет из-за использования Task.Run.

Источник:

https://stackoverflow.com/questions/17248680/await-works-but-calling-task-result-hangs-deadlocks

Этот ответ предназначен для всех, кто использует WPF для .NET 4.5.

Если вы попытаетесь выполнить Task.Run() в потоке GUI, то task.Wait() будет зависать бесконечно, если у вас нет ключевого слова async в определении вашей функции.

Этот метод расширений решает проблему, проверяя, есть ли мы в потоке графического интерфейса пользователя, и если да, выполняем задачу в потоке диспетчера WPF.

Этот класс может действовать как клей между миром async/await и неасинхронным/ожидающим миром в ситуациях, когда это неизбежно, например, свойства MVVM или зависимости от других API, которые не используют async/await.

/// <summary>
///     Intent: runs an async/await task synchronously. Designed for use with WPF.
///     Normally, under WPF, if task.Wait() is executed on the GUI thread without async
///     in the function signature, it will hang with a threading deadlock, this class 
///     solves that problem.
/// </summary>
public static class TaskHelper
{
    public static void MyRunTaskSynchronously(this Task task)
    {
        if (MyIfWpfDispatcherThread)
        {
            var result = Dispatcher.CurrentDispatcher.InvokeAsync(async () => { await task; });
            result.Wait();
            if (result.Status != DispatcherOperationStatus.Completed)
            {
                throw new Exception("Error E99213. Task did not run to completion.");
            }
        }
        else
        {
            task.Wait();
            if (task.Status != TaskStatus.RanToCompletion)
            {
                throw new Exception("Error E33213. Task did not run to completion.");
            }
        }
    }

    public static T MyRunTaskSynchronously<T>(this Task<T> task)
    {       
        if (MyIfWpfDispatcherThread)
        {
            T res = default(T);
            var result = Dispatcher.CurrentDispatcher.InvokeAsync(async () => { res = await task; });
            result.Wait();
            if (result.Status != DispatcherOperationStatus.Completed)
            {
                throw new Exception("Error E89213. Task did not run to completion.");
            }
            return res;
        }
        else
        {
            T res = default(T);
            var result = Task.Run(async () => res = await task);
            result.Wait();
            if (result.Status != TaskStatus.RanToCompletion)
            {
                throw new Exception("Error E12823. Task did not run to completion.");
            }
            return res;
        }
    }

    /// <summary>
    ///     If the task is running on the WPF dispatcher thread.
    /// </summary>
    public static bool MyIfWpfDispatcherThread
    {
        get
        {
            return Application.Current.Dispatcher.CheckAccess();
        }
    }
}

Протестировано в .Net 4.6. Это также может избежать тупика.

Для метода aysnc верните Task.

Task DoSomeWork()

Task.Run(async () => await DoSomeWork()).Wait();

Для асинхронного метода верните Task<T>

Task<T> GetSomeValue()

var result = Task.Run(() => GetSomeValue()).Result;

Я думаю, что следующий вспомогательный метод также может решить проблему.

private TResult InvokeAsyncFuncSynchronously<TResult>(Func< Task<TResult>> func)
    {
        TResult result = default(TResult);
        var autoResetEvent = new AutoResetEvent(false);

        Task.Run(async () =>
        {
            try
            {
                result = await func();
            }
            catch (Exception exc)
            {
                mErrorLogger.LogError(exc.ToString());
            }
            finally
            {
                autoResetEvent.Set();
            }
        });
        autoResetEvent.WaitOne();

        return result;
    }

Может использоваться следующим образом:

InvokeAsyncFuncSynchronously(Service.GetCustomersAsync);

Вы можете использовать CoRoutines. См. Caliburn.Micro. У меня есть пользовательская реализация здесь.

Я обнаружил, что SpinWait работает довольно хорошо для этого.

var task = Task.Run(()=>DoSomethingAsyncronous());

if(!SpinWait.SpinUntil(()=>task.IsComplete, TimeSpan.FromSeconds(30)))
{//Task didn't complete within 30 seconds, fail...
   return false;
}

return true;

Вышеупомянутый подход не должен использовать .Result или .Wait(). Это также позволяет вам указать тайм-аут, чтобы вы не застряли навсегда в случае, если задача никогда не завершится.

Это работает для меня

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net.Http;
using System.Text;
using System.Threading;
using System.Threading.Tasks;

namespace ConsoleApp2
{
    public static class AsyncHelper
    {
        private static readonly TaskFactory _myTaskFactory = new TaskFactory(CancellationToken.None, TaskCreationOptions.None, TaskContinuationOptions.None, TaskScheduler.Default);

        public static void RunSync(Func<Task> func)
        {
            _myTaskFactory.StartNew(func).Unwrap().GetAwaiter().GetResult();
        }

        public static TResult RunSync<TResult>(Func<Task<TResult>> func)
        {
            return _myTaskFactory.StartNew(func).Unwrap().GetAwaiter().GetResult();
        }
    }

    class SomeClass
    {
        public async Task<object> LoginAsync(object loginInfo)
        {
            return await Task.FromResult(0);
        }
        public object Login(object loginInfo)
        {
            return AsyncHelper.RunSync(() => LoginAsync(loginInfo));
            //return this.LoginAsync(loginInfo).Result.Content;
        }
    }
    class Program
    {
        static void Main(string[] args)
        {
            var someClass = new SomeClass();

            Console.WriteLine(someClass.Login(1));
            Console.ReadLine();
        }
    }
}

Или вы можете просто пойти с:

customerList = Task.Run<List<Customer>>(() => { return GetCustomers(); }).Result;

Для компиляции убедитесь, что вы ссылаетесь на сборку:

System.Net.Http.Formatting

В wp8:

Оберните его:

Task GetCustomersSynchronously()
{
    Task t = new Task(async () =>
    {
        myCustomers = await GetCustomers();
    }
    t.RunSynchronously();
}

Назовите его:

GetCustomersSynchronously();

    private int GetSync()
    {
        try
        {
            ManualResetEvent mre = new ManualResetEvent(false);
            int result = null;

            Parallel.Invoke(async () =>
            {
                result = await SomeCalcAsync(5+5);
                mre.Set();
            });

            mre.WaitOne();
            return result;
        }
        catch (Exception)
        {
            return null;
        }
    }

Попробуйте использовать следующий код для меня:

public async void TaskSearchOnTaskList (SearchModel searchModel)
{
    try
    {
        List<EventsTasksModel> taskSearchList = await Task.Run(
            () => MakeasyncSearchRequest(searchModel),
            cancelTaskSearchToken.Token);

        if (cancelTaskSearchToken.IsCancellationRequested
                || string.IsNullOrEmpty(rid_agendaview_search_eventsbox.Text))
        {
            return;
        }

        if (taskSearchList == null || taskSearchList[0].result == Constants.ZERO)
        {
            RunOnUiThread(() => {
                textViewNoMembers.Visibility = ViewStates.Visible;                  
                taskListView.Visibility = ViewStates.Gone;
            });

            taskSearchRecureList = null;

            return;
        }
        else
        {
            taskSearchRecureList = TaskFooterServiceLayer
                                       .GetRecurringEvent(taskSearchList);

            this.SetOnAdapter(taskSearchRecureList);
        }
    }
    catch (Exception ex)
    {
        Console.WriteLine("ActivityTaskFooter -> TaskSearchOnTaskList:" + ex.Message);
    }
}