1

Algoritmo de Planificación

Un algoritmo de planificación es un conjunto de políticas y

mecanismos incorporados al sistema operativo, a través de un

módulo denominado planificador, que debe decidir cuál de los

procesos en condiciones de ser ejecutado conviene ser despachado

primero y qué orden de ejecución debe seguirse. Esto debe

realizarse sin perder de vista su principal objetivo que consiste en el

máximo aprovechamiento del sistema, lo que implica proveer un

buen servicio a los procesos existentes en un momento dado. Un

"buen" servicio podría traducirse en tiempo de respuesta aceptable,

productividad y eficiencia del procesador.

Estos algoritmos de planificación se dividen en dos tipos:

No preemptive scheduling (apropiativo): Una vez que el

proceso pasa al estado de ejecución, continúa ejecutando

hasta que termina, se bloquean en espera de una E/S o al

solicitar algún servicio del sistema.

Preemptive scheduling (no apropiativo): Generalmente

conocida como política de planificación por torneo. El proceso

que se está ejecutando actualmente puede ser interrumpido y

pasado al estado de listos por el sistema operativo.

2

Requisitos de un buen Algoritmo de Planificación

El planificador es el módulo del sistema operativo que decide

qué proceso se debe ejecutar, para ello usa un algoritmo de

planificación que debe cumplir con los siguientes objetivos:

Imparcialidad.

Política justa.

Eficiencia: mantener la CPU ocupada en lo posible el mayor

tiempo con procesos de usuario.

Minimizar el tiempo de espera de usuarios.

Maximizar el número de procesos ejecutados. (Rendimiento:

trabajos que se procesan por hora).

Tiempo de respuesta excelente (por ejemplo: minimizar el

tiempo de respuesta para los usuarios interactivos).

Predictibilidad en la ejecución.

Equilibrio en el uso de los recursos.

Planificación de lista de espera múltiple

Uno de los primeros planificadores con prioridad era el de

CTSS (Corbato et ai, 1962). CTSS tenía el problema de que la

alternancia entre procesos era muy lenta, puesto que la 7094 sólo

podía mantener un proceso dentro de la memoria. Cada alternancia

representaba un intercambio: el envío del proceso activo al disco y

la lectura en el disco de un nuevo proceso. Los diseñadores de CTSS

se dieron cuenta de que era más eficaz dar de una vez a los

procesos con limitaciones de CPU un quantum más grande, que

3

darles pequeños quanta con frecuencia (para reducir el

intercambio).

Por otro lado, si se les daba a los procesos un quantum muy

grande se tendría un tiempo de respuesta pobre, como ya hemos

visto. La solución fue el establecimiento de clases de prioridad. Los

procesos en la clase de mayor prioridad se ejecutaban en un

quantum. Los procesos de la siguiente clase se ejecutaban en dos

quanta, los de la siguiente clase en cuatro quanta, etc. Cuando un

proceso consumiera todos los quanta asignados a él, se le movía a

la siguiente clase.

Algoritmo de

planificación con

cuatro clases de

prioridades

Por ejemplo, si un proceso necesitaba hacer cálculos en forma

continua para 100 quanta, primero se tendría un quantum y un

primer intercambio. A continuación se consideraban dos quanta,

antes del siguiente intercambio. En las ejecuciones subsecuentes se

tenían 4, 8, 16, 32 y 64 quanta, aunque sólo hubiese utilizado 37 de

los últimos 64 quanta para terminar su trabajo. Sólo eran

necesarios 7 intercambios (incluida la carga final) en lugar de los

100 correspondientes a un algoritmo puro de round robin. Además,

4

al avanzar en las colas de prioridad, el proceso se ejecutaría cada

vez con menor frecuencia, lo que representa un ahorro de tiempo

de CPU para los procesos interactivos cortos.

Se adoptó la siguiente política para evitar que un proceso que

requería una ejecución larga al iniciar, pero que posteriormente

funcionara en forma interactiva, fuera penalizado para siempre.

Siempre que se escribiera un retorno de carro (Enter) en una

terminal, el proceso asociado a dicha terminal pasaba a la clase de

máxima prioridad, partiendo de la hipótesis de que se convertía en

interactivo. Cierto día, algún usuario, con un proceso con serias

limitaciones de uso de la CPU, descubrió que al sentarse frente a la

terminal y escribir retornos de carro en forma aleatoria durante

varios se gundos pudo lograr maravillas con su tiempo de

respuesta. Se lo dijo a sus amigos. Moraleja: hacer lo correcto en la

práctica es mucho más difícil que hacer lo correcto en principio.

Se han utilizado muchos otros algoritmos para la asignación

de procesos a clases de prioridad. Por ejemplo, el XDS 940

(Lampson, 1968), sistema construido en Berkeley y que ejerció una

gran influencia, tenía cuatro clases de prioridad, llamadas terminal,

E/S, quantum corto y quantum largo. Cuando un proceso en espera

de una entrada de terminal despertaba, pasaba a la clase de

máxima prioridad (terminal). Cuando un proceso en espera de un

bloque de disco estuviera listo, pasaba a la segunda clase. Cuando

un proceso en ejecución agotaba su quantum, se le colocaba en

primera instancia en la tercera clase. Sin embargo, si un proceso

agotaba su quantum demasiadas veces seguidas sin bloqueo de

5

terminal o E/S, pasaba a la cola inferior. Muchos otros sistemas

utilizan algo similar para favorecer a los usuarios interactivos.

Planificación conducida por política

Hasta ahora, hemos supuesto en forma tácita que todos los

procesos en el sistema pertenecen a diversos usuarios y que, por

tanto, compiten por la CPU. Aunque esto es muy frecuente, a veces

ocurre que un proceso tiene muchos hijos ejecutándose bajo su

control. Por ejemplo, un proceso en un sistema de administración

de una base de datos podría tener muchos hijos. Cada hijo podría

trabajar una solicitud distinta, o bien cada uno podría desarrollar

cierta función específica (análisis de interrogantes, acceso a disco,

etc.) Es completamente posible que el proceso principal tenga una

idea excelente de cuáles de sus hijos son los más importantes (o

críticos respecto al tiempo) y cuáles los menos. Por desgracia,

ninguno de los planificadores analizados antes acepta datos de los

procesos del usuario relativos a decisiones de planificación. Como

resultado, el planificador pocas veces hace la mejor elección.

La solución a este problema es separar el mecanismo de

planificación de la política de planificación. Lo que esto quiere decir

es que el algoritmo de planificación queda parametrizado de alguna

manera, pero los parámetros pueden ser determinados por medio

de procesos del usuario. Consideremos de nuevo el ejemplo de la

base de datos. Supongamos que el núcleo utiliza un algoritmo de

planificación, pero que proporciona una llamada al sistema por

medio de la cual un proceso puede establecer (y modificar) la

prioridad de sus hijos. De esta forma, el padre puede controlar con

6

detalle la forma de planificar sus hijos, incluso aunque él mismo no

realice la planificación. En este caso, el mecanismo está en el

núcleo pero la política queda establecida por un proceso del

usuario.

7

Recomendaciones

1. Hay que tener en cuenta que los algoritmos de planificación

tienen poca aplicación práctica, debido a que los procesos

raramente saben la cantidad máxima de recursos que van a

utilizar, previendo esto, hay que evitar la ejecución de

muchos procesos para no sobresaturar el algoritmo, y evitar

errores, pérdida de datos, entre otros.

2. El número de procesos en un algoritmo de planificación,

nunca son fijos, siempre tienen que adaptarse a la llegada de

nuevos procesos a la lista. Por lo tanto, esto puede afectar el

tiempo total de ejecución de ciertos procesos, a no ser que los

mismos estén afectados por prioridades.

3. La planificación siempre se lleva en cuatro niveles, los

primeros tres, son definidos por el sistema operativo,

mientras que el último, el cuarto, es llevado a cabo por el

usuario, por tanto siempre hay que estar atentos a factores

externos que afecten a la ejecución de procesos, cuando

estos piden el uso de dispositivos de E/S.

4. Hay que tener en cuenta que los algoritmos de planificación

del tipo apropiativo, en realidad, no ayudan en el

aprovechamiento total del sistema, y el tiempo de respuesta,

debido a que, cuando un proceso muy largo entra en

ejecución, impide la ejecución de otros que quizá sean más

cortos, hasta que este termine su ejecución

8