Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

PLANIFICACIN DE PROCESOS
En un ordenador multiprogramado es frecuente que en un momento dado haya mltiples
procesos compitiendo por el uso de la CPU al mismo tiempo. Esta situacin se da siempre que dos
o ms procesos estn simultnemente en el estado listo. Si slo hay una CPU disponible, es
necesario hacer una eleccin para determinar cul de esos procesos ser el siguiente que se
ejecute. La parte del sistema operativo que realiza esa eleccin se denomina el planificador
(scheduler), y el algoritmo que se utiliza para esa eleccin se denomina el algoritmo de
planificacin. El planificador intentara conseguir:

Equidad: garantizar que cada proceso obtiene su proporcin justa de CPU.

Eficacia: mantener ocupada la CPU el 100% del tiempo.

Tiempo de Respuesta: minimizar el tiempo de respuesta para los usuarios interactivos.

Tiempo de Regreso: minimizar el tiempo que deben esperar los usuarios por lotes para
obtener sus resultados.

Rendimiento: maximizar el nmero de tareas procesadas en un determinado tiempo.

Muchas veces sucede que no todos estos aspectos pueden ser cubiertos, sino que para uno se
cumpla deba dejar de cumplirse otro. Cualquier algoritmo de planificacin que favorezca a una
tarea afecta a otra.
Otra complicacin que enfrenta el planificador es que cada proceso es nico e impredecible, lo
que hace que algunos de los procesos utilizan gran cantidad de tiempo en espera de E/S mientras
que otros utilizan la CPU por mucho tiempo si tienen la oportunidad. Para garantizar que ningn
proceso se ejecute un tiempo excesivo, todas las computadoras tienen un cronometro o reloj
incluido, que provoca una interrupcin en forma peridica; esta frecuencia puede ser establecida
por el sistema operativo en cualquier valor que estime conveniente.
La estrategia de permitir que procesos ejecutables (desde el punto de vista lgico) sean
suspendidos en forma temporal se llama planificacin apropiativa, en contraste con el mtodo de
ejecucin hasta terminar de los primeros sistemas por lotes, tambin denominada planificacin
no apropiativa.
Como vimos un proceso puede ser suspendido en cualquier instante para ejecutar otro proceso,
lo que conduce a condiciones de competencia, para las que se utilizan mtodos diferentes, con el
objetivo de salvarlas (Semforos, Contadores de eventos, Monitores, Mensajes, etc.), esto hace
que los algoritmos de planificacin no apropiativa, sencillos y fciles de implantar, no sean
adecuados para sistemas de propsito general con varios usuarios en competencia.

CUANDO PLANIFICAR
Una cuestin clave relacionada con la planificacin es en qu momento realizar las decisiones de
planificacin. Resulta que hay una gran variedad de situaciones en las que es necesaria la
planificacin.

2. En segundo lugar, debe hacerse una decisin de planificacin cuando un proceso termina.
Ya que no puede seguirse ejecutando ese proceso (puesto que ya no existe), debe elegirse
a algn otro proceso de entre el conjunto de procesos listos. Si no hay ningn proceso
preparado, normalmente se ejecuta un proceso ocioso proporcionado por el sistema.
Prof.: Lic. Javier Ruiz Diaz

Pgina 1

1. En primer lugar, cuando se crea un nuevo proceso, se necesita decidir si se ejecuta el

proceso padre o el proceso hijo. Ya que ambos procesos estn en el estado listo, se trata
de una decisin de planificacin normal y puede hacerse de cualquiera de las dos
maneras, esto es, el planificador puede legtimamente elegir ejecutar a continuacin bien
el padre, o bien el hijo.

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

3. En tercer lugar, cuando un proceso se bloquea en E/S, sobre un semforo, o por alguna
otra razn, es necesario seleccionar algn otro proceso para ejecutarlo. A veces el motivo
del bloqueo puede jugar algn papel en la eleccin.
Por ejemplo:
Si A es un proceso importante y est esperando a que B salga de su regin crtica, el dejar
que B se ejecute a continuacin puede permitir que salga de su regin crtica, haciendo
posible que A pueda continuar. Sin embargo, el problema es que generalmente el
planificador no cuenta con la informacin necesaria para poder tomar en cuenta esta
dependencia entre los procesos.
4. En cuarto lugar, cuando tiene lugar una interrupcin debida a una E/S, tambin es
necesario tomar una decisin de planificacin. Si la interrupcin proviene de un
dispositivo de E/S que ha completado ahora su trabajo, entonces algn proceso que
estaba bloqueado esperando por la E/S puede ahora estar preparado para ejecutarse.
Corresponde al planificador decidir si debe ejecutarse el nuevo proceso listo, si debe
continuar ejecutndose el proceso en ejecucin en el momento de la interrupcin, o si
debe ejecutarse algn tercer proceso.
Si un reloj de hardware proporciona interrupciones peridicas a 50 Hz, 60 Hz, o a alguna otra
frecuenta, puede tomarse una decisin de planificacin en cada interrupcin de reloj o en cada
k-sima interrupcin de reloj.
Los algoritmos de planificacin pueden dividirse en dos categoras si tenemos en cuenta cmo se
comportan ante las interrupciones de reloj.

Un algoritmo de planificacin no expulsor (nonpreemptive) escoge un proceso para

ejecutar dejndole que se ejecute hasta que se bloquee (bien debido a una E/S o
esperando por otro proceso) o hasta que el proceso ceda voluntariamente la CPU. Incluso
si el proceso se ejecuta durante horas, el sistema nunca forzar que el proceso se
suspenda. Por tanto, durante las interrupciones del reloj nunca se toma ninguna decisin
de planificacin. Despus de terminado el procesamiento de la interrupcin del reloj,
siempre se retoma para su ejecucin al mismo proceso que estaba ejecutndose antes de
la interrupcin.

En contraste, un algoritmo de planificacin expulsor (preemptive) escoge un proceso y

permite que se ejecute durante un mximo de tiempo prefijado. Si el proceso est todava
ejecutndose al final de ese intervalo de tiempo, se le suspende y el planificador escoge
algn otro proceso para ejecutarse (si es que hay alguno disponible). Para que sea posible
una planificacin expulsora es necesario contar con una interrupcin de reloj que tenga
lugar al final del intervalo de tiempo para ceder el control de la CPU de nuevo al
planificador. Si no est disponible ningn reloj, la nica opcin posible es la planificacin
no expulsora.

CATEGORAS DE ALGORITMOS DE PLANIFICACIN

De forma nada sorprendente sucede que en entornos diferentes se necesitan algoritmos de
planificacin diferentes. Esto se debe a que cada rea de aplicacin (y cada tipo de sistema
operativo) tiene objetivos diferentes. En otras palabras, lo que el planificador debe optimizar no
es lo mismo en todos los sistemas. Es necesario distinguir aqu tres entornos:
1. Batch.
2. Interactivo.
Pgina 2

3. Tiempo Real.

Prof.: Lic. Javier Ruiz Diaz

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

En los sistemas en batch, no existen usuarios que estn esperando impacientemente por una
rpida respuesta ante sus terminales. En consecuencia, son aceptables los algoritmos no
expulsores, o los algoritmos expulsores con largos periodos de tiempo para cada proceso. Con este
enfoque se reduce el nmero de cambios de proceso, mejorando por tanto el rendimiento.
En un entorno con usuarios interactivos es indispensable que haya expulsiones para impedir que
un proceso acapare la CPU, negando cualquier servicio de la CPU a los dems. Incluso aunque
ningn proceso tenga intencin de ejecutarse eternamente, es posible que debido a un error en el
programa un proceso mantenga parados a todos los dems indefinidamente. La expulsin es
necesaria para impedir ese comportamiento.
En los sistemas con restricciones de tiempo real, por extrao que parezca, la expulsin es algunas
veces innecesaria debido a que los procesos saben que no pueden ejecutarse durante largos
periodos de tiempo y usualmente hacen su trabajo y rpidamente se bloquean. La diferencia con
los sistemas interactivos es que los sistemas en tiempo real slo ejecutan programas pensados
como parte de una misma aplicacin. Los sistemas interactivos por el contrario son sistemas de
propsito general y pueden ejecutar programas arbitrarios no cooperantes o incluso maliciosos.

OBJETIVOS DE LOS ALGORITMOS DE PLANIFICACIN

Al disear un algoritmo de planificacin es necesario tener alguna idea de qu es lo que debe
hacer un buen algoritmo de planificacin. Algunos objetivos dependen del entorno (sistema en
batch, interactivo o de tiempo real), pero hay tambin algunos otros objetivos que son deseables
en todos los casos.

Bajo cualquier circunstancia, es importante la justicia (fairness). Procesos similares deben

recibir servicios similares. Dar a un proceso mucho ms tiempo de CPU que a otro proceso
equivalente no es justo. Por supuesto, diferentes categoras de procesos pueden recibir un
trato muy diferente.
Ejemplo:
Pensemos en el control de seguridad y en el procesamiento de las nminas en un centro de
computacin de un reactor nuclear.

Algo que est relacionado con la justicia es el reforzamiento de las polticas del sistema. Si la
poltica local es que los procesos de control de la seguridad se ejecuten siempre que quieran
hacerlo, incluso si eso significa que las nminas se retrasen 30 segundos, el planificador tiene
que asegurar el cumplimiento de esta poltica.

Otro objetivo general es mantener ocupadas todas las partes del sistema siempre que sea
posible. Si la CPU y todos los dispositivos de E/S pueden mantenerse ocupados todo el
tiempo, se realizar ms trabajo por segundo que si alguno de los componentes est ocioso.
Por ejemplo:
En un sistema en batch el planificador tiene el control de qu trabajos estn cargados en
memoria para ejecutarse. Tener en memoria juntos algunos procesos intensivos en CPU y
algunos procesos intensivos en E/S es una idea mejor que primero cargar y ejecutar todos los
trabajos intensivos en CPU y a continuacin una vez que se hayan terminado, cargar y ejecutar
todos los trabajos intensivos en E/S.

Pgina 3

Si se utiliza la ltima estrategia, mientras se ejecutan los procesos intensivos en CPU, esos
procesos lucharn por conseguir la CPU y el disco permanecer ocioso. Luego, cuando se
carguen los trabajos intensivos en E/S, esos procesos lucharn por utilizar el disco y la CPU
permanecer ociosa.

Prof.: Lic. Javier Ruiz Diaz

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

Es por tanto preferible mantener en memoria una mezcla de procesos cuidadosamente

estudiada para conseguir que todo el sistema est funcionando a la vez.
Los administradores de grandes centros de clculo donde se ejecutan muchos trabajos
normalmente utilizan tres mtricas para estimar lo bueno que es el servicio ofrecido por sus
sistemas:
1. Rendimiento,
2. Tiempo de retorno
3. Utilizacin de la CPU
El rendimiento (throughput) es el nmero de trabajos por hora terminados por el sistema. A
igualdad de otros factores, terminar 50 trabajos por hora es mucho mejor que terminar 40
trabajos por hora.
El tiempo de retorno (turnaround time) es el tiempo medio estadstico que transcurre desde que
un trabajo en batch se introduce en el sistema hasta que se completa.
Mide por tanto cuanto tiempo tiene que esperar el usuario medio para obtener la salida de su
trabajo. La regla es aqu: lo pequeo es bello. Un algoritmo de planificacin que maximice el
rendimiento no tiene necesariamente porqu minimizar el tiempo de retorno.
Por ejemplo:
Dada una mezcla de trabajos cortos y trabajos largos, un planificador que ejecute siempre los
trabajos cortos y nunca los trabajos largos puede conseguir un rendimiento excelente (muchos
trabajos cortos por hora) pero a expensas de obtener un tiempo de retorno terriblemente malo
para los trabajos largos.
Si continuamente estn llegando trabajos cortos a una velocidad constante, es posible que los
trabajos largos nunca lleguen a ejecutarse, provocando que el tiempo de retorno medio se haga
infinito al tiempo que se consigue un alto rendimiento.
La utilizacin de la CPU es tambin una cuestin importante en los sistemas de batch debido a
que en los mainframes donde se ejecutan los sistemas de batch la CPU representa todava el
principal coste. Por tanto los administradores de los centros de clculo sienten remordimientos
cuando la CPU no est ejecutando trabajos durante todo el tiempo.
Sin embargo, realmente no se trata de una buena mtrica. Lo que realmente importa es cuntos
trabajos por hora salen del sistema (rendimiento) y cunto tiempo se requiere para que un
trabajo se nos devuelva terminado (tiempo de retorno).
Emplear como mtrica la utilizacin de la CPU es igual que hacer la valoracin de los coches
basndonos en el nmero de revoluciones por hora del motor.
Para los sistemas interactivos, especialmente los sistemas en tiempo compartido y los
servidores, se aplican diferentes objetivos a los ya vistos. El ms importante es minimizar el
tiempo de respuesta, es decir el tiempo entre que se introduce un comando y se obtiene el
resultado.

Por ejemplo: Si pinchando con el ratn sobre un icono que llama un proveedor de Internet
utilizando un mdem analgico se tarda 45 segundos en establecer la conexin, el usuario
Prof.: Lic. Javier Ruiz Diaz

Pgina 4

Una cuestin relacionada es lo que puede denominarse la proporcionalidad. Los usuarios tienen
una idea inherente (pero a menudo incorrecta) de cunto tiempo deben tardar las cosas. Cuando
una peticin que se percibe complicada tarda mucho tiempo, los usuarios lo aceptan sin
problemas, pero cuando una peticin que se percibe como sencilla tarda mucho tiempo, los
usuarios se irritan.

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

probablemente aceptar esto como una de esas cosas que tiene la vida. Por otro lado, si
pinchando con el ratn sobre un icono que cierra la conexin se tarda 45 segundos, el usuario
probablemente estar a los 30 segundos profiriendo maldiciones, para acabar a los 45 segundos
echando espuma por la boca.
Este comportamiento se debe a la percepcin del usuario comn de que realizar una llamada de
telfono y establecer una conexin se supone que tarda mucho ms tiempo que simplemente
colgar el telfono. En algunos casos (tales como este), el planificador no puede hacer nada para
mejorar el tiempo de respuesta, pero en otros casos s que puede, especialmente cuando la
tardanza se debe a una pobre eleccin del orden de los procesos.
Los sistemas en tiempo real tienen diferentes propiedades que los sistemas interactivos, y por
tanto diferentes objetivos de planificacin. Los sistemas en tiempo real se caracterizan por tener
lmites de tiempo que deben, o al menos deberan, cumplirse.
Por ejemplo:
Si un ordenador est controlando un dispositivo que produce datos a una velocidad constante,
cualquier retraso en la ejecucin del proceso que recoge los datos dentro del lmite de tiempo
establecido puede provocar la prdida de algunos datos.
Por lo tanto el objetivo primordial en un sistema de tiempo real es cumplir con todos (o la
mayora) de los lmites de tiempo especificados.
En algunos sistemas de tiempo real, especialmente en aquellos relacionados con la multimedia, es
muy importante la predecibilidad. El incumplimiento ocasional de algunos lmites de tiempo no
resulta fatal, pero si el proceso de audio se ejecuta demasiado errticamente, la calidad del
sonido puede deteriorarse rpidamente. Lo mismo sucede con el vdeo, pero el odo es mucho
ms sensible a las perturbaciones que el ojo. La planificacin de procesos debe ser altamente
predecible y regular para conseguir evitar este problema.
Algunos objetivos aparecen listados.

Sistemas de batch

Sistemas interactivos

Sistemas de tiempo real

Justicia dar a cada

proceso la parte de CPU
que le corresponde
Reforzamiento de la
poltica cuidar de que la
poltica establecida se
cumpla
Equilibrio mantener
todas las partes del
sistema ocupadas

Rendimiento maximizar
el nmero de trabajos
ejecutados por hora
Tiempo de retorno
minimizar el tiempo entre
la entrada y la conclusin
de un trabajo
Utilizacin de la CPU
mantener la CPU ocupada
todo el tiempo

Tiempo de respuesta
responder rpidamente
a las peticiones
Proporcionalidad
satisfacer las
expectativas de los
usuarios

Cumplir los lmites de

tiempo evitar la prdida
de datos
Predecibilidad evitar la
degradacin de la calidad
en sistemas multimedia

Pgina 5

Todos los sistemas

Prof.: Lic. Javier Ruiz Diaz

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

PLANIFICACIN EN SISTEMAS EN BATCH

Es ahora el momento de dejar las cuestiones de planificacin ms generales para tratar algoritmos
de planificacin especficos. Vamos a examinar los algoritmos utilizados en sistemas en batch.
Planificacion en Sistemas en Batch

Primero en Llegar
Primero en ser
Servido

Primero el Trabajo
ms Corto

Tiempo Restante ms
Corto a Continuacin

Planificacin a Tres
Niveles

PRIMERO EN LLEGAR PRIMERO EN SER SERVIDO (FIFO)

Probablemente el ms simple de todos los algoritmos de planificacin es el algoritmo no expulsor
primero en llegar primero en ser servido (abreviadamente FCFS del ingls First- Come FirstServed). Con este algoritmo, se asigna la CPU a los procesos respetando el orden en el que la han
solicitado. Bsicamente, existe una nica cola de procesos preparados. Cuando por la maana
entra en el sistema el primer trabajo procedente del exterior, se le concede la CPU
inmediatamente permitindosele que se ejecute durante todo el tiempo que quiera. A medida
que van llegando nuevos trabajos, se van metiendo al final de la cola.
Cuando el proceso en ejecucin se bloquea, se ejecuta a continuacin el primer proceso de la
cola. Cuando un proceso bloqueado pasa a preparado, se mete al final de la cola de preparados
como si fuera un trabajo recin llegado.
La gran ventaja de este algoritmo es que es fcil de entender e igualmente fcil de programar.
Tambin es justo en el mismo sentido que es justo que se asignen las ltimas entradas de un
partido o de un concierto a la gente que ha estado haciendo cola desde las 2 de la madrugada.
Con este algoritmo, una nica lista enlazada lleva la cuenta de todos los procesos preparados.
Escoger un proceso para su ejecucin requiere simplemente sacar un proceso del principio de la
cola. Aadir un nuevo trabajo o un proceso que se ha desbloqueado no requiere ms que
incorporarlo al final de la cola. Qu puede haber ms simple?
Desafortunadamente, este algoritmo tiene tambin una gran desventaja:
Supongamos que tenemos un proceso intensivo en CPU que se ejecuta en rfagas de 1 segundo, y
muchos procesos intensivos en E/S que utilizan poco tiempo de CPU pero requieren 1000 lecturas
del disco para completarse.
El proceso intensivo en CPU se ejecuta durante 1 segundo, para a continuacin leer un bloque del
disco. Ahora todos los procesos intensivos en E/S se ejecutan y ponen en marcha lecturas del
disco. Cuando el proceso intensivo en CPU obtiene su bloque del disco se ejecuta durante otro
segundo, seguido en rpida sucesin por todos los procesos intensivos en E/S.
El resultado neto es que cada proceso intensivo en E/S leer un bloque por segundo y requerir
1000 segundos para terminar.

Pgina 6

Sin embargo utilizando un algoritmo de planificacin que expulse al proceso intensivo en CPU
cada 10 milisegundos, los procesos intensivos en E/S podran terminar en 10 segundos en vez de
los 1000 segundos, y esto sin ralentizar demasiado el proceso intensivo en CPU.

Prof.: Lic. Javier Ruiz Diaz

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

PRIMERO EL TRABAJO MS CORTO

Vamos a fijarnos ahora en otro algoritmo no expulsor propio de sistemas en batch que asume que
los tiempos de ejecucin se conocen por anticipado.
Por ejemplo:
En una compaa de seguros es posible predecir con mucha precisin cuanto tiempo va a tardar en
ejecutarse un batch de 1000 reclamaciones, puesto que todos los das se realiza un trabajo similar.
Cuando estn esperando para comenzar su ejecucin varios trabajos de la misma importancia en
la cola de entrada, el planificador escoge primero el trabajo ms corto (abreviando SJF del ingls
Shortest Job First).
Cuando varios trabajos de igual importancia esperan en la lista de entrada para iniciar, el
planificador deber utilizar el criterio de ejecutar primero el trabajo ms corto.
Ejemplo:
Se tienen cuatro tareas A, B, C y D, cuyos tiempos de ejecucin son de 8, 4, 4, y 4 minutos
respectivamente (a). Al ejecutarlos en ese orden, el tiempo de regreso para A es de 8 minutos,
para B de 12, para C de 16 y para D de 20 minutos, con un promedio de 14 minutos.

(a)

(b)

Consideremos la ejecucin del trabajo ms corto en primer lugar (b), los tiempos de regreso son ahora 4, 8,
12 y 20 minutos, con un promedio de 11 minutos, se demuestra que este algoritmo es el optimo.

Consideremos el caso de cuatro trabajos, con tiempos de ejecucin de a, b, c y d,

respectivamente. El primer trabajo termina en el momento a, el segundo termina en el momento
a + b, y as los dems. El tiempo de retorno medio es por tanto (4a + 3b + 2c + d)/4. Es claro que a
contribuye ms a la media que los dems tiempos de ejecucin, por lo cual debe ser el trabajo
ms corto, con b a continuacin, luego c y finalmente d como el ms largo al afectar tan solo a su
propio tiempo de retorno.
Podemos aplicar igual de bien el mismo argumento a cualquier nmero de trabajos.
Es necesario sealar que el algoritmo del trabajo ms corto primero slo es ptimo cuando todos
los trabajos estn disponibles simultneamente.
Como contraejemplo:
Consideremos cinco trabajos, de A hasta E, con tiempos de ejecucin de 2, 4, 1, 1 y 1,
respectivamente. Sus tiempos de llegada son 0, 0, 3, 3 y 3. Inicialmente, slo podemos elegir a A o
a B, ya que los otros tres trabajos no han llegado todava.Utilizando el algoritmo del trabajo ms
corto primero ejecutaremos los trabajos en el orden A, B, C, D y E obteniendo una espera media de
4,6. Sin embargo si los ejecutamos en el orden B, C, D, E y A la espera media obtenida es de 4,4.

El algoritmo denominado tiempo restante ms corto a continuacin (shortest remaining time

next) es una versin expulsora del trabajo ms corto primero. Con este algoritmo, el planificador
elige siempre el proceso al cual le queda menos tiempo de ejecucin. Aqu tambin se requiere
conocer el tiempo de ejecucin por adelantado. Cuando llega un nuevo trabajo, se compara su
Prof.: Lic. Javier Ruiz Diaz

Pgina 7

TIEMPO RESTANTE MS CORTO A CONTINUACIN

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

tiempo total con el tiempo de ejecucin que le queda al proceso actual. Si el nuevo proceso
necesita menos tiempo para terminar que el proceso actual, el proceso actual se suspende,
arrancndose el nuevo trabajo. Este esquema permite que los nuevos procesos cortos reciban un
buen servicio.

PLANIFICACIN DE TRES NIVELES

Desde una cierta perspectiva, los sistemas en batch permiten planificar a tres niveles diferentes,
como se ilustra en la figura. Tan pronto como llegan los trabajos al sistema, se los coloca en un
primer momento en una cola de entrada residente en el disco.

CPU

Planificador de CPU
Trabajo
Entrante
Cola de Entrada

Disco

Memoria
Principal
Planificador
de
Admisin

Planificador
de
Memoria

Planificacin a tres niveles.

En el primer nivel de planificacin, el planificador de admisin decide qu trabajos se admiten
en el sistema. Los dems trabajos se quedan en la cola de entrada hasta que sean seleccionados.
Un algoritmo tpico de control de la admisin puede tener como objetivo obtener una mezcla
adecuada de trabajos intensivos en CPU y trabajos intensivos en E/S. De forma alternativa, el
objetivo puede ser que los trabajos cortos puedan ser admitidos rpidamente mientras que los
largos tengan que esperar.
El planificador de admisin es libre para dejar algunos trabajos en la cola de entrada y admitir
otros que llegan despus, a su criterio.
Una vez que un trabajo ha sido admitido en el sistema, es posible crear para l un proceso que
pueda competir por la CPU. Sin embargo, puede tambin ocurrir que el nmero de procesos sea
tan grande que no exista suficiente espacio para todos ellos en la memoria. En este caso, algunos
de los procesos tienen que salir de la memoria guardndose en el rea de intercambio del disco.
El segundo nivel de planificacin consiste en decidir qu procesos deben mantenerse en
memoria y qu procesos deben mantenerse en el disco.
Vamos a llamar a este planificador el planificador de memoria, ya que determina qu procesos
van a estar en memoria y qu procesos van a estar en el disco.

Sin embargo, probablemente esta revisin no debe de realizarse ms de una vez por segundo, o
incluso menos, ya que cargar un proceso desde el disco resulta muy costoso.
Prof.: Lic. Javier Ruiz Diaz

Pgina 8

Esta decisin debe revisarse frecuentemente para permitir a los procesos que estn en el disco
recibir algn servicio.

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

Si los contenidos de la memoria principal se transvasan de memoria al disco y del disco a

memoria demasiado a menudo, se estar gastando una gran cantidad de ancho de banda del
disco, ralentizando la E/S de ficheros.
Para optimizar el rendimiento del sistema en conjunto, el planificador de memoria debe decidir
cuidadosamente cuantos procesos desea que residan en memoria, lo que se denomina el grado
de multiprogramacin, y qu tipo de procesos.
Si tiene informacin sobre qu procesos son intensivos en CPU y cules son intensivos en E/S,
puede tratar de mantener una mezcla adecuada de esos tipos de procesos en memoria.
Ejemplo: Si una cierta clase de proceso realiza clculos durante el 20% del tiempo, mantener en
torno a cinco de esos procesos en memoria es un nmero adecuado para tener a la CPU
completamente ocupada.
Para tomar sus decisiones, el planificador de memoria inspecciona peridicamente cada proceso
en el disco para decidir si lo carga o no en memoria.
Entre los criterios que puede utilizar para tomar esa decisin estn los siguientes:
1.

Cunto tiempo ha pasado desde que el proceso se intercambi al disco?

2.

Cunto tiempo de CPU ha tenido el proceso recientemente?

3.

Qu tan grande es el proceso? (Los procesos pequeos no son problema)

4.

Cun importante es el proceso? (Prioridad de un proceso)

El tercer nivel de planificacin consiste realmente en escoger uno de los procesos preparados
que hay en memoria para ejecutarlo a continuacin.
A menudo se le denomina el planificador de la CPU y es aqul en el que piensa toda la gente
cuando se habla del planificador. Aqu puede utilizarse cualquier algoritmo apropiado, bien
expulsor o no expulsor. Estos algoritmos incluyen los descritos anteriormente as como un
nmero de algoritmos que van a describirse en la siguiente seccin.

PLANIFICACIN EN SISTEMAS INTERACTIVOS

Vamos a ver ahora algunos algoritmos que pueden utilizarse en los sistemas interactivos. Todos
ellos pueden utilizarse tambin como planificadores de la CPU en sistemas en batch.

Pgina 9

Mientras que la planificacin a tres niveles no es posible aqu, s que es posible e incluso comn
una planificacin a dos niveles (planificador de memoria y planificador de la CPU). A continuacin
vamos a concentrarnos en el planificador de la CPU.

Prof.: Lic. Javier Ruiz Diaz

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

Planificacion en Sistemas Interactivos

Planificacin de Dos niveles
Planificacin por Prioridades
Colas Mltiples
Proceso ms Corto a Continuacin
Planificacion Garantizada
Planificacin por Lotera
Planificacin por Reparto Justo

PLANIFICACIN DE DOS NIVELES

Hemos supuesto de alguna manera que todos los procesos ejecutables se encuentran en la
memoria principal, pero si no se dispone de memoria suficiente ser necesario que algunos
procesos ejecutables se mantengan en el disco.
Esta situacin tiene importantes implicaciones para la planificacin, puesto que el tiempo de
alternancia entre procesos para traer y procesar un proceso del disco es considerablemente
mayor que el tiempo para un proceso que ya se encuentra en la memoria principal.
Para este tipo de situaciones, una forma ms prctica de trabajar con el intercambio de los
procesos es utilizar un planificador de dos niveles:
Planificador de nivel superior para los procesos que se encuentran en memoria.
Planificador de nivel inferior para los procesos que se encuentren en disco.

Eliminar de la memoria los procesos que hayan permanecido en ella el tiempo suficiente,

Cargar a memoria los procesos que hayan estado en disco demasiado tiempo.

Prof.: Lic. Javier Ruiz Diaz

Pgina 10

Primero se cambia en la memoria principal cierto subconjunto de procesos ejecutables (a). El

planificador se restringe entonces a ese subconjunto durante cierto tiempo, en forma peridica se
llama a un planificador de nivel superior para:

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

Una vez hecho el cambio (b), el planificador de nivel inferior se restringe de nuevo a los procesos
ejecutables que se encuentren en la memoria:

Se encarga de elegir de entre los procesos que estn en memoria en ese momento.

a, b,
c, d

Procesos en
la memoria
principal

e, f,
g, h

b, c,
f, g

e, f,
g, h

Procesos en
disco

a, b,
c, d

a, d,
e, h

(b)

(c)

(a)

Un planificador de dos niveles debe desplazar los procesos entre el disco y la memoria, adems de que debe
elegir los procesos por ejecutar de entre aquellos que se encuentran en la memoria.

PLANIFICACIN ROUND ROBIN

Vamos a ver ahora algunos algoritmos de planificacin especficos. Uno de los ms antiguos,
simples, justos y de uso ms extendido es round robin. A cada proceso se le asigna un intervalo de
tiempo, denominado su quantum (o tambin rodaja de CPU), durante el que se le permite
ejecutarse.
Este el mtodo ms antiguo, sencillo, justo y de uso ms amplio, cada proceso tiene asignado un
intervalo de tiempo de ejecucin, llamado su quantum; donde el procedimiento es de la forma:

Si el proceso continua en ejecucin finalizado su quantum, otro proceso se apropia de la

CPU.

Si el proceso est bloqueado o ha terminado antes de consumir su quantum, se alterna el

uso de la CPU ( por supuesto, si el proceso se ha bloqueado).

Este mtodo es fcil de implantar, todo lo que necesita el planificador es mantener una lista de
procesos ejecutables, cuando el quantum de un proceso se consume y este an no ha terminado
de ejecutarse, se le coloca al final de la lista, as lo demuestra el esquema representativo de la
figura.
Proceso activo

Siguiente

Proceso activo

(a)

(b)

Planificacin Round Robin. (a) la lista de los procesos ejecutables. (b) la lista de los procesos ejecutables
despus de agotarse el quantum B

Pgina 11

El nico aspecto a tener en cuenta es la longitud del quantum. La alternancia entre un proceso y
otro, alternancia de procesos o alternancia de contexto, necesita cierta cantidad de tiempo para
administracin (resguardo y carga de registros y mapas de memoria, actualizacin de varias tablas
y listas, etc.)

Prof.: Lic. Javier Ruiz Diaz

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

Ejemplo: Supongamos que la alternancia de procesos tarda 5 mseg y el quantum tiene una
longitud de 20 mseg Con estos parmetros, despus de llevar a cabo 20 mseg de trabajo til, la
CPU deber utilizar 5 mseg para alternar entre los procesos. 20 % del tiempo de CPU se
desperdicia en el costo administrativo.
Tiempo de alternancia de proceso Tap = 5 mseg
Tiempo de quantum Tq = 20 mseg
Tiempo de CPU Tcpu = Tap + Tq = 5 mseg + 20 mseg = 25 mseg

Tap = 5 % Tcpu

Para mejorar la eficacia de la CPU, podramos establecer una longitud de quantum de 500 mseg el
tiempo desperdiciado seria entonces del 1 %.
Tap = 5 mseg
Tq = 500 mseg
Tcpu = Tap + Tq = 5 mseg + 500 mseg = 505 mseg

Tap = 1 % Tcpu

El problema surge: si diez usuarios interactivos oprimen la tecla enter casi al mismo tiempo, diez
procesos se colocaran en la lista de ejecutables. Si la CPU est libre el primero de los procesos
comienza de inmediato, el segundo lo hara hasta segundo ms tarde, etc. El ltimo de los
procesos debera esperar 5 seg antes de poder ejecutarse, (suponiendo que los dems utilizan la
totalidad de su quantum).
Este tiempo es demasiado largo para los usuarios interactivos trabajando en lnea, adems
hablamos de solo diez usuarios, que es un nmero ms pequeo de lo que usualmente se tiene en
una red.
Si el quantum es muy corto se alternan demasiado los procesos, lo que reduce la eficacia de la
CPU; pero si es muy largo, esto puede causar una respuesta lenta a las solicitudes interactivas
breves. Un quantum cercano a los 100 mseg es con frecuencia un compromiso razonable.

PLANIFICACIN POR PRIORIDADES

La planificacin round robin supone tcitamente que todos los procesos son igualmente
importantes. Frecuentemente, la gente que posee y opera un ordenador multiusuario tiene ideas
muy diferentes al respecto.
Por ejemplo: En una universidad, la jerarqua puede ser primero los decanos, luego los profesores,
las secretarias, los conserjes y finalmente los estudiantes.
La necesidad de tener en cuenta factores externos conduce a la planificacin por prioridades. La
idea bsica es trivial: a cada proceso se le asigna una prioridad, y siempre es el proceso
ejecutable con mayor prioridad al que se le permite ejecutarse.
Incluso en un PC con un nico propietario, puede haber mltiples procesos, algunos ms
importantes que otros.
Por ejemplo: A un proceso demonio que enva el correo electrnico como proceso de fondo se le
puede asignar una menor prioridad que a un proceso que visualiza en tiempo real una pelcula de
vdeo en la pantalla.

Pgina 12

Para impedir que los procesos de mayor prioridad se ejecuten de manera indefinida, el
planificador podra hacer decrecer la prioridad del proceso que se est ejecutando en cada tic
del reloj (es decir, en cada interrupcin de reloj).

Prof.: Lic. Javier Ruiz Diaz

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

Si esta accin provoca que la prioridad descienda por debajo de la del siguiente proceso de mayor
prioridad, tendr lugar un cambio de proceso.
Alternativamente, se podra asignar a cada proceso un quantum de tiempo mximo durante el
cual puede ejecutarse. Una vez consumido ese quantum, el proceso con la siguiente prioridad
ms alta tendr la oportunidad de ejecutarse.
Las prioridades se pueden asignar en forma esttica, as pues en una computadora del ejrcito las
prioridades pueden estar asociadas al rango; o podra darse que en un centro de cmputos
comercial las prioridades se asocien al costo de los procesos.
Por ejemplo: En un ordenador militar, los procesos iniciados por los generales podran comenzar
con prioridad 100; los iniciados por coroneles, con 90; los de los comandantes con 80; los de los
capitanes con 70; los de los tenientes con 60, y as en forma sucesiva.
Alternativamente, en un centro de clculo comercial, los trabajos de alta prioridad podran costar
100 dlares la hora; los de mediana prioridad, 75 dlares la hora, y los de baja prioridad 50
dlares la hora.
Ejemplos:

USUARIO

PRIORIDAD

GENERAL

100

CORONEL

90

MAYOR

80

CAPITAN

70

TENIENTE

60

COSTO

PRIORIDAD

$ 100

ALTA

$ 75

MEDIA

$ 50

BAJA

Las prioridades tambin pueden ser asignadas en forma dinmica por el sistema con el fin de
lograr ciertas metas, esta es aplicada en los casos en que los tiempos de ejecucin de los procesos
son relativamente distintos uno de otro.
Por ejemplo: Algunos procesos estn completamente dedicados a hacer E/S y gastan la mayor
parte de su tiempo esperando a que terminen las operaciones de E/S. Cada vez que un proceso de
ese tipo quiera la CPU, debe concedrsela de inmediato para que pueda iniciar su siguiente
solicitud de E/S, la cual puede proceder en paralelo con otro proceso que s haga uso de la CPU.
Hacer que los procesos intensivos en E/S esperen mucho tiempo por la CPU slo consigue tenerlos
ocupando la memoria durante un tiempo innecesariamente largo.

Ejemplo: Un proceso que utiliz slo 1 milisegundo de su quantum de 50 milisegundos obtendra

una prioridad de 50, mientras que uno que se ejecut durante 25 milisegundos antes de

Prof.: Lic. Javier Ruiz Diaz

Pgina 13

Un algoritmo sencillo para dar un buen servicio a los procesos intensivos en E/S consiste en
asignarles como prioridad el valor 1/f, donde f es la fraccin del ltimo quantum que utiliz un
proceso.

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

bloquearse obtendra una prioridad de 2. Un proceso que consumi todo su quantum obtendra
una prioridad de 1.
Tiempo de quantum Tq = 100 mseg

Tiempo de proceso A TA = 2 mseg

100mseg/2mseg = 50

Prioridad P = 50

PROCESO

TIEMPO DE EJECUCION

PRIORIDAD

2 mseg

50

50 mseg

100 mseg

En muchos casos es conveniente agrupar los procesos en clases de prioridad y utilizar

planificacin por prioridades entre las clases, pero planificacin round-robin dentro de cada
clase.
La figura muestra un sistema con cuatro clases de prioridad. El algoritmo de planificacin es el
siguiente:
Mientras haya procesos ejecutables en la clase de prioridad 4, se ejecutar cada uno durante un
quantum, al modo round-robin, sin ocuparse de las clases de menor prioridad. Si la clase 4 est
vaca, se ejecutan los procesos de la clase 3 de forma round robin. Si las clase 4 y 3 estn ambas
vacas, se ejecuta la clase 2 de forma round robin, y as sucesivamente. Si no se realiza un ajuste
de las prioridades ocasionalmente, puede suceder que las clases de menor prioridad sufran de
inanicin hasta morir.
Encabezado
de la cola

Procesos ejecutables

Prioridad 1
(Mxima prioridad)

Prioridad 2
Prioridad 3
Prioridad 4

(Mnima prioridad)

Mientras existan procesos ejecutables en la clase 4, solo se ejecuta un proceso para cada quantum, en forma de Round
Robin. Si la clase 4 est vaca se ejecutan los procesos de la clase 3 con Round Robin. As sucesivamente hasta ejecutar
todas las clases.

COLAS MLTIPLES

Ejemplo: Si un proceso necesita hacer clculos en forma continua con una duracin estimada de
100 quanta, primero se tendra un quantum y un primer intercambio, a continuacin se consideran
dos quantum antes del siguiente intercambio. En las ejecuciones subsecuentes se tendran 4, 8, 16,
32 y 64 quanta, aunque solo se utilizan 37 de los ltimos 64 quantum para terminar su trabajo.
Prof.: Lic. Javier Ruiz Diaz

Pgina 14

En este mtodo de colas mltiples la solucin implementada por el planificador es el

establecimiento de clases de prioridad. Los procesos en la clase de mayor prioridad se ejecutan
en un quantum, los procesos de la siguiente clase en dos quanta, los de la siguiente en cuatro
quantum, etc. Cuando un proceso consumiera todos los quanta asignados a l, se le mova a la
siguiente clase.

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

Solo sern necesarios 7 intercambios en lugar de los 100 correspondientes a un algoritmo puro de
round robn.
Adems de todo esto, al avanzar en las colas de prioridad, el proceso se ejecutara cada vez con
menor frecuencia, lo que representa un ahorro de tiempo de CPU para procesos interactivos
cortos.

PROCESO MS CORTO A CONTINUACIN

Debido a que el trabajo ms corto primero siempre produce el mnimo tiempo de respuesta
medio en los sistemas en batch, resultara bonito poder utilizarlo tambin con procesos
interactivos. Hasta cierto punto, tal cosa es posible.
Por lo general, los procesos interactivos siguen el patrn de esperar por un comando, ejecutar el
comando, esperar un comando, ejecutar el comando, y as sucesivamente. Si vemos la ejecucin
de cada comando como un trabajo separado, podramos minimizar el tiempo de respuesta
global ejecutando el ms corto primero. El nico problema es determinar cul de los procesos
preparados es el ms corto.
Una estrategia consiste en hacer estimaciones basadas en el comportamiento anterior y ejecutar
el proceso que tenga el tiempo de ejecucin estimado ms corto.
Ejemplo: Supongamos que el tiempo estimado por comando para un terminal dado es T0. Ahora
supongamos que la siguiente ejecucin de un comando proveniente de ese terminal tarda T1.
Podramos actualizar nuestra estimacin calculando una suma ponderada de estas dos
estimaciones, es decir, aT0 + (1 - a)T1.
Mediante la eleccin del valor de a, podemos decidir que el proceso de estimacin olvide
rpidamente las ejecuciones pasadas o que las recuerde durante mucho tiempo. Con a = 1/2,
obtenemos las siguientes estimaciones sucesivas:
T0,

T0/2 + T1/2,

T0/4 + T1/4 + T2/2,

T0/8 + T1/8 + T2/4 + T3/2

Despus de tres nuevas ejecuciones, el peso de T0 en la vigente estimacin habr bajado a 1/8.
La tcnica de estimar el siguiente valor de una serie, calculando la media ponderada del ltimo
valor medido y su estimacin anterior, se conoce como envejecimiento (aging), y puede aplicarse
en muchas situaciones en las que es preciso hacer una prediccin con base en los valores
anteriores.

PLANIFICACIN GARANTIZADA
Un enfoque a la planificacin completamente diferente es la de hacer promesas reales a. los
usuarios sobre el rendimiento y luego cumplirlas en la prctica. Una promesa que es realista y
fcil de cumplir es la siguiente:
si hay n usuarios conectados, cada uno recibir aproximadamente 1/n de la potencia de la CPU.
Similarmente, en un sistema monousuario en el que se estn ejecutando n procesos, si todos los
dems factores son iguales, cada uno deber recibir un 1/n de los ciclos de CPU.

Puesto que se conoce el tiempo de CPU que ha utilizado cada proceso, se puede calcular el
cociente del tiempo de CPU consumido realmente entre el tiempo al que el proceso tiene
derecho.

Prof.: Lic. Javier Ruiz Diaz

Pgina 15

Para cumplir esta promesa, el sistema necesita llevar la cuenta de cunto tiempo de CPU ha
recibido cada proceso desde su creacin. Luego se calcula el tiempo de CPU al que cada uno tiene
derecho, que sera el tiempo desde la creacin dividido entre n.

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

Para ello el sistema debe mantener un registro de:

Tiempo de CPU que cada usuario a tenido desde su entrada al sistma.

Tiempo transcurrido desde la entrada al sistema.

Ejemplo: Una proporcin de 0.5 indica que un proceso solo ha dispuesto de la mitad del tiempo
ebido, mientras que una proporcin de 2.0 indica que un proceso ha utilizado el doble de lo que
debera.

PLANIFICACIN POR LOTERA

La idea bsica consiste en dar a los procesos como dcimos de lotera para los distintos
recursos del sistema, tales como el tiempo de CPU. Siempre que deba tomarse una decisin de
planificacin, se escoge un dcimo al azar, concedindose el recurso al proceso que lo tenga.
Ejemplo: Si este sistema se aplica a la planificacin de la CPU, el sistema podra celebrar un
sorteo 50 veces por segundo, dando como premio al ganador los siguientes 20 milisegundos de
tiempo de CPU.
Podramos dar ms dcimos a los procesos ms importantes para aumentar sus posibilidades de
ganar. Si se emiten 100 dcimos y un proceso tiene 20 de ellos, tendr una probabilidad del 20%
de ganar cada sorteo. A la larga, este proceso recibir aproximadamente un 20% de la CPU. En
contraste con un planificador por prioridades, donde es muy difcil establecer lo que significa
tener una prioridad de 40, aqu la regla est muy clara: un proceso poseyendo una fraccin f de
los dcimos obtendr una fraccin f del recurso en cuestin.
La planificacin por lotera tiene varias propiedades interesantes.

Si llega un nuevo proceso y recibe cierto nmero de dcimos, en el siguiente sorteo tendr
una probabilidad de ganar proporcional al nmero de dcimos que tenga. Dicho de otro
modo, la planificacin por lotera es muy sensible en el sentido de que responde muy
rpidamente a los cambios.

Los procesos que cooperan pueden intercambiar dcimos si lo desean. Si un proceso cliente
enva un mensaje a un proceso servidor y luego se bloquea, podra entregar todos sus
dcimos al servidor para mejorar la probabilidad de que sea el servidor quien se ejecute a
continuacin. Cuando el servidor termine, devolver los dcimos al cliente para que pueda
ejecutarse otra vez. De hecho, si no hay clientes, los servidores no necesitan dcimos.

PLANIFICACIN POR REPARTO JUSTO

Hasta aqu hemos dado por hecho que cada proceso se planifica por sus propios mritos sin
considerar quin es su dueo. El resultado es que si el usuario 1 inicia 9 procesos y el usuario 2
inicia slo un proceso, y se utiliza round robn o prioridades estticas, el usuario 1 recibir el 90%
del tiempo de CPU y el usuario 2 recibir slo el 10%.
A fin de prevenir esa situacin, algunos sistemas toman en cuenta quien es el propietario del
proceso antes de planificarlo. En este modelo, a cada usuario se le asigna cierta fraccin del
tiempo de CPU y el planificador escoge los procesos de manera que se respete ese reparto.

Consideremos el caso de un sistema con dos usuarios, a cada uno de los cuales se le ha prometido
el 50% de la CPU. El usuario 1 tiene cuatro procesos, A, B, C y D, y el usuario 2 slo tiene un

Prof.: Lic. Javier Ruiz Diaz

Pgina 16

Por ejemplo: Si a dos usuarios se les prometi el 50% del tiempo de CPU, cada uno recibir esa
fraccin, sin importar cuntos procesos cree cada uno.

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

proceso, E. Si se emplea la planificacin round robn, la siguiente sera una posible secuencia de
planificacin que se ajusta a todas las restricciones:
AEBECEDEAEBECEDE...
Por otra parte, si el usuario 1 tiene derecho al doble de tiempo de CPU que el usuario 2, podramos
tener
ABECDEABECDE...
Por supuesto, existen muchas otras posibilidades, y pueden explotarse, dependiendo del concepto
de justicia que se utilice.

PLANIFICACIN EN SISTEMAS DE TIEMPO REAL

Un sistema de tiempo real es uno en el cual el tiempo juega un papel esencial. Tpicamente, se
tiene uno o ms dispositivos fsicos externos al ordenador que generan estmulos a los cuales
debe reaccionar el ordenador de la manera apropiada y dentro de un plazo de tiempo prefijado.
Por ejemplo: El ordenador interno de un reproductor de discos compactos recibe los bits tal y como
salen de la unidad y debe convertirlos en msica en un intervalo de tiempo muy ajustado. Si el
clculo tarda demasiado, la msica sonar rara.
Otros sistemas en tiempo real:

Monitorizan pacientes en la unidad de cuidados intensivos de un hospital,

Controlan el piloto automtico de un avin y

Controlan los robots en una fbrica automatizada.

En todos estos casos, producir la respuesta correcta demasiado tarde es a menudo tan malo como
no producir ninguna respuesta.
Los sistemas en tiempo real se clasifican generalmente en sistemas de tiempo real estricto (hard
real time) y sistemas de tiempo real moderado (soft real time).

En los sistemas de tiempo real estricto hay plazos absolutos que deben cumplirse, pase
lo que pase.

En los sistemas de tiempo real moderado el incumplimiento ocasional de un plazo

aunque es indeseable, es sin embargo tolerable.

En ambos casos, el comportamiento en tiempo real se logra dividiendo el programa en varios

procesos cuyo comportamiento es predecible y conocido por adelantado. Generalmente, tales
procesos son cortos y pueden terminar su trabajo en mucho menos de un segundo. Cuando se
detecta un suceso externo, el planificador debe planificar los procesos de tal modo que se
cumplan todos los plazos.

Peridicos (que se presentan a intervalos regulares)

Aperidicos (cuya ocurrencia es impredecible).

Un sistema puede tener que responder a mltiples flujos de sucesos peridicos. Dependiendo de
cunto tiempo se requiere para procesar cada suceso, podra no ser siquiera posible atenderlos a
todos. Por ejemplo, si hay m sucesos peridicos y el suceso i tiene lugar con un periodo Pi y su

Prof.: Lic. Javier Ruiz Diaz

Pgina 17

Los sucesos a los que un sistema de tiempo real debe tener que responder pueden clasificarse
como:

Universidad de la Cuenca del Plata

Sistemas Operativos
III PLANIFICACIN DE PROCESOS

tratamiento requiere Ci segundos de tiempo de CPU, entonces el sistema slo podr soportar esa
carga si:
m

Ci
1
i =1 Pi

Un sistema en tiempo real que cumpla este criterio se dice que es planificable.
Los algoritmos de planificacin para tiempo real pueden ser estticos o dinmicos.

Los algoritmos estticos toman sus decisiones de planificacin antes de que el sistema
comience a ejecutarse.

Los algoritmos dinmicos toman las decisiones en tiempo de ejecucin.

La planificacin esttica slo funciona si se est perfectamente informado por anticipado sobre el
trabajo que debe realizarse y los plazos que deben cumplirse. Los algoritmos de planificacin
dinmica no tienen estas restricciones.

BIBLIOGRAFA
Sistemas Operativos Modernos. Tanenbaum A. Edt. Prentice Hall. Ao: 2004 Ed.
2.
Fundamentos de los Sistemas Operativos. Silberschatz, J.L. and Galvin P. B. and G.
Gagne. Edt. Mc Graw Hill. Ao: 2005.

Pgina 18

SISTEMAS OPERATIVOS: ASPECTOS INTERNOS Y PRINCIPIOS DE DISEO. Stallings, William. Edt.

Pearson Education. Ao: 2005.

Prof.: Lic. Javier Ruiz Diaz