PCLSRing (también conocido como Program Counter Lusering [1] [a] ) es el término utilizado en el sistema operativo ITS para un principio de consistencia en la forma en que un proceso accede al estado de otro proceso. [2]
Este escenario presenta complicaciones particulares:
¿Cuál debería ser el estado visible del contexto del Proceso A en el momento en que el Proceso B accede a él? De hecho, el Proceso A está en medio de una llamada al sistema, pero ITS hace que las llamadas al sistema parezcan no ser visibles para otros procesos (o incluso para el mismo proceso).
Si la llamada del sistema no puede completarse antes del acceso, entonces debe ser reiniciable . Esto significa que el contexto se respalda hasta el punto de entrada a la llamada del sistema, mientras que los argumentos de la llamada se actualizan para reflejar cualquier parte de la operación que ya se haya completado. [2] Para una operación de E/S, esto significa que la dirección de inicio del búfer debe avanzarse sobre los datos ya transferidos, mientras que la longitud de los datos a transferir debe disminuirse en consecuencia. Una vez que se completa la interacción del Proceso B, el Proceso A puede reanudar la ejecución y la llamada del sistema se reanuda desde donde se quedó.
Esta técnica refleja en el software lo que el PDP-10 hace en el hardware. Algunas instrucciones del PDP-10, como BLT, pueden no ejecutarse hasta su finalización, ya sea debido a una interrupción o a un fallo de página. [2] Durante el procesamiento de la instrucción, el PDP-10 modificaría los registros que contienen argumentos para la instrucción, de modo que más tarde la instrucción pueda ejecutarse nuevamente con nuevos argumentos que completarían cualquier trabajo restante por hacer. PCLSRing aplica la misma técnica a las llamadas del sistema.
Esto requiere cierta complejidad adicional. Por ejemplo, las páginas de memoria en el espacio de usuario no pueden ser paginadas durante una llamada al sistema en ITS. Si esto se permitiera, entonces cuando la llamada al sistema es PCLSRed e intenta actualizar los argumentos para que la llamada pueda ser abortada, la página que contiene los argumentos podría no estar presente y la llamada al sistema tendría que bloquearse, impidiendo que la PCLSR tenga éxito. Para evitar esto, ITS no permite que las páginas de memoria en el espacio de usuario sean paginadas después de que se acceda a ellas por primera vez durante una llamada al sistema, y las llamadas al sistema normalmente comienzan tocando páginas en el espacio de usuario a las que saben que necesitarán acceder. [2]
Comparemos esto con el enfoque adoptado en el sistema operativo UNIX , donde existe la posibilidad de reinicio, pero no es transparente. En cambio, una operación de E/S devuelve el número de bytes realmente transferidos (o el error EINTR si la operación se interrumpió antes de que se transfirieran realmente los bytes), y la aplicación debe comprobarlo y gestionar su propia reanudación de la operación hasta que se hayan transferido todos los bytes. En la filosofía de UNIX , Richard P. Gabriel dio este ejemplo del principio de " lo peor es mejor ".
Es posible adoptar un enfoque diferente. Es evidente en lo anterior que la llamada al sistema tiene que ser sincrónica , es decir, el proceso que la llama tiene que esperar a que se complete la operación. Esto no es inevitable: en el sistema operativo OpenVMS , todas las operaciones de E/S y otras operaciones que consumen mucho tiempo son inherentemente asincrónicas , lo que significa que la semántica de la llamada al sistema es "iniciar la operación y realizar una o más de estas notificaciones cuando se complete", después de lo cual regresa inmediatamente al llamador. Hay un conjunto estándar de notificaciones disponibles (como establecer un indicador de evento o entregar una trampa del sistema asincrónica ), así como un conjunto de llamadas al sistema para suspender explícitamente el proceso mientras se espera por estas, que son a) completamente reiniciables en el sentido de ITS, y b) mucho más pequeñas en número que el conjunto de llamadas al sistema que consumen mucho tiempo reales.
OpenVMS ofrece versiones sincrónicas alternativas de "iniciar operación y esperar a que finalice" de todas las llamadas del sistema que consumen mucho tiempo. Estas se implementan como "ejecutar la operación asincrónica real" seguida de "esperar hasta que la operación establezca el indicador de evento". Cualquier acceso al contexto del proceso durante este tiempo lo verá a punto de (re)ingresar a la llamada de espera de indicador de evento.