8.

1 Introduccin

Hemos hablado de cmo la multiprogramacin permite a un sistema operativo utilizar sus

recursos de manera ms eficiente. Cuando un sistema tiene una seleccin de procesos a ejecutar,
debe tener una estrategia llamada una poltica de programacin del procesador (o disciplina) para
decidir qu proceso se ejecutar en un momento dado. Una poltica de programacin debe
intentar satisfacer ciertos criterios de rendimiento, como maximizar el nmero de procesos que
completan por unidad de tiempo (es decir, rendimiento), minimizar el tiempo que cada proceso
espera antes de ejecutar (es decir, latencia), prevenir el aplazamiento indefinido de los procesos,
Que cada proceso se completa antes de su plazo establecido, o maximizar la utilizacin del
procesador. Algunos de estos objetivos, como maximizar la utilizacin del procesador y el
rendimiento, son complementarios; Otros entran en conflicto unos con otros -un sistema que
garantiza que los procesos se completen antes de que sus plazos no alcancen el rendimiento ms
alto, en este captulo discutimos los problemas de determinar cundo deben asignarse los
procesadores ya qu procesos. Aunque nos centramos en los procesos, muchos de los temas que
describimos se aplican tambin a trabajos e hilos.

Auto revisin

1. Cundo podra un sistema que asegura que los procesos se completen antes de que sus plazos
no alcancen el rendimiento ms alto?

2. Qu criterio de rendimiento es el ms importante en un sistema operativo? Por qu es una

pregunta difcil de responder?

Resp:

1) Esto ocurre, por ejemplo, cuando varios procesos cortos se retrasan mientras el sistema
distribuye un proceso largo que debe cumplir con su fecha lmite.

2) Ninguna interpretacin de desempeo es ms importante que las dems para cada sistema
operativo. Depende de las metas del sistema. Por ejemplo, en sistemas en tiempo real, dar
procesos e hilos inmediatos, el servicio predecible es ms importante que la alta utilizacin del
procesador. En las supercomputadoras que realizan clculos largos, la utilizacin del procesador
suele ser ms importante que minimizar la latencia.

8.2 Niveles de programacin

En esta seccin se consideran tres niveles de programacin (Fig. 8.1). La programacin de alto
nivel, tambin llamada programacin de tareas o programacin a largo plazo, determina qu
trabajos el sistema permite competir activamente por los recursos del sistema. Este nivel se
denomina a veces programacin de admisin, ya que determina qu trabajos obtienen la admisin
al sistema. Una vez admitidos, los trabajos se inician y se convierten en procesos o grupos de
procesos. La poltica de programacin de alto nivel determina el grado de multiprogramacin: el
nmero total de procesos en un sistema en un momento determinado.1 La entrada de
demasiados procesos en el sistema puede saturar los recursos del sistema, lo que conduce a un
rendimiento deficiente. En este caso, la poltica de programacin de alto nivel puede decidir
prohibir temporalmente la entrada de nuevos trabajos hasta que se completen otros trabajos.
Despus de que la poltica de programacin de alto nivel haya admitido un trabajo (que puede
contener uno o ms procesos) al sistema, la poltica de programacin de nivel intermedio
determina qu procesos se les permitir competir por los procesadores. Esta poltica responde a
fluctuaciones a corto plazo en la carga del sistema. Suspende y reanuda temporalmente los

Figura 8.1 | Planificacin de niveles.

procesos para lograr un funcionamiento suave del sistema y para ayudar a alcanzar ciertos
objetivos de rendimiento del sistema. El planificador de nivel intermedio acta como un buffer
entre la admisin de trabajos al sistema y la asignacin de procesadores a los procesos que
representan estos trabajos.

La poltica de programacin de bajo nivel de un sistema determina qu proceso activo asignar el

sistema a un procesador cuando una prxima est disponible. En muchos de los sistemas actuales,
los planificadores de nivel bajo y medio son los nicos programadores. (En este caso, la iniciacin
del trabajo es realizada por el planificador de nivel intermedio.) Los planificadores de nivel alto a
menudo se limitan a los grandes sistemas mainframe que realizan el procesamiento por lotes.

Las polticas de programacin de bajo nivel a menudo asignan una prioridad a cada proceso, lo que
refleja su importancia. Cuanto ms importante es un proceso, ms probable es que la poltica de
programacin lo seleccione para ejecutarlo a continuacin. Discutimos las prioridades en la
Seccin 8.4, Prioridades, ya lo largo de este captulo. El programador de bajo nivel (tambin
llamado distribuidor) tambin asigna (es decir, enva) un procesador al proceso seleccionado. El
despachador opera muchas veces por segundo y por lo tanto debe residir en la memoria principal
en todo momento.

En este captulo discutiremos muchas polticas de programacin de bajo nivel. Presentamos cada
uno en el contexto de ciertos objetivos y criterios de programacin (que discutimos en la Seccin
8.5, Objetivos de programacin y Seccin 8.6, Criterios de programacin) y describimos cmo se
relacionan entre s. Coffman y Kleinrock discuten las polticas de programacin populares e indican
cmo los usuarios que saben cul es el sistema que emplea realmente pueden lograr un mejor
desempeo tomando medidas apropiadas. Ruschitzka y Fabry dan una clasificacin de algoritmos
de programacin y formalizan la nocin de prioridad.

Auto revisin

1. Cmo debe el planificador intermedio responder a las fluctuaciones en la carga del sistema?

2. Qu nivel de planificador debe permanecer residente en la memoria principal? Por qu?

Resp:

1) El programador intermedio puede prohibir que los procesos procedan al programador de nivel
bajo cuando el sistema se sobrecarga y puede permitir que estos procesos continen cuando la
carga del sistema vuelve a la normalidad.

2) El programador de bajo nivel debe permanecer residente en la memoria principal porque se

ejecuta con frecuencia, lo que obliga a responder rpidamente para reducir la sobrecarga de
programacin.

8.3 Programacin Preemptiva vs. No Preemptiva

Las disciplinas de programacin son preemptivas o no preventivas. Una disciplina de programacin

no es preventiva si, una vez que el sistema ha asignado un procesador a un proceso, el sistema no
puede eliminar ese procesador de ese proceso. Una disciplina de programacin es preventiva si el
sistema puede eliminar el procesador del proceso que est ejecutando. Bajo una disciplina de
programacin no preemptiva, cada proceso, una vez dado un procesador, se ejecuta hasta su
finalizacin o hasta que renuncia voluntariamente a su procesador. Bajo una disciplina de
programacin preventiva, el procesador puede ejecutar una parte del cdigo de un proceso y
luego realizar un cambio de contexto.

La programacin preventiva es til en sistemas en los que los procesos de alta prioridad requieren
una respuesta rpida. En sistemas en tiempo real (discutidos en la Seccin 8.9, Programacin en
tiempo real), por ejemplo, las consecuencias de no responder a una interrupcin podran ser
catastrficas. En los sistemas interactivos de tiempo compartido, la programacin preventiva
ayuda a garantizar un tiempo de respuesta del usuario aceptable. Preemption no es sin
costcontext switches incurrir en gastos generales (vase el sistema operativo Thinking
caracterstica, Overhead). Para que la preemption sea efectiva, el sistema debe mantener muchos
procesos en la memoria principal, de modo que el siguiente proceso est listo cuando un
procesador est disponible. Como veremos en el Captulo 10, Organizacin de memoria virtual,
slo una parte de cada proceso normalmente est en memoria principal en cualquier momento;
Las porciones menos activas tpicamente residen en el disco.

En los sistemas no preventivos, los procesos cortos pueden experimentar largos retrasos de
servicio mientras los procesos ms largos se completan, pero los tiempos de respuesta son ms
predecibles, porque los procesos entrantes de alta prioridad no pueden desplazar los procesos de
espera. Debido a que un sistema no preemptivo no puede eliminar un proceso de un procesador
hasta que se completa, los programas errantes que nunca se completan (por ejemplo, al introducir
un bucle infinito) nunca pueden renunciar al control del sistema. Adems, en un sistema no
preemptivo, la ejecucin de procesos sin importancia puede hacer que los procesos importantes
esperen.

Para evitar que los usuarios monopolicen el sistema (malicioso o accidentalmente), un sistema
preventivo puede alejar al procesador de un proceso. Como se analiza en el Captulo 3, Conceptos
de proceso, esto se implementa tpicamente estableciendo un reloj de interrupcin o un
temporizador de intervalos que peridicamente genera una interrupcin, lo que permite que el
sistema operativo se ejecute. Una vez asignado un procesador a un proceso, el proceso se ejecuta
hasta que libera voluntariamente su procesador, o hasta que se produce la interrupcin del reloj o
alguna otra interrupcin. El sistema operativo puede entonces decidir si el proceso en ejecucin
debe continuar o algn otro "prximo" proceso debe ejecutarse.

El reloj de interrupcin ayuda a garantizar tiempos de respuesta razonables a los usuarios

interactivos, impide que el sistema se colgue en un bucle infinito.

Auto revisin

1. Cundo es ms apropiada la programacin no preventiva que la programacin preventiva?

2. Puede un programa que entra en un bucle infinito monopolizar un sistema preventivo?

Resp:

1) La programacin no preventiva proporciona tiempos de respuesta predecibles, lo cual es

importante para los sistemas de procesamiento por lotes que deben proporcionar a los usuarios
tiempos de finalizacin de trabajos precisos.

2) Esto depende de la prioridad del proceso y de la poltica de programacin. En general, un

sistema preventivo que contiene un proceso que ejecuta un bucle infinito experimentar un
rendimiento reducido, pero todava ser capaz de ejecutar peridicamente otros procesos. Un
proceso de alta prioridad que entra en un bucle infinito, sin embargo, puede ejecutarse
indefinidamente si todos los otros procesos del sistema tienen una prioridad menor. En general,
los sistemas preventivos son menos afectados por estos programas que los sistemas no
preventivos. Los sistemas operativos normalmente se ocupan de tales situaciones limitando el
tiempo mximo que un proceso puede utilizar un procesador.

8.4 Prioridades

Los planificadores a menudo usan prioridades para determinar cmo programar y enviar procesos.
Las prioridades pueden asignarse estticamente o pueden cambiar dinmicamente. Las
prioridades cuantifican la importancia relativa de los procesos.

Las prioridades estticas permanecen fijas, por lo que los mecanismos basados en la prioridad
esttica son relativamente fciles de implementar e incurren en gastos generales relativamente
bajos. Sin embargo, estos mecanismos no responden a los cambios en el entorno, ni siquiera los
que podran aumentar el rendimiento y reducir la latencia. Los mecanismos de prioridad dinmica
responden al cambio. Por ejemplo, el sistema puede querer aumentar la prioridad de un proceso
que contiene un recurso clave necesario para un proceso de mayor prioridad. Despus de que el
primer proceso abandona el recurso, el sistema disminuye la prioridad, de modo que el proceso de
mayor prioridad puede ejecutarse.

Los esquemas de prioridad dinmica son ms complejos de implementar y tienen una mayor
sobrecarga que los esquemas estticos. Esperemos que la sobrecarga se justifique por la mayor
capacidad de respuesta del sistema.

En los sistemas multiusuario, un sistema operativo debe proporcionar un servicio razonable a una
gran comunidad de usuarios, pero tambin debe prever situaciones en las que un miembro de la
comunidad de usuarios necesita un tratamiento especial. Un usuario con un trabajo importante
puede estar dispuesto a pagar una prima, es decir, a la compra de prioridad, para un mayor nivel
de servicio. Este cargo adicional se merece porque los recursos pueden necesitar ser retirados de
otros clientes que pagan. Si no hubiera ningn cargo adicional, todos los usuarios solicitaran el
nivel ms alto de servicio.

Auto revisin

1. Por qu vale la pena incurrir en un costo ms alto y un aumento de los gastos generales de un
mecanismo dinmico prioritario?

2. Por qu un planificador dinmico optara por favorecer un proceso de baja prioridad

Recurso subutilizado?

Resp:

1) Un mecanismo de prioridad dinmica cuidadosamente diseado podra producir un sistema

ms sensible que un mecanismo de prioridad esttica.

2) El recurso subutilizado es probable que est disponible, permitiendo que el proceso de baja
prioridad para completar y salir del sistema antes de un proceso de mayor prioridad en espera de
un recurso saturado.
8.5 Objetivos de programacin

Un diseador de sistemas debe considerar una variedad de factores al desarrollar una disciplina de
programacin, como el tipo de sistema y las necesidades de los usuarios. Por ejemplo, la disciplina
de programacin para un sistema en tiempo real debe diferir de la de un sistema de escritorio
interactivo; Los usuarios esperan resultados diferentes de este tipo de sistemas. Dependiendo del
sistema, el usuario y el diseador pueden esperar que el planificador:

Maximizar el rendimiento. Una disciplina de programacin debe intentar reparar el nmero

mximo de procesos por unidad de tiempo.

Maximizar el nmero de procesos interactivos que reciben tiempos de respuesta "aceptables".

Maximizar la utilizacin de recursos. Los mecanismos de programacin deben mantener

ocupados los recursos del sistema.

Evitar el aplazamiento indefinido. Un proceso no debe experimentar un tiempo de espera

ilimitado antes o mientras recibe servicio.

Hacer cumplir las prioridades. Si el sistema asigna prioridades a los procesos, el mecanismo de
programacin debe favorecer los procesos de mayor prioridad.

Minimizar los gastos generales. Curiosamente, esto no se considera generalmente como uno de
los objetivos ms importantes. La sobrecarga a menudo resulta en recursos desperdiciados. Pero
una cierta porcin de los recursos del sistema invertidos de manera efectiva como gastos
generales puede mejorar en gran medida el rendimiento general del sistema.

Asegurar la previsibilidad. Mediante la minimizacin de la varianza estadstica en los tiempos de

respuesta al proceso, un sistema puede garantizar que los procesos recibirn niveles de servicio
predecibles (vea la funcin Pensamiento de sistemas operativos, previsibilidad).

Un sistema puede lograr estas metas de varias maneras. En algunos casos, el programador puede
evitar el aplazamiento indefinido de los procesos mediante el envejecimiento, aumentando
gradualmente la prioridad de un proceso a medida que el proceso espera el servicio.
Eventualmente, su prioridad se vuelve lo suficientemente alta como para que el programador
seleccione ese proceso para ejecutarlo.

El planificador puede aumentar el rendimiento favoreciendo procesos cuyas peticiones pueden

satisfacerse rpidamente o cuya finalizacin libera otros procesos para ejecutarse. Una de estas
estrategias favorece los procesos que contienen recursos clave. Por ejemplo, un proceso de baja
prioridad puede contener un recurso clave que es requerido por un proceso de mayor prioridad. Si
el recurso no es preemptivo, el planificador debe dar al proceso de baja prioridad ms tiempo de
ejecucin de lo que normalmente recibira, de modo que liberar el recurso clave antes. Esta
tcnica se denomina inversin de prioridad, porque los pries relativos de los dos procesos se
invierten de modo que el de alta prioridad obtenga el recurso que requiere para continuar la
ejecucin. Del mismo modo, el planificador puede optar por favorecer un proceso que solicite
recursos subutilizados, porque el sistema tendr ms probabilidades de satisfacer las peticiones de
este proceso en un perodo de tiempo ms corto.
Muchas de estas metas entran en conflicto entre ellas, haciendo que programar un problema
complejo. Por ejemplo, la mejor manera de minimizar los tiempos de respuesta es disponer de
recursos suficientes cuando se necesiten. El precio de esta estrategia es que la utilizacin general
de recursos ser pobre. En sistemas en tiempo real, las respuestas rpidas y predecibles son
cruciales, y la utilizacin de los recursos es menos importante. En otros tipos de sistemas, la
economa suele hacer imprescindible la utilizacin eficaz de los recursos.

A pesar de las diferencias en los objetivos entre los sistemas, muchas disciplinas de programacin
exhiben propiedades similares:

Equidad. Una disciplina de programacin es justa si todos los procesos similares son tratados de
la misma manera, y ningn proceso puede sufrir un aplazamiento indefinido debido a problemas
de programacin (vea la caracterstica de Pensamiento de Sistemas Operativos, Equidad).

Previsibilidad. Un proceso dado siempre debe ejecutarse en la misma cantidad de tiempo bajo
cargas similares del sistema.

Escalabilidad. El rendimiento del sistema debe degradarse con gracia (es decir, no debe
colapsarse inmediatamente) bajo cargas pesadas.

Auto revisin

1. Cmo se contraponen los objetivos de reducir la varianza en los tiempos de respuesta y hacer
cumplir las prioridades?

2. La planificacin de gastos generales es siempre "intil"?

Resp:

1) En los sistemas preventivos, los procesos de alta prioridad pueden prevalecer

En cualquier momento, aumentando as la variacin en los tiempos de respuesta.

2) No, la sobrecarga incurrida bj operaciones de programacin eficaces pueden aumentar la

utilizacin de recursos.

8.6 Criterios de programacin

Para realizar los objetivos de programacin de un sistema, el planificador debe considerar el

comportamiento del proceso. Un procesador-bound proceso tiende a utilizar todo el tiempo de
procesador que el sistema asigna para l. Un proceso de E / S-bound tiende a utilizar el procesador
slo brevemente antes de generar una solicitud de E / S y renunciar a ella. Los procesos vinculados
al procesador pasan la mayor parte del tiempo usando el procesador; Los procesos vinculados a E
/ S pasan la mayor parte del tiempo esperando recursos externos (por ejemplo, impresoras,
unidades de disco, conexiones de red, etc.) para atender sus peticiones y slo tiempo nominal
usando procesadores.

Una disciplina de programacin tambin podra considerar si un proceso es lote o interactivo. Un

proceso por lotes contiene trabajo para que el sistema realice sin interactuar con el usuario. Un
proceso interactivo requiere entradas frecuentes del usuario. El sistema debe proporcionar
buenos tiempos de respuesta a un proceso interactivo, mientras que un proceso por lotes
generalmente puede sufrir retrasos razonables. Del mismo modo, una disciplina de programacin
debe ser sensible a la urgencia de un proceso. Un proceso discontinuo durante la noche no
requiere respuestas inmediatas. Un sistema de control de procesos en tiempo real que monitorea
una refinera de gasolina debe ser sensible, posiblemente para evitar una explosin.

Cuando se public la segunda edicin de este libro, los usuarios interactuaron con los procesos
mediante la emisin de peticiones triviales utilizando un teclado. En este entorno, un programador
podra favorecer un proceso interactivo con poco efecto en otros procesos, ya que el tiempo
necesario para dar servicio a procesos interactivos (por ejemplo, mostrando texto) era nominal.
Las computadoras AS se hicieron ms potentes, los diseadores de sistemas y los programadores
de aplicaciones incluyeron caractersticas como grficos e interfaces grficas para mejorar la
facilidad de uso. Aunque algunos sistemas todava utilizan interfaces basadas en texto, la mayora
de los usuarios de hoy interactan a travs de GUIs, usando un ratn para realizar acciones como
abrir, cambiar el tamao, arrastrar y cerrar ventanas. Los usuarios esperan que los sistemas
respondan rpidamente para que estas acciones produzcan un movimiento suave. A diferencia de
la visualizacin de texto, esta puede ser una tarea intensiva en computacin que requiere que el
sistema vuelva a dibujar la pantalla muchas veces por segundo. El favorecer estos procesos
interactivos puede reducir significativamente el nivel de servicio proporcionado a otros procesos
en el sistema. En el caso de un proceso por lotes, esta reduccin temporal en el servicio puede ser
aceptable, aunque tal vez no sea para procesos que se ejecutan en tiempo real (por ejemplo,
aplicaciones multimedia).

En un sistema que emplea prioridades, el programador debe favorecer procesos con prioridades
ms altas. Los planificadores pueden basar sus decisiones en la frecuencia con la que un proceso
de mayor prioridad ha rechazado una prioridad menor. En algunas disciplinas, los procesos
frecuentemente preemptivos reciben tratamiento menos favorecido. Esto se debe a que el corto
tiempo de ejecucin del proceso antes de la anticipacin no justifica la sobrecarga incurrida por un
cambio de contexto cada vez que se enva el proceso. Se puede argumentar al contrario que tales
procesos deben recibir tratamiento ms favorecido para compensar el "maltrato" anterior.

Las polticas de planificacin preventiva a menudo mantienen informacin sobre cunto tiempo de
ejecucin real ha recibido cada proceso. Algunos diseadores creen que un proceso que ha
recibido poco tiempo de ejecucin debe ser favorecido. Otros creen que un proceso que ha
recibido mucho tiempo de ejecucin podra estar casi terminado y debera ser favorecido para
ayudarlo a alcanzar la terminacin, liberar sus recursos para otros procesos para usar y salir del
sistema tan pronto como sea posible. De manera similar, un planificador puede mantener una
estimacin de cunto tiempo queda antes de que se complete un proceso. Es fcil demostrar que
los tiempos de espera promedio se pueden minimizar ejecutando primero esos procesos que
requieren el tiempo de ejecucin mnimo hasta su finalizacin. Desafortunadamente, un sistema
rara vez sabe exactamente cunto ms tiempo cada proceso necesita para completar.

Auto revisin

1. Estn vinculados los procesos interactivos generalmente vinculados al procesador o I / O?

Qu hay de los procesos por lotes?
2. El programador rara vez sabe exactamente cunto ms tiempo cada proceso necesita para
completar. Considere un sistema que planifique procesos basados en esta estimacin. Cmo
pueden los procesos abusar de esta poltica?

Resp:

1) Los procesos interactivos a menudo esperan la entrada de los usuarios, por lo que
generalmente estn vinculados a E / S, pero un proceso interactivo podra entrar en una fase
durante la cual es principalmente procesador. Los procesos por lotes no interactan con los
usuarios ya menudo se limitan al procesador. Los procesos por lotes que requieren acceso
frecuente al disco oa otros dispositivos de E / S estn vinculados a E / S.

2) Los procesos tienden a subestimar sus tiempos hasta su finalizacin para recibir el tratamiento
favorecido del planificador.

8.7 Algoritmos de Programacin

En las secciones anteriores hablamos de polticas de programacin, que especifican la meta del
planificador (por ejemplo, maximizar el rendimiento o hacer cumplir las prioridades). En las
subsecciones que siguen se discuten algoritmos de programacin que determinan en tiempo de
ejecucin qu proceso se ejecuta a continuacin. Estos algoritmos deciden cundo y por cunto
tiempo se ejecuta cada proceso; Toman decisiones acerca de la predisposicin, las prioridades, el
tiempo de ejecucin, el tiempo hasta la finalizacin, la equidad y otras caractersticas del proceso.
Como veremos, algunos sistemas requieren el uso de un tipo particular de planificador (por
ejemplo, los sistemas en tiempo real normalmente requieren planificadores prioritarios basados
en prioridad). Otros se basan en el comportamiento del proceso al tomar decisiones de
planificador (por ejemplo, favoreciendo procesos enlazados a E / S).

8.7.1 Programacin de First-In-First-Out (FIFO)

Quizs el algoritmo de programacin ms simple sea el primero en entrar primero en salir (FIFO),
tambin llamado primer llegado primero a ser servido (FCFS) (Fig. 8.2). Los procesos se despachan
segn su hora de llegada en la cola lista. FIFO es no preemptivo - una vez que un proceso tiene un
procesador, el proceso se ejecuta hasta su finalizacin. FIFO es justo porque programa los
procesos de acuerdo a sus tiempos de llegada, por lo que todos los procesos son tratados de igual
manera, pero algo injusto porque los procesos largos hacen esperar procesos cortos y los procesos
sin importancia hacen esperar procesos importantes.

FIFO no es til en la programacin de procesos interactivos porque no puede garantizar tiempos

de respuesta cortos. El FIFO rara vez se utiliza como un esquema maestro en los sistemas actuales,
pero a menudo se encuentra dentro de otros esquemas. Por ejemplo, muchos esquemas de
planificacin distribuyen procesos de acuerdo con la prioridad, pero los procesos con la misma
prioridad se envan en orden FIFO.
 Figura 8.2 | Primera en la primera salida de programacin.

Auto revisin

1. Puede ocurrir un aplazamiento indefinido en un sistema que utiliza un planificador FIFO?

Suponga que todos los procesos finalmente se ejecutan hasta completarse (es decir, ningn
proceso entra en un bucle infinito).

2. (T / F) La programacin FIFO rara vez se encuentra en los sistemas actuales.

Resp:

1) No, no puede ocurrir un aplazamiento indefinido, ya que los procesos que llegan deben entrar
en la parte posterior de la cola, lo que significa que no pueden impedir que los procesos que ya
estn esperando se ejecuten.

2) Falso. FIFO puede encontrarse dentro de muchos algoritmos de programacin de hoy (por
ejemplo, planificadores basados en prioridades que despachan procesos con la misma prioridad en
el orden FIFO).

8.7.3 Programacin de procesos ms cortos (SPF)

El SPF (shortest-process-first) es una disciplina de planificacin no preemptiva en la que el

planificador selecciona el proceso de espera con el menor tiempo estimado de ejecucin hasta su
finalizacin. SPF reduce el tiempo de espera promedio en FIFO.14 Los tiempos de espera, sin
embargo, tienen una mayor varianza (es decir, son ms impredecibles) que FIFO, especialmente
para grandes procesos.

SPF favorece procesos cortos a expensas de los ms largos. Muchos diseadores abogan por que
cuanto ms corto sea el proceso, mejor ser el servicio que debe recibir. Otros diseadores no
estn de acuerdo, ya que esta estrategia no incorpora las prioridades (medida por la importancia
de un proceso). Los procesos interactivos, en particular, tienden a ser "ms cortos" que los
procesos procesados por el procesador, por lo que esta disciplina parece proporcionar todava
buenos tiempos de respuesta interactivos. El problema es que no es preventivo, por lo que, en
general, los procesos interactivos que llegan no recibirn un servicio rpido.

SPF selecciona los procesos para el servicio de una manera que asegura que el siguiente
completar y dejar el sistema tan pronto como sea posible. Esto tiende a reducir el nmero de
procesos de espera y tambin el nmero de procesos que esperan detrs de grandes procesos.
Como resultado, SPF puede minimizar el tiempo de espera promedio de los procesos a medida
que pasan a travs del sistema.
Un problema clave con SPF es que requiere un conocimiento preciso de cunto tiempo un proceso
se ejecutar, y esta informacin por lo general no est disponible. Por lo tanto, SPF debe basarse
en estimaciones de tiempo de ejecucin suministradas por el usuario o el sistema. En entornos de
produccin donde los mismos procesos se ejecutan con regularidad, el sistema puede ser capaz de
mantener una heurstica de tiempo de ejecucin razonable. En entornos de desarrollo, sin
embargo, el usuario rara vez sabe cunto tiempo un proceso se ejecutar.

Otro problema de depender de las estimaciones de la duracin del proceso del usuario es que los
usuarios pueden proporcionar estimaciones pequeas (tal vez inexactas) para que el sistema d
prioridad a sus programas. Sin embargo, el programador puede ser diseado para eliminar esta
tentacin. Por ejemplo, si un proceso dura ms tiempo de lo estimado, el sistema podra
terminarlo y reducir la prioridad de los otros procesos de ese usuario, incluso invocando penas. Un
segundo mtodo consiste en ejecutar el proceso por el tiempo estimado ms un pequeo
porcentaje extra, luego "dejarlo" (es decir, conservarlo en su forma actual) para que el sistema lo
reinicie ms tarde.

SPF deriva de una disciplina llamada trabajo corto primero (SJF), que pudo haber trabajado bien
programar trabajos en fbricas pero claramente es inadecuado para la programacin de bajo nivel
en sistemas operativos. El SPF, al igual que FIFO, no es preventivo y, por lo tanto, no es adecuado
para entornos en los que se deben garantizar tiempos de respuesta razonables.

Auto revisin

1. Por qu el SPF es ms deseable que FIFO cuando el rendimiento del sistema es un sistema
primario

objetivo?

2. Por qu el SPF es inadecuado para la programacin de bajo nivel en los sistemas operativos
actuales?

Resp:

1) SPF reduce los tiempos de espera medios, lo que aumenta el rendimiento.

2) SPF no proporciona procesos con tiempos de respuesta rpidos, lo cual es esencial en los
sistemas interactivos de hoy en da, amigables para el usuario y multiprogramados.

8.7.2 Programacin Round-Robin (RR)

En la programacin round-robin (RR) (Fig. 8.3), los procesos se envan FIFO, pero se les da una
cantidad limitada de tiempo de procesador llamado tiempo o cuantitativo. Si un proceso no se
completa antes de que su quantum expire, el sistema lo reemplaza y le da al procesador el
siguiente proceso de espera. A continuacin, el sistema coloca el proceso predeterminado en la
parte posterior de la cola lista. En la Fig. 8.3, el proceso P1 se enva a un procesador, donde se
ejecuta hasta completarse, en cuyo caso sale del sistema, o hasta que su intervalo de tiempo
expira, momento en el que se previene y se coloca en la cola de la cola lista. El planificador enva
entonces el proceso P2.
Round-robin es eficaz para entornos interactivos en los que el sistema debe garantizar tiempos de
respuesta razonables. El sistema puede minimizar la sobrecarga de preemption a travs de
mecanismos eficientes de conmutacin de contexto y manteniendo los procesos de espera en la
memoria principal.

Al igual que FIFO, round-robin se encuentra comnmente dentro de algoritmos de programacin

de procesador ms sofisticados, pero rara vez es el esquema maestro. Como veremos a lo largo de
esta seccin, muchos algoritmos de programacin ms sofisticados degeneran en FIFO o round-
robin cuando todos los procesos tienen la misma prioridad. Por esta razn, FIFO y round-robin son
dos de los tres algoritmos de programacin requeridos por la especificacin POSIX para sistemas
en tiempo real (discutimos la programacin en tiempo real en la Seccin 8.9, Programacin en
tiempo real).

Figure 8.3 | Round-robin Scheduling.

Selfish Round-Robin
Kleinrock discuti una variante del round-robin llamado egosta round-robin (SRR) que utiliza el
envejecimiento para aumentar gradualmente las prioridades del proceso con el tiempo. En este
esquema, a medida que cada proceso entra en el sistema, primero reside en una cola de espera,
donde envejece hasta que su prioridad alcanza el nivel de procesos en la cola activa. En este
punto, se coloca en la cola activa y se planifica round-robin con otros procesos en la cola. El
planificador distribuye slo los procesos en la cola activa, lo que significa que los procesos ms
antiguos son favorecidos sobre los que acaban de entrar en el sistema. En SRR. La prioridad de un
proceso aumenta a un ritmo en la cola de espera, ya una velocidad b, donde b a, en la cola.
Cuando b <a, los procesos en la cola de espera varan a una velocidad mayor que los de la cola
activa, por lo que eventualmente entrarn en la cola activa y contendern por el procesador. La
adaptacin de los parmetros ayb afecta la forma en que la edad de un proceso afecta a la latencia
y el rendimiento promedio. Por ejemplo, a medida que se convierte en mucho mayor que b, los
procesos que entran en el sistema pasarn poco tiempo, si es que alguno, en la cola de espera. Si b
<< a, entonces los procesos pasan una cantidad insignificante de tiempo en la cola de espera, por
lo que SRR degenera a round-robin. Si b = a, cada proceso en el sistema envejece a la misma
velocidad, por lo que SRR degenera a FIFO. El ejercicio 8.23 investiga algunas propiedades del
esquema SRR.
Tamao Quantum

La determinacin del tamao cuntico, q, es crtica para el funcionamiento efectivo de un sistema

informtico con programacin preventiva.11 Debera el quantum ser grande o pequeo? Debe
ser fijo o variable? Debe ser el mismo para todos los procesos, o debe ser determinado por
separado para cada proceso?

En primer lugar, consideremos el comportamiento del sistema cuando el cuanto llega a ser
extremadamente grande o extremadamente pequeo. A medida que el quantum se hace grande,
los procesos tienden a recibir tanto tiempo como necesitan completarse, por lo que el esquema
round-robin degenera a FIFO. A medida que el cuanto se vuelve pequeo, el cambio de contexto
domina; El rendimiento se degrada al punto de que el sistema pasa la mayor parte de su contexto
de tiempo de conmutacin con poco trabajo, si es que alguno, til realizado.

Justo donde entre el cero y el infinito debe el quntum fijarse? Considere el siguiente
experimento. Supongamos que un dial circular est marcado con valores entre q = 0 yq = c, donde
c es un valor extremadamente grande. Comenzamos con el dial situado a cero. Al girar el dial, el
quantum del sistema aumenta. Suponga que el sistema est operativo y hay muchos procesos
interactivos. Al girar inicialmente el dial, los tamaos cunticos estn cerca de cero, y el overhead
de cambio de contexto consume la mayora de los ciclos del procesador. Los usuarios interactivos
experimentan un sistema lento con tiempos de respuesta deficientes. A medida que aumentamos
el quantum, los tiempos de respuesta mejoran. El porcentaje de procesador consumido por la
sobrecarga es lo suficientemente pequeo como para que los procesos reciban algn servicio de
procesador, pero los tiempos de respuesta no son tan rpidos como prefiera cada usuario.

A medida que giramos el dial ms, los tiempos de respuesta continan mejorando. Finalmente,
alcanzamos un tamao cuntico para el cual la mayora de los procesos interactivos reciben
respuestas del sistema, pero an no est claro si el ajuste cuntico es ptimo. Giramos el dial un
poco ms y los tiempos de respuesta se vuelven ligeramente mejores. A medida que continuamos
girando el dial, los tiempos de respuesta comienzan a volverse lentos nuevamente. El quantum, a
medida que se hace ms grande, eventualmente se convierte en lo suficientemente grande para
que cada proceso se ejecute hasta completarse al recibir el procesador. La programacin est
degenerando a FIFO, en la que los procesos ms largos hacen esperar ms cortos, y el tiempo de
espera promedio aumenta a medida que los procesos ms largos se ejecutan hasta completarse
antes de entregar el procesador.

Consideremos el valor supuestamente ptimo del cuanto que produjo buenos tiempos de
respuesta. Es una pequea fraccin de segundo. Qu representa exactamente este quantum? Es
lo suficientemente grande para que la gran mayora de las peticiones interactivas requieran menos
tiempo que la duracin del quantum. Cuando un proceso interactivo comienza a ejecutarse.
Normalmente utiliza el procesador slo brevemente, slo el tiempo suficiente para generar una
solicitud de E / S, y luego bloquear, momento en el que el proceso da lugar al procesador al
siguiente proceso. El quantum es mayor que este tiempo de clculo hasta I / O. Cada vez que un
proceso obtiene el procesador, es muy probable que el proceso se ejecute hasta que genera una
solicitud de E / S. Esto maximiza la utilizacin de E / S y proporciona tiempos de respuesta
relativamente rpidos para procesos interactivos. Lo hace con un impacto mnimo en los procesos
vinculados al procesador, que continan obteniendo la mayor parte del tiempo del procesador
porque los procesos vinculados a E / S se bloquean poco despus de ejecutarse.

Cul es el quantum ptimo en segundos reales? Claramente, el tamao vara de un sistema a otro
y bajo diferentes cargas. Tambin vara de proceso a proceso, pero nuestro experimento particular
no est orientado a medir las diferencias en los procesos.

En Linux, el quantum predeterminado asignado a un proceso es 100ms, pero puede variar de 10 a

200ms, dependiendo de la prioridad del proceso y el comportamiento. En Windows XP, el
quantum predeterminado asignado a un proceso es un valor especfico de arquitectura que
equivale a 20ms en la mayora de los sistemas. Los procesos de alta prioridad e I / Obound reciben
un proceso cuntico mayor que los procesos de baja prioridad. Este valor puede variar
dependiendo de si el proceso se ejecuta en primer plano o en segundo plano de la GUI.13

Cuando todos los procesos estn vinculados al procesador, la sobrecarga adicional disminuye el
rendimiento del sistema. Sin embargo, incluso cuando slo procesos procesados por el procesador
estn activos, la preemption todava es til. Por ejemplo, considere que los procesos enlazados al
procesador podran estar controlando un sistema de misin crtica en tiempo real, sera
devastador si un proceso entraba en un bucle infinito o incluso en una fase en la que demandaba
ms tiempo del procesador de lo esperado. Ms sencillamente, muchos sistemas con procesador
soportan procesos interactivos ocasionales, por lo que se necesita preempcin para asegurar que
los procesos interactivos que llegan reciben buenos tiempos de respuesta.

Auto revisin

1. Imagine convertir el dial cuntico en un sistema que contenga slo procesos vinculados a E / S.
Despus de un punto q = c, el aumento del valor cuntico da lugar a un cambio pequeo, si es que
hay alguno, en el rendimiento del sistema. Qu representa el punto c, y por qu no hay cambio
en el rendimiento del sistema cuando q> c?

2. El texto describe un valor cuntico ptimo que permite que cada proceso enlazado a E / S se
ejecute justo el tiempo suficiente para generar una peticin de E / S y luego bloquear. Por qu es
difcil de implementar?

Resp:

1) Este punto sera el perodo ms largo de clculo entre las peticiones de E / S para cualquier
proceso en el sistema. Aumentar el valor de q pasado c no afecta a ningn proceso. Debido a que
cada proceso se bloquea antes de que su cantidad expire, por lo que los procesos no pueden
aprovechar el tiempo de procesador adicional asignado a ellos.

2) En el caso general, es imposible predecir el camino de ejecucin que un programa tomar, lo

que significa que el sistema no puede determinar con precisin cundo un proceso generar E / S.
Por lo tanto, el tamao cuntico ptimo es difcil de determinar, porque es diferente para cada
proceso y puede variar con el tiempo.
8.7.6 Colas de Feedback Multinivel

Cuando un proceso obtiene un procesador, especialmente cuando el proceso an no ha tenido la

oportunidad de establecer un patrn de comportamiento (por ejemplo, cunto tiempo
normalmente se ejecuta antes de generar una solicitud de E / S o qu partes de memoria est
favoreciendo actualmente) , El programador no puede determinar la cantidad precisa de tiempo
de procesador que el proceso requerir. Los procesos de E / S normalmente utilizan el procesador
brevemente antes de generar una peticin de E / S. Los procesos enlazados al procesador pueden
usar el procesador durante horas si el sistema lo hace disponible en una base no preferible. Un
algoritmo de programacin suele favorecer procesos cortos, favorecer los procesos de I / O-bound
para obtener una buena utilizacin de dispositivos de E / S y buenos tiempos de respuesta
interactivos y debe determinar la naturaleza de un proceso lo ms rpido posible y programar el
proceso en consecuencia.

Las colas de respuesta de niveles mltiples (Fig. 8.4) ayudan a lograr estas metas.17 Un nuevo
proceso entra en la red de colas en la cola de la cola ms alta. El proceso progresa a travs de esa
cola en orden FIFO hasta que el proceso obtiene un procesador. Si el proceso completa su
ejecucin, o si renuncia al procesador a esperar la finalizacin de E / S o la finalizacin de algn
otro evento, sale de la red de colas. Si el quantum de un proceso expira antes de que el proceso
renuncie voluntariamente al procesador, el sistema coloca el proceso en la cola de la siguiente
cola de nivel inferior. Mientras el proceso use el quantum completo proporcionado en cada nivel,
contina movindose a la cola de la siguiente cola inferior. Normalmente hay alguna cola de nivel

Figura 8.4 | Colas de comentarios de niveles mltiples.

inferior a travs de la cual el proceso circula round robin hasta que se completa. El siguiente
proceso que recibe un procesador es el que est al frente de la cola ms alta no vaca en la cola de
realimentacin de varios niveles. Un proceso en ejecucin es preempted por uno que llega en una
cola ms alta.

En este sistema, un proceso en una cola inferior puede sufrir un aplazamiento indefinido, si una
cola ms alta siempre contiene al menos un proceso. Esto puede ocurrir en sistemas que tienen
una alta tasa de procesos entrantes para ser atendidos, o en el cual hay varios procesos de E / S
que consumen sus cuantos.

En muchos esquemas de retroalimentacin multinivel, el programador aumenta el tamao

cuntico de un proceso a medida que el proceso se desplaza a cada cola de nivel inferior. Por lo
tanto, cuanto ms tiempo ha estado un proceso en la red de colas, mayor es el cunto que recibe
cada vez que obtiene el procesador. Pronto veremos por qu esto es apropiado.

Examinemos el tratamiento que reciben los procesos considerando cmo esta disciplina responde
a diferentes tipos de procesos. Las colas de respuesta de niveles mltiples favorecen los procesos I
/ Obound y otros procesos que necesitan slo pequeas rfagas de tiempo del procesador, porque
entran en la red con alta prioridad y obtienen un procesador rpidamente. La disciplina elige para
la primera cola un quantum lo suficientemente grande como para que la gran mayora de los
procesos de E / S (y procesos interactivos) emitan una solicitud de E / S antes de que ese quantum
expire. Cuando un proceso solicita E / S, abandona la red de colas, habiendo recibido el
tratamiento deseado deseado. El proceso vuelve a entrar en la red cuando est listo.

Ahora considere un proceso vinculado al procesador. El proceso entra en la red con alta prioridad,
y el sistema lo coloca en la cola de nivel ms alto. En este punto, la red de colas no "sabe" si el
proceso est vinculado al procesador o al lmite de E / S, la meta de la red es decidir esto
rpidamente. El proceso obtiene el procesador rpidamente, usa su quantum completo, su
quantum expira, y el planificador mueve el proceso a la siguiente cola inferior. Ahora el proceso
tiene una prioridad inferior, y los procesos entrantes obtienen primero el procesador. Esto
significa que los procesos interactivos seguirn recibiendo buenos tiempos de respuesta, aun
cuando muchos procesadores se hunden en la red de colas. Eventualmente, el procesador-bound
proceso obtiene el procesador, recibe un quantum ms grande que en la cola ms alta y de nuevo
utiliza su quntum completo. El planificador entonces coloca el proceso en la cola de la siguiente
cola menor. El proceso contina movindose a colas ms bajas, espera ms tiempo entre los
intervalos de tiempo y usa su cuntica completa cada vez que obtiene el procesador (a menos que
sea anticipado por un proceso que llegue). Eventualmente, el procesador-bound proceso llega a la
cola de nivel ms bajo, donde circula round-robin con otros procesos de procesador de procesos
hasta que se complete.

Auto revisin

1. Qu objetivos de programacin se deben evaluar al elegir el nmero de niveles que se

utilizarn en una cola de realimentacin de varios niveles?

2. Por qu son deseables los mecanismos de adaptacin en los planificadores actuales?

Resp:
1) Un objetivo principal es la variacin en los tiempos de respuesta. Aumentar el nmero de
niveles puede hacer que procesos procesados por el procesador esperen ms, lo que aumenta la
variacin en los tiempos de respuesta. Otro objetivo a considerar es la utilizacin de los recursos.
A medida que aumenta el nmero de niveles, muchos procesos pueden ejecutar y emitir E / S
antes de que sus cuantos expiren, lo que resulta en un uso efectivo tanto del tiempo del
procesador como de los dispositivos de E / S.

2) En las computadoras de hoy en da, muchas aplicaciones pueden ser computacionalmente

intensivas y vinculadas a E / S. Por ejemplo, un reproductor de video de flujo continuo debe
realizar E / S para recuperar datos de videoclips de un servidor remoto, debe realizar operaciones
de computacin intensiva para decodificar y mostrar las imgenes de video. Del mismo modo, un
juego interactivo como un simulador de vuelo debe responder a la entrada del usuario (por
ejemplo, movimientos de la palanca de mando) mientras se procesan escenas 3D complicadas. Los
mecanismos adaptativos permiten al sistema proporcionar respuestas alternativas a estos
procesos, ya que alternan entre el comportamiento vinculado a E / S y el procesador.