Sistemas operativos modernos

La eficiencia se logra evitando transiciones innecesarias entre el espacio de usuario y el de kemel. Si un subproceso se bloquea en espera de que otro haga algo, por ejemplo, el kemel no tiene por qué intervenir, y es innecesario el procesamiento adicional de la transición kemel- usuario. El sistema de tiempo de ejecución en espacio de usuario puede bloquear el subproceso sincronizador y calendarizar otro por su cuenta. Cuando se usan activaciones del calendarizador, el kemel asigna cierto número de proce­ sadores virtuales a cada proceso y permite al sistema de tiempo de ejecución (en espacio de usuario) asignar subprocesos a procesadores. Este mecanismo también puede usarse en un mul­ tiprocesador en el que los procesadores virtuales podrían ser CPUs reales. Al principio, el nú­ mero de procesadores virtuales asignados a un proceso es uno, pero el proceso puede pedir más y también devolver procesadores que ya no necesite. El kemel también puede recuperar proce­ sadores virtuales ya asignados para asignarlos a otros procesos más necesitados. La idea fundamental que hace que este esquema funcione es que cuando el kemel sabe que un subproceso se ha bloqueado (por ejemplo, porque ejecutó una llamada bloqueadora al sis­ tema o causó un fallo de página), lo notifica al sistema de tiempo de ejecución del proceso, pa­ sándole como parámetros de la pila el número del subproceso en cuestión y una descripción del suceso. La notificación consiste en que el kemel activa el sistema de tiempo de ejecución en una dirección de inicio conocida, algo parecido al uso de señales en UNIX. Este mecanis­ mo se denomina llamada directa (upcall). Una vez activado, el sistema de tiempo de ejecución puede recalendarizar sus subprocesos, casi siempre marcando el actual como bloqueado, tomando otro subproceso listo, preparando sus registros y reiniciándolo. Más adelante, cuando el kemel se entere de que el subproceso ori­ ginal puede continuar su ejecución (por ejemplo, porque la canalización de la que estaba tra­ tando de leer ya contiene datos, o porque la página que necesitaba ya se trajo del disco), emitirá otra llamada directa al sistema de tiempo de ejecución para informarle del suceso. El sistema de tiempo de ejecución, a criterio suyo, puede reiniciar de inmediato el subproceso bloqueado, o bien, marcarlo como listo para que se ejecute después. Si se presenta una interrupción de hardware mientras se está ejecutando un subproceso de usuario, la CPU interrumpida cambia a modo de kemel. Si la interrupción se debió a un suce­ so que no interesa al proceso interrumpido, digamos que terminó ia E/S de otro proceso, cuan­ do el manejador de interrupciones termine, colocará el subproceso interrumpido otra vez en el estado en que estaba antes de la interrupción. En cambio, si la interrupción interesa al proceso (por ejemplo, la llegada de una página que uno de los subprocesos del proceso necesitaba), no se reiniciará el subproceso interrumpido; en vez de ello, se suspenderá y se iniciará el sistema de tiempo de ejecución en esa CPU virtual, con el estado dei subproceso interrumpido en la pi­ la. Entonces corresponderá al sistema de tiempo de ejecución decidir cuál subproceso calenda- rizará en esa CPU: el interrumpido, el que recién está listo o algún otro. Una objeción a las activaciones del calendarizador es la dependencia fundamental de las llamadas directas, concepto que viola la estructura inherente a cualquier sistema de capas. Por lo general, la capa n ofrece ciertos servicios que la capa n + 1 puede solicitar, pero la capa n no puede invocar procedimientos de la capa n-¥\ . Las llamadas directas no obedecen este prin­ cipio fundamental.