День триста двадцать пятый. #AsyncAwaitFAQ
FAQ по async/await и ConfigureAwait
3. Как SynchronizationContext и TaskScheduler связаны с await?
Представьте кнопку в приложении. Нажав на кнопку, мы хотим загрузить текст с веб-сайта и установить его в качестве текста кнопки. Доступ к кнопке возможен только из UI-потока, которому она принадлежит, поэтому, когда мы успешно загрузили новый текст и хотим установить его как текст кнопки, мы должны сделать это из потока, которому принадлежит элемент управления (из UI-потока). Если мы этого не сделаем, мы получим исключение:

System.InvalidOperationException: 'The calling thread cannot access this object because a different thread owns it.' (Вызывающий поток не может получить доступ к этому объекту, поскольку он принадлежит другому потоку).

Если бы мы писали это вручную, мы могли бы использовать SynchronizationContext, чтобы выполнить установку текста в исходном контексте, например через TaskScheduler:

private static readonly HttpClient сlient = new HttpClient();
private void downloadBtn_Click(object sender, RoutedEventArgs e)
{
   сlient.GetStringAsync("http://example.com/gettext")
    .ContinueWith(downloadTask => {
        downloadBtn.Text = downloadTask.Result;
    }, TaskScheduler.FromCurrentSynchronizationContext());
}

Либо можно напрямую использовать SynchronizationContext:

private void downloadBtn_Click(object sender, RoutedEventArgs e)
{
  SynchronizationContext sc = SynchronizationContext.Current;
  сlient.GetStringAsync("http://example.com/gettext")
    .ContinueWith(downloadTask => {
      sc.Post(delegate {
        downloadBtn.Text = downloadTask.Result;
      }, null);
    });
}

Однако оба этих подхода явно используют функции обратного вызова. Вместо этого мы можем написать код естественным образом с помощью async/await:

private async void downloadBtn_Click(object sender, RoutedEventArgs e)
{
    string text = await сlient.GetStringAsync("http://example.com/gettext");
    downloadBtn.Text = text;
}

Этот код «просто работает», успешно устанавливая текст в UI-потоке, потому что, как и в случае с вручную реализованными версиями выше, ожидание задачи по умолчанию запоминает текущий контекст (SynchronizationContext.Current) или текущий планировщик (TaskScheduler.Current).
Когда вы ожидаете чего-либо в C#, компилятор использует паттерн awaitable и просит «ожидаемый» (awaitable) объект (в данном случае Task) предоставить ему объект «ожидателя» (awaiter) – в данном случае TaskAwaiter<string>. Этот «ожидатель» отвечает за создание метода обратного вызова (часто называемого «продолжением»), который «вернёт выполнение в исходный код» после того, как задача завершит работу. И делает он это с захватом текущего контекста/планировщика. В упрощённом виде это выглядит так:

object scheduler = SynchronizationContext.Current;
if (scheduler is null && TaskScheduler.Current != TaskScheduler.Default)
{
  scheduler = TaskScheduler.Current;
}

Другими словами, сначала проверяется, установлен ли SynchronizationContext, и, если нет, установлен ли «нестандартный» TaskScheduler. Если таким образом контекст/планировщик будет захвачен, он будет использован для выполнения метода обратного вызова соответственно в контексте или через планировщик. В противном случае чаще всего метод обратного вызова выполнится в том же контексте, что и ожидаемая задача.

Источник: https://devblogs.microsoft.com/dotnet/configureawait-faq/