Здравствуйте, Serginio1, Вы писали:

S>·>Выполнение в отдельном потоке означает параллельное выполнение. Это не отвечает на вопрос _зачем_ метод обязан быть асинхронным.
S> Задача может выполняться как в отдельном потоке LongRunning, так и пуле потоков. А там можно настроить, что бы пул потока состоял из одного потока.
S>Кроме того операции ввода вывода используют один поток использую один поток для контроля выполнения через контроллер.
ЗАЧЕМ?? Ты путаешь средство и цель.

S>·>Речь о коде на языке программирования идёт, а не об операционной системе.
S> Мы говорим об асинхронных методах, которые используют операции ввода вывода. Ты же спрашиваешь зачем использовать асинхронный код.
Зачем о них говорить? Почему в коде нельзя использовать синхронные операции ввода-вывода?

S>·>_Зачем_ он отвечает за параллельность?
S> Затем, что Task работает как с потоками так и пулом потоков со своим планировщиком. Так же компилятор создает класс энумератор со state machine с вызовом MoveNext после выполнения await
Это средство, а не цель. Мне, как программисту, не надо создавать энумераторы. Мне, как программисту, надо выполнить миллион операций ввода-вывода.

S>·>Или для тебя сложностью является наличие выбора?
S>Вот именно, что апи зависит от задач. Task универсален и легко читаем.
Нифига он не легко читаем. Примеры асинхронных очередей и т.п. ты мне тут показывал.

S>·>Нет, за параллельность отвечают потоки. Создаёшь много потоков — они выполяются параллельно. То что тебе _приходится_ использовать асинхронность — это недостаток платформенных тредов. Ты их не можешь запускать миллионами, поэтому _приходится_ переписывать "старый" код. Иначе всё просто падает нахрен.
S> Task это задача. Она отвязана от потоков. Еще раз внимательно читаем про операции ввода вывода, TaskCompletionSource
S> Что там внутри происходит зависит от планировщика, пула потоков, опций для Task.
Угу. Но зачем? Почему нельзя просто писать обычный код с обычными синхронными операциями?