Unidad4

Sistemas Operativos Unidad 4

4. ADMINISTRACIÓN DEL PROCESADOR
La asignación de procesadores físicos a los procesos hace posible que éstos realicen
su trabajo, y tal asignación es un problema complejo manejado por el sistema operativo.

4.1 NIVELES, OBJETIVOS Y CRITERIOS DE LA PLANIFICACIÓN

4.1.1 NIVELES DE PLANIFICACIÓN
Se tratarán tres niveles importantes de planificación (figura 4.1.)

Planificación de alto nivel. También conocida como planificación de trabajo, determina
cuáles trabajos podrán competir activamente por los recursos del sistema o cuáles trabajos
deben admitirse en el sistema, por lo que también se llama planificación de admisión. Una
vez admitidos, los trabajos se convierten en procesos o grupos de procesos.

Planificación de nivel intermedio. Determina qué procesos pueden competir por la CPU.
El planificador de nivel intermedio responde a las fluctuaciones temporales en la carga del
sistema mediante la suspensión temporal y la activación (o reanudación) de procesos para
lograr una operación más fluida del sistema y para ayudar al alcanzar ciertas metas globales
de rendimiento del sistema. Este planificador de nivel intermedio actúa, pues, como
amortiguador entre la admisión de trabajos en el sistema y la asignación de la CPU a esos
trabajos.

Planificación de bajo nivel. Determina a cuál proceso listo se le asignará la CPU cuando
ésta se encuentre disponible, y de hecho se encarga de asignar la CPU a ese proceso (es
decir, despacha la CPU al proceso). La planificación de bajo nivel se realiza mediante el
despachador (dispatcher), que opera muchas veces por segundo. El despachador debe
residir en todo momento en el almacenamiento primario.

Universidad Autónoma de Nayarit 1


Figura 4.1 Niveles de planificación



4.1.2 OBJETIVOS DE LA PLANIFICACIÓN
En el diseño de una disciplina de planificación deben considerarse muchos objetivos.
En particular, una disciplina de planificación debe:
• Ser justa: Una disciplina de planificación es justa si todos los procesos se tratan de
la misma forma y ningún proceso se aplaza en forma indefinida.
• Elevar al máximo la producción o rendimiento: Una disciplina de planificación
debe tratar de atender el mayor número posible de procesos por unidad de tiempo.
• Aumentar al máximo el número de usuarios interactivos que reciben respuesta en
tiempos aceptables (es decir, en unos cuantos segundos).
• Ser predecible: Una tarea debe ejecutarse aproximadamente en el mismo tiempo y
casi al mismo costo sea cual sea la carga del sistema.
• Reducir al mínimo el gasto extra: Contra lo que podría pensarse, este punto no suele
considerarse como uno de los objetivos más importantes. El gasto extra se considera
por lo común como un desperdicio de recursos, pero la inversión de cierta porción
de los recursos del sistema como gasto extra puede mejorar en gran medida el
rendimiento total del sistema.
• Equilibrar el aprovechamiento de los recursos: Los mecanismos de planificación
deben mantener ocupados los recursos del sistema. Deben favorecerse los procesos
que requieren recursos poco utilizados.
• Lograr un equilibrio entre la respuesta y el aprovechamiento: La mejor manera de
garantizar tiempos de respuesta adecuados es tener suficientes recursos disponibles
en el momento en que son necesarios. El precio que se debe pagar por esta
estrategia es que el aprovechamiento global de los recursos será pobre. En los
sistemas de tiempo real, las respuestas rápidas son esenciales y el aprovechamiento
de los recursos es menos importante. En otros tipos de sistemas, la economía exige
un aprovechamiento efectivo de los recursos.
• Evitar el aplazamiento indefinido: En muchos casos, el aplazamiento indefinido es
tan perjudicial como el bloqueo mutuo. La mejor forma de evitarlo es emplear el
envejecimiento; es decir, mientras un proceso espera un recurso, su prioridad debe
crecer. En algún momento, la prioridad será tan alta que el recurso se asignará al
proceso.
• Imponer prioridades: En los ambientes en que se asignan prioridades a los
procesos, los mecanismos de planificación deben favorecer a los proceso de más
alta prioridad.
• Dar preferencia a los procesos que ocupan recursos decisivos: Aunque un proceso
tenga baja prioridad, podría estar ocupando un recurso decisivo, y el recurso puede
ser requerido por un proceso de prioridad alta. Si el recurso no es apropiable, el
mecanismo de planificación debe dar al proceso un trato mejor del que se le daría de
ordinario, de manera que libere el recurso con más rapidez.



• Dar un mejor trato a los procesos que muestren un comportamiento deseable (por
ejemplo, tasas bajas de paginación).
• Degradarse paulatinamente con las cargas pesadas: Un mecanismo de
planificación no debe desplomarse bajo el peso de una carga fuerte en el sistema.
Debe evitar la carga excesiva impidiendo la creación de procesos nuevos cuando la
carga es pesada, o bien debe dar servicio a la carga mayor con una reducción
moderada del nivel de atención a todos los procesos.
Muchas de estas metas están en conflicto unas con otras, por lo que la planificación se torna
un problema complejo.

4.1.3 CRITERIOS DE LA PLANIFICACIÓN
Para lograr los objetivos de planificación, un mecanismo debe considerar:
• La limitación de un proceso por entrada y salida. Cuando un proceso obtiene la
CPU, ¿sólo la usará brevemente antes de generar una petición de E/S?
• La limitación de un proceso por CPU. Cuando un proceso obtiene la CPU, ¿tiende a
usarla hasta que expira su cuanto de tiempo?
• Si un proceso es por lotes o interactivo. Los usuarios interactivos suelen hacer
peticiones "triviales" que deben atenderse de inmediato para garantizar tiempos de
respuesta adecuados. Los usuarios por lotes por lo general pueden tolerar retrasos
razonables.
• Cuán urgente es la respuesta. Un proceso por lotes que tarda toda la noche no
necesitará una respuesta inmediata. Un sistema de control de procesos en tiempo
real que supervise una refinería de petróleo requiere una respuesta rápida, quizás
para evitar una explosión.
• Las prioridades de los procesos. Los procesos de alta prioridad deben recibir mejor
tratamiento que los de baja prioridad.
• La frecuencia con la que un proceso está generando fallas de página.
Supuestamente, un proceso que genera pocas fallas de página tiene acumulados sus
conjuntos de trabajo en el almacenamiento principal. Pero los procesos que
experimentan muchas fallas de página no han establecido aún sus conjuntos de
trabajo, y lo convencional es favorecer a los procesos que ya los han establecido.
Otro punto de vista es que los procesos con altas tasas de fallas de página deben
tener preferencia, ya que usan poco la CPU antes de generar una petición de E/S.
• La frecuencia con la que los recursos de un proceso son apropiados por otro de
mayor prioridad. Los procesos cuyos recursos son apropiados muy a menudo deben
recibir un tratamiento menos favorable. La cuestión es que cada vez que el sistema
operativo invierte trabajo extra en echar a andar este proceso, el breve lapso de
ejecución que se logra antes de la apropiación no justifica el gasto extra necesario
para echar a andar el proceso en primer lugar.



• Cuánto tiempo real de ejecución ha recibido el proceso. Algunos diseñadores opinan
que deben favorecerse los procesos con poco tiempo de ejecución. Otro punto de
vista es que un proceso que ha recibido mucho tiempo de ejecución debe estar por
terminar y debe favorecerse para ayudarlo a que termine y abandone el sistema tan
pronto como sea posible.
• Cuánto tiempo más necesitará el proceso para terminar. Los tiempos de espera
promedio pueden reducirse al mínimo ejecutando primero aquellos procesos que
requieran los menores tiempos de ejecución para terminar. Por desgracia, casi nunca
se sabe con exactitud cuánto tiempo durará un proceso.

4.1.4 PLANIFICACIÓN APROPIATIVA Y NO APROPIATIVA
Una disciplina de planificación es no apropiativa si una vez que la CPU ha sido asignada al
proceso, ya no se le puede arrebatar. Una disciplina de planificación es apropiativa si al
proceso se le puede arrebatar la CPU.
La planificación apropiativa es útil en los sistemas en los cuales los procesos de alta
prioridad requieren una atención rápida. En los sistemas de tiempo real, por ejemplo, las
consecuencias de perder una interrupción pueden ser desastrosas. En los sistemas
interactivos de tiempo compartido, la planificación apropiativa es importante para
garantizar tiempos de respuesta aceptables.
La apropiación tiene un precio. El cambio de contexto implica un gasto extra. Para que la
técnica de apropiación sea efectiva deben mantenerse muchos procesos en almacenamiento
principal de manera que el siguiente proceso se encuentre listo cuando quede disponible la
CPU. Conservar en el almacenamiento principal programas que no estén en ejecución
también implica un gasto extra. En los sistemas no apropiativos, los trabajos largos retrasan
a los cortos, pero el tratamiento para todos los procesos es más justo. Los tiempos de
respuesta son más predecibles porque los trabajos nuevos de alta prioridad no pueden
desplazar a los trabajos en espera.
Al diseñar un mecanismo de planificación apropiativa no hay que perder de vista la
arbitrariedad de casi todos los sistemas de prioridades. Se puede construir un mecanismo
complejo para implantar fielmente un esquema de apropiación por prioridades sin que, de
hecho, se hayan asignado las prioridades en forma coherente. En los sistemas operativos no
es raro encontrar mecanismos rebuscados que apoyan esquemas un tanto arbitrarios. El
diseñador debe evaluar con todo cuidado cada mecanismo propuesto antes de implantarlo.
La sencillez resulta atractiva, pero si el mecanismo no se puede hacer sencillo, debe tratarse
al menos de hacerlo efectivo y significativo.

4.1.5 EL CRONÓMETRO DE INTERVALOS O RELOJ DE INTERRUPCIONES
Se dice que el proceso al cual está asignada la CPU está en ejecución. Si el proceso
pertenece al sistema operativo, se dice que el sistema operativo está en ejecución y puede
tomar decisiones que afectan la operación del sistema. Para evitar que los usuarios
monopolicen el sistema (ya sea deliberada o accidentalmente), el sistema operativo tiene
mecanismos para arrebatar la CPU al usuario.



El sistema operativo mantiene un reloj de interrupciones o cronómetro de intervalos para
generar interrupciones en algún momento futuro específico (o después de cierto tiempo).
Luego la CPU se despacha al proceso. Éste mantiene el control de la CPU hasta que la
libera voluntariamente, hasta que el reloj interrumpe o hasta que alguna otra interrupción
desvía la atención de la CPU. Si el usuario se encuentra en ejecución y el reloj interrumpe,
el sistema operativo entra en ejecución y entonces decide a qué proceso se asignará
enseguida la CPU.
El reloj de interrupciones ayuda a garantizar tiempos de respuesta aceptables para los
usuarios interactivos, evita que el sistema quede bloqueado en un ciclo infinito de algún
usuario y permite que los procesos respondan a eventos dependientes de tiempo. Los
procesos que deben ejecutarse periódicamente dependen del reloj de interrupciones.

4.1.6 PRIORIDADES
Las prioridades pueden ser asignadas en forma automática por el sistema, o bien se pueden
asignar externamente. Pueden ganarse o comprarse. Pueden ser estáticas o dinámicas.
Pueden asignarse en forma racional, o de manera arbitraria en situaciones en las que un
mecanismo del sistema necesita distinguir entre procesos pero no le importa cuál de ellos es
en verdad más importante.

Prioridades estáticas y dinámicas
Las prioridades estáticas no cambian. Los mecanismos de prioridad estática son fáciles de
llevar a la práctica e implican un gasto extra relativamente bajo. Sin embargo, no responden
a cambios en el ambiente que podrían hacer necesario un ajuste de prioridades.
Los mecanismos de prioridad dinámica responden a los cambios. La prioridad inicial
asignada a un proceso tiene una duración corta, después de lo cual se ajusta a un valor más
apropiado. Los esquemas de prioridad dinámica son más complejos e implican un mayor
gasto extra que los esquemas estáticos. El gasto extra queda justificado por el aumento en la
sensibilidad del sistema.

Prioridades compradas
Un sistema operativo debe proporcionar un servicio competente y razonable a una gran
comunidad de usuarios, pero también debe manejar las situaciones en las cuales un
miembro de la comunidad necesite un trato especial.

Un usuario con un trabajo urgente puede estar dispuesto a pagar extra, es decir, comprar
prioridad, por un nivel más alto de servicio. Este pago extra es obligatorio debido a que
puede ser necesario arrebatar recursos a otros usuarios que también pagan. Si no hubiera un
pago extra, entonces todos los usuarios pedirían un nivel más alto de servicio.



4.2 ALGORITMOS DE SECUENCIACIÓN
4.2.1 PLANIFICACIÓN DE PLAZO FIJO (apropiativa)
En la planificación de plazo fijo se programan ciertos trabajos para terminarse en un tiempo
específico o plazo fijo. Estos trabajos pueden tener un gran valor si se entregan a tiempo, y
carecer de él si se entregan después del plazo. A menudo los usuarios están dispuestos a
pagar algo extra con tal de asegurar la terminación a tiempo. La planificación de plazo fijo
es compleja por muchas razones.
• El usuario debe informar por adelantado de las necesidades precisas de recursos
de la tarea. Semejante información rara vez está disponible.
• El sistema debe ejecutar la tarea a plazo fijo sin degradar demasiado el servicio
a los otros usuarios.
• El sistema debe planificar cuidadosamente sus necesidades de recursos dentro
del plazo. Ello puede ser difícil por la llegada de nuevos procesos que impongan
demandas impredecibles al sistema.
• Si hay muchas tareas a plazo fijo activas al mismo tiempo, la planificación
puede ser tan compleja que se necesiten métodos de optimización avanzados
para cumplir con los plazos.
• La administración intensiva de recursos requerida por la planificación de plazo
fijo puede producir un gasto extra sustancial. Aunque los usuarios estén
dispuestos a pagar una cuota alta por los servicios recibidos, el consumo neto de
los recursos del sistema puede ser tan alto que el resto de la comunidad puede
sufrir una degradación del servicio. Los diseñadores de sistemas operativos
deben considerar con cuidado tales conflictos.

4.2.2 PLANIFICACIÓN DE PRIMERAS ENTRADAS-PRIMERAS SALIDAS
(PEPS) (no apropiativa)
Tal vez la disciplina más simple de planificación sea la de primeras entradas-primeras
salidas (PEPS)(Figura 4.2). Los procesos se despachan de acuerdo con su tiempo de llegada
a la cola de procesos listos. Cuando un proceso tiene la CPU, se ejecuta hasta terminar. La
disciplina PEPS es no apropiativa. Es justa en el sentido formal, pero algo injusta en cuanto
a que los trabajos largos hacen esperar a los cortos y los trabajos sin importancia hacen
esperar a los importantes. PEPS ofrece variaciones relativamente pequeñas en los tiempos
de respuesta y por tanto es más predecible que los otros esquemas. No es útil en la
planificación para usuarios interactivos porque no puede garantizar buenos tiempos de
respuesta.

Figura 4.2 Planificación de primeras entradas-primeras salidas



El esquema PEPS rara vez se usa como esquema principal en los sistemas actuales, pero a
menudo está incorporado en otros esquemas. Por ejemplo, muchos esquemas de
planificación despachan los procesos de acuerdo con la prioridad, pero los procesos con la
misma prioridad se despachan mediante el esquema PEPS.

4.2.3 PLANIFICACIÓN ROUND ROBIN (RR) (apropiativa)
En la planificación Round Robin (por turno) (Figura 4.3), los procesos se despachan en
forma PEPS, pero se les asigna una cantidad limitada de tiempo de CPU conocida como
división de tiempo o quantum. Si un proceso no termina antes de que expire su tiempo de
CPU, se le quita la CPU y ésta se asigna al siguiente proceso en espera. El proceso
desposeído se coloca al final de la lista de procesos listos.
La asignación por turno es afectiva en ambientes de tiempo compartido en los cuales el
sistema necesita garantizar tiempos de respuesta razonables para usuarios interactivos. El
gasto extra debido a la apropiación es bajo gracias a eficientes mecanismos de cambio de
contexto y a la asignación de suficiente memoria para que los procesos residan en el
almacenamiento principal al mismo tiempo.

Kleinrock presenta una variable de la planificación por turno conocida como planificación
por turno egoísta. En este esquema, cuando un proceso entra en el sistema reside en
principio en una cola de espera hasta que su prioridad alcanza el nivel de las prioridades de
los procesos que están en la cola activa. Mientras un proceso está en la cola de espera, su
prioridad aumenta con una tasa a hasta que es lo bastante alta para entrar en la cola activa,
y a partir de ese momento su prioridad aumenta con una tasa b.

4.2.4 TAMAÑO DEL QUANTUM
La determinación del tamaño del cuanto es vital para la operación efectiva de un sistema de
cómputo.



Si el cuanto es muy grande, cada proceso tendrá el tiempo necesario para terminar, de
manera que el esquema de planificación por turno degenera en uno de primeras entradas -
primeras salidas. Si el cuanto es muy pequeño, el gasto extra por cambio de contexto se
convierte en el factor dominante y el rendimiento del sistema se degradará hasta el punto en
que la mayor parte del tiempo se invierta en la conmutación del procesador, con muy poco
o ningún tiempo para realizar los cálculos de los usuarios.

4.2.5 PLANIFICACIÓN POR PRIORIDAD DEL TRABAJO MÁS CORTO (SJF)
(noapropiativa)
La planificación por prioridad del trabajo más corto (SJF, shortest-job-first) es una
disciplina no apropiativa según la cual se ejecuta primero el trabajo (o proceso) en espera
que tiene el menor tiempo estimado de ejecución hasta terminar. SJF reduce el tiempo de
espera promedio de PEPS, pero, los tiempos de espera tienen una variación más grande (es
decir, son más impredecibles) que los de PEPS, sobre todo el caso de trabajos grandes.
SJF favorece los trabajos (o procesos) cortos a expensas de los largos. Muchos diseñadores
declaran que cuanto más pequeño sea el trabajo, mejor será el servicio que reciba. No hay
un acuerdo universal al respecto en especial cuando deben tenerse en cuenta las prioridades
de los trabajos.
SJF selecciona trabajos para atenderlos de manera que se asegure que el siguiente trabajo se
completará y saldrá del sistema lo antes posible. Esto tiende a reducir el número de trabajos
en espera, y reduce también el número de los que esperan detrás de un trabajo grande.
Como resultado, SJF puede reducir al mínimo el tiempo de espera promedio de los trabajos
que entran en el sistema.

El problema obvio con SJF es que exige conocer con exactitud el tiempo que tardará en
ejecutarse un trabajo o proceso, y esa información no suele estar disponible; lo mejor que
puede hacer SJF es basarse en los tiempos de ejecución estimados por el usuario. En los
ambientes de producción donde se ejecutan regularmente los mismos trabajos es posible
proporcionar estimaciones razonables, pero en los ambientes de desarrollo los usuarios rara
vez conocen el tiempo que tardaran en ejecutarse sus programas.
Basarse en las estimaciones de los usuarios tiene una consecuencia interesante. Si los
usuarios saben que el sistema está diseñado para favorecer trabajos con cortos tiempos
estimados de ejecución, pueden proporcionar estimaciones bajas. No obstante, el
planificador puede ser diseñado de manera que elimine semejante tentación. Se puede
indicar al usuario con anticipación que si su trabajo se ejecuta en más tiempo del estimado
será suspendido y el usuario deberá pagar el trabajo. Una segunda opción es ejecutar el
trabajo durante el tiempo estimado más un pequeño porcentaje extra y después aplazarlo, es
decir preservarlo en su forma actual para proseguir con su ejecución en un momento
posterior. Lógicamente, el usuario ha de pagar el gasto extra del aplazamiento y la
reactivación y sufrirá un retraso en la terminación del trabajo. Otra solución es ejecutar la
tarea durante el tiempo estimado a tarifas normales y después cobrar una tarifa extra, muy
por encima de la normal, por el tiempo adicional de ejecución. En este sistema, el usuario
que proporcione estimaciones exageradamente bajas para obtener mejor servicio acabará
pagando una cuota muy alta.



SJF, al igual que PEPS, no es apropiativa y por tanto no resulta útil en ambientes de tiempo
compartido en los que deben garantizarse tiempos de respuesta razonables.

4.2.6 PLANIFICACIÓN POR EL TIEMPO RESTANTE MÁS CORTO (SRT)
(apropiativa)
La planificación por el tiempo restante más corto (SRT, shortest-remaining-time-
scheduling) es la contraparte apropiativa de SJF y es útil en tiempo compartido. En SRT, el
proceso con el menor tiempo estimado de ejecución para terminar es el primero en
ejecutarse, incluyendo los procesos nuevos. En SJF, una vez que un trabajo comienza su
ejecución continúa hasta terminar. En SRT, un proceso en ejecución puede ser desposeído
por uno nuevo con menor tiempo de ejecución estimado. SRT también requiere
estimaciones efectivas del futuro y el diseñador debe tener en cuenta el posible abuso por
parte del usuario de las estrategias de planificación del sistema.
SRT implica un mayor gasto extra que SJF. Debe estar al tanto del tiempo transcurrido de
servicio del trabajo en ejecución y debe manejar apropiaciones ocasionales. Los procesos
pequeños que llegan se ejecutarán casi de inmediato. Los trabajos grandes, empero, tienen
un tiempo de espera promedio más largo y una variación del tiempo de espera mayor que
en SJF.
SRT requiere registrar el tiempo de servicio transcurrido y ello con tribuye al gasto extra
del esquema. En teoría, SRT ofrece tiempos mínimos de espera, pero debido al gasto extra
de la apropiación, es posible que SJF tenga mayor rendimiento en ciertos casos.

4.2.7 PLANIFICACIÓN POR PRIORIDAD DE LA TASA DE RESPUESTA MÁS
ALTA (HRN) (no apropiativa)
Brinch Hansen desarrolló la estrategia de prioridad de la tasa de respuesta más alta (HRN,
highest-response-ratio-next) que corrige algunas deficiencias de SJF, particularmente el
retraso excesivo de trabajos largos y el favoritismo excesivo para los trabajos cortos. HRN
es una disciplina de planificación no apropiativa en la cual la prioridad de cada trabajo no
sólo es función del tiempo de servicio, sino también del tiempo que ha esperado el trabajo
para ser atendido. Cuando un trabajo obtiene el procesador, se ejecuta hasta terminar. Las
prioridades dinámicas en HRN se calculan de acuerdo con la siguiente fórmula:

Prioridad = tiempo de espera + tiempo de servicio
Como el tiempo de servicio aparece en el denominador, los trabajos cortos tendrán
preferencia. Pero como el tiempo de espera aparece en el numerador, los trabajos largos que
han esperado también tendrán un trato favorable. Obsérvese que la suma

Tiempo de espera + tiempo de servicio
es el tiempo de respuesta del sistema para el trabajo si éste se inicia de inmediato.



4.2.8 COLAS DE RETROALIMENTACIÓN EN MÚLTIPLES NIVELES
(apropiativa)
Cuando un proceso obtiene la CPU, sobre todo cuando todavía no ha tenido oportunidad de
establecer un patrón de comportamiento, el planificador no tiene idea de la cantidad de
tiempo de CPU que necesitará el proceso. Los procesos limitados por E/S normal mente
usan CPU sólo un momento antes de generar una solicitud de E/S; los procesos limitados
por CPU pueden usar el procesador durante horas si está disponible en forma no
apropiativa.
Un mecanismo de planificación debe:
• favorecer los trabajos cortos,
• favorecer los trabajos limitados por E/S para lograr un mejor aprovechamiento
de los dispositivos de entrada/salida, y
• determinar la naturaleza de un trabajo lo más pronto posible y planificarlo de
acuerdo con su naturaleza.

Las colas de retroalimentación en múltiples niveles (Figura 4.4) ofrecen una estructura que
cumple con estos objetivos. Un proceso nuevo entra en la red de colas al final de la primera
cola. Se desplaza en esa cola por PEPS hasta que obtiene la CPU. Si el trabajo termina o
cede la CPU para esperar la terminación de una operación de E/S o de algún evento, el
trabajo abandona la red de colas. Si el cuanto expira antes de que el proceso ceda
voluntariamente la CPU, el proceso se colocará al final de la cola del siguiente nivel. El
proceso será atendido otra vez cuando llegue a la cabeza de esa cola si está vacía la
primera. Mientras el proceso utilice todo el cuanto proporcionado en cada nivel, continuará
desplazándose al final de la siguiente cola inferior. Por lo general, existe una cola en el
nivel más bajo en la cual el proceso circula por turno (RR) hasta que termina.
En muchos esquemas de retroalimentación en múltiples niveles, el cuanto asignado al
proceso cuando pasa a una cola de nivel inferior alcanza un valor mayor. De esta forma,
cuanto más tiempo se encuentre un proceso en la red de colas más grande será el cuanto
asignado cada vez que obtenga la CPU, pero tal vez no obtenga la CPU muy a menudo,
porque los procesos de las colas de nivel superior tienen mayor prioridad. Un proceso en
cierta cola no puede ejecutarse a menos que estén vacías las colas de nivel más alto. Un
proceso en ejecución será desposeído por un proceso que llegue a una cola superior.
Considérese ahora cómo responde un mecanismo de ese tipo a diferentes tipos de procesos.
El mecanismo debe favorecer los procesos limitados por E/S para lograr un buen
aprovechamiento de los dispositivos y una buena respuesta para los usuarios interactivos; y
de hecho lo hace porque los procesos limitados por E/S entrarán en la red con alta prioridad
y rápidamente les será asignada la CPU. El tamaño del cuanto de la primera cola se elegirá
lo bastante grande para que la gran mayoría de los trabajos limitados por E/S generen una
petición de E/S antes de que expire el primer cuanto. Cuando el proceso solicita entrada
/salida, abandona la red y ha obtenido un tratamiento favorable, tal como se deseaba.



Ahora considérese una tarea limitada por CPU que necesita mucho tiempo de procesador.
Esa tarea entra en la cola más alta de la red con alta prioridad. Recibe rápidamente su
primera asignación de la CPU, pero su cuanto expira y el proceso se coloca en la cola del
siguiente nivel inferior. En ese momento, el proceso tiene una prioridad menor que la de los
procesos que llegan al sistema, en particular los trabajos limitados por E/S, que obtienen
primero la CPU. El proceso limitado por CPU acaba recibiendo ésta, obtiene un cuanto
mayor que en la cola más alta y vuelve a utilizar la totalidad de su cuanto. Luego es situado
al final de la siguiente cola inferior. El proceso sigue desplazándose a colas inferiores,
espera más entre divisiones de tiempo y utiliza todo su cuanto cada vez que obtiene la CPU
(a menos que ésta sea arrebatada por un proceso entrante). En algún momento, el proceso
limitado por CPU llega a la cola de más bajo nivel en donde entrará en una planificación
por turno hasta terminar.



Las colas de retroalimentación con múltiples niveles son ideales para separar procesos en
categorías basadas en su necesidad de la CPU. En un sistema de tiempo compartido, cada
vez que un proceso abandona 'a red de colas puede "marcarse" con la identidad de la última
cola en donde estuvo, y cuando el proceso entra de nuevo en la red de colas, puede enviarse
directamente a la cola en la cual terminó su operación por última vez. En este caso, el
planificador está usando un razonamiento heurístico, según el cual el comportamiento
anterior del proceso es un buen indicador de su comportamiento en un futuro inmediato. De
esta forma, un proceso limitado por CPU que regresa a la red de colas no se coloca en las
colas de alto nivel, donde interferiría con el servicio a los procesos cortos de alta prioridad
o con los limitados por E/S.
Si los procesos se colocan siempre dentro de la red en la cola que ocuparon la última vez,
será imposible que el sistema responda a cambios de un proceso, por ejemplo, de estar
limitado por CPU a estar limitado por E/S. El problema puede resolverse marcando al
proceso también con su duración dentro de la red la última vez que estuvo en ella. Así,
cuando el proceso entra de nuevo en la red puede colocarse en la cola correcta. Entonces, si
el proceso entra en una fase nueva en la cual deja de estar limitado por CPU y empieza a
estar limitado por E/S, el proceso experimentará en principio un tratamiento lento mientras
el sistema determina que la naturaleza del proceso está cambiando. Pero el mecanismo de
planificación responderá con rapidez a este cambio. Otra forma de hacer que el sistema
responda a los cambios en el comportamiento de los procesos es permitir que un proceso
ascienda un nivel en la red de colas cada vez que abandona voluntariamente la CPU antes
de que expire su cuanto.
El mecanismo de colas de retroalimentación en múltiples niveles es un buen ejemplo de
mecanismo adaptativo, que responde a los cambios en el comportamiento del sistema que
controla. Los mecanismos adaptativos implican en general una carga extra mayor que los
no adaptativos pero la sensibilidad ante los cambios en el sistema da como resultado una
mejor capacidad de respuesta y justifica el aumento en el gasto extra.
Una variante común del mecanismo de colas de retroalimentación en múltiples niveles
consiste en hacer que un proceso circule por turno varias veces en cada cola antes de pasar
a la siguiente cola inferior. El número de ciclos en cada cola crece por lo regular cuando el
proceso pasa a la siguiente cola inferior.

4.2.9 PLANIFICACIÓN DE PORCIÓN JUSTA (APROPIATIVA)
Los sistemas manejan por lo general varios conjuntos de procesos relacionados entre sí (por
ejemplo, un conjunto de procesos pertenecientes a un usuario en particular); la
planificación de porción justa (FSS, fair share scheduling) permite la planificación de tales
conjuntos de procesos. En el ambiente UNIX, FSS se desarrolló para "proporcionar a un
costo fijo una tasa previamente especificada de los recursos del sistema a un conjunto de
usuarios relacionados entre sí.

Normalmente, UNIX aplica parecidas tasas de consumo de recursos a todos los procesos
(figura 4.5), pero con FSS los recursos se reparten a varios grupos de porción justa (figura
4.6).Los recursos no utilizados por un grupo de porción justa se distribuyen a otros grupos
en proporción a sus necesidades relativas.



Figura 4.5 Planificador estándar de procesos. El planificador asigna al procesador a los usuarios, cada uno
de los cuales puede tener muchos procesos.

Figura 4.6 Planificador de porción justa divide los recursos del sistema en porciones, las cuales se
asignan a los planificadores de procesos de varios grupos de porción justa.



Existen mandatos de UNIX para establecer grupos de porción justa y asociar usuarios
específicos a esos grupos. UNIX utiliza un planificador por turno con prioridad. Cada
proceso tiene una prioridad y los procesos con cierta prioridad se asocian a una cola de
prioridad adecuada. El planificador de procesos elige al proceso listo que está a la cabeza
de la cola de más alta prioridad, y los procesos con una misma prioridad se asignan por
turno; un proceso que todavía requiere servicio después de ceder la CPU tendrá una
prioridad menor; las prioridades del kernel son altas y se aplican a los procesos que se
ejecutan dentro de él: los eventos de disco tienen una prioridad mayor que los de terminal;
las prioridades de usuario son menores que las del kernel. La prioridad del usuario es la
razón entre la utilización reciente del procesador y el tiempo real transcurrido: cuanto
menor sea este valor mayor será la prioridad.
Los grupos de porción justa obtienen prioridades de acuerdo con su proximidad a la
consecución de sus metas en la utilización de recursos. Los grupos que van mal tienen
mayor prioridad; los otros tienen una prioridad menor. Este tipo de esquema de equilibrio
dinámico de cangas fue investigado en el proyecto Multics del proyecto MAC de M.I.T.


Unidad4

Recommended

Recommended

More Related Content

What's hot

What's hot (14)

Similar to Unidad4

Similar to Unidad4 (20)

More from Universidad Autónoma de Nayarit

More from Universidad Autónoma de Nayarit (20)

Unidad4