Asíncrono vs Multihilo - ¿Hay alguna diferencia?

Siempre que la operación que tiene que ocurrir de forma asíncrona no requiere que la CPU funcione, esa operación se puede hacer sin generar otro subproceso. Por ejemplo, si la operación asincrónica es E/S, la CPU no tiene que esperar a que se complete la E / S. Solo necesita iniciar la operación, y luego puede pasar a otro trabajo mientras que el hardware de E/S (controlador de disco, interfaz de red, etc.) hace el trabajo de E/S. El hardware permite que la CPU sepa cuándo ha terminado interrumpiendo la CPU, y el sistema operativo luego entrega el evento a su aplicación.

Con frecuencia las abstracciones y API de nivel superior no exponen las API asíncronas subyacentes disponibles en el sistema operativo y el hardware subyacente. En esos casos, generalmente es más fácil crear subprocesos para realizar operaciones asíncronas, incluso si el subproceso generado está esperando una operación de E / S.

Si la operación asíncrona requiere que la CPU funcione, entonces generalmente esa operación tiene que ocurrir en otro subproceso en orden para que sea verdaderamente asíncrona. Incluso entonces, realmente solo será asincrónico si hay más de una unidad de ejecución.

No, las llamadas asíncronas no siempre involucran hilos.

Normalmente inician algún tipo de operación que continúa en paralelo con la persona que llama. Pero esa operación puede ser manejada por otro proceso, por el sistema operativo, por otro hardware (como un controlador de disco), por alguna otra computadora en la red o por un ser humano. Los hilos no son la única manera de hacer las cosas en paralelo.

Multi threading se refiere a más de una operación que ocurre en el mismo proceso. Mientras que la programación asincrónica se extiende a través de los procesos. Por ejemplo, si mis operaciones llaman a un servicio web, el subproceso no necesita esperar hasta que el servicio web regrese. Aquí usamos programación asincrónica que permite que el hilo no espere a que se complete un proceso en otra máquina. Y cuando comienza a recibir respuesta del servicio web puede interrumpir el hilo principal para decir que el servicio web ha completado el procesamiento de la solicitud. Ahora el hilo principal puede procesar el resultado.

JavaScript es un subproceso simple y asíncrono. Cuando usa XMLHttpRequest, por ejemplo, le proporciona una función de devolución de llamada que se ejecutará de forma asíncrona cuando regrese la respuesta.

John Resig tiene una buena explicación del problema relacionado de cómo funcionan los temporizadores en JavaScript.

Windows siempre tuvo un procesamiento asíncrono desde los tiempos no preventivos (versiones 2.13, 3.0, 3.1, etc.) usando el bucle de mensajes, mucho antes de soportar subprocesos reales. Así que para responder a su pregunta, no, no es necesario crear un hilo para realizar un procesamiento asíncrono.

Las llamadas asíncronas ni siquiera necesitan ocurrir en el mismo sistema/dispositivo que el que invoca la llamada. Así que si la pregunta es, ¿una llamada asíncrona requiere un hilo en el proceso actual, la respuesta es no. Sin embargo, debe haber un hilo de ejecución en algún lugar procesando la solicitud asíncrona.

El hilo de ejecución es un término vago. En un sistema cooperativo de tareas como los primeros sistemas operativos Macintosh y Windows, el hilo de ejecución podría ser simplemente el mismo proceso eso hizo que la solicitud ejecutara otra pila, puntero de instrucciones, etc... Sin embargo, cuando la gente generalmente habla de llamadas asincrónicas, normalmente se refieren a llamadas que son manejadas por otro subproceso si es intra-proceso (es decir, dentro del mismo proceso) o por otro proceso si es inter-proceso.

Tenga en cuenta que la comunicación entre procesos (o interproceso) (IPC) se generaliza comúnmente para incluir la comunicación intra-proceso, ya que las técnicas para bloquear y sincronizar datos suelen ser los mismos independientemente del proceso en el que se ejecuten los subprocesos separados de ejecución.

Algunos sistemas le permiten aprovechar la concurrencia en el kernel para algunas instalaciones usando callbacks. Para una instancia bastante oscura, se utilizaron devoluciones de llamada de E / s asincrónicas para implementar cortadores de Internet sin bloqueo en los días de multitarea no preventiva del sistema Mac 6-8.

De esta manera tiene flujos de ejecución concurrentes "en" que programa sin hilos como tales.

Asíncrono solo significa que no bloquea su programa esperando algo (llamada a función, dispositivo, etc.) terminar. Se puede implementar en un subproceso separado, pero también es común usar un subproceso dedicado para tareas síncronas y comunicarse a través de algún tipo de sistema de eventos y así lograr un comportamiento asíncrono.

Hay ejemplos de programas asíncronos de un solo subproceso. Algo como:

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

La naturaleza de las llamadas asíncronas es tal que, si desea que la aplicación continúe ejecutándose mientras la llamada está en progreso, necesitará generar un nuevo hilo, o al menos utilizar otro hilo que haya creado únicamente con el propósito de manejar devoluciones de llamada asíncronas.

A veces, dependiendo de la situación, es posible que desee invocar un método asíncrono, pero hacer que parezca que el usuario es síncrono (es decir, bloquear hasta que el el método asíncrono ha señalado que está completo). Esto se puede lograr a través de API Win32 como WaitForSingleObject.

Una operación asíncrona es una operación que continúa en segundo plano después de ser iniciada, sin forzar al llamador a esperar a que termine antes de ejecutar otro código.

En lugar de bloquear el programa que llama (o subproceso) hasta que llegue una respuesta, una implementación asíncrona (también llamada sin bloqueo) enviará una solicitud a la base de datos o servicio web o lo que sea, luego regresará inmediatamente, permitiendo que su programa continúe ejecutando otro código mientras el el servicio remoto envía una respuesta. Una vez que llegue la respuesta, el sistema ejecutará una devolución de llamada (ya sea en su bucle de mensajes o en un subproceso de puerto de finalización de E / S separado, dependiendo del entorno), permitiendo que su código maneje la respuesta.

Multi-threading significa ejecutar más de un subproceso de ejecución a la vez. En este modelo, todas las operaciones siguen siendo síncronas, pero la CPU ejecutará múltiples subprocesos de operaciones síncronas al mismo tiempo.

Multi-threading hace la mayoría de los sentidos al llamar a múltiples (e independientes) operaciones vinculadas a la CPU, en un procesador multinúcleo. Por ejemplo, un programa que analiza de forma independiente cada píxel de una imagen podría dividir la imagen en una tira para cada núcleo de CPU, luego analizar cada tira en su propio hilo al mismo tiempo.

Leer más aquí - https://blog.slaks.net/2014-12-23/parallelism-async-threading-explained/