Если async-await не создает никаких дополнительных потоков, то как это делает приложения отзывчивыми?

единственный способ, которым компьютер может делать больше, чем 1 вещь за раз, - это (1) фактически делать больше, чем 1 вещь за раз, (2) имитировать его, планируя задачи и переключаясь между ними. Поэтому, если async-await не делает ни того, ни другого

это не то, что ждетни тех. Помните, цель await не сделать синхронный код асинхронным магически. Это позволит используя то же самое методы, которые мы используем для записи синхронного кода при вызове асинхронного кода. Жду около сделать код, использующий операции с высокой задержкой, похожим на код, использующий операции с низкой задержкой. Эти операции с высокой задержкой могут быть в потоках, они могут быть на специальном оборудовании, они могут разрывать свою работу на маленькие кусочки и помещать ее в очередь сообщений для обработки потоком пользовательского интерфейса позже. Они делают что-то в достичь асинхронности, но они это те, кто это делает. Await просто позволяет вам воспользоваться этой асинхронностью.

кроме того, я думаю, что вам не хватает третьего варианта. Мы, старики - сегодняшние дети с их рэп-музыкой должны убраться с моей лужайки и т. д.-помним мир окон в начале 1990-х. Не было ни многопроцессорных машин, ни планировщиков потоков. Вы хотели запустить два приложения Windows одновременно, вы должны были доходность. Мультизадачность кооператива. ОС сообщает процессу, что он запускается, и если он плохо себя ведет, он лишает все остальные процессы обслуживания. Он бежит, пока не уступит, и каким-то образом он должен знайте, как забрать, где он остановился в следующий раз, когда ОС руки управления обратно к нему. Однопоточный асинхронный код очень похож на этот, с "await "вместо"yield". Ожидание означает: "Я собираюсь вспомнить, где я остановился здесь, и пусть кто-то другой побегает некоторое время; позвоните мне когда задачу я жду, и я забрать, где я остановился."Я думаю, вы можете видеть, как это делает приложения более отзывчивыми, как это было в Windows 3 days.

вызов любого метода означает ожидание завершения метода

есть ключ, которого вам не хватает. метод может вернуться до завершения его работы. В этом суть асинхронности. Метод возвращает, он возвращает задачу, которая означает "эта работа продолжается; скажите мне, что делать, когда она будет завершена". Работа метода не выполнена,даже если он вернулся.

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

Я объясняю это полностью в своем блоге There Is No Thread.

таким образом, современные системы ввода-вывода широко используют DMA (прямой доступ к памяти). Есть специальные, выделенные процессоры на сетевых картах, видеокартах, контроллерах HDD, последовательных / параллельных портах и т. д. Эти процессоры имеют прямой доступ к шине памяти и обрабатывают чтение/запись полностью независимо от процессора. CPU просто нужно уведомить устройство о местоположении в памяти, содержащей данные, и затем может делать свое дело, пока устройство не поднимет прерывание, уведомляющее процессор, что чтение/запись завершена.

Как только операция находится в полете, для процессора нет работы, и, следовательно, нет потока.

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

после исследования мой собственный, я, наконец, нашел недостающий кусок: select(). В частности, мультиплексирование ввода-вывода, реализуемое различными ядрами под разными именами:select(), poll(), epoll(), kqueue(). Это

await и async использовать задачи не потоки.

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

дали задание можно добавить продолжение это новый задание объект для выполнения как только нить закончится.

С async/await использовать заданиеs они не создать новый нить.

в то время как техника программирования прерываний широко используется в каждой современной ОС, я не думаю, что они здесь уместно.
Вы можете иметь два CPU bonded задачи выполнение параллельно (фактически перемежается) в одном процессоре с использованием aysnc/await.
Это не может быть объяснено просто тем, что ОС поддерживает очередь IORP.

последний раз, когда я проверял компилятор transformed async методы DFA работа делится на этапы, каждый из них заканчивается await инструкция.
The await начинается задание и прикрепить его продолжение выполнения следующий шаг.

в качестве примера концепции, вот пример псевдо-кода.
Вещи были упрощены для ясности и потому что я не помню все детали.

method:
   instr1                  
   instr2
   await task1
   instr3
   instr4
   await task2
   instr5
   return value

он превращается во что-то вроде этого

int state = 0;

Task nextStep()
{
  switch (state)
  {
     case 0:
        instr1;
        instr2;
        state = 1;

        task1.addContinuation(nextStep());
        task1.start();

        return task1;

     case 1:
        instr3;
        instr4;
        state = 2;

        task2.addContinuation(nextStep());
        task2.start();

        return task2;

     case 2:
        instr5;
        state = 0;

        task3 = new Task();
        task3.setResult(value);
        task3.setCompleted();

        return task3;
   }
}

method:
   nextStep();

¹ фактически пул может иметь свою политику создания задач.

Я не собираюсь конкурировать с Эриком Липпертом или Лассе В. Карлсеном и другими, я просто хотел бы обратить внимание на другой аспект этого вопроса, который, я думаю, не был явно упомянут.

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

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

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

есть в основном два типа обработки (вычисления), которые происходят на машине:

• обработка, которая происходит на CPU
• обработка, которая происходит на других процессорах (GPU, сетевая карта и т. д.), назовем их ИО.

Итак, когда мы пишем кусок кода, после компиляции, в зависимости от объекта мы используем (и это очень важно), обработка будет CPU bound или IO bound, и на самом деле, это может быть связано с комбинацией обоих.

примеры:

• если я использую метод Write FileStream объект (который является потоком), обработка будет, скажем, 1% CPU bound и 99% IO bound.
• если я использую метод Write NetworkStream объект (который является потоком), обработка будет, скажем, 1% CPU bound и 99% IO связанный.
• если я использую метод Write Memorystream объект (который является потоком), обработка будет 100% CPU.

Итак, как видите, с объектно-ориентированной точки зрения программиста, хотя я всегда к Stream объект, то, что происходит ниже, может сильно зависеть от конечного типа объекта.

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

примеры:

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

до async / await у нас было два решения для этого:

• темы. Он был относительно прост в использовании, с Классы Thread и ThreadPool. потоки связаны только с процессором.
• "старые" Begin/End / AsyncCallback асинхронная модель программирования. Это просто модель, она не говорит вам, будете ли вы привязаны к CPU или IO. Если вы посмотрите на классы сокетов или FileStream, это IO bound, что круто, но мы редко используем его.

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

и реальная победа в основном на Io связанных задач, задача, которая не использует CPU, но async/await по-прежнему является только моделью программирования, это не поможет вам определить, как/где обработка произойдет в конце.

это означает, что это не потому, что класс имеет метод "DoSomethingAsync" возвращает объект задачи, который вы можете предположить, что он будет привязан к процессору (что означает, что это может быть совсем бесполезно, особенно если у него нет параметра токена отмены) или привязки ввода-вывода (что означает, что это, вероятно,должны), или сочетание обоих (поскольку модель довольно вирусная, склеивание и потенциальные преимущества могут быть, в конце концов, супер смешанными и не столь очевидными).

Итак, возвращаясь к моим примерам, выполняя мои операции записи, используя async/await на MemoryStream останется привязанным к процессору (я, вероятно, не выиграю от этого), хотя я, безусловно, выиграю от этого с файлами и сетевыми потоками.

на самом деле async await цепочки-это государственная машина, генерируемая компилятором CLR.

async await однако использует потоки, которые TPL использует пул потоков для выполнения задач.

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

читайте далее:

что генерирует async & await?

асинхронное ожидание и Созданный StateMachine

асинхронный C# и F# (III.): Как это работает? - И Tomas Petricek

редактировать:

- ладно. Похоже, мои объяснения неверны. Однако я должен отметить, что государственные машины являются важными активами для async awaits. Даже если вы принимаете асинхронный ввод-вывод, вам все равно нужен помощник, чтобы проверить, завершена ли операция, поэтому нам все еще нужна машина состояния и определить какую рутину можно выполнять вместе.

обобщение других ответов:

Async / await в основном создается для связанных с IO задач, так как с их помощью можно избежать блокировки вызывающего потока.

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

Async не создает собственный поток. Поток вызывающего метода используется для выполнения асинхронного метода, пока он не найдет ожидаемый. Тот же затем поток продолжает выполнять остальную часть вызывающего метода за пределами вызова асинхронного метода. В рамках вызываемого асинхронного метода, после возвращения из ожидаемого, продолжение может быть выполнено на потоке из пула потоков-единственное место, где отдельный поток входит в изображение.