INSTITUTO TECNOLOGICO DE MATAMOROS

UNIDADII

NOMBRE:JUAN ISSAC HERNANDEZ DEGOLLADO

MAESTRO: JUAN PABLO TRISTAN

TEMA:ADMINISTRACION DE PRCOESOS Y PROCESADOR GRUPO B ING.EN SISTEMAS COMUTACIONALES

ADMINISTRACION DE PROCESOS Y DEL PROCESADOR

Concepto de proceso
El concepto central de cualquier sistema operativo es el proceso: una abstraccin de un programa en ejecucin. Todo lo dems gira alrededor de este concepto, y es importante que el diseador (y el estudiante) de sistemas operativos sepa lo antes posible qu es un proceso. Todas las computadoras modernas pueden hacer varias cosas al mismo tiempo. Mientras ejecuta un programa de usuario, una computadora tambin puede estar leyendo de un disco y enviando texto a una pantalla o impresora. En un sistema de multiprogramacin, la CPU tambin conmuta de un programa a otro, ejecutando cada uno durante decenas o centenas de milisegundos. Si bien, estrictamente hablando, en un instante dado la CPU est ejecutando slo un programa, en el curso de un segundo puede trabajar con varios programas, dando a los usuarios la ilusin de paralelismo. A veces se usa el trmino seudoparalelismo para referirse a esta rpida conmutacin de la CPU entre programas, para distinguirla del verdadero paralelismo de hardware de los sistemas multiprocesador (que tienen dos o ms CPU que comparten la misma memoria fsica). Para el ser humano es difcil seguir la pista a mltiples actividades paralelas. Por ello, los diseadores de sistemas operativos han desarrollado a lo largo de los aos un modelo (procesos secuenciales) que facilita el manejo del paralelismo.

Estados y transiciones de procesos

Aunque cada proceso es una entidad independiente, con su propio contador de programa y estado interno, los procesos a menudo necesitan interactuar con otros procesos. Un proceso podra generar ciertas salidas que otro proceso utiliza como entradas. En el comando de Shell cat captulol captulo2 captulo3 grep rbol el primer proceso, que ejecuta cat, concatena y enva a la salida tres archivos. El segundo proceso, que ejecuta grep, selecciona todas las lneas que contienen la palabra rbol. Dependiendo de las velocidades relativas de los dos procesos (que a su vez dependen de la complejidad relativa de los programas y de cunto tiempo de CPU ha ocupado cada uno), puede suceder que grep est listo para ejecutarse, pero no haya entradas esperando ser procesadas por l. En tal caso, grep deber bloquearse hasta que haya entradas disponibles. Cuando un proceso se bloquea, lo hace porque le es imposible continuar lgicamente, casi siempre porque est esperando entradas que todava no estn disponibles. Tambin puede ser que un programa que conceptualmente est listo y en condiciones de ejecutarse sea detenido porque el sistema operativo ha decidido asignar la CPU a otro proceso durante un tiempo. Estas dos condiciones son totalmente distintas. En el primer caso, la suspensin es inherente al problema (no es posible procesar la lnea de comandos delusuario antes de que ste la teclee). En el segundo caso, se trata de un

tecnicismo del sistema (no hay suficientes CPU para darle a cada proceso su propio procesador privado). En la Fig. 2-2 vemos un diagrama de estados que muestra los tres estados en los que un proceso puede estar: 1. Ejecutndose (usando realmente la CPU en ese instante). 2. Listo (se puede ejecutar, pero se suspendi temporalmente para dejar que otro pro ceso se ejecute). 3. Bloqueado (no puede ejecutarse en tanto no ocurra algn evento externo). Lgicamente, los dos primeros estados son similares. En ambos casos el proceso est dispuesto a ejecutarse, slo que en el segundo temporalmente no hay una CPU a su disposicin. El tercer estado es diferente de los primeros dos en cuanto a que el proceso no puede ejecutarse, incluso si la CPU no tiene nada ms que hacer. Puede haber cuatro transiciones entre estos tres estados, como se muestra. La transicin 1 ocurre cuando un proceso descubre que no puede continuar. En algunos sistemas el proceso debe ejecutar una llamada al sistema, BLOCK, para pasar al estado bloqueado. En otros sistemas, cuando un proceso lee de un conducto o de un archivo especial (p. ej., una terminal) y no hay entradas disponibles, se bloquea automticamente.

Las transiciones 2 y 3 son causadas por el planificador de procesos, una parte del sistema operativo, sin que el proceso se entere siquiera de ellas. La transicin 2 ocurre cuando el planificador decide que el proceso en ejecucin ya se ejecut durante suficiente tiempo y es hora de dejar que otros procesos tengan algo de tiempo de CPU. La transicin 3 ocurre cuando todos los dems procesos han disfrutado de una porcin justa y es hora de que el primer proceso reciba otra vez la CPU para ejecutarse. El tema de la planificacin, es decir, de decidir cul proceso debe ejecutarse cundo y durante cunto tiempo, es muy importante; lo examinaremos ms adelante en este captulo. Se han inventado muchos algoritmos para tratar de equilibrar las exigencias opuestas de eficiencia del sistema global y de equitatividad para los procesos individuales. La transicin 4 ocurre cuando acontece el suceso externo que un proceso estaba esperando (como la llegada de entradas). Si ningn otro proceso se est ejecutando en ese instante, se dispara de inmediato la transicin 3, y el proceso comienza a ejecutarse. En caso

contrario, el proceso tal vez tenga que esperar en el estado listo durante cierto tiempo hasta que la CPU est disponible. Usando el modelo de procesos, es mucho ms fcil visualizar lo que est sucediendo dentro del sistema. Algunos de los procesos ejecutan programas que llevan a cabo comandos tecleados por un usuario. Otros procesos forman parte del sistema y se encargan de tareas tales como atender solicitudes de servicios de archivos o manejar los detalles de la operacin de una unidad de disco o de cinta. Cuando ocurre una interrupcin de disco, el sistema toma la decisin de dejar de ejecutar el proceso en curso y ejecutar el proceso de disco, que estaba bloqueado esperando dicha interrupcin. As, en lugar de pensar en interrupciones, podemos pensar en procesos de usuario, procesos de disco, procesos de terminal, etc., que se bloquean cuando estn esperando que algo suceda. Cuando se ha ledo el bloque de disco o se ha tecleado el carcter, el proceso que lo estaba esperando se desbloquea y es elegible para ejecutarse otravez. Esta perspectiva da lugar al modelo que se muestra en la Fig. 2-3. Aqu, el nivel ms bajo del sistema operativo es el planificador, con diversos procesos arriba de l. Todo el manejo de interrupciones y los detalles del inicio y la detencin de procesos estn ocultos en el planificador, que en realidad es muy pequeo. El resto del sistema operativo est estructurado en forma de procesos. El modelo de la Fig. 2-3se emplea en MINIX, con el entendido de que planificador no slo se refiere a planificacin de procesos, sino tambin a manejo de interrupciones y toda la comunicacin entre procesos. No obstante,como una primera aproximacin, s muestra la estructura bsica.

Procesos ligeros: hilos o hebras En un proceso tradicional del tipo que acabamos de estudiar hay un solo hilo de control y un solo contador de programa en cada proceso. Sin embargo, algunos sistemas operativos modernos manejan mltiples hilos de control dentro de un proceso. Estos hilos de control normalmente se llaman slo hilos u, ocasionalmente, procesos ligeros.

Vemos tres procesos tradicionales. Cada proceso tiene su propio espacio de direcciones y un solo hilo de control. En contraste, en la Fig. 2-6(b) vemos un solo proceso con tres hilos de control. Aunque en ambos casos tenemos tres hilos, en la Fig. 2-6(a) cada uno de ellos opera en un espacio de direcciones distinto, en tanto que en la Fig. 2-6(b) los tres comparten el mismo espacio de direcciones.

Como ejemplo de situacin en la que podran usarse mltiples hilos, consideremos un proceso servidor de archivos que recibe solicitudes para leer y escribir archivos y devuelve los datos solicitados oacepta datos actualizados. A fin de mejorar el rendimiento, el servidor mantiene un cach de archivos recientemente usados en la memoria, leyendo del cach y escribiendo en l siempre que es posible. Esta situacin se presta bien al modelo de la Fig. 2.6(b). Cuando llega una solicitud, se le entrega a un hilo para que la procese. Si ese hilo se bloquea en algn momento esperando una transferencia de disco, los dems hilos an pueden ejecutarse, de modo que el servidor puede seguir procesando nuevas solicitudes incluso mientras se est efectuando E/S de disco. En cambio, el modelo de la Fig. 2-6(a) no es apropiado, porque es indispensable que todos los hilos del servidor de archivos tengan acceso al mismo cach, y los tres hilos de la Fig. 2-6(a) no comparten el mismo espacio de direcciones y, por tanto, no pueden compartir el mismo cach en memoria.

Otro ejemplo de caso en el que son tiles los hilos es el de los navegadores de la World Wide Web, como Netscape y Mosaic. Muchas pginas Web contienen mltiples imgenes pequeas. Para cada imagen de una pgina Web, el navegador debe establecer una conexin individual con el sitio de la pgina de casa y solicitar la imagen. Se desperdicia una gran cantidad de tiempo estableciendo y liberando todas estas conexiones. Si tenemos mltiples hilos dentro del navegador, podemos solicitar muchas imgenes al mismo tiempo, acelerando considerablemente el rendimiento en la mayor parte de los casos, ya que en el caso de imgenes pequeas el tiempo de preparacin es el factor limitante, no la rapidez de la lnea de transmisin. Cuando estn presentes mltiples hilos en el mismo espacio de direcciones, algunos de los campos de la Fig. 2-4 no contienen informacin para cada proceso, sino para cada hilo, as que se necesita una tabla de hilos aparte, con una entrada por hilo. Entre los elementos que son distintos para cada hilo estn el contador de programa, los registros y el estado. El contador de programa se necesita porque los hilos, al igual que los procesos, pueden suspenderse y reanudarse. Los registros se necesitan porque cuando los hilos se suspenden sus registros deben guardarse. Por ltimo, los hilos, al igual que los procesos, pueden estar en los estados de ejecutndose, listo o bloqueado. En algunos sistemas el sistema operativo no est consciente de la existencia de los hilos. En otras palabras, los hilos se manejan totalmente en el espacio de usuario. Por ejemplo, cuando un hilo est a punto de bloquearse, escoge e inicia a su sucesor antes de detenerse. Hay varios paquetes de hilos a nivel de usuario, incluidos los paquetes de hilos P de POSIX e hilos C de Mach. En otros sistemas, el sistema operativo est consciente de la existencia de mltiples hilos por proceso, as que, cuando un hilo se bloquea, el sistema operativo escoge el que se ejecutar a continuacin, ya sea del mismo proceso o de uno distinto. Para realizar la planificacin, el kernel debe tener una tabla de hilos que liste todos los hilos del sistema, anloga a la tabla de procesos. Aunque estas dos alternativas pueden parecer equivalentes, su rendimiento es muy distinto. La conmutacin de hilos es mucho ms rpida cuando la administracin de hilos se efecta en el espacio de usuario que cuando se necesita una llamada al kernel. Este hecho es un argumento convincente para realizar la administracin de hilos en el espacio de usuario. Por otro lado, cuando los hilos se manejan totalmente en el espacio de usuario y uno se bloquea (p. ej., esperando E/S o que se maneje una falla de pgina), el kernel bloquea todo el proceso, ya que no tiene idea de que existen otros hilos. Este hecho es un argumento importante en favor de realizar la administracin de hilos en el kernel. La consecuencia es que se usan ambos sistemas; adems, se han propuesto diversos esquemas hbridos (Anderson et al., 1992). Sea que los hilos sean administrados por el kernel o en el espacio de usuario, introducen una serie de problemas que deben resolverse y que modifican sustancialmente el modelo de programacin. Para comenzar, consideremos los efectos de la llamada al sistema FORK. Si el proceso padre tiene mltiples hilos, debe tenerlos tambin el hijo? Si no, es posible que el proceso no funcione correctamente, ya que es posible que todos ellos sean esenciales.

Por otro lado, si el proceso hijo obtiene tantos hilos como el padre, qu sucede si un hilo estaba bloqueado en una llamada READ de, digamos, el teclado. Hay ahora dos hilos bloqueados esperando el teclado? Si se teclea una lnea, reciben ambos hilos una copia de ella? Slo el padre? Slo el hijo? El mismo problema ocurre con las conexiones de red abiertas. Otra clase de problemas tiene que ver con el hecho de que los hilos comparten muchas estructuras de datos. Qu sucede si un hilo cierra un archivo mientras otro todava lo est leyendo? Supongamos que un hilo se da cuenta de que hay muy poca memoria y comienza a asignar ms memoria. Luego, antes de que termine de hacerlo, ocurre una conmutacin de hilo, y el nuevo hilo tambin se da cuenta de que hay demasiada poca memoria y comienza a asignar ms memoria. La asignacin ocurre una sola vez o dos? En casi todos los sistemas que no se disearon pensando en hilos, las bibliotecas (como el procedimiento de asignacin de memoria) no son reentrantes, y se caen si se emite una segunda llamada mientras la primera todava est activa. Otro problema se relaciona con los informes de error. En UNIX, despus de una llamada al sistema, la situacin de la llamada se coloca en una variable global, errno. Qu sucede si un hilo efecta una llamada al sistema y, antes de que pueda leer errno, otro hilo realiza una llamada al sistema, borrando el valor original? Consideremos ahora las seales. Algunas seales son lgicamente especficas para cada hilo, en tanto que otras no lo son. Por ejemplo, si un hilo invoca ALARM, tiene sentido que la seal resultante se enve al hilo que efectu la llamada. Si el kernel est consciente de la existencia de hilos, normalmente puede asegurarse de que el hilo correcto reciba la seal. Si el kernel no sabe de los hilos, el paquete de hilos de alguna forma debe seguir la pista a las alarmas. Surge una complicacin adicional en el caso de hilos anivel de usuario cuando (como sucede en UNIX) un proceso slo puede tener una alarma pendiente a la vez y varios hilos pueden invocar ALARM independientemente. Otras seales, como una interrupcin de teclado, no son especficas para un hilo. Quin deber atraparlas? Un hilo designado? Todos los hilos? Un hilo recin creado? Todas estas soluciones tienen problemas. Adems, qu sucede si un hilo cambia los manejadores de seales sin avisar a los dems hilos? Un ltimo problema introducido por los hilos es la administracin de la pila. En muchos sistemas, cuando hay un desbordamiento de pila, el kernel simplemente ampla la pila automticamente. Cuando un proceso tiene varios hilos, tambin debe tener varias pilas. Si el kernel no tiene conocimiento de todas estas pilas, no podr hacerlas crecer automticamente cuando haya una falla de pila. De hecho, es posible que el kernel ni siquiera se d cuenta de que la falla de memoria est relacionada con el crecimiento de una pila. Estos problemas ciertamente no son insuperables, pero s ponen de manifiesto que la simple introduccin de hilos en un sistema existente sin un rediseo sustancial del sistema no funcionar. Cuando menos, es preciso redefinir la semntica de las llamadas al sistema y

reescribir las bibliotecas. Adems, todas estas cosas deben hacerse de modo tal que sigan siendo compatibles hacia atrs con los programas existentes para el caso limitante de un proceso con un solo hilo. Si desea informacin adicional acerca de los hilos.

Concurrencia y secuenciabilidad .
La concurrencia es el punto clave de los tres campos anteriores y fundamentales para el di-seo de sistemas operativos. La concurrencia comprende un gran nmero de cuestiones de diseo, incluyendo la comunicacin entre procesos, comparticin y competencia por los recursos, sincronizacin de la ejecucin de varios procesos y asignacin del tiempo de procesador a los procesos. Se vera que estas cuestiones no solo surgen en entornos de multi-procesadores y proceso distribuido, sino incluso en sistemas multi programados con un solo procesador. La concurrencia puede presentarse en tres contextos diferentes: Varias aplicaciones: La multiprogramacin se cre para permitir que el tiempo de procesador de la mquina fuese compartido dinmicamente entre varios trabajos o aplicaciones activas. Aplicaciones estructuradas: Como ampliacin de los principios del diseo modular yla programacin estructurada, algunas aplicaciones pueden implementarse eficazmente como un conjunto de procesos concurrentes. 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. En un sistema multiprogramado con un nico procesador, los procesos se intercalan en el tiempo para dar la apariencia de ejecucin simultnea (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 ejecucin intercalada produce beneficios importantes en la eficiencia del procesamiento y en la estructuracin de los programas. En un sistema con varios procesadores, no solo es posible intercalar los procesos, sino tambin superponerlos. A primera vista, podra parecer que la intercalacin y la superposicin representan formas de ejecucin muy diferentes y que introducen problemas distintos. De hecho, ambas tcnicas 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 multiprogramacin parten del hecho de que la velocidad relativa de ejecucin 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 polticas de planificacin.

OBJETIVOS DE PLANIFICACIN Los objetivos de la planificacin del procesador son los siguientes e involucran alos conceptos detallados seguidamente: Ser justa: Todos los procesos son tratados de igual manera. Ningn proceso espostergado indefinidamente. Maximizar la capacidad de ejecucin: Maximizar el nmero de procesos servidospor unidad de tiempo. Maximizar el nmero de usuarios interactivos que reciban unos tiempos derespuesta aceptables: En un mximo de unos segundos. Ser predecible: Un trabajo dado debe ejecutarse aproximadamente en la mismacantidad 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 utilizarn recursosinfrautilizados. Equilibrar respuesta y utilizacin: La mejor manera de garantizar buenos tiemposde respuesta es disponer de los recursos suficientes cuando se necesitan, pero lautilizacin total de recursos podr ser pobre. Evitar la postergacin indefinida: Se utiliza la estrategia del envejecimiento .Mientras un proceso espera por un recurso su prioridad debe aumentar, as laprioridad llegar a ser tan alta que el proceso recibir el recurso esperado. Asegurar la prioridad: Los mecanismos de planificacin deben favorecer a losprocesos con prioridades ms altas. Dar preferencia a los procesos que mantienen recursos claves: Un proceso debaja prioridad podra mantener un recurso clave, que puede ser requerido por unproceso de ms alta prioridad. Si el recurso es no apropiativo, el mecanismo deplanificacin debe otorgar al proceso un tratamiento mejor del que lecorrespondera normalmente, puesto que es necesario liberar rpidamente elrecurso clave. Dar mejor tratamiento a los procesos que muestren un comportamientodeseable: Un ejemplo de comportamiento deseable es una tasa baja depaginacin. Degradarse suavemente con cargas pesadas: Un mecanismo de planificacin nodebe colapsar con el peso de una exigente carga del sistema. Se debe evitar unacarga excesiva mediante las siguientes acciones: No permitiendo que se creennuevos procesos cuando la carga ya es pesada. Dando servicio a la carga mspesada al proporcionar un nivel moderadamente reducido de servicio a todos losprocesos

CRITERIOS DE PLANIFICACIN -Equidad Garantizar que cada proceso obtiene su proporcin 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 usuariosinteractivos. -Tiempo de regreso Minimizar el tiempo que deben esperar los usuarios por lotes(batch) para obtener sus resultados. -Rendimiento Maximizar el nmero de tareas procesadas por hora.

Tcnicas de administracin del planificador.

FIFO Cuando se tiene que elegir a qu proceso asignar la CPU se escoge al que llevarams tiempo listo. El proceso se mantiene en la CPU hasta que se bloquea voluntariamente. La ventaja de este algoritmo es su fcil implementacin, sin embargo, no es vlidopara entornos interactivos ya que un proceso de mucho clculo de CPU haceaumentar el tiempo de espera de los dems procesos . Para implementar elalgoritmo (ver figura 2) slo se necesita mantener una cola con los procesos listosordenada por tiempo de llegada. Cuando un proceso pasa de bloqueado a listo sesita el ltimo de la cola.En a) el proceso P7 ocupa la CPU, los procesos P2, P4 y P8 se mantienen en lalista de preparados. En b) P7 se bloquea (ya sea al realizar una E/S, unaoperacin WAIT sobre un semforo a cero u otra causa) y P2 pasa a ocupar laCPU. En c) ocurre un evento (finalizacin de la operacin de E/S,operacin SIGNAL, ...) que desbloquea a P7, esto lo vuelve listo, pasando al finalde la cola de procesos listos.

Lista de procesos preparados en FIFO. SJF Al igual que en elalgoritmo FIFO las rfagas se ejecutan sin interrupcin, portanto, slo es til para entornos batch . Su caracterstica es que cuando se activa elplanificador, 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 minimizael tiempo de finalizacin promedio, como puede verse en el siguiente ejemplo:Ej: 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 quepertenece la rfaga R1 es la que lleva ms tiempo ejecutable, seguido del procesoal que pertenece R2 y del de R3. Veamos el tiempo medio de finalizacin (F) delas rfagas aplicando FIFO y SJF:

FIFO F = (24 + 27 + 30) / 3 = 27 ms. SJF F = (3 + 6 + 30) / 3 = 13 ms. Se puede demostrar que este algoritmo es el ptimo. Para ello, consideremos el caso de cuatro rfagas, con tiempos de ejecucin de a, b, c y d . La primera rfagatermina en el tiempo a a+b , etc. El tiempopromedio de finalizacin es (4a+3b+2c+d)/4. Es evidente que a contribuye ms alpromedio que los dems tiempos, por lo quedebe ser la rfaga ms corta, b lasiguiente, y as sucesivamente. El mismo razonamiento se aplica a un nmeroarbitrario de rfagas. RR Este es uno de los algoritmos ms antiguos, sencillos y equitativos en el reparto de la CPU entre los procesos, muy vlido para entornos de tiempo compartido.Cada proceso tiene asignado un intervalo de tiempo de ejecucin, llamado cuantum o cuanto . Si el proceso agota su cuantum de tiempo, se elige aotro proceso para ocupar la CPU. Si el proceso se bloquea o termina antes deagotar sucuantum 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, como se muestra en la figura 6.2. En esta figura en a) el proceso P7 ocupa la CPU. En b) P7 se bloquea pasando P2a ocupar la CPU. En c) P2 agota su cuantum con lo que pasa al final de la lista yP4 ocupa la CPU. La figura 4 representa un ejemplo ms largo de la ocupacin dela CPU utilizando el algoritmo round robin.

.Figura 7. Lista de procesos preparados por RR. Queves multi-level. Un algoritmo de planificacin mediante 'colas multinivel' divide la cola de procesos preparados en varias colas distintas. Los procesos se asignan permanentemente a una cola, generalmente en funcin de alguna propiedad del proceso, como por ejemplo el tamao memoria, la prioridad del proceso o el tipode proceso. Cada cola tiene su propio algoritmo de planificacin. Por ejemplo, pueden emplearse colas distintas para los procesos de primer plano y de segundo plano. La cola de primer plano puede planificarse mediante un algoritmo por