Изменить: Этот вопрос выглядит, как будто это может быть та же проблема, но не имеет ответов ...

Изменить: в тестовом примере 5 задача застряла в WaitingForActivationсостоянии.

Я столкнулся с каким-то странным поведением при использовании System.Net.Http.HttpClient в .NET 4.5, где «ожидание» результата вызова (например) httpClient.GetAsync(...)никогда не вернется.

Это происходит только при определенных обстоятельствах при использовании новых функций языка async / await и API задач - кажется, код всегда работает при использовании только продолжений.

Вот некоторый код, который воспроизводит проблему - поместите его в новый «проект MVC 4 WebApi» в Visual Studio 11, чтобы предоставить следующие конечные точки GET:

/api/test1
/api/test2
/api/test3
/api/test4
/api/test5 <--- never completes
/api/test6

Каждая из конечных точек здесь возвращает одни и те же данные (заголовки ответа от stackoverflow.com), за исключением тех, /api/test5которые никогда не завершаются.

Сталкивался ли я с ошибкой в ​​классе HttpClient, или я каким-то образом неправильно использую API?

Код для воспроизведения:

public class BaseApiController : ApiController
{
    /// <summary>
    /// Retrieves data using continuations
    /// </summary>
    protected Task<string> Continuations_GetSomeDataAsync()
    {
        var httpClient = new HttpClient();

        var t = httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead);

        return t.ContinueWith(t1 => t1.Result.Content.Headers.ToString());
    }

    /// <summary>
    /// Retrieves data using async/await
    /// </summary>
    protected async Task<string> AsyncAwait_GetSomeDataAsync()
    {
        var httpClient = new HttpClient();

        var result = await httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead);

        return result.Content.Headers.ToString();
    }
}

public class Test1Controller : BaseApiController
{
    /// <summary>
    /// Handles task using Async/Await
    /// </summary>
    public async Task<string> Get()
    {
        var data = await Continuations_GetSomeDataAsync();

        return data;
    }
}

public class Test2Controller : BaseApiController
{
    /// <summary>
    /// Handles task by blocking the thread until the task completes
    /// </summary>
    public string Get()
    {
        var task = Continuations_GetSomeDataAsync();

        var data = task.GetAwaiter().GetResult();

        return data;
    }
}

public class Test3Controller : BaseApiController
{
    /// <summary>
    /// Passes the task back to the controller host
    /// </summary>
    public Task<string> Get()
    {
        return Continuations_GetSomeDataAsync();
    }
}

public class Test4Controller : BaseApiController
{
    /// <summary>
    /// Handles task using Async/Await
    /// </summary>
    public async Task<string> Get()
    {
        var data = await AsyncAwait_GetSomeDataAsync();

        return data;
    }
}

public class Test5Controller : BaseApiController
{
    /// <summary>
    /// Handles task by blocking the thread until the task completes
    /// </summary>
    public string Get()
    {
        var task = AsyncAwait_GetSomeDataAsync();

        var data = task.GetAwaiter().GetResult();

        return data;
    }
}

public class Test6Controller : BaseApiController
{
    /// <summary>
    /// Passes the task back to the controller host
    /// </summary>
    public Task<string> Get()
    {
        return AsyncAwait_GetSomeDataAsync();
    }
}

Вы неправильно используете API.

Вот ситуация: в ASP.NET только один поток может обрабатывать запрос одновременно. При необходимости можно выполнить некоторую параллельную обработку (заимствование дополнительных потоков из пула потоков), но только один поток будет иметь контекст запроса (дополнительные потоки не имеют контекста запроса).

Это управляется ASP.NETSynchronizationContext .

По умолчанию, когда вы , метод возобновляется на захваченный (или не захвачен , если нет ). Обычно это как раз то, что вы хотите: асинхронное действие контроллера будет чем-то, и когда оно возобновится, оно возобновится с контекстом запроса.awaitTaskSynchronizationContextTaskSchedulerSynchronizationContextawait

Итак, вот почему test5не получается:

• Test5Controller.Getвыполняется AsyncAwait_GetSomeDataAsync(в контексте запроса ASP.NET).
• AsyncAwait_GetSomeDataAsyncвыполняется HttpClient.GetAsync(в контексте запроса ASP.NET).
• HTTP-запрос отправляется и HttpClient.GetAsyncвозвращает незавершенный Task.
• AsyncAwait_GetSomeDataAsyncждет Task; поскольку он не завершен, AsyncAwait_GetSomeDataAsyncвозвращает незавершенный Task.
• Test5Controller.Get блокирует текущий поток, пока он не Taskзавершится.
• HTTP-ответ приходит, а Taskвозвращаемый HttpClient.GetAsyncзавершается.
• AsyncAwait_GetSomeDataAsyncпытается возобновить в контексте запроса ASP.NET. Однако в этом контексте уже существует поток: поток заблокирован в Test5Controller.Get.
• Тупик.

Вот почему другие работают:

• ( test1, test2и test3): Continuations_GetSomeDataAsyncпланирует продолжение в пул потоков вне контекста запроса ASP.NET. Это позволяет завершить Taskвозврат Continuations_GetSomeDataAsyncбез необходимости повторно вводить контекст запроса.
• ( test4А test6): Так как Taskэто ожидали , запрос поток ASP.NET не заблокирован. Это позволяет AsyncAwait_GetSomeDataAsyncиспользовать контекст запроса ASP.NET, когда он готов продолжить.

И вот лучшие практики:

1. В ваших «библиотечных» asyncметодах используйте по ConfigureAwait(false)возможности. В вашем случае это изменится AsyncAwait_GetSomeDataAsyncнаvar result = await httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead).ConfigureAwait(false);
2. Не блокируйте на Taskс; это asyncвсе вниз. Другими словами, используйте awaitвместо GetResult( Task.Resultи Task.Waitтакже следует заменить на await).

Таким образом, вы получаете оба преимущества: продолжение (оставшаяся часть AsyncAwait_GetSomeDataAsyncметода) запускается в базовом потоке пула потоков, который не должен входить в контекст запроса ASP.NET; и сам контроллер async(который не блокирует поток запроса).

Больше информации:

• Мой async/ awaitвступительный пост , который включает в себя краткое описание того, как Taskиспользуют ожидающие SynchronizationContext.
• Асинхронный / Await FAQ , который переходит в более подробно о контекстах. Также смотрите Await, UI и тупики! О боже! который делает применить здесь , даже если вы в ASP.NET , а не пользовательского интерфейса, поскольку ASP.NET SynchronizationContextограничивает контекст запроса , чтобы только один поток одновременно.
• Это сообщение на форуме MSDN .
• Стивен Тауб демонстрирует этот тупик (используя пользовательский интерфейс) , как и Lucian Wischik .

Обновление 2012-07-13: Включите этот ответ в сообщение в блоге .

Изменить: как правило, старайтесь избегать выполнения ниже, кроме как последнее усилие рва, чтобы избежать тупиков. Прочитайте первый комментарий от Стивена Клири.

Быстрое решение здесь . Вместо того чтобы писать:

Task tsk = AsyncOperation();
tsk.Wait();

Пытаться:

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

Или если вам нужен результат:

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

Из исходного кода (отредактировано в соответствии с приведенным выше примером):

AsyncOperation теперь будет вызываться в ThreadPool, где не будет SynchronizationContext, и продолжения, используемые внутри AsyncOperation, не будут принудительно возвращаться в вызывающий поток.

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

Из источника:

Убедитесь, что ожидание в методе FooAsync не находит контекста, к которому нужно вернуться. Самый простой способ сделать это - вызвать асинхронную работу из ThreadPool, например, обернуть вызов в Task.Run, например

int Sync () {return Task.Run (() => Library.FooAsync ()). Result; }

FooAsync теперь будет вызываться в ThreadPool, где не будет SynchronizationContext, и продолжения, используемые внутри FooAsync, не будут принудительно возвращаться в поток, который вызывает Sync ().

Поскольку вы используете .Resultили, .Waitили awaitэто приведет к тупику в вашем коде.

Вы можете использовать ConfigureAwait(false)в asyncметодах предотвращения тупика

как это:

var result = await httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead)
                             .ConfigureAwait(false);

Вы можете использовать, ConfigureAwait(false)где это возможно, для Не блокировать асинхронный код.

Эти две школы на самом деле не исключают.

Вот сценарий, где вы просто должны использовать

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

или что-то вроде

   AsyncContext.Run(AsyncOperation);

У меня есть действие MVC, которое находится под атрибутом транзакции базы данных. Идея была (вероятно) откатить все, что было сделано в действии, если что-то пойдет не так. Это не позволяет переключение контекста, в противном случае откат транзакции или фиксация само по себе приведет к сбою.

Мне нужна библиотека async, так как ожидается, что она будет работать async.

Единственный вариант. Запустите его как обычный вызов синхронизации.

Я просто говорю каждому свое.

Я собираюсь поместить это здесь больше для полноты, чем для непосредственного отношения к ФП. Я потратил почти день на отладку HttpClientзапроса, задаваясь вопросом, почему я так и не получил ответ.

Наконец обнаружил, что я забыл awaitо asyncвызове дальше вниз по стеку вызовов.

Ощущает себя так же хорошо, как пропустить точку с запятой.

Я смотрю здесь:

http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.taskawaiter(v=vs.110).aspx

И тут:

http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.taskawaiter.getresult(v=vs.110).aspx

И увидев:

Этот тип и его члены предназначены для использования компилятором.

Учитывая, что awaitверсия работает, и является ли «правильный» способ ведения дел, вам действительно нужен ответ на этот вопрос?

Мой голос: Неправильное использование API .