Programación sincronizada/asincrónica

Si una persona que llama envía un mensaje a un receptor y está esperando una respuesta, ¿puede hacer otra cosa? Me refiero a una persona que llama/receptor en lugar de un servidor/cliente, ya que estas llamadas ocurren en todas partes. Por diseño, cuando creamos la informática por primera vez, todo estaba sincronizado. Esto se puede ver como una onda sinusoidal en la que una persona que llama y un servidor están sincronizados o al mismo ritmo. Asíncrono significa que no están sincronizados.

E/S síncrona
La persona que llama envía la solicitud al receptor y luego la bloquea. Esto es cuando la persona que llama está bloqueada, no hace nada y, por lo tanto, es una pérdida total de tiempo. En los viejos tiempos, la CPU eliminaba el proceso del procesador, pensando que solo estaba bloqueado, y agregaba un nuevo proceso que no está bloqueado (cambio de contexto). Entonces, la persona que llama no puede ejecutar mientras tanto. Finalmente, cuando el receptor responde, el sistema operativo puede devolver el proceso al procesador. Por lo tanto, la persona que llama se desbloquea. Esto muestra cómo el cliente y el servidor están completamente sincronizados.

Ejemplo de E/S síncrona del sistema operativo:
1. El programa le pide a la CPU que lea un archivo del disco.
2. El hilo principal del programa se quita de la CPU.
3. La lectura se completa y el programa comienza a ejecutarse nuevamente.

// A simple Js example
// Program starts
// Programs uses CPU to execute work.

SampleFunction();
// Program reads from the disk
// Program can't do anything until file loads
readfile("SyncExample.dat")

// Program resumes

Hablando específicamente desde el punto de vista de NodeJs, usa epoll en Linux y, en el caso de Windows, usa una pila de finalización. Otra cosa que hace nodeJs es generar un nuevo hilo que bloquea en caso de que algo requiera realizar una operación de bloqueo. De forma predeterminada, Nodejs tiene 4 subprocesos de trabajo en la biblioteca libuv , que utiliza para las operaciones de E/S, pero es configurable.

Ejemplo de una llamada asíncrona del sistema operativo (NodeJS)
a) El programa activa un subproceso secundario
b) el subproceso secundario lee del disco. Obviamente, el sistema operativo elimina del procesador actual
c) el programa principal todavía se ejecuta y ejecuta.
d) Termina el hilo y llama al hilo principal.

// A simple Javascript example
// Program starts
// Programs uses CPU to execute work.

SampleFunction();
// Program reads from the disk
// Program hapilly moves on to the samplefunction2
readfile("SyncExample.dat", onReadFinish(console.log))
//file is not probably read yet

SampleFunction2();
//onReadFinish function called
// executing it

Ahora vamos a discutir las cosas puramente desde la perspectiva de un cliente y un servidor (backend).
Por lo tanto, la sincronicidad también se puede conocer como una propiedad del cliente en la que puede esperar o seguir adelante. Hoy en día, ningún cliente es síncrono y la mayoría de las bibliotecas son asíncronas. En su mayoría, el cliente envía la solicitud y obtiene una respuesta, y se llama a alguna devolución de llamada cada vez que se ejecuta la respuesta. Entonces, en Node.js específicamente, hay un bucle principal de bucle de eventos que verifica la respuesta.
Esto puede ser confuso, como siempre lo fue para mí cuando alguien lo explicó con este hermoso ejemplo de la vida real que sincrónico es como hacer una pregunta en una reunión donde la reunión continuará si el presentador responde. Asíncrono es como hacer una pregunta en un correo electrónico que se puede responder cuando el receptor tiene tiempo.

Procesamiento asíncrono de back-end

Siendo un ingeniero de back-end, sería injusto si no hablara de hacer que el back-end sea asíncrono. En muchos códigos/repositorios, el cliente es principalmente asíncrono, pero el backend aún lo hace esperar. Entonces, cuando un cliente solicita enviar algunos datos, digamos para hacer una llamada a la base de datos, muchas veces se le pide que espere la respuesta del backend, que devuelve una respuesta de estado 200 después de la confirmación. Ahora, si movemos la lente hacia el backend, el frontend es asíncrono, pero el backend sigue siendo síncrono. Entonces, ¿cómo devolvemos una respuesta inmediata?
Una de las soluciones es usar esta hermosa estructura de datos, llamada cola. Si un cliente envía una solicitud, no prometemos ejecutarla de inmediato, pero la incluiremos en la cola. La razón de esto es que el backend podría estar completando las solicitudes anteriores y el cliente ya no está bloqueado; podemos enviar la respuesta de que hemos puesto en cola la solicitud, y aquí hay una promesa/ID de trabajo. Para obtener más información, puede leer acerca de las colas de mensajes .
Hay soluciones muy populares aparte de esto, dependiendo del caso de uso.

Un ejemplo del mundo real de una carga de trabajo asíncrona:
a) Confirmaciones asíncronas en Postgres ↗ .
b) E/S asíncrona en Linux (io-uring).
c) E/S asíncrona fsync (fs-cache): Cada vez que escribimos algo en cualquier archivo, no se escribe directamente en el disco sino en el caché del sistema de archivos. Hay un caché en el sistema operativo y las escrituras van a las páginas. Y luego, el sistema operativo vacía todas las páginas de una sola vez.

Podemos resumir todo de la siguiente manera:
a) El enfoque de programación síncrona ejecuta tareas secuencialmente. Cada tarea se lleva a cabo después de haber esperado a que finalice cualquier tarea anterior.
b) Cuando se ejecuta una tarea en un modelo de programación asíncrona, podemos pasar a otra sin esperar a que finalice la anterior.

Gracias por leer; Espero que haya sido de ayuda.
En caso de más dudas, no dude en conectarse a través de LinkedIn / Instagram .