LRНаверное правильней будет сказать, что UI-поток будет ждать завершения выполнения задачи, которая будет выполняться все же в своем потоке, нет?

нет, никакого ожидания не будет, точнее будет то, что называется асинхронным ожиданием, но это по сути метафора к тому, что происходит на самом деле

Shocker.ProЕсть UI-поток, он запустил делегат в другом потоке (A) и ждет его завершения.

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

Никто ничего не ждёт, иными словами.

LR правильное слово нашёл для этого: «поджидание» :)

Shocker.ProДелегат выполняется в потоке А и запускает DownloadAsync в потоке В

DownloadAsync не выполняется ни в каком потоке. Это IO операция. Условно говоря, есть отдельные IO потоки (но это не потоки конечно же), которые сигнализируют о завершении своего выполнения.

Shocker.ProПри отсутствии ConfigureAwait(false) после завершения DownloadAsync выполнение должно вернуться в поток В и в нем выполниться Compute

В этом месте уже нет потока B. Если ConfigureAwait(false) отсутствует, то завершение будет обрабатывать основной поток, который владеет контекстом синхронизации.

https://habr.com/post/107583/ здесь подробней.


Shocker.ProПоток B - это не поток UI
Где я ошибаюсь?

Ты ошибаешься (всё ещё) в том, что считаешь задачу Task потоком. Это не так. Поток дошёл до первого await и пошёл гулять. Он как разнорабочий, залил цементный раствор и пошёл курить, или ещё что-то делать. Мимо проходил другой или тот же самый рабочий, увидел, что цемент застыл и продолжил начатую работу здесь. А главный поток это Прораб, который по умолчанию поручает, чтобы его звали каждый раз, когда длительная операция закончится (застывание цемента, например). Без него ничего не может продолжится, если не сконфигурировано иначе.

LRо каком выполнении в UI-потоке идет речь?

О синхронном коде.

LR,

Это зависит от конфигурации await вызова, и работает для кода продолжения, но контекст синхронизации не назначается потоку, как это можно сделать старым способом через Post или через шедулер.

Shocker.ProИтак, UI-поток запустил делегат на потоке из пула (А). Когда делегат закончит выполнение, тогда будет продолжение в UI-потоке (а именно, выполнится присвоение button1.Text =)

Ты думаешь, что UI-поток получит управление только в точке вызова Task, т.е. на момент присвоения button1.Text, но это не так. UI-поток подключится после любого await, не важно какой каскад функций был вызван внутри, если не сконфигурировано иначе.

Обычно принято в библиотеках везде втыкать ConfigureAwait, чтобы разработчик не получал фризы и дедлоки.


Shocker.ProТак как при вызове DownloadAsync() нет ConfigureAwait(false), то продолжение в делегате после await-а (а именно метод Compute()) должен выполняться в потоке А. Где я не прав?

Ты всё ещё думаешь, что после выполнения асинхронного метода есть какой-то поток А, который запустил DownloadAsync и теперь сидит ждёт, когда он выполнится :) После запуска асинхронного метода, поток освободился, и где будет выполнятся продолжение метода теперь зависит от ConfigureAwait.