2.1 Concepto de proceso.
El concepto de proceso es fundamental en la estructura de los sistemas operativos. Este término fue acuñado por primera vez por los diseñadores de Multics en los años 60. Es un término algo más general que el de trabajo. Se han dado muchas definiciones para el término proceso, entre las que se incluyen las siguientes:
• Un programa en ejecución.
• El "espíritu animado" de un programa.
• La entidad que puede ser asignada al procesador y ejecutada por él.
2.2 Estados y transiciones de los procesos.
El estado de un proceso puede plasmarse como un grafico el cual asemeja una maquina virtual, asi por ejemplo sea la siguiente figura que especifica el estatus de un proceso:
Figura 5. Estados y transiciones de un proceso.
Así por ejemplo cuando ninguno de los procesos en memoria principal está en estado Listo el sistema operativo expulsa hacia el disco a alguno de los procesos que este Bloqueado y lo pasa a alguna lista de Suspendidos. Transiciones. Nuevo–>Listo Al crearse un proceso pasa inmediatamente al estado listo.
Listo–>Ejecutando
En el estado de listo, el proceso solo espera para que se le asigne un procesador para ejecutar (tener en cuenta que puede existir más de un procesador en el sistema).Al liberarse un procesador el planificador (scheduler ) Selecciona el próximo proceso, según algún criterio definido, a ejecutar. Ejecutando–>Listo Ante una interrupción que se generé, el proceso puede perder el recurso procesador y pasar al estado de listo. El planificador será el encargado deseleccionar el próximo proceso a ejecutar. Ejecutando–>Bloqueado a medida que el proceso ejecuta instrucciones realiza pedidos en distintos componentes (ej.: genera un pedido de E/S). Teniendo en cuenta que el pedido puede demorar y, además, si está en un sistema multiprogramado, el proceso expuesto en una cola de espera hasta que se complete su pedido. De esta forma, se logra utilizar en forma más eficiente el procesador. Bloqueado–>Listo Una vez que ocurre el evento que el proceso estaba esperando en la cola de espera, el proceso es puesto nuevamente en la cola de procesos listos. Ejecutando->Terminado Cuando el proceso ejecuta su última instrucción pasa al estado terminado. El sistema libera las estructuras que representan al proceso.
2.3 Procesos ligeros (Hilos o hebras). En la mayoría de los sistemas operativos, estas dos características son, de hecho, la esencia de un proceso. Sin embargo, algunos argumentos pueden convencer de que estas dos características son independientes y que deben ser tratadas de manera independiente por el sistema operativo. Esto se hace así en una serie de sistemas operativos, en particular en algunos sistemas operativos de desarrollo reciente. Para distinguir estas dos características, la unidad de expedición se conoce corno hilo (thread) o proceso ligero (lightweight process),mientras que a la unidad de propiedad de los recursos se le suele llamar proceso o tarea.
Los beneficios clave de los hilos se derivan de las implicaciones del rendimiento: Se tarda mucho menos tiempo en crear un nuevo hilo en un proceso existente que en crear una nueva tarea, menos tiempo para terminar un hilo y menos tiempo para cambiar entre dos hilos de un mismo proceso. Por tanto, si hay una aplicación o una función que pueda implementarse como un conjunto de unidades de ejecución relacionadas, es más eficiente hacerlo con una colección de hilos que con una colección de tareas separadas.
Algunos estudios llevados a cabo por los desarrolladores de Mach demuestran que la aceleración en la creación de procesos, comparada con la de Las implementaciones de UNIX que no utilizan hilos, está en un factor de 10 [ITEVA87].
2.4 Concurrencia y secuenciabilidad.
La concurrencia es el punto clave de los tres campos anteriores y fundamentales para el di-seño de sistemas operativos. La concurrencia comprende un gran número de cuestiones de diseño, incluyendo la comunicación entre procesos, compartición y competencia por los recursos, sincronización de la ejecución de varios procesos y asignación del tiempo de procesador a los procesos. Se verá que estas cuestiones no solo surgen en entornos de multi-procesadores y proceso distribuido, sino incluso en sistemas multiprogramados con un solo procesador. La concurrencia puede presentarse en tres contextos diferentes:
• Varias aplicaciones: La multiprogramación se creó para permitir que el tiempo de procesador de la máquina fuese compartido dinámicamente entre varios trabajos o aplicaciones activas.
• Aplicaciones estructuradas: Como ampliación de los principios del diseño modular y la programación estructurada, algunas aplicaciones pueden implementarse eficazmente como un conjunto de procesos concurrentes.
• Estructura del sistema operativo: Las mismas ventajas de estructuración son aplicables a los programadores de sistemas y se ha comprobado que algunos sistemas operativos están implementados como un conjunto de procesos.
En un sistema multiprogramados con un único procesador, los procesos se intercalan en el tiempo para dar la apariencia de ejecución simultánea (figura 4.1a). Aunque no se consigue un proceso paralelo real y aunque se produce una cierta sobrecarga en los intercambios de procesos de un sitio a otro, la ejecución intercalada produce beneficios importantes en la eficiencia del procesamiento y en la estructuración de los programas. En un sistema con varios procesadores, no solo es posible intercalar los procesos, sino también superponerlos primera vista, podría parecer que la intercalación y la superposición representan formas de ejecución muy diferentes y que introducen problemas distintos. De hecho, ambas técnicas pueden contemplarse como ejemplos de proceso concurrente y ambas plantean los mismos problemas. En el caso de un sistema monoprocesador, los problemas creados por la multiprogramación parten del hecho de que la velocidad relativa de ejecución de los procesos no puede predecirse. Depende de la actividad de otros procesos, de la forma en que el sistema operativo trata las interrupciones y de las políticas de planificación.
2.4.1 Exclusión mutua de secciones criticas. Cualquier servicio o capacidad que dé soporte para la exclusión mutua debe cumplir los requisitos siguientes:
1. Debe cumplirse la exclusión mutua: Solo un proceso, de entre todos los que poseen secciones críticas por el mismo recurso u objeto compartido, debe tener permiso para entrar en ella en un instante dado.
2. Un proceso que se interrumpe en una sección no crítica debe hacerlo sin estorbar a los otros procesos.
3. Un proceso no debe poder solicitar acceso a una sección crítica para después ser demorado indefinidamente; no puede permitirse el interbloqueo o la inanición.
4. Cuando ningún proceso está en su sección crítica, cualquier proceso que solicite entrar en la suya debe poder hacerlo sin dilación.
5. No se pueden hacer suposiciones sobre la velocidad relativa de los procesos o su número.
6. Un proceso permanece en su sección crítica solo por un tiempo finito. Hay varias formas de satisfacer los requisitos de exclusión mutua. Una manera es dejar la responsabilidad a los procesos que deseen ejecutar concurrentemente. Así pues, tanto si son programas del sistema como de aplicación, los procesos deben coordinarse unos con otros para cumplir la exclusión mutua, sin ayuda por parte del lenguaje de programación o del sistema operativo. Estos métodos reconocen como soluciones por software. Aunque las soluciones por software son propensas a errores y a una fuerte carga de proceso, resulta útil estudiar estos métodos para tener un mejor entendimiento de la complejidad del proceso concurrente. Este tema está cubierto en la sección
4.2. Un segundo método propone el uso de instrucciones de la máquina a tal efecto. Estas tienen la ventaja de reducir la sobrecarga pero, sin embargo, se verá en la sección 4.3 que no son interesantes. El tercer método consiste en dar algún tipo de soporte en el sistema operativo. Más adelante en el capitulo, se examinarán algunas de las técnicas más importantes.
Algoritmo de Dekker
Dijkstra [DIJ65] presentó un algoritmo de exclusión mutua para dos procesos que diseñó el matemático holandés Dekker. Según Dijkstra, la solución se desarrolla por etapas. Este método tiene la ventaja de ilustrar la mayoría de los errores habituales que se producen en la construcción de programas concurrentes. A medida que se construya el algoritmo, se emplearán algunas ilustraciones pintorescas tomadas de Ben-Ari.
Algoritmo de Peterson
El algoritmo de Dekker resuelve el problema de la exclusión mutua pero con un programa complejo, difícil de seguir y cuya corrección es difícil de demostrar. Peterson [PETE81] desarrollado una solución simple y elegante. Como antes, la variable global señal indica La posición de cada proceso con respecto a la exclusión mutua y la variable global turno resuelve los conflictos de simultaneidad. Se puede demostrar fácilmente que se cumple La exclusión mutua. Considérese el proceso P0. Una vez que ha puesto señal [0] a cierto, P1 no puede entrar en su sección critica. Si P1 está aún en su sección critica, señal [1] = cierto y P0 está bloqueado para entrar en su sección crítica. Por otro lado, se impide el bloqueo mutuo. Supóngase que P0 está bloqueado en su bucle while.
Esto significa que señal es cierto y turno = 1. P0 puede entrar en su sección crítica cuando señal [1] se ponga a falso o cuando turno se ponga a 0. Considérense ahora los siguientes casos exhaustivos:1. P1 no está interesado en entrar en su sección crítica. Este caso es imposible porque implica que señal [l]= falso.2. P1 está esperando entrar en su sección crítica. Este caso es también imposible porque si turno = 1, P1 podrá entrar en su sección critica.3. P1 entra en su sección crítica varias veces y monopoliza el acceso a ella. Esto no puede pasar porque P1 está obligado a dar a P0 una oportunidad poniendo turno a 0 antes de cada intento de entrar en su sección crítica. Así pues, se tiene una solución simple al problema de la exclusión mutua parados procesos. Es más, el algoritmo de Peterson se puede generalizar fácilmente al caso de n procesos.
2.4.2 Sincronización de procesos en S.C.
2.4.2.1 Mecanismo de semáforos.
El primer gran avance en la resolución de los problemas de procesos concurrentes llegó en 1965, con el tratado de Dijkstra sobre la cooperación entre procesos secuénciales [DIJK65] Dijkstra estaba interesado en el diseño de un sistema operativo como un conjunto de procesos secuénciales cooperantes y en el desarrollo de mecanismos eficientes y fiables para dar soporte a la cooperación. Los procesos de usuario podrán utilizar estos mecanismos en tanto que el procesador y el sistema operativo los hagan disponibles. El principio fundamental es el siguiente: Dos o más procesos pueden cooperar por medio de simples señales, de forma que se pueda obligar a detenerse a un proceso en una posición determinada hasta que reciba una señal específica. Cualquier requisito complicado de coordinación puede satisfacerse por medio de la estructura de señales adecuada. Para la señalización, se usan variables especiales llamados semáforos. Para transmitir una señal por el Semáforo s, los procesos ejecutan la primitiva signal(s). Para recibir una señal del semáforo s, los procesos ejecutan la primitiva wait(s); si la señal correspondiente aún no se ha transmitido, el proceso es suspendido hasta que tenga lugar la transmisión. Para lograr el efecto deseado, se pueden contemplar los semáforos como variables que tienen un valor entero sobre el que se definen las tres operacionessiguientes:1. Un semáforo puede inicializarse con un valor no negativo.2. La operación wait decrementa el valor del semáforo. Si el valor se hace negativo, el proceso que ejecuta el wait se bloquea.3. La operación signal incrementa el valor del semáforo. Si el valor no es positivo, se des-bloquea a un proceso bloqueado por una operación wait. Aparte de estas tres operaciones, no hay forma de examinar o manipular los semáforos. Las primitivas wait y signal se suponen atómicas, es decir, no pueden ser interrumpidas y cada rutina puede considerarse como un paso indivisible. En principio, los semáforos binarios son más sencillos de implementar y puede demostrarse que tienen la misma potencia de expresión que los semáforos generales Tanto en los semáforos como en los semáforos binarios se emplea una cola para mantener los procesos esperando en el semáforo. La definición no dicta el orden en el que se quitan los procesos de dicha cola. La política más equitativas la FIFO: el proceso que ha estado bloqueado durante más tiempo se libera de la cola. La única exigencia estricta es que un proceso no debe que-dar retenido en la cola de un semáforo indefinidamente porque otros procesos tengan preferencia.
2.4.2.2 Mecanismo de monitores.
A fin de facilitar la escritura de programas correctos, Hoare (1974) y BrinchHansen (1975) propusieron una primitiva de sincronización de nivel más alto llamada monitor
. Sus propuestas tenían pequeñas diferencias, que describiremos más adelante. Un monitor es una colección de procedimientos, variables y estructuras de datos que se agrupan en un tipo especial de módulo o paquete. Los procesos pueden invocar los procedimientos de un monitor en el momento en que deseen, pero no pueden acceder directamente a las estructuras de datos internas del monitor desde procedimientos declarados afuera del monitor. Los monitores poseen una propiedad especial que los hace útiles para lograr la exclusión mutua: sólo un proceso puede estar activo en un monitor en un momento dado. Los monitores son una construcción de lenguaje de programación, así que el compilador sabe que son especiales y puede manejar las llamadas a procedimientos de monitor de una forma diferente a como maneja otras llamadas procedimientos. Por lo regular, cuando un proceso invoca un procedimiento de monitor, las primeras instrucciones del procedimiento verifican si hay algún otro proceso activo en ese momento dentro del monitor. Si así es, el proceso invocadores suspende hasta que el otro proceso abandona el monitor. Si ningún otro proceso está usando el monitor, el proceso invocador puede entrar. Es responsabilidad del compilador implementar la exclusión mutua en las entradas a monitores, pero una forma común es usar un semáforo binario. Puesto que el compilador, no el programador, se está encargando de la exclusión mutua, es mucho menos probable que algo salga mal. En cualquier caso, la persona que escribe el monitor no tiene que saber cómo el compilador logra la exclusión mutua; le basta con saber que si convierte todas las regiones críticas en procedimientos de monitor, dos procesos nunca podrán ejecutar sus regiones críticas al mismo tiempo.
Aunque los monitores ofrecen una forma fácil de lograr la exclusión mutua, esto no es suficiente, como acabamos de ver. También necesitamos un mecanismo para que los procesos se bloqueen cuando no puedan continuar. En el problema de productor-consumidor, es fácil colocar todas las pruebas para determinar si el buffer está lleno o está vacío en procedimientos de monitor, pero ¿cómo deberá bloquearse el productor cuando encuentra lleno el buffer?
2.4.3 Interbloqueo (DeadLock).
Es el bloqueo permanente de un conjunto de procesos que compiten por los recursos del sistema o bien se comunican unos con otros. A diferencia de otros problemas de la gestión concurrente de procesos, para el caso general no existe una solución eficiente. En esta sección, se examinará la naturaleza del problema del interbloqueo. Todos los interbloqueos suponen demandas contradictorias de recursos por parte de dos o más procesos. Los dos ejes del diagrama representan el avance de los dos procesos en términos de instrucciones ejecutadas. El avance conjunto de los dos procesos se representa entonces con una secuencia discreta de puntos en el espacio. Las líneas horizontales o verticales representan el intervalo de tiempo en el que sólo uno de los procesos está ejecutándose (intercalado); una línea diagonal significa ejecución simultánea (solapamiento). Supóngase que existe un punto en la ejecución de cada proceso en el que se requiere el uso exclusivo de ambos recursos, Rl y R2, para continuar. En el ejemplo, llega un punto en el que el proceso Pl ha adquirido el recurso Rl y el proceso P2 ha adquirido el recurso R2 y cada proceso necesita el otro recurso. Este es el punto de interbloqueo. El interbloqueo se produce si cada proceso retiene un recurso y solicita el otro. Puede parecer que es un error de programación en lugar de un error del diseño del sistema operativo. Sin embargo, se ha visto que el diseño de un programa concurrente entraña gran dificultad. Se producen interbloqueos como éste y la causa está frecuentemente en la compleja lógica del programa, lo que hace más difícil su detección. Una posible estrategia para resolver estos interbloqueos es imponer restricciones en el diseño del sistema sobre el orden en el que se solicitan los recursos.
2.4.3.1 Prevención. La estrategia de prevención del interbloqueo consiste, a grandes rasgos, en diseñar un sistema de manera que esté excluida, a priori, la posibilidad de interbloqueo. Los métodos para prevenir el interbloqueo son de dos tipos. Los métodos indirectos consisten en impedir la aparición de alguna de las tres condiciones necesarias, antes mencionadas (condiciones 1 a 3). Los métodos directos consisten en evitar la aparición del círculo vicioso de espera (condición 4).Se examinarán a continuación las técnicas relacionadas con cada una de las cuatro condiciones.
Exclusión Mutua
En general, la primera de las cuatro condiciones no puede anularse. Si el acceso a un recurso necesita exclusión mutua, el sistema operativo debe soportar la exclusión mutua. Algunos recursos, como los archivos, pueden permitir varios accesos para lectura, pero sólo accesos exclusivos para escritura. Incluso en este caso, se puede producir interbloqueo si más de un proceso necesita permiso de escritura.
Retención y Espera
La condición de retención y espera puede prevenirse exigiendo que todos los procesos soliciten todos los recursos que necesiten a un mismo tiempo y bloqueando el proceso hasta que todos los recursos puedan concederse simultáneamente. Esta solución resulta ineficiente por dos factores. En primer lugar, un proceso puede estar suspendido durante mucho tiempo, esperando que se concedan todas sus solicitudes de recursos, cuando de hecho podría haber avanzado con sólo algunos de los recursos. Y en segundo lugar, los recursos asignados a un proceso pueden permanecer sin usarse durante periodos considerables, tiempo durante el cual se priva del acceso a otros procesos.
No apropiación
La condición de no apropiación puede prevenirse de varias formas. Primero, si a un proceso que retiene ciertos recursos se le deniega una nueva solicitud, dicho proceso deberá liberar sus recursos anteriores y solicitarlos de nuevo, cuando sea necesario, junto con el recurso adicional. Por otra parte, si un proceso solicita un recurso que actualmente está retenido por otro proceso, el sistema operativo puede expulsar al segundo proceso y exigirle que libere sus recursos. Este último esquema evitará el interbloqueo sólo si no hay dos procesos que posean la misma prioridad.
Esta técnica es práctica sólo cuando se aplica a recursos cuyo estado puede salvarse y restaurarse más tarde de una forma fácil, como es el caso de un procesador.
Círculo Vicioso de Espera
La condición del círculo vicioso de espera puede prevenirse definiendo una ordenación lineal de los tipos de recursos. Si a un proceso se le han asignado recursos de tipo R, entonces sólo podrá realizar peticiones posteriores sobre los recursos de los tipos siguientes a R en la ordenación. Para comprobar el funcionamiento de esta estrategia, se asocia un índice a cada tipo de recurso. En tal caso, el recurso R, antecede a R, en la ordenación si
i <j.
Entonces, supóngase que dos procesos A y B se interbloquean, porque A ha adquirido R, y solicitado Ry, mientras que B ha adquirido R;y solicitado R¿. Esta situación es imposible porque implica que
í<jyj<i.
Como en la retención y espera, la prevención del círculo vicioso de espera puede ser ineficiente, retardando procesos y denegando accesos a recursos innecesariamente.
2.4.3.2 Detección. Las estrategias de prevención del interbloqueo son muy conservadoras; solucionan el problema del interbloqueo limitando el acceso a los recursos e imponiendo restricciones a los procesos. En el lado opuesto, las estrategias de detección del interbloqueo no limitan el acceso a los recursos ni restringen las acciones de los procesos. Con detección del interbloqueo, se concederán los recursos que los procesos necesiten siempre que sea posible. Periódicamente, el sistema operativo ejecuta un algoritmo que permite detectar la condición de círculo vicioso de espera descrita en el punto 4 anterior. Puede emplearse cualquier algoritmo de detección de ciclos en grafos dirigidos. El control del interbloqueo puede llevarse a cabo tan frecuentemente como las solicitudes de recursos o con una frecuencia menor, dependiendo de la probabilidad de que se produzca el interbloqueo. La comprobación en cada solicitud de recurso tiene dos ventajas: Conduce a una pronta detección y el algoritmo es relativamente simple, puesto que está basado en cambios increméntales del estado del sistema. Por otro lado, tal frecuencia de comprobaciones consume un tiempo de procesador considerable. Una vez detectado el interbloqueo, hace falta alguna estrategia de recuperación.
Las técnicas siguientes son posibles enfoques, enumeradas en orden creciente de sofisticación:
1. Abandonar todos los procesos bloqueados. Esta es, se crea o no, una de las soluciones más comunes, si no la más común, de las adoptadas en un sistemaoperativo.
2. Retroceder cada proceso interbloqueado hasta algún punto de control definido previamente y volver a ejecutar todos los procesos. Es necesario que haya disponibles unos mecanismos de retroceso y reinicio en el sistema. El riesgo de esta solución radica en que puede repetirse el interbloqueo original. Sin embargo, el no determinismo del procesamiento concurrente asegura, en general, que esto no va a pasar.
3. Abandonar sucesivamente los procesos bloqueados hasta que deje de haber interbloqueo. El orden en el que se seleccionan los procesos a abandonar seguirá un criterio de mínimo coste. Después de abandonar cada proceso, se debe ejecutar de nuevo el algoritmo de detección para ver si todavía existe interbloqueo.
4. Apropiarse de recursos sucesivamente hasta que deje de haber interbloqueo. Como en el punto 3, se debe emplear una selección basada en coste y hay que ejecutar de nuevo el algoritmo de detección después de cada apropiación. Un proceso que pierde un recurso por apropiación debe retroceder hasta un momento anterior a la adquisición de ese recurso.
Para los puntos 3 y 4, el criterio de selección podría ser uno de los siguientes, consistentes en escoger el proceso con:
• La menor cantidad de tiempo de procesador consumido hasta ahora• El menor número de líneas de salida producidas hasta ahora.
• El mayor tiempo restante estimado.
• El menor número total de recursos asignados hasta ahora.
• La prioridad más baja Algunas de estas cantidades son más fáciles de medir que otras. El tiempo restante estimado deja lugar a dudas, especialmente. Además, aparte de las medidas de prioridad, no existe otra indicación del "coste" para el usuario frente al coste para el sistema en conjunto.
2.4.3.3 Recuperación. Un sistema que pretenda recuperarse del interbloqueo, debe invocar a un algoritmo de detección cuando lo considere oportuno(ej. periódicamente)Formas de intentar la recuperación: Terminación de procesos matando a todos los procesos implicados (drástico)matando a uno de los procesos ¿cuál? el que más recursos libere el que menos tiempo lleve en ejecución...Retrocediendo la ejecución de algún proceso (rollback ) muy complicado de implementar y necesita que el programa esté diseñado para que pueda retroceder Expropiación de recursos Selección de la víctima ¿Qué recursos y de que procesos se expropian ?En ambos casos (terminación de procesos o expropiación de recursos) hay que tener cuidado de no provocar la inanición de procesos.
2.5 Niveles, objetivos y criterios de planificación.
Se consideran tres niveles importantes de planificación, los que se detallan a continuación:
•Planificación de alto nivel: Se encarga de llevar procesos de disco a memoria y viceversa. Seleccionando los trabajos que deben admitirse en el sistema. También se denomina Planificación de trabajos. Determina a qué trabajos se les va a permitir competir activamente por los recursos del sistema, lo cual se denomina Planificación de admisión. Administrar todos los recursos del sistema excepto el CPU. Mantiene las colas de procesos bloqueados y suspendidos. Controla la creación de procesos. Maneja el nivel de multiprogramación.
Planificación de nivel intermedio: En algunos casos, en especial cuando el sistema está sobrecargado, el planificador de nivel medio encuentra ventajoso retirar trabajos activos de la memoria para reducir el grado de multiprogramación, y por lo tanto, permitir que los trabajos se completen más aprisa. Este subadministrador controla los trabajos que se intercambian hacia fuera y de regreso. Determina a qué procesos se les puede permitir competir por la CPU. Efectúa “suspensiones” y “activaciones” (“reanudaciones”) de procesos. Debe ayudar a alcanzar ciertas metas en el rendimiento total del sistema. Equilibrar la administración de trabajos en el sistema con la asignación del CPU a dichos procesos. Nivelar la carga del sistema (procesos activos y pasivos)
.•Planificación de bajo nivel: Se encarga de pasar de un proceso a otro en memoria principal. Determinando a cuál proceso listo se le asignará el CPU cuando éste se encuentra disponible. o Determina a qué proceso listo se le asigna la CPU cuando esta queda disponible y asigna la CPU al mismo, es decir que “despacha” la CPU al proceso.
OBJETIVOS DE PLANIFICACIÓN
Los objetivos de la planificación del procesador son los siguientes e involucran a los conceptos detallados seguidamente:•Ser justa: Todos los procesos son tratados de igual manera. Ningún proceso es postergado indefinidamente. Maximizar la capacidad de ejecución: Maximizar el número de procesos servidos por unidad de tiempo.
Maximizar el número de usuarios interactivos que reciban unos tiempos de respuesta aceptables: En un máximo de unos segundos. Ser predecible: Un trabajo dado debe ejecutarse aproximadamente en la misma cantidad de tiempo independientemente de la carga del sistema. Minimizar la sobrecarga: No suele considerarse un objetivo muy importante. Equilibrar el uso de recursos: Favorecer a los procesos que utilizarán recursos infrautilizados. •Equilibrar respuesta y utilización: La mejor manera de garantizar buenos tiempos de respuesta es disponer de los recursos suficientes cuando se necesitan, pero la utilización total de recursos podrá ser pobre. Evitar la postergación indefinida: Se utiliza la estrategia del “envejecimiento” .Mientras un proceso espera por un recurso su prioridad debe aumentar, así la prioridad llegará a ser tan alta que el proceso recibirá el recurso esperado. Asegurar la prioridad: Los mecanismos de planificación deben favorecer a los procesos con prioridades más altas. Dar preferencia a los procesos que mantienen recursos claves: Un proceso debajo prioridad podría mantener un recurso clave, que puede ser requerido por un proceso de más alta prioridad. Si el recurso es no apreciativo, el mecanismo de planificación debe otorgar al proceso un tratamiento mejor del que le correspondería normalmente, puesto que es necesario liberar rápidamente el recurso clave. Dar mejor tratamiento a los procesos que muestren un “comportamiento deseable”: Un ejemplo de comportamiento deseable es una tasa baja de paginación.
Degradarse suavemente con cargas pesadas: Un mecanismo de planificación no debe colapsar con el peso de una exigente carga del sistema. Se debe evitar una carga excesiva mediante las siguientes acciones: No permitiendo que se creen nuevos procesos cuando la carga ya es pesada. Dando servicio a la carga más pesada al proporcionar un nivel moderadamente reducido de servicio a todos los procesos.
CRITERIOS DE PLANIFICACIÓN
-Equidad. Garantizar que cada proceso obtiene su proporción justa de la CPU.
-Eficacia. Mantener ocupada la CPU el ciento por ciento del tiempo.-Tiempo de respuesta Minimizar el tiempo de respuesta para los usuarios interactivos.
-Tiempo de regreso. Minimizar el tiempo que deben esperar los usuarios por lotes(catch) para obtener sus resultados.
-Rendimiento. Maximizar el número de tareas procesadas por hora.
