SlideShare una empresa de Scribd logo
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
Sistemas Operativos                                         Unidad 4




                      Figura 4.1 Niveles de planificación



                      Universidad Autónoma de Nayarit       2
Sistemas Operativos                                                                        Unidad 4


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.




                               Universidad Autónoma de Nayarit                             3
Sistemas Operativos                                                                        Unidad 4


   •   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.




                               Universidad Autónoma de Nayarit                             4
Sistemas Operativos                                                                         Unidad 4


   •   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.



                                Universidad Autónoma de Nayarit                             5
Sistemas Operativos                                                                        Unidad 4


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.




                               Universidad Autónoma de Nayarit                             6
Sistemas Operativos                                                                         Unidad 4


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


                                Universidad Autónoma de Nayarit                            7
Sistemas Operativos                                                                        Unidad 4




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.




                               Universidad Autónoma de Nayarit                             8
Sistemas Operativos                                                                        Unidad 4


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.


                               Universidad Autónoma de Nayarit                             9
Sistemas Operativos                                                                       Unidad 4


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.




                                Universidad Autónoma de Nayarit                          10
Sistemas Operativos                                                                       Unidad 4


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.




                               Universidad Autónoma de Nayarit                           11
Sistemas Operativos                                                                        Unidad 4




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.


                               Universidad Autónoma de Nayarit                            12
Sistemas Operativos                                                                        Unidad 4


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.


                                Universidad Autónoma de Nayarit                             13
Sistemas Operativos                                                                                       Unidad 4




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.



                                    Universidad Autónoma de Nayarit                                     14
Sistemas Operativos                                                                      Unidad 4


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.




                               Universidad Autónoma de Nayarit                          15

Más contenido relacionado

La actualidad más candente

Manejo de procesos y procesador
Manejo de procesos y procesadorManejo de procesos y procesador
Manejo de procesos y procesador
Michael Vanegas
 
Planificación de Procesos-NéstorTraña
Planificación de Procesos-NéstorTrañaPlanificación de Procesos-NéstorTraña
Planificación de Procesos-NéstorTraña
Nestor Traña
 
U n i d a d 2 sist oper
U n i d a d    2 sist operU n i d a d    2 sist oper
U n i d a d 2 sist oper
floresitalagu
 
tecnologia 13 octubre 2011
tecnologia 13 octubre 2011tecnologia 13 octubre 2011
tecnologia 13 octubre 2011
anyomave
 
PLANIFICACION DE PROCESOS
PLANIFICACION DE PROCESOSPLANIFICACION DE PROCESOS
PLANIFICACION DE PROCESOS
Percy Javier Flores Mamani
 
Planificaion De Procesos
Planificaion De ProcesosPlanificaion De Procesos
Planificaion De Procesos
launica
 
Planificacion de Porcesos
Planificacion de PorcesosPlanificacion de Porcesos
Planificacion de Porcesos
guest18b3b79
 
planificacion de los procesos
planificacion de los procesosplanificacion de los procesos
planificacion de los procesos
vianycari
 
PLANIFICACION DE PROCESO
PLANIFICACION DE PROCESOPLANIFICACION DE PROCESO
PLANIFICACION DE PROCESO
gladysmamani
 
PLANIFICACION DE PROSECOS
PLANIFICACION DE PROSECOSPLANIFICACION DE PROSECOS
PLANIFICACION DE PROSECOS
merycondori
 
Ernesto planescontingencia
Ernesto planescontingenciaErnesto planescontingencia
Ernesto planescontingencia
francisnieto
 
2003 Clase0610
2003 Clase06102003 Clase0610
2003 Clase0610
Patricio Godoy
 
Sistemas Operativos[1]
Sistemas Operativos[1]Sistemas Operativos[1]
Sistemas Operativos[1]
guest5db8b1
 
Planificador del procesador
Planificador del procesadorPlanificador del procesador
Planificador del procesador
Colegio Agropecuario de San Carlos
 

La actualidad más candente (14)

Manejo de procesos y procesador
Manejo de procesos y procesadorManejo de procesos y procesador
Manejo de procesos y procesador
 
Planificación de Procesos-NéstorTraña
Planificación de Procesos-NéstorTrañaPlanificación de Procesos-NéstorTraña
Planificación de Procesos-NéstorTraña
 
U n i d a d 2 sist oper
U n i d a d    2 sist operU n i d a d    2 sist oper
U n i d a d 2 sist oper
 
tecnologia 13 octubre 2011
tecnologia 13 octubre 2011tecnologia 13 octubre 2011
tecnologia 13 octubre 2011
 
PLANIFICACION DE PROCESOS
PLANIFICACION DE PROCESOSPLANIFICACION DE PROCESOS
PLANIFICACION DE PROCESOS
 
Planificaion De Procesos
Planificaion De ProcesosPlanificaion De Procesos
Planificaion De Procesos
 
Planificacion de Porcesos
Planificacion de PorcesosPlanificacion de Porcesos
Planificacion de Porcesos
 
planificacion de los procesos
planificacion de los procesosplanificacion de los procesos
planificacion de los procesos
 
PLANIFICACION DE PROCESO
PLANIFICACION DE PROCESOPLANIFICACION DE PROCESO
PLANIFICACION DE PROCESO
 
PLANIFICACION DE PROSECOS
PLANIFICACION DE PROSECOSPLANIFICACION DE PROSECOS
PLANIFICACION DE PROSECOS
 
Ernesto planescontingencia
Ernesto planescontingenciaErnesto planescontingencia
Ernesto planescontingencia
 
2003 Clase0610
2003 Clase06102003 Clase0610
2003 Clase0610
 
Sistemas Operativos[1]
Sistemas Operativos[1]Sistemas Operativos[1]
Sistemas Operativos[1]
 
Planificador del procesador
Planificador del procesadorPlanificador del procesador
Planificador del procesador
 

Similar a Unidad4

Unidad4
Unidad4Unidad4
Administración de procesos y del procesador.pptx
Administración de procesos y del procesador.pptxAdministración de procesos y del procesador.pptx
Administración de procesos y del procesador.pptx
NoraTorres35
 
Sistema Operativo
Sistema OperativoSistema Operativo
Sistema Operativo
Jose Colina
 
Trabajo de sisope
Trabajo de sisopeTrabajo de sisope
Trabajo de sisope
amparopesantes
 
Trabajode Sisope
Trabajode SisopeTrabajode Sisope
Trabajode Sisope
amparopesantes
 
PLANIFICACION DE PROCESOS
PLANIFICACION DE PROCESOSPLANIFICACION DE PROCESOS
PLANIFICACION DE PROCESOS
gladysmamani
 
Planificacion de procesos
Planificacion de procesosPlanificacion de procesos
Planificacion de procesos
Yoselvi
 
Planificaion De Procesos
Planificaion De ProcesosPlanificaion De Procesos
Planificaion De Procesos
launica
 
expoci
expociexpoci
expoci
amluap
 
Planificaion de Procesos
Planificaion de ProcesosPlanificaion de Procesos
Planificaion de Procesos
FiorelaLV
 
SISTEMAS OPERATIVOS
SISTEMAS OPERATIVOSSISTEMAS OPERATIVOS
SISTEMAS OPERATIVOS
gladysmamani
 
Unidad3 pp planificacion del procesador
Unidad3 pp planificacion del procesadorUnidad3 pp planificacion del procesador
Unidad3 pp planificacion del procesador
Miguel Alejandro León Santos
 
(2) Arquitectura del SO (generalidades).pdf
(2) Arquitectura del SO (generalidades).pdf(2) Arquitectura del SO (generalidades).pdf
(2) Arquitectura del SO (generalidades).pdf
801 Almas - Internacional
 
programacion-de-operaciones-secuenciacion-de-trabajos
programacion-de-operaciones-secuenciacion-de-trabajosprogramacion-de-operaciones-secuenciacion-de-trabajos
programacion-de-operaciones-secuenciacion-de-trabajos
UNAM Facultad de Contaduría, Administración e Informática
 
Administración de cpu
Administración de cpuAdministración de cpu
Administración de cpu
Ramiro Estigarribia Canese
 
Administración de procesosby dan
Administración  de  procesosby danAdministración  de  procesosby dan
Administración de procesosby dan
Yuridia Leyva Sillas
 
Taller Preguntas
Taller PreguntasTaller Preguntas
Taller Preguntas
guest3bdbda
 
Administración de procesos en el S.O.
Administración de procesos en el S.O.Administración de procesos en el S.O.
Administración de procesos en el S.O.
Carlos Solano
 
Sistemas Operativos
Sistemas OperativosSistemas Operativos
Sistemas Operativos
Richard Ortega
 
Sistemas Operativos[1]
Sistemas Operativos[1]Sistemas Operativos[1]
Sistemas Operativos[1]
guest5db8b1
 

Similar a Unidad4 (20)

Unidad4
Unidad4Unidad4
Unidad4
 
Administración de procesos y del procesador.pptx
Administración de procesos y del procesador.pptxAdministración de procesos y del procesador.pptx
Administración de procesos y del procesador.pptx
 
Sistema Operativo
Sistema OperativoSistema Operativo
Sistema Operativo
 
Trabajo de sisope
Trabajo de sisopeTrabajo de sisope
Trabajo de sisope
 
Trabajode Sisope
Trabajode SisopeTrabajode Sisope
Trabajode Sisope
 
PLANIFICACION DE PROCESOS
PLANIFICACION DE PROCESOSPLANIFICACION DE PROCESOS
PLANIFICACION DE PROCESOS
 
Planificacion de procesos
Planificacion de procesosPlanificacion de procesos
Planificacion de procesos
 
Planificaion De Procesos
Planificaion De ProcesosPlanificaion De Procesos
Planificaion De Procesos
 
expoci
expociexpoci
expoci
 
Planificaion de Procesos
Planificaion de ProcesosPlanificaion de Procesos
Planificaion de Procesos
 
SISTEMAS OPERATIVOS
SISTEMAS OPERATIVOSSISTEMAS OPERATIVOS
SISTEMAS OPERATIVOS
 
Unidad3 pp planificacion del procesador
Unidad3 pp planificacion del procesadorUnidad3 pp planificacion del procesador
Unidad3 pp planificacion del procesador
 
(2) Arquitectura del SO (generalidades).pdf
(2) Arquitectura del SO (generalidades).pdf(2) Arquitectura del SO (generalidades).pdf
(2) Arquitectura del SO (generalidades).pdf
 
programacion-de-operaciones-secuenciacion-de-trabajos
programacion-de-operaciones-secuenciacion-de-trabajosprogramacion-de-operaciones-secuenciacion-de-trabajos
programacion-de-operaciones-secuenciacion-de-trabajos
 
Administración de cpu
Administración de cpuAdministración de cpu
Administración de cpu
 
Administración de procesosby dan
Administración  de  procesosby danAdministración  de  procesosby dan
Administración de procesosby dan
 
Taller Preguntas
Taller PreguntasTaller Preguntas
Taller Preguntas
 
Administración de procesos en el S.O.
Administración de procesos en el S.O.Administración de procesos en el S.O.
Administración de procesos en el S.O.
 
Sistemas Operativos
Sistemas OperativosSistemas Operativos
Sistemas Operativos
 
Sistemas Operativos[1]
Sistemas Operativos[1]Sistemas Operativos[1]
Sistemas Operativos[1]
 

Más de Universidad Autónoma de Nayarit

Programa admo. de redes de computadoras
Programa   admo. de redes de computadorasPrograma   admo. de redes de computadoras
Programa admo. de redes de computadoras
Universidad Autónoma de Nayarit
 
Administración de Redes de Computadoras - Capitulo 8
Administración de Redes de Computadoras - Capitulo 8Administración de Redes de Computadoras - Capitulo 8
Administración de Redes de Computadoras - Capitulo 8
Universidad Autónoma de Nayarit
 
Administración de Redes de Computadoras - Capitulo 7
Administración de Redes de Computadoras - Capitulo 7Administración de Redes de Computadoras - Capitulo 7
Administración de Redes de Computadoras - Capitulo 7
Universidad Autónoma de Nayarit
 
Administración de Redes de Computadoras - Capitulo 6
Administración de Redes de Computadoras - Capitulo 6Administración de Redes de Computadoras - Capitulo 6
Administración de Redes de Computadoras - Capitulo 6
Universidad Autónoma de Nayarit
 
Administración de Redes de Computadoras - Capitulo 5
Administración de Redes de Computadoras - Capitulo 5Administración de Redes de Computadoras - Capitulo 5
Administración de Redes de Computadoras - Capitulo 5
Universidad Autónoma de Nayarit
 
Administración de Redes de Computadoras - Capitulo 4
Administración de Redes de Computadoras - Capitulo 4Administración de Redes de Computadoras - Capitulo 4
Administración de Redes de Computadoras - Capitulo 4
Universidad Autónoma de Nayarit
 
Administración de Redes de Computadoras - Capitulo 3
Administración de Redes de Computadoras - Capitulo 3Administración de Redes de Computadoras - Capitulo 3
Administración de Redes de Computadoras - Capitulo 3
Universidad Autónoma de Nayarit
 
Administración de Redes de Computadoras - Capitulo 2
Administración de Redes de Computadoras - Capitulo 2Administración de Redes de Computadoras - Capitulo 2
Administración de Redes de Computadoras - Capitulo 2
Universidad Autónoma de Nayarit
 
Administración de Redes de Computadoras - Capitulo 1
Administración de Redes de Computadoras - Capitulo 1Administración de Redes de Computadoras - Capitulo 1
Administración de Redes de Computadoras - Capitulo 1
Universidad Autónoma de Nayarit
 
Administración de Redes de Computadoras - Capitulo 9
Administración de Redes de Computadoras - Capitulo 9Administración de Redes de Computadoras - Capitulo 9
Administración de Redes de Computadoras - Capitulo 9
Universidad Autónoma de Nayarit
 
Programa fundamento de redes de datos
Programa   fundamento de redes de datosPrograma   fundamento de redes de datos
Programa fundamento de redes de datos
Universidad Autónoma de Nayarit
 
Fundamento de Redes - Capitulo 2
Fundamento de Redes - Capitulo 2 Fundamento de Redes - Capitulo 2
Fundamento de Redes - Capitulo 2
Universidad Autónoma de Nayarit
 
Fundamento de Redes - Capitulo 1
Fundamento de Redes - Capitulo 1Fundamento de Redes - Capitulo 1
Fundamento de Redes - Capitulo 1
Universidad Autónoma de Nayarit
 
Fundamento de Redes - Capitulo 9
Fundamento de Redes - Capitulo 9Fundamento de Redes - Capitulo 9
Fundamento de Redes - Capitulo 9
Universidad Autónoma de Nayarit
 
Fundamento de Redes - Capitulo 8
Fundamento de Redes - Capitulo 8Fundamento de Redes - Capitulo 8
Fundamento de Redes - Capitulo 8
Universidad Autónoma de Nayarit
 
Fundamento de Redes - Capítulo 7
Fundamento de Redes - Capítulo 7 Fundamento de Redes - Capítulo 7
Fundamento de Redes - Capítulo 7
Universidad Autónoma de Nayarit
 
Fundamento de Redes - Capitulo 6
Fundamento de Redes - Capitulo 6Fundamento de Redes - Capitulo 6
Fundamento de Redes - Capitulo 6
Universidad Autónoma de Nayarit
 
Fundamento de Redes - Capitulo 5
Fundamento de Redes - Capitulo 5 Fundamento de Redes - Capitulo 5
Fundamento de Redes - Capitulo 5
Universidad Autónoma de Nayarit
 
Fundamento de Redes - Capitulo 4
Fundamento de Redes - Capitulo 4Fundamento de Redes - Capitulo 4
Fundamento de Redes - Capitulo 4
Universidad Autónoma de Nayarit
 
Ejemplo de casos de Estudios CCNA
Ejemplo de casos de Estudios CCNAEjemplo de casos de Estudios CCNA
Ejemplo de casos de Estudios CCNA
Universidad Autónoma de Nayarit
 

Más de Universidad Autónoma de Nayarit (20)

Programa admo. de redes de computadoras
Programa   admo. de redes de computadorasPrograma   admo. de redes de computadoras
Programa admo. de redes de computadoras
 
Administración de Redes de Computadoras - Capitulo 8
Administración de Redes de Computadoras - Capitulo 8Administración de Redes de Computadoras - Capitulo 8
Administración de Redes de Computadoras - Capitulo 8
 
Administración de Redes de Computadoras - Capitulo 7
Administración de Redes de Computadoras - Capitulo 7Administración de Redes de Computadoras - Capitulo 7
Administración de Redes de Computadoras - Capitulo 7
 
Administración de Redes de Computadoras - Capitulo 6
Administración de Redes de Computadoras - Capitulo 6Administración de Redes de Computadoras - Capitulo 6
Administración de Redes de Computadoras - Capitulo 6
 
Administración de Redes de Computadoras - Capitulo 5
Administración de Redes de Computadoras - Capitulo 5Administración de Redes de Computadoras - Capitulo 5
Administración de Redes de Computadoras - Capitulo 5
 
Administración de Redes de Computadoras - Capitulo 4
Administración de Redes de Computadoras - Capitulo 4Administración de Redes de Computadoras - Capitulo 4
Administración de Redes de Computadoras - Capitulo 4
 
Administración de Redes de Computadoras - Capitulo 3
Administración de Redes de Computadoras - Capitulo 3Administración de Redes de Computadoras - Capitulo 3
Administración de Redes de Computadoras - Capitulo 3
 
Administración de Redes de Computadoras - Capitulo 2
Administración de Redes de Computadoras - Capitulo 2Administración de Redes de Computadoras - Capitulo 2
Administración de Redes de Computadoras - Capitulo 2
 
Administración de Redes de Computadoras - Capitulo 1
Administración de Redes de Computadoras - Capitulo 1Administración de Redes de Computadoras - Capitulo 1
Administración de Redes de Computadoras - Capitulo 1
 
Administración de Redes de Computadoras - Capitulo 9
Administración de Redes de Computadoras - Capitulo 9Administración de Redes de Computadoras - Capitulo 9
Administración de Redes de Computadoras - Capitulo 9
 
Programa fundamento de redes de datos
Programa   fundamento de redes de datosPrograma   fundamento de redes de datos
Programa fundamento de redes de datos
 
Fundamento de Redes - Capitulo 2
Fundamento de Redes - Capitulo 2 Fundamento de Redes - Capitulo 2
Fundamento de Redes - Capitulo 2
 
Fundamento de Redes - Capitulo 1
Fundamento de Redes - Capitulo 1Fundamento de Redes - Capitulo 1
Fundamento de Redes - Capitulo 1
 
Fundamento de Redes - Capitulo 9
Fundamento de Redes - Capitulo 9Fundamento de Redes - Capitulo 9
Fundamento de Redes - Capitulo 9
 
Fundamento de Redes - Capitulo 8
Fundamento de Redes - Capitulo 8Fundamento de Redes - Capitulo 8
Fundamento de Redes - Capitulo 8
 
Fundamento de Redes - Capítulo 7
Fundamento de Redes - Capítulo 7 Fundamento de Redes - Capítulo 7
Fundamento de Redes - Capítulo 7
 
Fundamento de Redes - Capitulo 6
Fundamento de Redes - Capitulo 6Fundamento de Redes - Capitulo 6
Fundamento de Redes - Capitulo 6
 
Fundamento de Redes - Capitulo 5
Fundamento de Redes - Capitulo 5 Fundamento de Redes - Capitulo 5
Fundamento de Redes - Capitulo 5
 
Fundamento de Redes - Capitulo 4
Fundamento de Redes - Capitulo 4Fundamento de Redes - Capitulo 4
Fundamento de Redes - Capitulo 4
 
Ejemplo de casos de Estudios CCNA
Ejemplo de casos de Estudios CCNAEjemplo de casos de Estudios CCNA
Ejemplo de casos de Estudios CCNA
 

Unidad4

  • 1. 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
  • 2. Sistemas Operativos Unidad 4 Figura 4.1 Niveles de planificación Universidad Autónoma de Nayarit 2
  • 3. Sistemas Operativos Unidad 4 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. Universidad Autónoma de Nayarit 3
  • 4. Sistemas Operativos Unidad 4 • 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. Universidad Autónoma de Nayarit 4
  • 5. Sistemas Operativos Unidad 4 • 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. Universidad Autónoma de Nayarit 5
  • 6. Sistemas Operativos Unidad 4 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. Universidad Autónoma de Nayarit 6
  • 7. Sistemas Operativos Unidad 4 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 Universidad Autónoma de Nayarit 7
  • 8. Sistemas Operativos Unidad 4 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. Universidad Autónoma de Nayarit 8
  • 9. Sistemas Operativos Unidad 4 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. Universidad Autónoma de Nayarit 9
  • 10. Sistemas Operativos Unidad 4 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. Universidad Autónoma de Nayarit 10
  • 11. Sistemas Operativos Unidad 4 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. Universidad Autónoma de Nayarit 11
  • 12. Sistemas Operativos Unidad 4 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. Universidad Autónoma de Nayarit 12
  • 13. Sistemas Operativos Unidad 4 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. Universidad Autónoma de Nayarit 13
  • 14. Sistemas Operativos Unidad 4 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. Universidad Autónoma de Nayarit 14
  • 15. Sistemas Operativos Unidad 4 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. Universidad Autónoma de Nayarit 15