Planificación de procesos

Cuando hay más de un proceso ejecutable, el sistema operativo debe decidir cual ejecutara primero. La parte
del sistema operativo que toma esta decisión se denomina planificador; el algoritmo que usa se denomina algoritmo
de planificación.
En la época de los sistemas por lote, el algoritmo planificador era sencillo, simplemente se ejecutaba el
trabajo en la cinta. En los sistemas de tiempo compartido, el algoritmo de planificación es más complejo, pues es
comunique haya varios procesos iniciados por el usuario compartiendo la CPU.
Antes de examinar los algoritmos, debemos pesar en que está tratando de lograr. Algunos criterios son:
1. Equitativita. Cada proceso recibe una parte justa del tiempo de CPU.
2. Eficiencia. Mantener la CPU ocupada todo el tiempo.
3. Tiempo de respuesta. Minimizar el tiempo de respuesta para usuarios.
4. Retorno. Minimizar el tiempo de espera por salidas.
5. Volumen de producción. Maximizar el número de trabajos.

Puede ser que estos criterios sean un poco contradictorios. Sin embargo después de todo, la cantidad de
tiempo que dispone la CPU es finita. Para darle más a un usuario tenemos que darle menos a otro.
Una complicación que enfrentan los planificadores es que cada proceso es único e impredecible. Algunos
dedican el tiempo a esperar entrada-salida de archivos, mientras otros usarían la CPU durante horas si se les
permitiera, pero nunca se sabe con certeza cuando tiempo pasara antes de terminar y ejecutar un proceso.
Para asegurarse que ningún proceso se ejecute durante mucho tiempo, casi todas las computadoras tienen
incorporado un cronometro o reloj electrónico que genera interrupciones periódicamente. Es común que la frecuencia
sea de 50 o 60 interrupciones por segundo (50 o 60 Hertz-Hz). Esta estrategia se denomina planificación
expropiativa y contrasta con el método de ejecución hasta terminar de los primeros sistemas por lotes. La ejecución
hasta terminar también se denomina planificación no expropiativa. [BO]

Planificación round robin (de torneo)

Es uno de los más antiguos, sencillos, equitativos y ampliamente utilizados. A cada proceso se le asigna un
intervalo de tiempo llamando cuanto, durante el cual se le permite ejecutarse. Si el proceso todavía se está ejecutando
al expirar su cuanto, el SO se apropia de la CPU y se la da a otro proceso. Si el proceso se bloquea o termina antes de
expirar l cuanto, la comunicación del CPU se efectúa cuando el proceso se bloquee.
Todo lo que el planificador tiene que hacer es mantener una lista de procesos ejecutables. Cuando un
proceso gasta su cuanto se le coloca hasta el final de la lista.
La conmutación de un proceso a otro requiere cierto tiempo para llevar a cabo las tareas administrativas:
guardar y cargar registros y mapas de memoria, actualizar diversas tablas y listas, etc. Supongamos que esta
conmutación de proceso o conmutación de contexto requiere 5ms y que usamos cuantos de 20ms; después de realizar
trabajo útil durante 20ms, la CPU tendrá que ocupar 5ms en la conmutación de procesos que nos llevara a un
desperdicio del 20% del tiempo de CPU en gastos administrativos.
A fin de mejorar la eficiencia podríamos usar cuantos de 500ms consiguiendo un tiempo de desperdicio de
menos del 1%, pero si 10 usuarios interactivos pulsan una tecla de retorno de carro al mismo tiempo: diez procesos
se pondrían en lista. El primero iniciaría de inmediato, el segundo podría no iniciarse hasta dentro de medio segundo
y así sucesivamente. El último proceso tendría que esperar 5 segundos antes de tener su oportunidad, teniendo así
para cualquier usuario un retardo de 5 segundos lo cual sería terrible.
En conclusión, escoger un cuanto demasiado corto causa demasiadas conmutaciones y reduce la eficiencia;
pero escogerlo demasiado largo puede dar pie a una respuesta deficiente a solicitudes cortas. Un cuanto suele ser de
100ms como término medio razonable. [BO]

Planificación por prioridad.

En round robin se supone que todos los procesos son igualmente importantes. La necesidad de tener en
cuenta factores externos da pie a la planificación por prioridad. La idea es: a cada proceso se le asigna una prioridad
y se permite que se ejecute el proceso que tenga la prioridad más alta.
A fin de evitar que los procesos de alta prioridad se ejecuten indefinidamente, el planificador puede reducir
la prioridad de los procesos que actualmente se ejecutan en cada tic de reloj. Si esta acción hace que la prioridad se
vuelva menor que la del siguiente proceso, ocurrirá una conmutación. Como alternativa se podría asignar a cada
proceso un cuanto máximo en el que se le permitiera tener la CPU continuamente; cuando se agota este cuanto, se
da la oportunidad al proceso siguiente con prioridad más alta.
Las prioridades pueden ser estáticas o dinámicas. El sistema UNIX tiene un comando (nice) que permite a
un usuario reducir voluntariamente la prioridad de su proceso, con objeto de ser amable con los demás usuarios.
El sistema también puede asignar prioridades dinámicamente a fin de lograr ciertos objetivos del sistema.
Un proceso que uso solo 2ms de su cuanto de 100ms recibirá una prioridad de 5, en cuanto que un proceso se ejecutó
50ms antes de bloquearse obtendrá una prioridad de 2 y uno que ocupo todo su cuanto obtendrá una prioridad de 1.
En muchos casos es conveniente agrupar los procesos en las clases de prioridad y usar planificación por
prioridad entre las clase pero planificación round robin dentro de cada clase.
El algoritmo de planificación es el siguiente: En tanto que haya procesos ejecutables en la clase de prioridad
4, se ejecutara cada uno durante un cuanto, con round robin, sin ocuparse de las clases de menor prioridad. Si la clase
de prioridad4 esta vacía, se ejecutan los procesos de la clase 3 con round robin. Si tanto la clase 4 como la 3 están
vacías, se ejecutan los procesos de clase 2 con round robin, etc. Si las prioridades no se ajustan ocasionalmente, las
clases de baja prioridad podrían morir de inanición. [BO]

Colas múltiples.
 Uno de los primeros planificadores por prioridad se incluyó en CTSS (Compatible Time-Sharing System,
fue uno de los primeros sistemas operativos de tiempo compartido), El cual tenía el problema de que la conmutación
de procesos era muy lenta porque la 7094 solo podía contener un proceso en la memoria. Los diseñadores de CTSS
se dieron cuenta que resultaba más eficiente dar a los procesos limitados por CPU un cuanto largo de vez en cuando
en lugar de darles cuantos pequeños muy a menudo. Dar a los procesos un cuanto largo implicaría u tiempo de
respuesta deficiente. Su solución consistió en establecer clase e prioridad. Los procesos de la clase más alta se
ejecutaban durante un cuento. Los de la siguiente se ejecutaban durante cuatro cuanto y así sucesivamente. Cada que
un proceso agotaba todos los cuantos asignados, se le degradaba una clase.
Se adoptó la siguiente política para evitar que un proceso que en el momento de iniciarse necesita ejecutarse
durante un tiempo largo paro posteriormente se vuelve interactivo fuera castigado indefinidamente. Cada vez que en
una terminal se pulsaba el retorno de carro, el procedimiento perteneciente a esa terminal se pasaba a la clase de más
alta prioridad, bajo el supuesto de que estaba a punto de volverse inactivo.
Se han utilizado muchos otros algoritmos para signar procesos a clases de prioridad, por ejemplo el sistema
XDS 940, el cual tenía cuatro clases de prioridad llamadas terminal, E/S, cuanto corto y cuanto largo. Cuando un
proceso que estaba esperando entradas de la terminal finalmente se despertaba, pasaba a la clase de prioridad más
alta (Terminal). Cuando un proceso que estaba esperando un bloque de disco quedaba listo, pasaba a la segunda
clase, etc. Muchos otros sistemas usan algo similar para dar preferencia a los usuarios y procesos interactivos por
encima de los de segundo plano. [BO]