E/S asíncrona

Disponible en versiones tempranas de Unix. En un sistema operativo multitarea , el procesamiento se puede distribuir entre diferentes procesos, que se ejecutan de forma independiente, tienen su propia memoria y procesan sus propios flujos de E/S; estos flujos suelen estar conectados en tuberías . Los procesos son bastante costosos de crear y mantener, ^{[ 1 ]} por lo que esta solución solo funciona bien si el conjunto de procesos es pequeño y relativamente estable. También presupone que los procesos individuales pueden operar de forma independiente, salvo para procesar las E/S de los demás; si necesitan comunicarse de otras maneras, coordinarlos puede resultar difícil.

Una extensión de este enfoque es la programación de flujo de datos , que permite crear redes más complejas que las simples cadenas que admiten las tuberías.

Variaciones:

• Error si aún no se puede realizar (volver a publicar más tarde).
• Informe cuándo se puede hacer sin bloquear (y luego publíquelo).

El sondeo proporciona una API síncrona sin bloqueo que puede utilizarse para implementar alguna API asíncrona. Está disponible en sistemas Unix y Windows tradicionales . Su principal problema es que puede consumir tiempo de CPU realizando sondeos repetidamente cuando el proceso emisor no tiene nada más que hacer, lo que reduce el tiempo disponible para otros procesos. Además, dado que una aplicación de sondeo es esencialmente de un solo hilo, puede que no pueda aprovechar al máximo el paralelismo de E/S del que es capaz el hardware.

Disponible en BSD Unix y casi cualquier otro sistema con una pila de protocolos TCP/IP que utilice o se base en la implementación de BSD. Una variación del tema del sondeo, un bucle select utiliza la llamada al sistema para esperar hasta que se cumpla una condición en un descriptor de archivo (por ejemplo, cuando hay datos disponibles para leer), se produzca un tiempo de espera o se reciba una señal (por ejemplo, cuando un proceso hijo termina). Al examinar los parámetros de retorno de la llamada, el bucle averigua qué descriptor de archivo ha cambiado y ejecuta el código apropiado. A menudo, para facilitar su uso, el bucle select se implementa como un bucle de eventos , quizás utilizando funciones de devolución de llamada ; esta situación se presta particularmente bien a la programación orientada a eventos .selectselect

Si bien este método es fiable y relativamente eficiente, depende en gran medida del paradigma Unix de que " todo es un archivo "; cualquier E/S bloqueante que no involucre un descriptor de archivo bloqueará el proceso. El bucle select también depende de poder involucrar toda la E/S en la selectllamada central; las bibliotecas que realizan su propia E/S son particularmente problemáticas en este sentido. Un problema potencial adicional es que las operaciones select y de E/S aún están suficientemente desacopladas como para que el resultado de select pueda ser engañoso: si dos procesos están leyendo de un solo descriptor de archivo (un diseño posiblemente deficiente), select puede indicar la disponibilidad de datos leídos que han desaparecido para cuando se emite la lectura, lo que resulta en un bloqueo; si dos procesos están escribiendo en un solo descriptor de archivo (algo bastante común), select puede indicar escritura inmediata, pero la escritura aún puede bloquearse, porque el otro proceso ha llenado un búfer mientras tanto, o porque la escritura es demasiado grande para el búfer disponible o por otras razones inadecuadas para el destinatario.

El bucle select no alcanza la máxima eficiencia del sistema posible con, por ejemplo, el método de colas de finalizaciónselect , porque la semántica de la llamada, que permite el ajuste por llamada del conjunto de eventos aceptables, consume cierta cantidad de tiempo por invocación al recorrer la matriz de selección. Esto crea poca sobrecarga para las aplicaciones de usuario que podrían tener abierto un descriptor de archivo para el sistema de ventanas y algunos para archivos abiertos, pero se convierte en un problema mayor a medida que crece el número de posibles fuentes de eventos, y puede obstaculizar el desarrollo de aplicaciones de servidor de muchos clientes, como en el problema C10k ; otros métodos asíncronos pueden ser notablemente más eficientes en tales casos. Algunos Unix proporcionan llamadas específicas del sistema con mejor escalabilidad; por ejemplo, epollen Linux (que llena la matriz de selección de retorno solo con aquellas fuentes de eventos en las que ha ocurrido un evento), kqueueen FreeBSD , y puertos de eventos (y /dev/poll) en Solaris .

SVR3 Unix proporcionaba la pollllamada al sistema. Podría decirse que tiene un nombre mejor que select, pero para los fines de esta discusión es esencialmente lo mismo. Los sistemas SVR4 Unix (y por lo tanto POSIX ) ofrecen ambas llamadas.

Disponible en sistemas BSD y POSIX Unix. La E/S se ejecuta de forma asíncrona y, al completarse, se genera una señal ( interrupción ). Al igual que en la programación de bajo nivel del kernel, las funcionalidades disponibles para un uso seguro dentro del manejador de señales son limitadas, y el flujo principal del proceso podría interrumpirse en casi cualquier punto, lo que resultaría en estructuras de datos inconsistentes para el manejador de señales. Por lo general, el manejador de señales no puede generar más operaciones de E/S asíncronas por sí mismo.

El enfoque de señales , si bien es relativamente sencillo de implementar en el sistema operativo, conlleva para el programa de aplicación la desventaja de escribir el sistema de interrupciones del núcleo del sistema operativo. Su peor característica es que cada llamada al sistema síncrona (bloqueante) es potencialmente interrumpible; por lo general, el programador debe incorporar código de reintento en cada llamada.

Disponible en Mac OS clásico , VMS y Windows . Presenta muchas características del método de señales , ya que fundamentalmente es lo mismo, aunque rara vez se reconoce como tal. La diferencia radica en que cada solicitud de E/S suele tener su propia función de finalización, mientras que el sistema de señales tiene una única función de devolución de llamada.

Por otro lado, un problema potencial del uso de devoluciones de llamada es que la profundidad de la pila puede crecer de forma inmanejable, ya que es muy común programar otra operación de E/S al finalizar una. Si esta debe satisfacerse inmediatamente, la primera devolución de llamada no se libera de la pila antes de que se invoque la siguiente. Los sistemas para evitar esto (como la programación intermedia de nuevas tareas) añaden complejidad y reducen el rendimiento. Sin embargo, en la práctica, esto generalmente no representa un problema, ya que la nueva operación de E/S suele finalizar tan pronto como se inicia, lo que permite liberar la pila. El problema también puede evitarse impidiendo nuevas devoluciones de llamada mediante una cola, hasta que la primera devolución de llamada finalice.

Los procesos ligeros (LWP) o hilos están disponibles en la mayoría de los sistemas operativos modernos. Son similares al método de procesos , pero con menor sobrecarga y sin el aislamiento de datos que dificulta la coordinación de los flujos. Cada LWP o hilo utiliza E/S síncrona de bloqueo tradicional, lo que simplifica la lógica de programación; este es un paradigma común en muchos lenguajes de programación, incluidos Java y Rust. La programación multihilo requiere el uso de mecanismos de sincronización proporcionados por el kernel y bibliotecas seguras para hilos . Este método es el más adecuado para aplicaciones de gran escala, como los servidores web, debido a la gran cantidad de hilos necesarios.

Este enfoque también se utiliza en el sistema de ejecución del lenguaje de programación Erlang . La máquina virtual de Erlang utiliza E/S asíncrona mediante un pequeño grupo de solo unos pocos hilos o, a veces, un solo proceso, para gestionar la E/S de hasta millones de procesos Erlang. La gestión de E/S en cada proceso se implementa principalmente mediante E/S síncrona bloqueante. De esta forma, el alto rendimiento de la E/S asíncrona se combina con la simplicidad de la E/S convencional (véase el modelo Actor ). Muchos problemas de E/S en Erlang se asignan al paso de mensajes , que se puede procesar fácilmente mediante la recepción selectiva integrada.

Las fibras / coroutines pueden considerarse un enfoque igualmente ligero para realizar E/S asíncronas fuera del sistema de ejecución de Erlang, aunque no ofrecen exactamente las mismas garantías que los procesos de Erlang.

Disponible en Microsoft Windows , Solaris , AmigaOS , DNIX y Linux (usando io_uring , disponible en 5.1 y superior). ^{[ 2 ]} Las solicitudes de E/S se emiten de forma asíncrona, pero las notificaciones de finalización se proporcionan a través de un mecanismo de cola de sincronización en el orden en que se completan. Generalmente asociado con una estructuración de máquina de estados del proceso principal ( programación orientada a eventos ), que puede tener poca semejanza con un proceso que no usa E/S asíncrona o que usa una de las otras formas, lo que dificulta la reutilización del código . No requiere mecanismos de sincronización especiales adicionales ni bibliotecas seguras para subprocesos , ni están separados los flujos textuales (código) y de tiempo (evento).

Disponible en VMS y AmigaOS (a menudo se usa junto con un puerto de finalización). Presenta muchas de las características del método de cola de finalización , ya que es esencialmente una cola de finalización de profundidad uno. Para simular el efecto de la "profundidad" de la cola, se requiere un indicador de evento adicional para cada evento potencialmente no procesado (pero completado), de lo contrario, se puede perder información del evento. Esperar al siguiente evento disponible en dicho grupo requiere mecanismos de sincronización que pueden no ser escalables a un mayor número de eventos potencialmente paralelos.

Disponible en mainframes de IBM , Groupe Bull y Unisys . La E/S de canal está diseñada para maximizar la utilización de la CPU y el rendimiento al descargar la mayor parte de las operaciones de E/S a un coprocesador. El coprocesador cuenta con DMA integrado, gestiona las interrupciones de los dispositivos, es controlado por la CPU principal y solo interrumpe a esta última cuando es estrictamente necesario. Esta arquitectura también admite los denominados programas de canal, que se ejecutan en el procesador de canal para realizar las tareas más complejas relacionadas con las actividades y los protocolos de E/S.

Disponible en Windows Server 2012 y Windows 8. Optimizado para aplicaciones que procesan grandes cantidades de mensajes pequeños para lograr un mayor número de operaciones de E/S por segundo con menor fluctuación y latencia. ^{[ 3 ]}

Utilizando únicamente estas dos herramientas (sondeo e interrupciones), todas las demás formas de E/S asíncrona mencionadas anteriormente pueden sintetizarse (y de hecho, se sintetizan).

En un entorno como una máquina virtual Java (JVM), la E/S asíncrona puede sintetizarse incluso si el entorno en el que se ejecuta la JVM no la ofrece. Esto se debe a la naturaleza interpretada de la JVM. La JVM puede realizar sondeos (o recibir una interrupción) periódicamente para instituir un cambio en el flujo de control interno, lo que da la apariencia de múltiples procesos simultáneos, algunos de los cuales presumiblemente existen para realizar E/S asíncrona. (Por supuesto, a nivel microscópico el paralelismo puede ser bastante burdo y presentar algunas características no ideales, pero superficialmente parecerá ser el deseado).

Ese es, de hecho, el problema de usar el sondeo, en cualquiera de sus formas, para sintetizar una forma diferente de E/S asíncrona. Cada ciclo de CPU que se dedica al sondeo se desperdicia y se pierde en sobrecarga en lugar de realizar la tarea deseada. Cada ciclo de CPU que no se dedica al sondeo representa un aumento en la latencia de respuesta a las E/S pendientes. Lograr un equilibrio aceptable entre estas dos fuerzas opuestas es difícil. (Por eso se inventaron los sistemas de interrupción por hardware).

La clave para maximizar la eficiencia reside en minimizar el trabajo necesario para activar la aplicación correspondiente al recibir una interrupción. En segundo lugar (aunque quizás no menos importante) se encuentra el método que la propia aplicación utiliza para determinar qué debe hacer.

Los métodos de sondeo expuestos, incluidos los mecanismos de selección/sondeo, resultan particularmente problemáticos (para la eficiencia de las aplicaciones). Si bien es muy probable que los eventos de E/S subyacentes de interés se generen mediante interrupciones, la interacción con este mecanismo se realiza mediante sondeo, lo que puede consumir mucho tiempo. Esto es especialmente cierto en el caso del sondeo a gran escala que se puede realizar mediante selección (y sondeo). Las interrupciones se corresponden muy bien con señales, funciones de devolución de llamada, colas de finalización e indicadores de eventos, por lo que estos sistemas pueden ser muy eficientes.