Planificación

 

Los servicios de planificación incorporados en Off permiten la realización en área de usuario de diversos algoritmos de planificación (al igual que ocurre en otros sistemas como Aegis [60] y Fluke [71]). A diferencia de lo que ocurre en estos otros sistemas, es posible tratar la red entera como si de un multiprocesador se tratase.

Esquemas novedosos como los utilizados en Scout [85] donde la comunicación dicta la planificación (cómo en sistemas multimedia que requieren de transmisión de vídeo y audio y, por tanto, deben satisfacer ciertas restricciones temporales) son posibles ahora sin necesidad de ser aplicados a la totalidad de las aplicaciones. Téngase en cuenta que los procesadores en Off se limitan a repartir quanta entre las aplicaciones, con lo que es factible que distintas aplicaciones empleen ``planificadores'' distintos mediante el empleo de un sistema de planificación jerárquica (el kernel reparte quanta, que asigna un planificador de primer nivel entre diversos planificadores de segundo nivel, éstos a su vez reparten los quanta que tienen asignados, etc.) Esto abre nuevos caminos y la posibilidad de experimentar con técnicas de planificación destinadas a la consecución de SSOO distribuidos con soporte para multimedia [119].

En Off, cada procesador tiene asociado un vector de identificadores de shuttle. Dicho vector puede ser (re)instalado en cualquier momento y representa los quanta de procesador del procesador en que está ubicado. Cada uno de los elementos del vector (quantum) es susceptible de asignación ante peticiones procedentes de las aplicaciones. El esquema completo puede verse en la figura 3.15.

  
Figure: Vectores de ejecución en los procesadores de Off.

En el ejemplo que aparece en la figura 3.15 hay tres procesadores P1, P2, P3 y siete shuttles (1...7). Cada procesador ejecutará cíclicamente los elementos no vacíos del vector asociado runq. Los elementos vacíos pueden asignarse en demanda y, naturalmente, una vez lleno el vector futuras peticiones de asignación darán lugar a un evento de revocación disparado por el sistema (tal y como se dijo en el capítulo anterior).

Como puede apreciarse, no hay inconveniente en situar un mismo shuttle (en la figura 3.15, el shuttle 3) en el vector de ejecución de varios procesadores. Ahora bien, dado que un shuttle representa el estado de un procesador (aunque virtualizado con extensiones), no es razonable que ejecute simultáneamente en más de un procesador. Para evitarlo, cada shuttle tiene un flag que se activa cuando un procesador lo carga para ejecución y se desactiva cuando el shuttle abandona dicho procesador. Los shuttles que poseen dicho flag activado se ignoran a la hora de su consideración para ejecución. De este modo es factible incluir dicho shuttle en más de un procesador y si, por error, se requiriese su ejecución simultánea en distintos procesadores, ésta puede evitarse.

Este modelo de planificación --el reparto de intervalos de tiempo de procesador-- es un modelo simple que permite la implementación en área de usuario del esquema de planificación escogido. Como prueba basta considerar que el exokernel Aegis (que tiene una planificación semejante, para un sistema centralizado) soporta los esquemas de planificación empleados tradicionalmente (y otros experimentales). Dado que el modelo de planificación que hemos presentado es similar al de Aegis salvo por la distribución del sistema, cabe pensar que también soporta dichos esquemas de planificación.

Otra característica del modelo de planificación es que se incentiva la preplanificación. Ésto es, la instalación en la cola de ejecución (por parte del planificador que ejecuta sobre el kernel) de más de un shuttle. Si no sucede ningún suceso imprevisto por el planificador es factible efectuar varios cambios de contexto (agotar varias ranuras de procesador) sin que sea preciso emplear llamadas entre el kernel y el usuario. De no emplear preplanificación la sobrecarga introducida por las llamadas entre kernel y planificador sería intolerable en cuyo caso sería necesaria la inclusión del planificador dentro del kernel.

A modo de ejemplo, indicamos cómo pueden implementarse algunos esquemas de planificación bien conocidos:

• Ejecutivos cíclicos. Instalando un vector con un único shuttle se consigue evitar la expulsión del procesador. Dicho shuttle, que no ha de coincidir con los threads o tareas percibidas por los usuarios (como ocurre en sistemas como Solaris [81, 100] o Spring [84]) puede emplear un esquema de corrutinas para implementar el ejecutivo cíclico.
• Planificación estática. Basta con asignar a priori los elementos del vector. El quantum puede establecerse como el máximo común divisor de los tiempos de ejecución que aparecen en la tabla de planificación.
• Planificación con prioridades. Si se desea dar el control del procesador a un planificador que aplique un sistema de prioridades, basta con preasignar todos los quanta a dicho planificador. Posteriormente el planificador instalará en el vector aquellos identificadores de los shuttles que deban ejecutar.

  Alternativamente puede instalarse en el procesador el shuttle del planificador y hacer que el planificador por prioridades ceda su shuttle a las aplicaciones que deban ejecutar.

  Esquemas mixtos que combinen las dos implementaciones mencionadas también son posibles.