Асинхронный против многопоточности - есть ли разница?

Всегда ли асинхронный вызов создает новый поток? Какая разница между двумя?

Всегда ли асинхронный вызов создает или использует новый поток?

Википедия говорит :

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

Я знаю, что асинхронные вызовы могут выполняться в отдельных потоках? Как это возможно?

Этот вопрос слишком общий, чтобы на него можно было ответить.

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

Асинхронный просто означает, что вызывающий поток не сидит и не ждет ответа, а также асинхронная активность не происходит в вызывающем потоке.

Помимо этого, вам нужно будет уточнить детали.

Всякий раз, когда операция, которая должна выполняться асинхронно, не требует, чтобы ЦП выполнял работу, эту операцию можно выполнить без создания другого потока. Например, если асинхронная операция - это ввод-вывод, ЦП не должен ждать завершения ввода-вывода. Ему просто нужно запустить операцию, а затем можно перейти к другой работе, пока оборудование ввода-вывода (контроллер диска, сетевой интерфейс и т. Д.) Выполняет операции ввода-вывода. Аппаратное обеспечение сообщает процессору о завершении, прерывая работу процессора, а затем операционная система передает событие вашему приложению.

Часто абстракции и API более высокого уровня не раскрывают базовые асинхронные API, доступные из ОС и базового оборудования. В таких случаях обычно проще создавать потоки для выполнения асинхронных операций, даже если порожденный поток просто ожидает операции ввода-вывода.

Если асинхронная операция требует, чтобы ЦП выполнял работу, то обычно эта операция должна выполняться в другом потоке, чтобы она была действительно асинхронной. Даже в этом случае он действительно будет асинхронным только при наличии более одной исполнительной единицы.

Нет, асинхронные вызовы не всегда связаны с потоками.

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

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

У Джона Ресига есть хорошее объяснение связанной с этим проблемы работы таймеров в JavaScript .

Многопоточность означает, что в одном процессе выполняется более одной операции. В то время как асинхронное программирование распространяется по процессам. Например, если мои операции вызывают веб-службу, потоку не нужно ждать возврата веб-службы. Здесь мы используем асинхронное программирование, которое позволяет потоку не ждать завершения процесса на другой машине. И когда он начинает получать ответ от веб-службы, он может прервать основной поток, чтобы сказать, что веб-служба завершила обработку запроса. Теперь основной поток может обработать результат.

В Windows всегда использовалась асинхронная обработка с момента времени без прерывания (версии 2.13, 3.0, 3.1 и т.д.) с использованием цикла сообщений, задолго до поддержки реальных потоков. Итак, чтобы ответить на ваш вопрос, нет, нет необходимости создавать поток для выполнения асинхронной обработки.

Асинхронные вызовы даже не обязательно должны происходить в той же системе / устройстве, что и вызывающая вызов. Итак, если вопрос в том, требует ли асинхронный вызов потока в текущем процессе, ответ - нет. Однако где-то должен быть поток выполнения, обрабатывающий асинхронный запрос.

Поток исполнения - это расплывчатый термин. В системах кооперативного управления задачами, таких как ранние ОС Macintosh и Windows, поток выполнения мог быть просто тем же процессом, который выполнял запрос, выполняя другой стек, указатель инструкций и т. Д. Однако когда люди обычно говорят об асинхронных вызовах , они обычно означают вызовы, которые обрабатываются другим потоком, если он является внутрипроцессным (т. е. в рамках того же процесса), или другим процессом, если он является межпроцессным.

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

Некоторые системы позволяют использовать преимущества параллелизма в ядре для некоторых средств с помощью обратных вызовов. Для довольно малоизвестного примера, асинхронные обратные вызовы ввода-вывода использовались для реализации неблокирующих интернет-серверов еще в дни без вытесняющей многозадачности Mac System 6-8.

Таким образом, у вас есть параллельные потоки выполнения «внутри» вашей программы без потоков как таковых .

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

Есть примеры однопоточных асинхронных программ. Что-то вроде:

...do something
...send some async request
while (not done)
    ...do something else
    ...do async check for results

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

Иногда, в зависимости от ситуации, вы можете захотеть вызвать асинхронный метод, но сделать так, чтобы он казался пользователю синхронным (т. Е. Блокировать до тех пор, пока асинхронный метод не сообщит о завершении). Это может быть достигнуто с помощью Win32 API, таких как WaitForSingleObject .