Planificación Por Lotería Sistemas Operativos

INTRODUCCION

La planificación de procesos es un área de exhaustiva investigación, su desarrollo ha llegado a ser muy determinante en cuanto a la flexibilidad y eficiencia de ejecución del proceso, los diversos tipos de planificaciones generalmente traen consigo cálculos que suelen entretener al procesador a dedicarse a desarrollar los procesos, esta doctrina de planificación puede desarrollar por igual cada uno de los procesos, claro preocupándose también por los procesos que tienen mas tiempo de espera sin ser ejecutados y hasta por la prioridad.

Vale la pena un método de planificación que maximiza el tiempo de ejecución del procesador, y en el cual ninguno de los procesos puede morir de inanición.

Si bien hacer promesas a los usuarios y después complicarlas es una idea admirable, es difícil de implementar. Podemos usar otro algoritmo para obtener resultados igualmente predecibles con una implementación mucho más sencilla. El algoritmo se llama planificación por lotería (Waldspurger y Weihl, 1994).

La idea básica consiste en dar a los procesos boletos de lotería para los diversos recursos del sistema, como el tiempo de CPU: Cada vez que se hace necesario tomar una decisión de planificación, se escoge al azar un boleto de lotería, y el proceso poseedor de este boleto obtiene el recurso. Cuando se aplica a la planificación del tiempo de CPU, el sistema podría realizar una lotería 50 veces por segundo, concediendo a cada ganador 20ms de tiempo de CPU como premio.

Parafraseando a George Orwell, “todos los procesos son iguales, pero algunos son más iguales que otros”. Podemos dar más boletos a los procesos más importantes, a fin de aumentar sus posibilidades de ganar. Si hay 100 boletos pendientes, y un proceso tiene 20 de ellos, tendrá una posibilidad del 20% de ganar cada lotería. A largo plazo, obtendrá cerca del 20% del tiempo de CPU. En contraste con los planificadores por prioridad, donde es muy difícil establecer qué significa realmente tener una prioridad de 40, aquí la regla es clara: un proceso posee una fracción f de los boletos obtendrá aproximadamente una f del recurso en gestión.

La planificación por lotería tiene varias propiedades interesantes. Por ejemplo, si aparece un proceso nuevo y se le conceden algunos boletos, en la siguiente lotería ya tendrá una probabilidad de ganar que será proporcional al número de boletos que recibió. En otras palabras, la planificación por lotería es de respuesta muy rápida.

MARCO TEORICO

En un sistema de tiempo compartido monoprocesador, se pretende utilizar un algoritmo de planificación expulsor conocido como algoritmo de “la lotería”, cuyo funcionamiento se describe a continuación: cuando se crea un proceso se le asigna un número de papeletas en blanco. Por ejemplo, si hay 3 procesos preparados P1, P2 y P3, que cuentan respectivamente con 3, 1 y 5 papeletas, estarán ordenados en la cola como P3, P1 y P2. Cuando hay que elegir un nuevo proceso a planificar, el sistema realiza un sorteo generando un número aleatorio entre 1 y el número total de papeletas repartidas.

Tras el sorteo, encontraremos al ganador si contamos papeletas desde el principio de la cola de preparados. Por ejemplo, si sale ganadora la papeleta séptima, el ganador será el proceso P1.

El proceso ganador tomará control de la CPU hasta que se bloquee voluntariamente o el sistema le expulse porque haya consumido una porción de tiempo preestablecida. El sorteo se repite siempre que haya que elegir un nuevo proceso a planificar, teniendo en cuenta que, en cada sorteo, el número de procesos preparados puede ser distinto y por tanto, el número total de papeletas a considerar también.

Proporcionar a los procesos boletos de lotería para los diversos recursos del sistema (tiempo de CPU). Cada vez que sea necesario tomar una decisión de planificación se escoge al azar un boleto de lotería y el proceso que tiene el boleto obtiene el recurso.

En el caso de tiempo de CPU el sistema puede realizar un sorteo 50 veces por segundo, otorgando al ganador 20 ms de tiempo de CPU.

Debido a que unos procesos son mas importantes que otros, se les da mas boletos para aumentar sus posibilidades (tendrá una probabilidad de 20 % de ganar tendrá cerca del 20% del tiempo de CPU)

Si un proceso tiene una fracción de boletos, obtendrá una fracción del recurso en cuestión.

Si aparece un proceso nuevo se le conceden algunos boletos, en la siguiente vuelta ya tendrá la posibilidad de ganar (con una probabilidad proporcional al # de boletos que recibió).

COOPERACION ENTRE PROCESOS

Los procesos cooperativos pueden intercambiar boletos si así lo desean

EJEMPLO:

Si un proceso cliente envía un mensaje a un proceso servidor y luego se bloquea, puede regalarle sus boletos al servidor (aumentar sus probabilidades de ejecución inmediata).

Una vez que el servidor termina devuelve los boletos para que el cliente pueda ejecutarse otra vez.

Los procesos cooperativos pueden intercambiar boletos si así lo desean. Por ejemplo, si un proceso cliente envía un mensaje a un proceso servidor y luego ese bloque, puede regalarle todos sus boletos al servidor, a fin de incrementar la probabilidad de que el servidor se ejecute a continuación. Una vez que el servidor termina, devuelve los boletos para que el cliente pueda ejecutarse otra vez. De hecho, en ausencia de clientes los servidores no necesitan boletos.

En esta metodología de planificación el usuario es el que ingresa los procesos que es algo que el programa requiere necesariamente.

Luego, el microprocesador es otro actor que se encarga de sortear el tickets (sin realizar cálculos que no pueden ocuparle lo mínimo de tiempo) y, ejecutar el proceso, que por contener el ticket sorteado, es el que pasa a ejecutar. Claro que mientras se este ejecutando el proceso no se puede realizar el sorteo, a menos que si hubiera un proceso de entrada/salida, en ese caso el proceso que se estaba ejecutando es llevado nuevamente a la cola de listos (pues es expulsivo).

El sistema es el que asigna las papeletas a los procesos en cada ciclo de reloj beneficiando a los que estén más tiempo sin ejecutarse y a también

...