MATERIA: SISTEMAS OPERATIVOS ALUMNA: Karen garca Vzquez CARRERA: ING. EN SISTEMAS COMPUTACIONALES s.o.

Investigacin DE Unidad ii Administracin de procesos Y del procesador 2.1 concepto de proceso. 2.2 estados y transiciones de los procesos. 2.3procesos ligeros: hilos o hebras. 2.4concurrencia y secuenciabilidad. 2.5 niveles, objetivos y criterios de planificacin. 2.6Tcnicas de administracin del planificador

2.1 concepto de procesos

Es
Un programa en ejecucin

Que

ESTA

Dirigidos por el sistema operativo

Estn formados por:

*Las instrucciones de un programa destinadas a ser ejecutadas por el microprocesador. *Su estado de ejecucin en un momento dado, (los valores de los registros de la unidad central de procesamiento para dicho programa. ) *Su memoria de trabajo, es decir, la memoria que ha reservado y sus contenidos. *Otra informacin que permite al sistema operativo su planificacin.

2.1.- Concepto de pro

2.3procesos ligeros: hilos o hebras

El concepto de proceso engloba dos conceptos separados y potencialmente independientes: uno relativo a la propiedad de recursos y otro que hace referencia a la ejecucin. Unidad que posee recursos: A un proceso se le asigna un espacio de memoria y, de tanto en tanto, se le puede asignar otros recursos como dispositivos de E/S o ficheros. Unidad a la que se le asigna el procesador: Un proceso es un flujo de ejecucin (una traza) a travs de uno o ms programas. Esta ejecucin se entremezcla con la de otros procesos. De tal forma, que un proceso tiene un estado (en ejecucin, listo, etc.) y una prioridad de expedicin u origen. La unidad planificada y expedida por el sistema operativo es el proceso. En la mayora de los sistemas operativos, estas dos caractersticas son, de hecho, la esencia de un proceso. Sin embargo, son independientes, y pueden ser tratadas como tales por el sistema operativo. Esta distincin ha conducido en los sistemas operativos actuales a desarrollar la construccin conocida como thread, cuyas traducciones ms frecuentes son hilo, hebra y proceso ligero. Si se tiene esta divisin de caractersticas, la unidad de asignacin de la CPU se conoce como hilo, mientras que a la unidad que posee recursos se le llama proceso.

Dentro de un proceso puede haber uno o ms hilos de control cada uno con: Un estado de ejecucin (en ejecucin, listo, bloqueado) Un contexto de procesador, que se salva cuando no est ejecutndose. Una pila de ejecucin. Algn almacenamiento esttico para variables locales. Acceso a la memoria y a los recursos de ese trabajo que comparte con los otros hilos. Los beneficios clave de los hilos se derivan de las implicaciones del rendimiento: se tarda menos tiempo en crear un nuevo hilo de un proceso que ya existe, en terminarlo, y en hacer un cambio de contexto entre hilos de un mismo proceso. Al someter a un mismo proceso a varios flujos de ejecucin se mantiene una nica copia en memoria del cdigo, y no varias.

Un proceso ligero (thread o hebra) es un programa en ejecucin que comparte la imagen de la memoria y otras informaciones con otros procesos ligeros.

Es una unidad bsica de utilizacin de la CPU consistente en un juego de registros y un espacio de pila. Comparte el cdigo, los datos y los recursos con sus hebras pares Una tarea (o proceso pesado) est formada ahora por una o ms hebras Una hebra slo puede pertenecer a una tarea

CARACTERSTICAS:

Se comparten recursos. La comparicin de la memoria permite a las hebras pares comunicarse sin usar ningn mecanismo de comunicacin Inter.-proceso del SO. La conmutacin de contexto es ms rpida gracias al extenso compartir de recursos No hay proteccin entre las hebras. Una hebra puede escribir en la pila de otra hebra del mismo proceso.

ESTADOS DE LOS PROCESOS LIGEROS Un proceso ligero puede estar ejecutando, listo o bloqueado.

PARALELISMO Los procesos ligeros permiten paralelizar una aplicacin.

Concurrencias y secuenciabilidad:
Los procesos son concurrentes si existen simultneamente. Cuando dos o ms procesos llegan al mismo tiempo a ejecutarse, se dice que se ha presentado una concurrencia de procesos. Es importante mencionar que para que dos o ms procesos sean concurrentes, es necesario que tengan alguna relacin entre ellos.

La concurrencia puede presentarse en tres contextos diferentes: La multiprogramacin se cre para

Varias aplicaciones:

permitir que el tiempo de procesador de la mquina fuese compartido dinmicamente entre varios trabajos o aplicaciones activas.
Como ampliacin de los principios del diseo modular y la programacin estructurada, algunas aplicaciones pueden implementarse eficazmente como un conjunto de procesos concurrentes.

Aplicaciones estructuradas:

Estructura del sistema operativo:

Las mismas ventajas de estructuracin son aplicables a los programadores de sistemas y se ha comprobado que algunos sistemas operativos estn implementados como un conjunto de procesos.

ELEMENTOS A GESTIONAR Y DISEAR A CAUSA DE LA CONCURRENCIA

1. El sistema operativo debe ser capaz de seguir la pista de los distintos procesos activos. Esto lo hace por medio de PBCs (Bloque de Control de Procesos) . 2. El sistema operativo debe asignar y quitar los distintos recursos a cada proceso activo. Entre estos recursos se incluyen: Tiempo de procesador: Es funcin de la planificacin. Memoria. Archivos. Dispositivos de E/S: 3. El sistema operativo debe proteger los datos y los recursos fsicos de cada proceso contra injerencias no intencionadas de otros procesos. 4. Los resultados de un proceso deben ser independientes de la velocidad relativa a la que se realiza la ejecucin con respecto a otros procesos concurrentes.

Existen tres modelos de computadora en los que se Pueden ejecutar procesos concurrentes:

Multiprogramacin con un nico procesador.

En este modelo todos los procesos concurrentes ejecutan sobre un nico procesador. El sistema operativo se encarga de ir repartiendo el tiempo del procesador entre los distintos procesos, intercalando la ejecucin de los mismos para dar asi una apariencia de ejecucin simultanea.

Multiprocesador.

Un multiprocesador es una maquina formada por un conjunto de procesadores que comparten memoria principal. En este tipo de arquitecturas, los procesos concurrentes no solo pueden intercalar su ejecucin sino tambin superponerla. En este caso si existe una verdadera ejecucin simultanea de procesos, al coincidir las fases de procesamiento de distintos procesos. En un instante dado se pueden ejecutar de forma simultanea tantos procesos como procesadores haya. Una multicomputadora es una maquina de memoria distribuida, en contraposicin con el multiprocesador que es de memoria compartida. Esta formada por una serie de computadoras completas con su UCP, memoria principal y, en su caso, periferia. Cada uno de estos procesadores completo se denomina nodo. Los nodos se encuentran conectados y se comunican entre si a travs de una red de interconexin, empleando el mtodo de paso de mensajes. En este tipo de arquitecturas tambin es posible la ejecucin simultnea de los procesos sobre los distintos procesadores.

Multicomputadora.

TIPOS DE PROCESOS CONCURRENTES.

Proceso independiente: Es aquel que ejecuta sin requerir la ayuda o cooperacin de otros procesos. Un claro ejemplo de procesos independientes son los diferentes shells que se ejecutan de forma simultnea en un sistema.

Procesos cooperantes: Son aquellos que estn diseados para trabajar conjuntamente en alguna actividad, para lo que deben ser capaces de comunicarse e interactuar entre ellos. En ambos tipos de procesos (independientes y cooperantes), puede producirse una serie de interacciones entre ellos y pueden ser de dos tipos: Interacciones motivadas porque los procesos comparten o compiten por el acceso a recursos fsicos o lgicos. Por ejemplo, dos procesos independientes compiten por el acceso a disco o para modificar una base de datos. Interaccin motivada porque los procesos se comunican y sincronizan entre s para alcanzar un objetivo comn, Por ejemplo, un compilador que tiene varios procesos que trabajan conjuntamente para obtener un solo archivo de salida.

En general la concurrencia ser aparente siempre que el nmero de procesos sea mayor que el de procesadores disponibles, es decir, cuando haya ms de un proceso por procesador. La concurrencia ser real cuando haya un proceso por procesador

2.4.2 Sincronizacin de Procesos:

En muchos casos, los procesos se renen para realizar tareas en conjunto, a este tipo de relacin se le llama procesos cooperativos. Para lograr la comunicacin, los procesos deben sincronizarse, de no ser asi pueden ocurrir problemas no deseados. La sincronizacin es la transmisin y recepcin de seales que tiene por objeto llevar a cabo el trabajo de un grupo de procesos cooperativos. Es la coordinacin y cooperacin de un conjunto de procesos para asegurar la comparacin de recursos de cmputo. La sincronizacin entre procesos es necesaria para prevenir y/o corregir errores de sincronizacin debidos al acceso concurrente a recursos compartidos, tales como estructuras de datos o dispositivos de E/S, de procesos contendientes. La sincronizacin entre procesos tambin permite intercambiar seales de tiempo (ARRANQUE/PARADA) entre procesos cooperantes para garantizar las relaciones especficas de precedencia impuestas por el problema que se resuelve. Sin una sincronizacin adecuada entre procesos, la actualizacin de variables compartidas puede inducir a errores de tiempo relacionados con la concurrencia que son con frecuencia difciles de depurar. Una de las causas principales de este problema es que procesos concurrentes puedan observar valores temporalmente inconsistentes de una variable compartida mientras se actualizan. Una aproximacin para resolver este problema es realizar actualizaciones de variables compartidas de manera mutuamente exclusiva. Se pueden mejorar permitiendo que a lo ms un proceso entre a la vez en la seccin crtica de cdigo en la que se actualiza una variable compartida o estructura de datos en particular. Para que los procesos puedan sincronizarse es necesario disponer de servicios que permitan bloquear o suspender bajo determinadas circunstancias la ejecucin de un proceso. Los principales mecanismos de sincronizacin que ofrecen los sistemas operativos son:

Seales Tuberas Semforos Mutex y variables condicionales Paso de mensajes

Un semforo es un mecanismo de comunicacin con el cual no se mueven datos, puesto que solo se puede consultar y modificar su valor al tener un carcter puramente informativo Dijkstra define un semforo como una variable entera positiva o nula sobre la que slo se pueden realizar dos operaciones: wait (tambin denominada P) y signal (tambin denominada V). La operacin wait decremento el valor del semforo siempre que ste tenga un valor mayor que 0; por lo tanto esta operacin se utiliza para adquirir el semforo o para bloquearlo en el caso de que valga 0. La operacin signal incrementa el valor del semforo y por tanto se utiliza para liberarlo o inicializarlo Ambas operaciones deben ser atmicas para que funcionen correctamente; es decir que una operacin wait no puede ser interrumpida por otra operacin wait o signal sobre el mismo semforo, y lo mismo ocurre para la operacin signal. Este hecho garantiza que cuando varios procesos compitan por la adquisicin de un semforo, slo uno de ellos va a poder realizar la operacin Adems, se ha de indicar que este mecanismo memoriza las peticiones de operaciones wait no satisfechas y despierta por tanto a los procesos en espera Es una solucin sencilla y elegante del problema de la exclusin mutua. Esta tcnica permite solucionar la mayora de los problemas de sincronizacin entre procesos. Un semforo binario es un indicador de condicin (s) que registra si un registro est disponible o no. Un semforo slo puede tomar dos valores; 0 y 1. Si para un semforo, S=1 el recurso est disponible y la tarea lo puede utilizar; si S=0 el recurso no est disponible y el proceso debe esperar. Los semforos se implementan mediante una cola de tareas a la que se aaden los procesos que estn en espera del recurso. Solo se permiten tres operaciones sobre un semforo.

1. 2. 3.

Inicializa (s: Semforo_Binario; v: integer) -- > poner el valor del semforo s al valor de v (0,1). Espera (wait)(s) if s = 1 then s: = 0 else Suspender la tarea que hace la llamada y ponerla en la cola de tareas. Seal (signal)(s) if cola de tareas vaca then s : = 1 else Reanudar la primera tarea de la cola tareas.

Estas operaciones son procedimientos que se implementan como acciones indivisibles. En sistemas con un nico procesador bastar simplemente con inhibir las interrupciones durante la ejecucin de las operaciones del semforo. Al introducir el semforo se crea un nuevo estado en el diagrama de transiciones, el de espera

Exclusin mutua con semforos

La exclusin mutua se realiza fcilmente usando semforos. La operacin de espera se usar como procedimiento de bloqueo antes de acceder a una seccin crtica y la operacin seal como procedimiento de desbloqueo. Se emplean tantos semforos como clases de secciones crticas se establecen

Sincronizacin:
Las operaciones espera y seal no se utilizan dentro de un mismo proceso sino que sedan en dos procesos separados, el que ejecuta espera queda bloqueado hasta que el otro ejecuta seal VERSIN GENERAL DE LOS SEMFOROS El semforo binario resulta adecuado cuando hay que proteger un recurso que pueden compartir varios procesos, pero cuando lo que hay que proteger es un conjunto de recursos similares, se puede usar una versin ms general del concepto de semforo que lleve la cuenta del nmero de recursos disponibles. En este caso el semforo se inicializa con el nmero total de recursos disponibles (n) y las operaciones de espera y seal se disean de modo que se impida el acceso al recurso protegido por el semforo cuando el valor de ste es menor o igual que cero. Cada vez que se solicita y obtiene un recurso, el semforo se decrementa y se incrementa cuando se libera uno de ellos Si la operacin de espera se ejecuta cuando el semforo tiene un valor menor que 1, el proceso debe quedar en espera de que la ejecucin de una operacin seal libere alguno de los recursos

2.4.2.2 Mecanismos de Monitoreo

Los monitores son estructuras de datos utilizadas en lenguajes de programacin para sincronizar dos o ms procesos o hilos de ejecucin que usan recursos compartidos En el estudio y uso de los semforos se puede ver que las llamadas a las funciones necesarias para utilizarlos quedan repartidas en el cdigo del programa, haciendo difcil corregir errores y asegurar el buen funcionamiento de los algoritmos. Para evitar estos inconvenientes se desarrollaron los monitores. El concepto de monitor fue definido por primera vez por Charles Antony Richard Hoare en un artculo del ao 1974. La estructura de los monitores se ha implementado en varios lenguajes de programacin, incluido Pascal concurrente, Modula-2, Modula-3 y Java, y como biblioteca de programas Componentes: Un monitor tiene cuatro componentes: inicializacin, datos privados, procedimientos del monitor y cola de entrada Inicializacin: contiene el cdigo a ser ejecutado cuando el monitor es creado Datos privados: contiene los procedimientos privados, que slo pueden ser usados desde dentro del monitor y no son visibles desde fuera Procedimientos del monitor: son los procedimientos que pueden ser llamados desde fuera del monitor Cola de entrada: contiene a los threads que han llamado a algn procedimiento del monitor pero no han podido adquirir permiso para ejecutarlos an Exclusin mutua: Los monitores estn pensados para ser usados en entornos multiproceso o multihilo, y por lo tanto muchos procesos o threads pueden llamar a la vez a un procedimiento del monitor. Los monitores garantizan que en cualquier momento, a lo sumo un thread puede estar ejecutando dentro de un monitor. Ejecutar dentro de un monitor significa que slo un thread estar en estado de ejecucin mientras dura la llamada a un procedimiento del monitor. El problema de que dos threads ejecuten un mismo procedimiento dentro del monitor es que se pueden dar condiciones de carrera, perjudicando el resultado de los clculos. Para evitar esto y garantizar la integridad de los datos privados, el monitor hace cumplir la exclusin mutua implcitamente, de modo que slo un procedimiento est siendo ejecutado a la vez. De esta forma, si un thread llama a un procedimiento mientras otro thread est dentro del monitor, se bloquear y esperar en la cola de entrada hasta que el monitor quede nuevamente libre. Aunque se la llama cola de entrada, no debera suponerse ninguna poltica de encolado. Para que resulten tiles en un entorno de concurrencia, los monitores deben incluir algn tipo de forma de sincronizacin. Por ejemplo, supngase un thread que est dentro del monitor y necesita que se cumpla una condicin para poder continuar la

ejecucin. En ese caso, se debe contar con un mecanismo de bloqueo del thread, a la vez que se debe liberar el monitor para ser usado por otro hilo. Ms tarde, cuando la condicin permita al thread bloqueado continuar ejecutando, debe poder ingresar en el monitor en el mismo lugar donde fue suspendido. Para esto los monitores poseen variables de condicin que son accesibles slo desde adentro. Existen dos funciones para operar con las variables de condicin: cond_wait (c): suspende la ejecucin del proceso que la llama con la condicin c. El monitor se convierte en el dueo del lock y queda disponible para que otro proceso pueda entrar cond_signal(c): reanuda la ejecucin de algn proceso suspendido con cond_wait bajo la misma condicin. Si hay varios procesos con esas caractersticas elige uno. Si no hay ninguno, no hace nada

Las variables de condicin indican eventos, y no poseen ningn valor. Si un thread tiene que esperar que ocurra un evento, se dice espera por (o en) la variable de condicin correspondiente. Si otro thread provoca un evento, simplemente utiliza la funcin cond_signal con esa condicin como parmetro. De este modo, cada variable de condicin tiene una cola asociada para los threads que estn esperando que ocurra el evento correspondiente. Las colas se ubican en el sector de datos privados visto anteriormente La poltica de insercin de procesos en las colas de las variables condicin es la FIFO, ya que asegura que ningn proceso caiga en la espera indefinida, cosa que s ocurre con la poltica LIFO (puede que los procesos de la base de la pila nunca sean despertados) o con una poltica en la que se desbloquea a un proceso aleatorio Caractersticas: Es un proceso que se encarga de verificar el funcionamiento de algn recurso garantizando la exclusin mutua (mutex). En un monitor los procesos se bloquean y desbloquean. Pueden existir diversas implementaciones no estandarizadas de un monitor. En Java los monitores estn implementados de manera nativa con el modificador de los mtodos syncronized. El monitor es el mecanismo que nos permite controlar el acceso a una regin crtica, en este caso un mtodo. Tambin se puede utilizar semforos como objetos mutex disponibles en el paquete java.util.concurrent.

2.4.3 nter bloqueo (DeadLock)

El estancamiento se puede definir formalmente como sigue: "Un conjunto de procesos se estancan si cada proceso del conjunto esta esperando un evento que solo otro proceso del conjunto puede provocar". Puesto que todos los procesos estn en espera, ninguno de ellos podr ocasionar nuca ninguno de los eventos que podran desbloquear a algunos de los otros miembros del conjunto y todos los procesos seguirn esperando indefinidamente. Definicin de Abrazo Mortal

Un conjunto de procesos esta en un abrazo mortal cuando todos los procesos en ese conjunto estn esperando un evento que solo puede ser causado por otro proceso en el conjunto. Los eventos a los cuales nos estamos refiriendo son concernientes con la asignacin y liberacin de recursos principalmente. Sin embargo, otro tipo de eventos pueden llevar a la existencia de abrazos mortales. Para ejemplificar un estado de abrazo mortal, considere un sistema con tres unidades de disco. Suponga que existen tres procesos, cada uno de ellos tiene asignada una de las unidades de disco. Si ahora cada proceso pide otra unidad de disco, los tres procesos se encuentran ahora en un estado de abrazo mortal. Cada uno esta esperando el evento "unidad de disco liberada", lo cual solo puede ser causada por alguno de los otros procesos en espera. Este ejemplo ilustra un abrazo mortal involucrando procesos compitiendo por el mismo tipo de recurso. Los abrazos mortales pueden tambin involucrar diferentes tipos de recursos. Por ejemplo, considere un sistema con una impresora y una unidad de disco. Suponga que el proceso A tiene asignada la unidad de disco y que el proceso B tiene asignada la impresora. Ahora, si A pide la impresora y B pide la unidad de disco, ocurre un abrazo mortal.

Ejemplo de un abrazo mortal.

Debe ser obvio que un abrazo mortal es una condicin indeseable. En un abrazo mortal, los procesos nunca terminan de ejecutarse y los recursos del sistema esta amarrados, evitando que otros procesos puedan siquiera empezar.? Antes de discutir varios mtodos para manejar el problema de los abrazos mortales, seria til describir algunas de las propiedades que los caracterizan. Condiciones Necesarias Segn Coffman (1971), existen cuatro condiciones que deben cumplirse para que haya estancamiento. Una situacin de abrazo mortal puede surgir si y solo si las siguientes cuatro condiciones ocurren simultneamente en un sistema: Exclusin Mutua. Cada recurso se asigna por lo regular exactamente a un proceso o bien esta disponible. Al menos un recurso es mantenido en un modo no-compartible; esto es, solo un proceso a la vez puede usar el recurso. Si otro proceso solicita ese recurso, tiene que ser retardado hasta que el recurso haya sido liberado. 2. Retener y Esperar. Los procesos que regularmente contienen recursos otorgados antes pueden solicitar nuevos recursos. Debe existir un proceso que retenga al menos un recurso y este esperando para 1.

adquirir recursos adicionales que estn siendo retenidos por otros procesos. 3. No existe el derecho de des asignar (No preemtion). Los recursos previamente otorgados no pueden extraerse por la fuerza de un proceso. Deben ser liberados explcitamente por el proceso que los contiene. Los recursos no pueden ser des asignados (preempted); esto es, un recurso solo puede ser liberado voluntariamente por el proceso que lo retiene, despus de que el proceso ha terminado su tarea. 4. Espera Circular . Debe haber una cadena de dos o mas procesos, cada uno d los cuales este esperando u recurso contenido en el siguiente miembro de la cadena. Debe existir un conjunto {p0, p1, ...,pn} de procesos en espera tal que p0 este esperando por un recurso que esta siendo retenido por p1, p1 esta esperando por un recurso que esta siendo retenido por p2, ..., pn-1 esta esperando por un recurso que esta siendo retenido por pn y pn esta esperando por un recurso que esta siendo retenido por p0. Enfatizamos que las cuatro condiciones deben de cumplirse para que pueda ocurrir un abrazo mortal. La condicin de espera circular implica la condicin de retener y esperar, de tal manera que las cuatro condiciones no son totalmente independientes. Sin embargo, puede ser til el considerar cada condicin por separado. Una forma de modelar estas condiciones es usando un grafo de recursos: los crculos representan procesos, los cuadrados recursos. Una arista desde un recurso a un proceso indica que el recurso ha sido asignado al proceso. Una arista desde un proceso a un recurso indica que el proceso ha solicitado el recurso, y esta bloqueado esperndolo. Entonces, si hacemos el grafo con todos lo procesos y todos los recursos del sistema y encontramos un ciclo, los procesos en el ciclo estn bajo bloqueo mutuo.

Ejemplo de un grafo de recursos.

Mtodos para manejar los abrazos mortales

Principalmente, existen dos mtodos para manejar el problema de los abrazos mortales. Podemos usar algn protocolo para asegurar que el sistema nunca entrara en un estado de abrazo mortal. Alternativamente, podemos permitir que el sistema entre en un estado de abrazo mortal y despus recuperarnos. Como podremos ver posteriormente, el recuperarse de un abrazo mortal puede ser muy difcil y muy caro. Por ello, primeramente consideraremos los mtodos para asegurar que no ocurran los abrazos mortales. Comnmente, existen dos mtodos: El de PREVENCIN de abrazos mortales (Deadlock Prevention) y el de EVASIN de abrazos mortales (Deadlock Avoidance).

2.5 NIVELES, OBJETIVOS Y CRITERIOS DE PLANIFICACIN

La planificacin es el proceso por el cual el sistema operativo selecciona que proceso ejecutar. La seleccin del proceso se basa en alguno de los algoritmos de planificacin La planificacin de la CPU, en el sentido de conmutarla entre los distintos procesos, es una de las funciones del sistema operativo. Este despacho es llevado a cabo por un pequeo programa llamado planificador a corto plazo o dispatcher (despachador). La misin del dispatcher consiste en asignar la CPU a uno de los procesos ejecutables del sistema, para ello sigue un determinado algoritmo Los acontecimientos que pueden provocar la llamada al dispatcher dependen del sistema (son un subconjunto de las interrupciones), pero son alguno de estos El proceso en ejecucin acaba su ejecucin o no puede seguir ejecutndose (por una E/S, operacin WAIT, etc). Un elemento del sistema operativo ordena el bloqueo del proceso en ejecucin El proceso en ejecucin agota su quantum o cuanto de estancia en la CPU Un proceso pasa a estado listo Hay que destacar el hecho de que cuanto menos se llame al dispatcher menos tiempo ocupa la CPU un programa del sistema operativo, y, por tanto, se dedica ms tiempo a los procesos del usuario (un cambio de proceso lleva bastante tiempo). As, si slo se activa el dispatcher como consecuencia de los 2 primeros acontecimientos se estar haciendo un buen uso del procesador. Este criterio es acertado en sistemas por lotes en los que los programas no son interactivos. Sin embargo, en un sistema de tiempo compartido no es adecuado, pues un proceso que se dedicara a realizar clculos, y no realizara E/S, monopolizara el uso de la CPU. En estos sistemas hay que tener en cuenta el conjunto de todos los procesos, activndose el dispatcher con la circunstancia tercera y, posiblemente, la cuarta. Los sistema operativos en que las dos siguientes circunstancias no provocan la activacin del dispatcher muestran preferencia por el proceso en ejecucin, si no ocurre esto se tiene ms en cuenta el conjunto de todos los procesos Se puede definir el scheduling -algunas veces traducido como -planificacin- como el conjunto de polticas y mecanismos construidos dentro del sistema operativo que gobiernan la forma de conseguir que los procesos a ejecutar lleguen a ejecutarse El scheduling est asociado a las cuestiones de:

Cundo introducir un nuevo proceso en el Sistema. Determinar el orden de ejecucin de los procesos del sistema.

El scheduling est muy relacionado con la gestin de los recursos. Existen tres niveles de scheduling, estos niveles son: *Planificador de la CPU o a corto plazo. *Planificador a medio plazo. *Planificador a largo plazo. En la planificacin de procesos se suelen incluir varios niveles, en funcin del periodo temporal que cubren:

PLANIFICACIN A LARGO PLAZO

Este planificador est presente en algunos sistemas que admiten adems de procesos interactivos trabajos por lotes. Usualmente, se les asigna una prioridad baja a los trabajos por lotes, utilizndose estos para mantener ocupados a los recursos del sistema durante perodos de baja actividad de los procesos interactivos. Normalmente, los trabajos por lotes realizan tareas rutinarias como el clculo de nminas; en este tipo de tareas el programador puede estimar su gasto en recursos, indicndoselo al sistema. Esto facilita el funcionamiento del planificador a largo plazo. El objetivo primordial del planificador a largo plazo es el de dar al planificador de la CPU una mezcla equilibrada de trabajos, tales como los limitados por la CPU (utilizan mucho la CPU) o la E/S. As, por ejemplo, cuando la utilizacin de la CPU es baja, el planificador puede admitir ms trabajos para aumentar el nmero de procesos listos y, con ello, la probabilidad de tener algn trabajo til en espera de que se le asigne la CPU. A la inversa, cuando la utilizacin de la CPU llega a ser alta, y el tiempo de respuesta comienza a reflejarlo, el planificador a largo plazo puede optar por reducir la frecuencia de admisin de trabajos. Normalmente, se invoca al planificador a largo plazo siempre que un proceso termina. La frecuencia de invocacin depende, pues, de la carga del sistema, pero generalmente es mucho menor que la de los otros dos planificadores. Esta baja frecuencia de uso hace que este planificador pueda permitirse utilizar algoritmos complejos, basados en las estimaciones de los nuevos trabajos

PLANIFICACIN A MEDIANO PLAZO: En los sistemas de multiprogramacin y tiempo compartido varios procesos residen en la memoria principal. El tamao limitado de sta hace que el nmero de procesos que residen en ella sea finito. Puede ocurrir que todos los procesos en memoria estn bloqueados, desperdicindose as la CPU. En algunos sistemas se intercambian procesos enteros (swap) entre memoria principal y memoria secundaria (normalmente discos), con esto se aumenta el nmero de procesos, y, por tanto, la probabilidad de una mayor utilizacin de la CPU.
El planificador a medio plazo es el encargado de regir las transiciones de procesos entre memoria principal y secundaria, acta intentando maximizar la utilizacin de los recursos. Por ejemplo, transfiriendo siempre a memoria secundaria procesos bloqueados, o transfiriendo a memoria principal procesos bloqueados nicamente por no tener memoria.

PLANIFICACIN A CORTO PLAZO Qu proceso ser el que se ejecutar en el procesador en el instante siguiente

Expulsin denota si un proceso acapara el procesador cuando est ejecutndose. Existen sistemas con y sin expulsin:

a) Sin expulsin: un proceso conserva el uso del procesador mientras lo desee; es decir, mientras no solicite del SO un servicio que lo bloquee. Ventajas: minimiza tiempo de planificacin. Inconvenientes: un proceso podra monopolizar el uso del procesador. b) Con expulsin: el SO puede desalojar a un proceso del uso del procesador (sin que el proceso lo haya solicitado). Ventaja: control sobre el tiempo de ejecucin de cada proceso. Inconveniente: gasto de tiempo. OBJETIVOS Y CRITERIOS DE PLANIFICACIN Los objetivos del planificador se resumen en: a) Reparto equitativo del tiempo de procesador b) Eficiencia en el uso del procesador c) Menor tiempo de respuesta en uso interactivo d) Cumplir plazos de ejecucin de los sistemas de tiempo real El principal objetivo de la planificacin a corto plazo es repartir el tiempo del procesador de forma que se optimicen algunos puntos del comportamiento del sistema. Generalmente se fija un conjunto de criterios con los que evaluar las diversas estrategias de planificacin. El criterio ms empleado establece dos clasificaciones. En primer lugar, se puede hacer una distincin entre los criterios orientados a los usuarios y los orientados al sistema. Los criterios orientados al usuario se refieren al comportamiento del sistema tal y como lo perciben los usuarios o los procesos. Uno de los parmetros es el tiempo de respuesta. El tiempo de respuesta es el periodo de tiempo transcurrido desde que se emite una solicitud hasta que la respuesta aparece en la salida. Sera conveniente disponer de una poltica de planificacin que ofrezca un buen servicio a diversos usuarios.

Otros criterios estn orientados al sistema, esto es, se centran en el uso efectivo y eficiente del procesador. Un ejemplo puede ser la productividad, es decir, el ritmo con el que los procesos terminan. La productividad es una medida muy vlida del rendimiento de un sistema y que sera deseable maximizar. Otra forma de clasificacin es considerar los criterios relativos al rendimiento del sistema y los que no lo son. Los criterios relativos al rendimiento son cuantitativos y, en general, pueden evaluarse o ser analizados fcilmente. Algunos ejemplos son el tiempo de respuesta y la productividad. Los criterios no relativos al rendimiento son, en cambio cualitativos y no pueden ser evaluados fcilmente. Un ejemplo de estos criterios es la previsibilidad. Sera conveniente que el servicio ofrecido a los usuarios tenga las mismas caractersticas en todo momento, independientemente de la existencia de otros trabajos ejecutados por el sistema. En particular, una disciplina de planificacin debe: Ser equitativa: debe intentar hacer una planificacin justa, esto es, se debe tratar a todos los procesos de la misma forma y no aplazar indefinidamente ningn proceso. La mejor forma de evitarlo es emplear alguna tcnica de envejecimiento; es decir, mientras un proceso espera un recurso, su prioridad debe crecer. Ser eficiente: debe maximizar el uso de los recursos tales como intentar que la ocupacin de la CPU sea mxima. Al mismo tiempo se debe intentar reducir el gasto extra por considerar que es trabajo no productivo. Normalmente el idear algoritmos eficientes supone invertir recursos en gestin del propio sistema. Lograr un tiempo bueno de respuesta, es decir, que los usuarios interactivos reciban respuesta en tiempos aceptables. Lograr un tiempo de proceso global predecible. Esto quiere decir que un proceso debe ejecutarse aproximadamente en el mismo tiempo y casi al mismo costo con independencia de la carga del sistema. Elevar al mximo la productividad o el rendimiento, esto es, maximizar el nmero de trabajos procesados por unidad de tiempo. Eso supone, por un lado, dar preferencia a los procesos que ocupan recursos decisivos y, por otro, favorecer a los procesos que muestran un comportamiento deseable. En el primer caso conseguimos liberar el recurso cuanto antes para que est disponible para un proceso de mayor prioridad. Con el segundo criterio escogemos a los procesos que no consumen muchos recursos dejndole al sistema mayor capacidad de actuacin. Estos criterios son dependientes entre s y es imposible optimizar todos de forma simultnea. Por ejemplo, obtener un buen tiempo de respuesta puede exigir un algoritmo de planificacin que alterne entre los procesos con frecuencia, lo que incrementa la sobrecarga del sistema y reduce la productividad. Por tanto, en el diseo de una poltica de planificacin entran en juego compromisos entre requisitos opuestos; el peso relativo que reciben los distintos requisitos depender de la naturaleza y empleo del sistema

2.6 TCNICAS DE ADMINISTRACIN DEL PLANIFICADOR Las disciplinas de planificacin pueden ser: Expropiativas No expropiativas Se denomina planificador al software del sistema operativo encargado de asignar los recursos de un sistema entre los procesos que los solicitan. Siempre que haya tomar una decisin, el planificador debe decidir cul de los procesos que compiten por la posesin de un determinado recursos lo recibir. Los algoritmos (tcnicas) tienen distintas propiedades segn los criterios en los que se basen para su construccin, lo cual se refleja en qu tipo de procesos se puede ver favorecido frente a otro en la disputa del procesador. Antes de realizar la eleccin de un algoritmo se debe considerar las propiedades de estos frente al criterio de diseo elegido. Algunos de estos son: a) Eficacia: Se expresa como un porcentaje del tiempo medio de utilizacin. Aunque puede parecer lgico intentar mantener este parmetro prximo al 100%, con un valor tan elevado otros aspectos importante de medida del comportamiento del sistema pueden verse deteriorados, como por ejemplo el tiempo medio de espera. b) Rendimiento: Es una medida del nmero de procesos completados por unidad de tiempo. Por ejemplo 10 procesos por segundo. c) Tiempo de retorno o regreso: Es el intervalo de tiempo que transcurre desde que un proceso se crea o presenta hasta que completa por el sistema. d) Tiempo de espera: Es el tiempo que el proceso espera hasta que se le concede el procesador. Puede resultar una medida ms adecuada de la eficiencia del sistema, ya que se elimina de la media el tiempo que tarda en ejecutarse el mismo. e) Tiempo de respuesta a un evento: Se denomina as el intervalo de tiempo que transcurre desde que se seala un evento hasta que se ejecuta la primera instruccin de la rutina de servicio de dicho evento. El criterio de seleccin de un algoritmo se suele basar en la maximizacin o minimizacin de una funcin de los parmetros anteriores.

2.6.1 FIFO Algoritmo de planificacin de FIFO Tal vez la disciplina mas simple de planificacin sea la de primeras entradas ? primeras salidas (PEPS). 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. Es junto 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. FIFO ofrece variaciones relativamente pequeas en los tiempos de respuesta y por lo tanto es ms predecible que los otros esquemas. No es til en la planificacin para los usuarios interactivos porque no puede garantizar buenos tiempos de respuesta. El esquema FIFO rara vez se usa como esquema principal en los sistemas actuales, pero a menudo esta incorporado en otros sistemas. Por ejemplo, muchos esquemas de planificacin despachan los procesos de acuerdo con la prioridad, pero los procesos con la misma prioridad se despachan de acuerdo con el esquema FIFO. Este es un algoritmo que no usa apropiacin, y que consiste en atender a los procesos por estricto orden de llegada a la lista de procesos listos. Cada proceso se ejecuta hasta que termina, o hasta que hace una llamada bloqueante (de E/S). Se trata de una poltica muy simple y sencilla de llevar a la practica, pero muy pobre en cuanto a su comportamiento. Las caractersticas principales de este algoritmo son las siguientes: No es apropiativa. Es justa, aunque los procesos largos hacen esperar mucho a los cortos. Es una poltica predecible. El tiempo promedio de servicio es muy variable ya que esta en funcin del nmero de procesos y la duracin promedio que tenga. EJEMPLO Proceso Tiempo de UCP P1 24 P2 3 P3 3 Media del tiempo de espera: Caso 1) ( 0 + 24 + 27 ) / 3 =17 Caso 2) ( 6 + 0 + 3 ) / 3 = 3 En este esquema se tienen tres procesos (P1, P2, P3) listos para ejecutarse, con un tiempo de ejecucin de 24, 3 y 3 unidades de tiempo (para facilidad tomaremos milisegundos como unidad de tiempo) respectivamente. Los procesos se ejecutan en ese mismo orden. El primer proceso se ejecuta de inmediato y no espera nada. El segundo proceso espera todo lo que dura en ejecutarse el primer proceso que son 24 milisegundos. Por ultimo el tercer proceso esperara la suma de lo que duran en ejecutarse los dos procesos anteriores, o sea, 27 segundos. Todo esto da como resultado un tiempo promedio de espera de 17 milisegundos. Si en cambio, el orden en que se ejecuten los procesos es como el caso 2), entonces el proceso P2 se ejecutara de inmediato, P3 esperara lo que tarde en ejecutarse P2 (3 milisegundos) y P1 esperara lo que duran los dos procesos anteriores, obteniendo un tiempo promedio de espera de 3 milisegundos. Como puede verse el tiempo promedio de espera que tengan los procesos depende por completo del orden en que llegan los procesos a ejecutarse

2.6.2 SJF Al igual que en el algoritmo FIFO las rfagas se ejecutan sin interrupcin, por tanto, slo es til para entornos batch. Su caracterstica es que cuando se activa el planificador, ste elige la rfaga de menor duracin. Es decir, introduce una nocin de prioridad entre rfagas. Hay que recordar que en los entornos batch se pueden hacer estimaciones del tiempo de ejecucin de los procesos. La ventaja que presenta este algoritmo sobre el algoritmo FIFO es que minimiza el tiempo de finalizacin promedio, como puede verse en el siguiente ejemplo: Supongamos que en un momento dado existen tres rfagas listos R1, R2 y R3, sus tiempos de ejecucin respectivos son 24, 3 y 3 ms. El proceso al que pertenece la rfaga R1 es la que lleva ms tiempo ejecutable, seguido del proceso al que pertenece R2 y del de R3. FIFO F = (24 + 27 + 30) / 3 = 27 ms. SJF F = (3 + 6 + 30) / 3 = 13 ms.
2.6.3 Planificacin de Asignacin en Rueda (RR-Round Robin) RR

Cada proceso tiene asignado un intervalo de tiempo de ejecucin, llamado quantum o cuanto. Si el proceso agota su quantum de tiempo, se elige a otro proceso para ocupar la CPU. Si el proceso se bloquea o termina antes de agotar su quantum tambin se alterna el uso de la CPU. El round robin es muy fcil de implementar. Todo lo que necesita el planificador es mantener una lista de los procesos listos Es un sistema apropiativo. Cada proceso recibe una fraccin de tiempo de procesamiento o cuanto para su ejecucin, de manera que cuando se esta ejecutando y excede el tiempo que se le ha concedido, se genera una interrupcin de reloj, mediante la cual la ejecucin del proceso se detiene y se coloca al proceso al final de la cola de procesos listos para su posterior ejecucin, seleccionndose a continuacin un nuevo proceso de la cola para su ejecucin. Si un proceso finaliza su ejecucin antes de que termine el tiempo que se le ha asignado, este cede el control, seleccionndose un nuevo proceso de la cola para su ejecucin. Con el Round Robind, cuando un proceso inicia una operacin de E/S, este es penalizado respecto de los procesos que no realizan E/S. Los procesos se despachan en FIFO y disponen de una cantidad limitada de tiempo de cpu, llamada divisin de tiempo o cuanto. Si un proceso no termina antes de expirar su tiempo de cpu ocurren las siguientes acciones: 1. La cpu es apropiada. 2. La cpu es otorgada al siguiente proceso en espera. 3. El proceso apropiado es situado al final de la lista de listos. Es efectiva en ambientes de tiempo compartido. La sobrecarga de la apropiacin se mantiene baja mediante mecanismos eficientes de intercambio de contexto y con suficiente memoria principal para los procesos.

Tamao del Cuanto o Quantum La determinacin del tamao del cuanto es decisiva para la operacin efectiva de un sistema computacional. Los interrogantes son: ?cuanto pequeo o grande?, ?cuanto fijo o variable? y ?cuanto igual para todos los procesos de usuarios o determinado por separado para cada uno de ellos? Si el cuanto se hace muy grande, cada proceso recibe todo el tiempo necesario para llegar a su terminacin, por lo cual la asignacin en rueda (RR) degenera en FIFO. Si el cuanto se hace muy pequeo, la sobrecarga del intercambio de contexto se convierte en un factor dominante y el rendimiento del sistema se degrada, puesto que la mayor parte del tiempo de cpu se invierte en el intercambio del procesador (cambio de contexto) y los procesos de usuario disponen de muy poco tiempo de cpu. El cuanto debe ser lo suficientemente grande como para permitir que la gran mayora de las peticiones interactivas requieran de menos tiempo que la duracin del cuanto, es decir que el tiempo transcurrido desde el otorgamiento de la cpu a un proceso hasta que genera una peticin de Entrada / Salida debe ser menor que el cuanto establecido, de esta forma, ocurrida la peticin la cpu pasa a otro proceso y como el cuanto es mayor que el tiempo transcurrido hasta la peticin de Entrada / Salida, los procesos trabajan al mximo de velocidad, se minimiza la sobrecarga de apropiacin y se maximiza la utilizacin de la Entrada / Salida. El cuanto optimo vara de un sistema a otro y con la carga, siendo un valor de referencia 100 mseg (cien milisegundos). Caractersticas de RR 1. Baja sobrecarga si el cambio entre un proceso y otro es eficiente y los procesos siempre estn en la memoria principal 2. El tamao optimo del quantum depende de: El tipo de sistema. Las cargas que vaya a soportar el sistema. El numero de procesos en el sistema y su tipo. 3. Es la poltica mas usada para tiempo compartido. 4. Ofrece un servicio igual para todos los procesos. 5. Es una poltica apropiativa. 6. Mantiene mas equilibradas las colas de procesos listos y bloqueados. Virtual Round Robind (vrr) Este sistema va a permitir solucionar el problema del RoundRobind en relacin al favorecimiento que este realiza con los procesos orientados a la CPU frente a los procesos orientados a las operaciones de E/S. El vrr utiliza una cola auxiliar de espera que incluye aquellos procesos que no hayan consumido completamente el cuanto que tenan asignados al verse detenidos por una operacin de E/S. Esta cola tiene prioridad respecto a la principal y a los procesos almacenados en ella se les asigna temporalmente (hasta que se ejecuten de nuevo) un nuevo cuanto, que es el tiempo del cuanto principal que no llegaron a consumir antes de ser bloqueados (el 2o cuanto es el cuanto principal menos el tiempo del mismo que ya haya sido consumido por el proceso).

2.6.4 Queves Multi-level Un algoritmo de planificacin multinivel particin la cola de listos en colas separadas. Se asignan en forma permanente los trabajos a una cola, generalmente, basndose en alguna propiedad del mismo (requerimientos de memoria, tipo de trabajo), teniendo cada cola su propio algoritmo. Por ejemplo, la cola interactiva podra planificarse usando RR y la batch FIFO. Ningn trabajo en una cola de baja prioridad puede ejecutarse si las colas con mayor prioridad no estn vacas. Si algn trabajo entra en una cola de mayor prioridad, el trabajo de otras colas es interrumpido 2.6.5 Multi-Level Feedback Queves En colas multinivel realimentadas los trabajos pueden moverse dentro de distintas colas. La idea es separar procesos con distintos tipos de interrupciones de la CPU. Si un trabajo consume mucho tiempo de CPU, ser movido a una cola con menor prioridad. En forma similar, si un proceso espera demasiado tiempo en una cola de baja prioridad, lo moveremos a una cola de mayor prioridad. En general un planificador de este tipo esta definido por los siguientes parmetros: 1. El nmero de colas. 2. El tipo de algoritmo de planificacin de cada cola. 3. Un mtodo de determinacin de cuando mover un trabajo a una cola de mayor prioridad. 4. Un mtodo de determinacin de cuando mover un trabajo a una cola de menor prioridad. 5. Un mtodo de determinacin de a qu cola se enviar un trabajo cuando necesita servicio.