Sistemas operativos modernos

poniendo otra vez un tiempo de cambio de contexto de 1 ms, un subproceso giraría durante 2 ms como máximo, pero observaría cuánto tiempo estuvo dando vueltas en verdad. Si no logra obtener el bloqueo y observa que en las tres ejecuciones anteriores esperó 200 ns en promedio, deberá girar durante 2 ms antes de cambiar de contexto. En cambio, si observa que giró duran­ te los 2 ms completos en cada uno de los intentos anteriores, deberá cambiar de contexto de inmediato, y no girar. Puede encontrar más detalles en Karlin et al. (1991). 8.1.4 Calendarización de multiprocesadores En un uniprocesador, la calendarización es unidimensional. La única pregunta que debe contes­ tarse (una y otra vez) es: “¿Cuál proceso debe ejecutarse a continuación?” En un multiprocesa­ dor la calendarización es bidimensional. El calendarizador debe decidir cuál proceso ejecutará y en cuál CPU lo hará. Esta dimensión adicional complica de manera considerable la calenda­ rización en multiprocesadores. Otra complicación es que, en algunos sistemas, los procesos no están relacionados entre sí, pero en otros vienen en grupos. Un ejemplo de la primera situación es un sistema de tiempo compartido en el que usuarios independientes inician procesos independientes. Los procesos no están relacionados y cada uno puede calendarizarse sin tomar en cuenta los otros. Un ejemplo de la segunda situación se presenta a menudo en los entornos de desarrollo de programas. Muchos sistemas grandes consisten en cierto número de archivos de encabezado que contienen macros, definiciones de tipo y declaraciones de variables que son ufilizados por los ar­ chivos de código propiamente dichos. Cuando se modifica un archivo de encabezado, es necesa­ rio recompilar todos los archivos de código que lo incluyen. Es común utilizar el programa make para administrar el desarrollo. Cuando se invoca, make inicia la compilación sólo de aquellos ar­ chivos de código que deben recompilarse debido a que los archivos de encabezado o de código sufrieron modificaciones. Los archivos objeto que siguen siendo válidos no se regeneran. La versión original de make trabajaba de manera secuencial, pero las versiones más nue­ vas diseñadas para multiprocesadores pueden iniciar todas las compilaciones al mismo fiempo. Si se necesitan 10 compilaciones, no fiene senfido calendarizar nueve de ellas rápido y dejar la úlfima para mucho después, porque el usuario no considerará que el trabajo está terminado en tanto no termine la última compilación. En este caso, tiene senfido manejar los procesos como un grupo y tomarlo en cuenta al calendarizarlos. Tiempo compartido Abordemos primero el caso de calendarizar procesos independientes; después consideraremos la calendarización de procesos relacionados. El algoritmo de calendarización más sencillo para manejar procesos (o subprocesos) no relacionados es tener una sola estructura de datos en todo el sistema para los procesos fistos, tal vez una lista, pero lo más seguro es que sea un conjunto de listas según la prioridad de los procesos, como se muestra en la figura 8-12a. Aquí las 16 CPUs están ocupadas por el momento, y un conjunto de 14 procesos, clasificados según su prio­ ridad, está esperando para ejecutarse. La primera CPU en terminar su trabajo actual (o cuyo pro­ ceso es el primero en bloquearse) es la 4, que entonces bloquea las colas de calendarización y