Trampa del sistema asíncrono

La trampa del sistema asíncrono ( AST ) se refiere a un mecanismo utilizado en varios sistemas operativos de computadoras diseñados por la antigua Digital Equipment Corporation (DEC) de Maynard , Massachusetts . El mecanismo es un método para ejecutar subrutinas fuera del hilo principal de ejecución. ^{[ 1 ]}

Varios eventos dentro de estos sistemas pueden ser señalizados opcionalmente a los procesos de usuario a través del mecanismo AST. Estos AST actúan como llamadas a subrutinas, pero se entregan de forma asíncrona , es decir, sin tener en cuenta el contexto del hilo principal. Por ello, se debe tener cuidado:

• para garantizar que cualquier código que se comparta entre el hilo principal y el AST debe estar diseñado para ser reentrante y
• Cualquier dato compartido debe estar protegido contra la corrupción si el AST lo modifica en cualquier momento. De lo contrario, los datos deben protegerse bloqueando los AST durante las secciones críticas .

Los AST se encuentran con mayor frecuencia como resultado de emitir llamadas QIO al kernel . La finalización de la E/S puede ser señalada mediante la emisión de un AST al proceso/tarea que realiza la llamada. Ciertos errores de tiempo de ejecución también podrían ser señalados utilizando el mecanismo AST. Dentro de OpenVMS, los AST especiales en modo kernel se utilizan como mecanismo estándar para obtener un acceso relativamente conveniente al contexto de un proceso (incluida la paginación del proceso en la memoria física según sea necesario). Este tipo de AST se ejecutan con la prioridad por proceso más alta posible la próxima vez que el planificador hace que ese proceso sea actual, y se utilizan, entre otras cosas, para recuperar información a nivel de proceso (en respuesta a una llamada al sistema $GETJPI "obtener información del trabajo/proceso") y para realizar la eliminación de procesos.

Los siguientes sistemas operativos implementan AST:

• RSX-11 (incluidas todas las variantes)
• RSTS/E
• OpenVMS

Los AST son aproximadamente análogos a las señales de Unix . Las diferencias importantes son:

• No se asignan "códigos de señal" a los AST: en lugar de asignar un manejador a un código de señal y generar dicho código, el AST se especifica directamente mediante su dirección. Esto permite que cualquier número de AST estén pendientes simultáneamente (sujeto a las cuotas de procesamiento).
• Los AST nunca abortan ninguna llamada al sistema en curso . De hecho, es posible que un proceso se ponga en estado de "hibernación" (con la llamada al sistema $HIBER) o que espere un indicador de evento llamando, por ejemplo, a $WAITFR, tras lo cual no hace nada más que esperar a que se entreguen los AST. Cuando se entrega un AST (activado por la finalización de una operación de E/S, un temporizador u otro evento), el proceso sale temporalmente de la espera para ejecutar el AST. Una vez que el procedimiento AST finaliza, se vuelve a realizar la llamada que puso al proceso en hibernación o la espera del indicador de evento; en esencia, se reevalúa el motivo de la espera. La única forma de salir de este bucle (aparte de la eliminación del proceso) es ejecutar una llamada al sistema $WAKE o $SETEF para satisfacer la espera. Esto puede hacerlo el propio proceso invocando $WAKE o $SETEF dentro del AST, o (si se utiliza un indicador de evento global) $SETEF dentro de otro proceso.

VAX/VMS V4 y versiones posteriores implementaron una optimización interesante para el problema de la sincronización entre el código a nivel de AST y el que no lo está. Un servicio del sistema llamado $SETAST podía utilizarse para habilitar o deshabilitar la entrega de AST para el modo de acceso actual y todos los modos de acceso menos privilegiados (el término de OpenVMS para las funciones de seguridad basadas en anillos ). Sin embargo, si la sección crítica que necesitaba protección de los AST constaba de solo unas pocas instrucciones, la sobrecarga de realizar las llamadas a $SETAST podía ser mucho mayor que el tiempo necesario para ejecutar dichas instrucciones.

Así, solo para el modo de usuario (el anillo de privilegios mínimos, normalmente utilizado por los programas de usuario ordinarios), se proporcionaba un par de indicadores de bits en una ubicación de memoria predefinida con permisos de escritura para el usuario (en el espacio "P1" por proceso). El significado de estos dos indicadores podía interpretarse como "no entregar ningún AST" y "los AST se han deshabilitado". En lugar del par habitual de llamadas a $SETAST, el código en modo de usuario establecía el primer indicador antes de ejecutar la secuencia de instrucciones durante la cual los AST debían bloquearse, y lo borraba después de la secuencia. Luego (nótese el orden aquí, para evitar condiciones de carrera ) comprobaba el segundo indicador para ver si se había establecido durante este tiempo: si era así, entonces los AST se habían deshabilitado realmente, y se debía llamar a $SETAST para volver a habilitarlos. En el caso más común, ningún AST se habría quedado pendiente durante este tiempo, por lo que no habría necesidad de llamar a $SETAST en absoluto.

Por su parte, el código de entrega del AST del kernel comprobaría el primer indicador antes de intentar entregar un AST en modo usuario; si estuviera activado, establecería directamente el bit de AST deshabilitados en el bloque de control del proceso (el mismo bit que se establecería mediante una llamada explícita a $SETAST desde el modo usuario), y también establecería el segundo indicador, antes de regresar y dejar el AST sin entregar.

El mecanismo de llamada a procedimientos asíncronos en la familia de sistemas operativos Windows NT es un mecanismo similar.

• OpenVMS Alpha Internals and Data Structures  : Scheduling and Process Control  : Version 7.0, Ruth Goldenberg, Saro Saravanan, Denise Dumas, ISBN 1-55558-156-0