La programación asincrónica es mucho más una filosofía que un simple truco de programación. Si bien, su última pregunta atrajo respuestas principalmente sobre aspectos de programación y mi respuesta fue un solitario desconectado por ser mayormente teórico, estoy tratando de darle una nueva perspectiva basada en la misma línea, pero explicaciones en lugar de solo referencias.
Este trata sobre algunos fundamentos de por qué y cómo de la programación asincrónica.
Supongamos que va a una panadería (y suponiendo que el pastel se preparará después del pedido): tiene dos opciones: elegir esperar hasta que el pastel esté listo o dar el pedido y regresar a casa y recogerlo luego cuando esté listo. El primero (esperar) es un método sincrónico y luego es un método asincrónico . No hace falta decir que este ejemplo proporciona una buena referencia de por qué debería usar métodos asincrónicos sobre síncronos.
La programación basada en eventos es solo una de las formas en que se pueden construir los sistemas asíncronos y no es solo un patrón de diseño útil sino que es un patrón arquitectónico. Estoy enumerando casos en los que esta teoría se usa de una manera prácticamente útil, con la esperanza de que traiga algo de claridad.
Uno de los primeros ejemplos de sistemas asincrónicos son el sistema Unix IO. Si bien sabemos read(), write()e incluso las select()llamadas bloquean el flujo del programa, pero dentro del sistema operativo, son asíncronas, es decir, el núcleo generalmente sabe que el dispositivo de bloqueo (también conocido como disco duro) tardará un tiempo en llenar el búfer, hasta que la CPU esté libre de ese hilo respectivo y, por lo tanto, el hilo está estacionado como (no está listo). Consulte 1. Moris Bach "El diseño del sistema operativo Unix"
Otro ejemplo más común es la mayoría de los marcos de IU. Aquí, todos los clics de los usuarios se envían primero a través de un controlador que, a su vez, devuelve la solicitud a la aplicación correspondiente. Lo importante es que las devoluciones de llamadas no deberían mantener las devoluciones de llamadas en espera, de lo contrario el sistema se congelará. La devolución de llamada desde el controlador de la interfaz de usuario a los back-end suele ser asíncrona si implica un procesamiento pesado.
Otro buen ejemplo de programación asincrónica (como un patrón de diseño puro) es Active Object. Un objeto activo es aquel que tiene su propio hilo privado, de modo que uno puede mantener muchas solicitudes en una cola y ejecutar una por una. Consulte este documento: Objeto activo . Este patrón se usa mucho desde el software Enterprise hasta los marcos móviles. Las plataformas populares Java / EJB y .NET permiten la invocación de métodos asincrónicos locales o remotos , lo que esencialmente permite que los objetos normales se conviertan en objetos activos. Los objetos activos estaban presentes en Symbian: objetos activos en Symbian OS por Aapo Haapanen (ver esto también: Objetos activos en Symbian ). Esto ahora también está presente enAndroid )
Además del objeto activo, el mismo autor Douglas C. Schmidt , ha producido varios otros trabajos que son otros paralelos al objeto activo y también son los patrones asincrónicos. Vea este evento Patrones de manejo y una cuenta completa está disponible en su libro Arquitectura de software orientada a patrones: patrones para objetos concurrentes y en red - V2
Cuando un objeto dado necesita devolver la API, mientras se trabaja en segundo plano para realizar el trabajo, la metodología habitual es tener un sistema multiproceso para lograrlo. Los sistemas roscados están presentes en todas partes, desde C (posix), C ++ ( boost ) hasta Java, C #, etc. El objeto activo es esencialmente solo una abstracción que puede ocultar esto. Vea por qué las implementaciones de objetos activos son preferibles a los hilos desnudos. Otra buena lectura .
Pero este concepto va más allá de hilos u objetos dentro de una aplicación para volverse asíncrono. Uno de los mejores usos es en sistemas distribuidos donde dos aplicaciones no necesariamente tienen que esperar entre sí para coordinarse. RPC bueno (o no tan bueno, de cualquier forma que lo veas) RPC era sincrónico. [por supuesto, también hay otros RPC asincrónicos ]. Pero las alternativas modernas como el Middleware orientado a mensajes es verdaderamente asíncrono por buenas razones.
Por último, pero podría ser el más interesante, es la programación de Agentes que puede beneficiarse del modelo asíncrono de comunicación .
Si bien la programación asincrónica se ve sexy , crea su propia complejidad, que incluye:
- marco para pasar el valor de retorno
- sobrecarga adicional de comunicación
- necesidad adicional de sincronizar construcciones
- posibilidad de puntos muertos, carreras, etc. si las cosas no se hacen bien.
... y así.
Siempre debe usarse solo por razones genuinas.
Entonces, ¿cuándo se debe usar el modelo asincrónico? ¿Cuándo debe colocar un hilo de fondo y permitir que la persona que llama se vuelva asíncrona? Aquí hay algunas buenas reglas generales cuando se aplica (pero no completa)
Cuando el sistema desea aplicar una conversación estricta sobre recursos serios: por ejemplo, desea mantener un número fijo absoluto de subprocesos. El patrón asincrónico obliga al sistema a implementar la cola.
Cuando la necesidad de la persona que llama de hacer "otras cosas útiles que hacer" es genuina. Muchas veces, el otro hilo, incluso si se desbloquea, no hará nada útil y se queda sin sondeo para obtener resultados. De hecho, esto puede consumir más CPU que el modelo síncrono básico.
Cuando necesita mayores niveles de confiabilidad en sistemas distribuidos. (ver Middleware orientado a mensajes ).