Concurrencia, paralelismo, asincronía, non-blocking y sus conceptos

Empecé con una breve organización de términos y lo abordé ampliamente, desde gráficos hasta semiconductores.

1. Términos
   • Concurrencia / paralelismo
   • Asincronía / non-blocking
   • Apropiativo / no apropiativo
2. Sistema operativo y procesador
   • Sistema operativo
   • Procesador
3. Corutinas y fibras
   • Fibras
   • Corutinas
4. Generadores, Async/Await y continuaciones
   • Generadores
   • Async / Await
   • Continuaciones
5. Promise y Future
6. Multiplexación de I/O
   • Multiplexación
   • Sockets
   • Modelos de I/O
7. Ring buffer, modelos modernos de I/O y LMAX Disruptor
   • Ring buffer
   • Modelos modernos de I/O
   • LMAX Disruptor
8. Primitivas de sincronización
   • Necesidad
   • Seguridad de hilos
   • Spinlock
   • Mutex
   • Semáforo
   • STM
   • GIL
9. Enfoques de otros lenguajes de scripting y patrones Reactor/Proactor
   • Ractor (Ruby)
   • Node.js (patrón Reactor)
   • Patrón Proactor
10. CSP y actores
    • CSP
    • Actores
11. Green threads, goroutines y tecnologías modernas de runtime asíncrono
    • Green threads
    • Runtime modernos de CSP
    • Runtime modernos de actores
12. Paralelismo
    • SIMD y pipelining
    • OpenMP & MPI
    • Técnicas modernas de paralelismo
    • Arquitectura lambda
13. GPU
    • Pipeline y shaders
    • Monitor
    • Buffering
    • Sincronización vertical
    • Frame pacing y beam racing
    • Compositor
    • API / bibliotecas gráficas
14. Otros chips
    • Panorama general
    • DSP
    • FPGA
    • TPU
15. Referencias

[roxie]

En la sincronía y la asincronía, la pregunta es quién verifica que la tarea se haya completado.
En el bloqueo y no bloqueo, la pregunta es si se tiene el control.

He visto que esta frase se repite exactamente igual en muchísimos blogs, y me da curiosidad saber cuál es la fuente original.

Como la mayoría de los blogs están demasiado ocupados citándose entre sí, no pude inferir cuál era el texto original; lo único que encontré fue el documento sobre AIO de IBM, pero me da la impresión de que ahí se habla solo de kernel io, ¿no? Además, también escuché que esa forma de distinguirlos es polémica en sí misma.

¿Es un criterio de juicio con autoridad?

[alstjr7375]

Primero, parece que se puede tomar como base el concepto de síncrono/asíncrono del lado de los circuitos.
Los circuitos síncronos usan un reloj para la temporización, y los asíncronos se activan por eventos u otras entradas.
Es decir, no sería forzado definir una API asíncrona como una que, de la misma manera, se activa mediante callbacks u otros mecanismos.
https://developer.mozilla.org/en-US/docs/…

Para las API bloqueantes/no bloqueantes, una definición adecuada es si es necesario esperar obligatoriamente a que termine la tarea.
Sin embargo, para no esperar, tiene que existir una implementación en la que la función llamada tenga el control, así que creo que por eso suele explicarse mucho de esa manera.
https://nodejs.org/en/docs/guides/blocking-vs-non-blocking/

Quise pasarlo por encima de forma breve y por eso lo había omitido, pero voy a intentar agregar también este contenido.

[roxie]

Estoy de acuerdo con todo lo que mencionaste. Sin embargo, todavía me cuesta estar seguro de si estos dos ejes de referencia deben dibujarse en una sección dividida en cuadrantes, si realmente pueden dibujarse así y si quedan adecuadamente diferenciados. Para mí, Blocking y Sync se sienten conceptualmente como si compartieran el 90% del mismo contexto. Lo mismo pasa con Non-Blocking y Async.

[alstjr7375]

Aunque Blocking-Sync y Non-Blocking-Async suelen usarse juntos, hay casos en los que es necesario distinguirlos.

• Blocking-Async: multiplexación de I/O como select
• Non-Blocking-Sync: sondeo de datos (polling)

Por eso, más bien creo que lo correcto es usarlos de forma diferenciada.

[roxie]

Parece que no logro empatizar del todo porque casi no entiendo los ejemplos que mencionaste.

https://incredible-larva.tistory.com/entry/IO-Multiplexing-Topabogi-1bu En este artículo lo explican así:

Al final, el proceso de usuario que solicitó select decide si hay trabajo posterior o no al revisar el valor de retorno. Como múltiples solicitudes de I/O que llegan de forma impredecible se gestionan al mismo tiempo, hay quienes lo consideran asíncrono; pero, en última instancia, cada operación individual de I/O muestra un comportamiento sincrónico.

Me gustaría saber qué opinas sobre esto. La verdad, en este punto sentí que esta clasificación 2x2 ya no tenía mucho sentido. Parece que según el dominio y la perspectiva, las interpretaciones varían bastante.

[alstjr7375]

Luego, al esperar la respuesta del kernel, llega una señal de callback desde el kernel indicando que el valor de resultado ya está preparado, y se muestra que el proceso de usuario copia los datos a su propio buffer.

Como esta parte es un método de activación por callback, tal como acordaron arriba, si hubiera que distinguirlo/definirlo expresamente, creo que lo correcto sería llamarlo Blocking-Async.
Pienso que, según la perspectiva, puede haber casos que parezcan ambiguos.

Sin embargo, el polling es un ejemplo claro: https://en.wikipedia.org/wiki/Polling_(computer_science)

En el caso del polling, como se verifica repetidamente si los datos están listos, es un ejemplo apropiado de Sync-Blocking.

[wonkwh]

Guau, gracias por el buen material.

[kayws426]

¡Lo leí con gusto!

[bus710]

Parece que el scroll no termina nunca.
Creo que vale la pena leer al menos una vez el libro "7 modelos de concurrencia", que trata temas similares.

[alstjr7375]

Al comparar el índice, se parecen bastante.
Parece un buen libro.