Следует ли использовать ConfigureAwait (false) в библиотеках, которые вызывают асинхронные обратные вызовы?

Когда вы говорите await task.ConfigureAwait(false), вы переходите к пулу потоков, в результате чего mapping запускается в нулевом контексте, а не в предыдущем контексте. Это может вызвать различное поведение. Итак, если звонивший написал:

await Map(0, i => { myTextBox.Text = i.ToString(); return 0; }); //contrived...

Тогда это выйдет из строя при следующей реализации Map:

var result = await task.ConfigureAwait(false);
return await mapper(result);

Но не здесь:

var result = await task/*.ConfigureAwait(false)*/;
...

Еще ужаснее:

var result = await task.ConfigureAwait(new Random().Next() % 2 == 0);
...

Подбросьте монетку о контексте синхронизации! Выглядит смешно, но не так абсурдно, как кажется. Более реалистичный пример:

var result =
  someConfigFlag ? await GetSomeValue<T>() :
  await task.ConfigureAwait(false);

Таким образом, в зависимости от некоторого внешнего состояния контекст синхронизации, в котором выполняется остальная часть метода, может измениться.

Это также может произойти с очень простым кодом, например:

await someTask.ConfigureAwait(false);

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

Этот недетерминизм - слабое место конструкции await. Это компромисс во имя производительности.

Самая досадная проблема здесь в том, что при вызове API непонятно, что происходит. Это сбивает с толку и вызывает ошибки.

Что делать?

Альтернатива 1: Вы можете возразить, что для обеспечения детерминированного поведения лучше всего всегда использовать task.ConfigureAwait(false).

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

var uiScheduler = TaskScheduler.FromCurrentSynchronizationContext;
Map(..., async x => await Task.Factory.StartNew(
        () => { /*access UI*/ },
        CancellationToken.None, TaskCreationOptions.None, uiScheduler));

Вероятно, что-то из этого лучше скрыть в служебном методе.

Альтернатива 2: вы также можете утверждать, что функция Map не должна зависеть от контекста синхронизации. Следует просто оставить это в покое. Затем контекст перетекает в лямбду. Конечно, простое присутствие контекста синхронизации может изменить поведение Map (не в этом конкретном случае, а в целом). Так что Map должен быть разработан, чтобы справиться с этим.

Альтернатива 3: вы можете добавить логический параметр в Map, который указывает, передавать ли контекст или нет. Это сделало бы поведение явным. Это хороший дизайн API, но он загромождает API. Кажется неуместным рассматривать базовый API, такой как Map, с проблемами контекста синхронизации.

Какой маршрут выбрать? Я думаю, это зависит от конкретного случая. Например, если Map - вспомогательная функция пользовательского интерфейса, имеет смысл передать контекст. Если это библиотечная функция (например, помощник повтора), я не уверен. Я вижу, что все альтернативы имеют смысл. Обычно рекомендуется применять ConfigureAwait(false) во всем коде библиотеки. Следует ли делать исключение в тех случаях, когда мы вызываем обратные вызовы пользователей? Что делать, если мы уже вышли из правого контекста, например:

void LibraryFunctionAsync(Func<Task> callback)
{
    await SomethingAsync().ConfigureAwait(false); //Drops the context (non-deterministically)
    await callback(); //Cannot flow context.
}

Так что, к сожалению, нет простого ответа.

Вопрос в том, должны ли мы использовать ConfigureAwait (false) в этом случае?

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

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

Изменить:

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

Хорошая идея, предложенная @ i3arnon, - принять необязательный флаг bool, указывающий, нужен контекст или нет. Хотя это немного некрасиво, было бы неплохо обойтись.

Я думаю, что настоящая проблема здесь связана с тем, что вы добавляете операции к Task, в то время как на самом деле вы работаете с их результатом.

Нет реальной причины дублировать эти операции для задачи в качестве контейнера вместо того, чтобы хранить их в результате задачи.

Таким образом, вам не нужно решать, как await эту задачу в служебном методе, поскольку это решение остается в коде потребителя.

Если вместо этого Map реализуется следующим образом:

public static TResult Map<T, TResult>(this T value, Func<T, TResult> mapping)
{
    return mapping(value);
}

Вы можете легко использовать его с Task.ConfigureAwait или без него соответственно:

var result = await task.ConfigureAwait(false)
var mapped = result.Map(result => Foo(result));

Map это просто пример. Дело в том, чем вы здесь манипулируете. Если вы манипулируете задачей, вам не следует await передавать ее и передавать результат делегату-потребителю, вы можете просто добавить async логику, и вызывающий может выбрать, использовать Task.ConfigureAwait или нет. Если вы работаете на результат, вам не о чем беспокоиться.

Вы можете передать логическое значение каждому из этих методов, чтобы указать, хотите ли вы продолжить работу с захваченным контекстом или нет (или даже более надежно передать флаги параметров enum для поддержки других await конфигураций). Но это нарушает разделение ответственности, поскольку это не имеет ничего общего с Map (или его эквивалентом).