2.1 Concepto de Proceso. ..................................................................................................................... 3 2.2 Estados y Transiciones de los Procesos. .......................................................................................... 6 2.3 Procesos Ligeros (Hilos o Hebras). ................................................................................................... 9 2.4 Concurrencia y Secuenciabilidad. .................................................................................................... 12 2.4.1 Exclusin Mutua de Secciones Crticas. ............................................................................... 15 2.4.2 Sincronizacin de Procesos en S.C. ...................................................................................... 19 2.4.2.1 Mecanismo de Semforos. ...................................................................................... 23 2.4.2.2 Mecanismo de Monitores. ...................................................................................... 25 2.4.3 Interbloqueo (DeadLock). .................................................................................................... 30 2.4.3.1 Prevencin. .............................................................................................................. 32 2.4.3.2 Deteccin. ................................................................................................................ 33 2.4.3.3 Recuperacin. .......................................................................................................... 34 2.5 Niveles, Objetivos y Criterios de Planificacin................................................................................. 35 2.6 Tcnicas de Administracin del Planificador. .................................................................................. 40 2.6.1 FIFO. ..................................................................................................................................... 41 2.6.2 SJF. ....................................................................................................................................... 43 2.6.3 RR. ........................................................................................................................................ 45 2.6.4 Queves Multi-level. .............................................................................................................. 46 2.6.5 Multi-level Feedback Queves. ............................................................................................. 48
Introduccin.
Los sistemas operativos manejan muchsimos procesos, todos estos procesos se llevan a cabo con ayuda del procesador, En este trabajo se encuentra una informacin muy completa de la forma en que se realizan los procesos en el procesador, entre ellos se encuentra la forma de planificacin de los procesos, los tipos de interbloqueo y las tcnicas de administracin de procesos. En el desarrollo del trabajo presentamos las definiciones que cada tipo de planificacin utiliza, los objetivos que utilizan para ser la base de cada estructura de los procesos, presentamos algunas tcnicas de administracin en las que indicamos cual es la forma en que se deben de implementar para realizar operaciones con el procesador o para hacer funcionar mejor el procesador.
[2]
[3]
Imaginemos ahora que el hijo del computologo llega corriendo y llorando, diciendo que le pico una abeja. El computologo registra el punto en que estaba en la receta (guarda el estado del proceso actual), saca un libro de primeros auxilios, y comienza a seguir las instrucciones que contiene. Aqu vemos como el procesador se conmuta de un proceso (hornear) a un proceso de ms alta prioridad (administrar cuidados mdicos), cada uno con un programa diferente (receta vs primeros auxilios). Una vez que se ha atendido la picadura de abeja, el computologo regresa a su pastel, continuando en el punto donde haba interrumpido. la idea clave aqu es que un proceso es una actividad de algn tipo: tiene programa, entrada, salida y un estado. Se puede compartir un procesador entre varios procesos, usando algn algoritmo de planificacin para determinar cundo debe de trabajar en un proceso para atender a uno distinto. Informalmente, un proceso es un programa en ejecucin. La ejecucin de un proceso debe proceder de manera secuencial. Es decir, en cualquier instante, cuando ms una instruccin se estar ejecutando nombre del proceso. un proceso es ms que el cdigo del programa (tambin conocido como seccin de texto); tambien incluye la actividad actual, representada por el valor del contador de programa y el contenido de los registros del procesador. Generalmente, un proceso tambin incluye la pila (stack) del proceso, que contiene datos temporales (como los parmetros de subrutinas, direcciones de retorno y variables temporales), y una seccin de datos que contiene variables globales. Hacemos hincapi en que un programa por s solo no es un proceso; un programa es una entidad pasiva, como el contenido de un archivo guardado en disco, mientras que un proceso es una entidad activa, con el contador de programa especificando la siguiente instruccin que se ejecutara, y un conjunto de recursos asociados. Aunque podra haber dos procesos asociados al mismo programa, de todas maneras se consideran como dos secuencias de ejecucin distintas. Por ejemplo, varios usuarios podran estar ejecutando copias del programa editor. Cada una de estas es un proceso aparte, y aunque las secciones de texto sean equivalentes, las secciones de datos variaran. Tambin es comn tener un proceso que engendra muchos procesos durante su ejecucin. [4]
Jerarqua de procesos.
Los sistemas operativos que manejan el concepto de proceso deben contar con algn mecanismo para crear todos los procesos necesarios. En los sistemas muy sencillos, o en los diseados para ejecutar solo una aplicacin (por ejemplo, controlar un dispositivo en tiempo real), es posible que, cuando el sistema de inicia, todos los procesos que puedan necesitarse estn presentes. Sin embargo, en la mayor parte de los sistemas se necesita algn mecanismo para crear y destruir procesos segn sea necesario durante la operacin. En minix, los procesos se crean con la llamada del sistema fork (bifurcar), que crea una copia idntica del proceso invocador. El proceso hijo tambin puede ejecutar fork, as que es posible tener un rbol de procesos. En otros sistemas operativos existen llamadas al sistema para crear un proceso, cargar su memoria y ponerlo a ejecutar. Sea cual sea la naturaleza exacta de la llamada al sistema, los procesos necesitan poder crear otros procesos. Obsrvese que cada proceso tiene un padre, pero cero, uno, dos, o ms hijos. Como ejemplo sencillo del uso de los rboles de procesos, veamos la forma en que minix se inicializa a si mismo cuando se pone en marcha. Un proceso especial, llamado mit, est presente en la imagen de arranque. Cuando este proceso comienza a ejecutarse, lee un archivo que le indica cuantas terminales hay, y luego bifurca un proceso nuevo por terminal. Estos procesos esperan a que alguien inicie sesin. Si un inicio de sesin ( login ) tiene xito, el proceso de inicio de sesin ejecuta un shell para aceptar comandos . Estos comandos pueden iniciar ms procesos, y as sucesivamente. Por tanto, todos los procesos del sistema pertenecen a un mismo rbol, que tiene a mit en si raz. (El cdigo de mit no se alista en este libro, y tampoco el del shell. Haba que poner un lmite en algn lado).
[5]
Estos nombres son arbitrarios, y varan de un sistema operativo a otro; sin embargo, los estados que representan se encuentran en todos los sistemas. Ciertos sistemas operativos hacen distinciones todava ms sutiles entre estados de los procesos. Es importante tener presente que solo un proceso puede estar ejecutndose en cualquier procesador en un instante dado, pero muchos procesos pueden estar listos y esperando. Un proceso sale de un sistema en dos pasos. Primero, el proceso termina cuando liega al punto normal de terminacin, cuando se abandona debido a un error irrecuperable o cuando otro proceso con la debida autoridad hace que el proceso abandone, la terminacin pasa el proceso al estado terminado. En este punto, el proceso ya no se elige ms para la ejecucin. Sin embargo, las tablas y otra informacin asociada con el trabajo son conservadas temporalmente por el sistema operativo. Esto le da tiempo a otros programas auxiliares o de soporte para extraer la informacin necesaria. Por ejemplo, puede ser que un programa de contabilidad necesite registrar el tiempo de procesador y otros recursos usados por el proceso con fines de facturacin. Un programa de utilidades puede tener [6]
que extraer informacin sobre la historia del proceso con fines relativos a un anlisis de uso o de rendimiento. Una vez que estos programas han extrado la informacin necesaria, el sistema operativo ya no necesita mantener ms datos relativos al proceso y estos se borran del sistema. Nulo nuevo: se crea un nuevo proceso para ejecutar un programa.
Nuevo listo: el sistema operativo pasara a un proceso del estado nuevo al estado listo cuando est preparado para aceptar un proceso ms. La mayora de los sistemas ponen un lmite en funcin del nmero de procesos existentes o en la cantidad de memoria virtual dedicada a los procesos existentes. El motivo de este lmite es asegurar que no haya tantos procesos activos como para degradar el rendimiento.
Listo ejecucin: cuando es hora de seleccionar un nuevo proceso para ejecutar, el sistema operativo elige a uno de los procesos del estado listo. Ejecucin terminada: el proceso que se est ejecutando es finalizado por el sistema operativo si indica que termino 0 si se abandona. Ejecucin listo: la razn ms comn de esta transicin es que el proceso que est en ejecucin ha alcanzado el tiempo mximo permitido de ejecucin interrumpida; casi todos los sistemas operativos con multiprogramacin imponen este tipo de norma de tiempo. Hay otras causas alternativas para esta transicin que no estn implementadas en todos los sistemas operativos. Por ejemplo, si el sistema operativo asigna diferentes niveles de prioridad a los diferentes procesos. Supngase que un proceso a esta ejecutndose con un cierto nivel de prioridad y que el proceso b, con un nivel de prioridad mayor, est bloqueado. Si el sistema operativo se entera de que el suceso que b estaba esperando se ha producido, pasando as b ha estado listo, entonces puede interrumpir al proceso a y expandir a b. Por ltimo, otro caso es que un proceso ceda voluntariamente el control del procesador. Ejecucin bloqueada: un proceso se pone en el estado bloqueado sus e solicita algo por lo que debe esperar. Las solicitudes al sistema operativo suelen ser en forma de llamadas a [7]
servicios del sistema, es decir , llamadas desde el programa que esta ejecutndose a un procedimiento que forma parte del cdigo del sistema operativo. Bloqueado listo: un proceso que est en el estado bloqueado pasara al estado listo cuando se produzca el suceso que estaba esperando. Listo terminado: en algunos sistemas, un padre puede terminar con un proceso hijo en cualquier momento. Adems, si el padre termina, todos los hijos asociados con l pueden ser finalizados. Bloqueado terminado: se aplica el mismo comentario que en el caso anterior.
[8]
Servidor puede manejar muchas solicitudes de forma eficiente. Los hilos en el nivel de usuario que ejecute una llamada al sistema harn que toda la tarea espere hasta que la llamada regrese.
Los hilos operan en muchos sentidos, de la misma forma que los procesos. Los hilos pueden estar en uno de varios estados: listo, bloquead, en ejecucin o terminado. Al igual que los procesos, los hilos comparten la CPU, y solo hay un hilo activo (en ejecucin) en un instante dado. Un hilo dentro de un proceso se ejecuta secuencialmente, y cada hilo tiene su propia pila y contador de programa. los hilos pueden crear hilos hijos, y se pueden bloquear en espera a que termine la ejecucin de llamadas al sistema; si un hilo se bloquea, otro puede ejecutarse. Por otro lado, a diferencia de los procesos, los hilos no son independientes entre s. Dado que todos los hilos pueden acceder a todas las direcciones de la tarea, un hilo puede leer la pila de cualquier otro hilo o escribir sobre ella. Esta estructura no ofrece proteccin entre hilos. Los hilos ofrecen un mecanismo que permite a procesos secuenciales hacer llamadas al sistema bloqueadoras y al mismo tiempo lograr paralelismo. La popularidad de los hilos est creciendo por que tienen algunas de las caractersticas de los procesos pesados pero se pueden ejecutar con mayor eficiencia. Hay muchas aplicaciones en las que esta combinacin es til. Por ejemplo, algunas implementaciones del ncleo de Unix son mono tareas: solo una tarea puede estar ejecutando cdigo del ncleo en un momento dado con esto se evitan muchos problemas, como la sincronizacin del acceso a datos (poniendo cerraduras a las estructuras de datos mientras se estn modificando), porque solo permite a un proceso efectuar la modificacin. Mach, en cambio, es multicitado y permite al ncleo atender muchas solicitudes simultneamente.
[10]
En algunos sistemas del 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 esta consiente de la existencia de mltiples hilos por proceso, as que, cuando un hilo se bloquea, el sistema operativo escoge el que se ejecutara 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 necesita una llamada al kernel. Este hecho es un argumento convincente para realizar la administracin en el espacio de usuario y uno se bloquea.
[11]
Aplicaciones estructuradas: como aplicacin de los principios del diseo modular y la 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.
[12]
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 como puede la cooperacin para un determinado trabajo o el uso de informacin o recursos compartidos, por ejemplo: en un sistema de un procesador , la multiprogramacin es una condicin necesaria pero no suficiente para que exista concurrencia ya que los procesos pueden ejecutarse de forma totalmente independiente. Por otro lado en un sistema de varios procesos se puede presentar la concurrencia siempre y cuando las actividades necesiten actuar entre si ya sea para utilizar informacin en comn o para cualquier otra cosa.
BENEFICIOS DE LA CONCURRENCIA : Trata de evitar los tiempos muertos de la UCP. Comparte y optimiza el uso de recursos. Permite la modularidad en las diferentes etapas del proceso. Acelera los clculos. Da mayor comodidad.
DESVENTAJAS DE LA CONCURRENCIA: Inanicin e interrupcin de procesos Ocurrencia de bloqueos Que dos o ms procesos requieran el mismo recurso (no apropiativo).
Tipos de computadora en los que puede haber concurrencia: multiprogramacin con un CPU: el sistema operativo se encarga de repartir el CPU entre los procesos, intercalando su ejecucin para dar una apariencia de ejecucin simultnea. Multiprocesador: maquina formada por ms de un CPU que comparten memoria principal. Los procesos no solo intercalan su ejecucin sino tambin la superponer. [13]
Multicomputadora: es una mquina de memoria distribuida formada por una serie de computadoras, es posible la ejecucin simultanea de los proceso en los diferentes cups. La concurrencia ser aparente siempre que el nmero de procesos sea mayor que el de procesadores disponibles y ser real cuando haya un proceso por procesador (paralelismo).
[14]
[15]
En un sistema multiprocesador de memoria compartida, se usa la operacin indivisible test-and-set sobre una bandera, para esperar hasta que el otro procesador la despeje. La operacin test-and-set realiza ambas operaciones sin liberar el bus de memoria a otro procesador. As, cuando el cdigo deja la seccin crtica, se despeja la bandera. Esto se conoce como espera activa. Algunos sistemas tienen instrucciones multi-operacin indivisibles similares a las anteriormente descritas para manipular las listas enlazadas que se utilizan para las colas de eventos y otras estructuras de datos que los sistemas operativos usan comnmente. La mayora de los mtodos de exclusin mutua clsicos intentan reducir la latencia y espera activa mediante las colas y cambios de contexto. Algunos investigadores afirman que las pruebas indican que estos algoritmos especiales pierden ms tiempo del que ahorran. A pesar de todo lo dicho, muchas tcnicas de exclusin mutua tienen efectos colaterales. Por ejemplo, los semforos permiten interbloqueos (deadlocks) en los que un proceso obtiene un semforo, otro proceso obtiene el semforo y ambos se quedan a la espera de que el otro proceso libere el semforo. Otros efectos comunes incluyen la inanicin, en el cual un proceso esencial no se ejecuta durante el tiempo deseado, y la inversin de prioridades, en el que una tarea de prioridad elevada espera por otra tarea de menor prioridad, as como la latencia alta en la que la respuesta a las interrupciones no es inmediata. La mayor parte de la investigacin actual en este campo, pretende eliminar los efectos anteriormente descritos. Si bien no hay un esquema perfecto conocido, hay un interesante esquema no clsico de envo de mensajes entre fragmentos de cdigo que, aunque permite inversiones de prioridad y produce una mayor latencia, impide los interbloqueos. Algunos ejemplos de algoritmos clsicos de exclusin mutua son: El algoritmo de Dekker.
El algoritmo de Peterson.
[16]
Los puntos de entrada de un recurso indican la cantidad de procesos que pueden utilizar simultneamente al mismo. Si un recurso tiene slo un punto de entrada, se lo denomina recurso crtico o recurso no compartible. Regin crtica de un proceso es la fase o etapa en la vida de ese proceso concurrente en la cual accede a un recurso crtico para modificarlo o alterarlo. El uso adecuado de la concurrencia entre procesos exige la capacidad de definir secciones crticas y hacer cumplir la exclusin mutua. Cualquier servicio o capacidad que d soporte para la exclusin mutua debe cumplir con un protocolo de sincronizacin, que tiene los requisitos siguientes: Debe cumplirse la exclusin mutua: slo un proceso de entre todos los que poseen secciones crticas por el mismo recurso u objeto compartido, debe tener permiso para entrar en ella en un instante dado.
Un proceso que se interrumpe en una seccin no crtica debe hacerlo sin estorbar a los otros. Es decir que si se cuelga un proceso que est usando un recurso, los dems procesos que esperan deben poder acceder al recurso de todas formas (el S.O. mata al proceso que se colg y as libera al recurso).
No se puede demorar indefinidamente la entrada de un proceso a un cierto recurso; no debe permitirse el interbloqueo y la inanicin. Todos los procesos deben poder acceder al recurso que solicitan, sino se van a morir sin usarlo y no es justo.
Cuando ningn proceso est en su seccin crtica, cualquier proceso que solicite entrar en la suya debe poder hacerlo sin dilatacin. Es decir, si nadie est usando un cierto recurso, entonces se le otorga al primer proceso que lo solicite.
No se pueden hacer suposiciones sobre la velocidad relativa de los procesos o su nmero (cantidad de procesadores). Nunca se puede saber a priori si a un proceso le falta mucho o poco para terminar.
[17]
Un proceso permanece en su seccin crtica slo por un tiempo finito. Esto sirve para evitar que un proceso se quede con un recurso por mucho tiempo y para que un recurso no se quede trabado sin sentido.
[18]
Representar el estado de cada proceso para mantener el grafo de transicin de estados. Normalmente los estados se representan mediante colas de procesos. Planificar el siguiente proceso que entre en la CPU (scheduling). Se requiere informacin que permita aplicar los criterios de planificacin (prioridad, quantum, etc). Contabilizar el uso de recursos por el proceso (tiempo consumido de CPU, tiempo de ejecucin del proceso, tiempos mximos asignados, identificador de usuario). Parte de esta informacin puede ser til para la planificacin.
[19]
Gestionar el contexto de los procesos. Por cada proceso hay que almacenar el estado del procesador, de la pila y de los otros recursos (memoria y entrada/salida). En un cambio de contexto hay que guardar el contexto del proceso que abandona la ejecucin y restaurar el contexto del proceso planificado. Gestionar la memoria. Punteros a tablas de pginas y otra informacin de la que hablaremos en su momento. Soportar la entrada/salida. Peticiones pendientes, dispositivos asignados, tabla de canales, etc.
Esta informacin no tiene por qu estar concentrada en una estructura de datos nica para cada proceso. Cmo se almacene depender de la estructura del sistema operativo. Por ejemplo, en los sistemas por capas, la informacin de un proceso estar segmentada a travs de las capas. Sin embargo, conceptualmente podemos suponer una estructura, que denominaremos Bloque de Control del Proceso o PCB (Process Control Block), que almacena la informacin del proceso. Los PCBs se enlazan para formar listas encadenadas (Figura B), por lo que el PCB incluye uno o ms apuntadores. La disciplina de acceso a los PCBs puede ser diversa (FCFS, en base a la prioridad, etc.). As, la gestin de procesos en el sistema operativo se puede representar mediante un conjunto de colas de PCBs. Habr una cola para los procesos que estn en estado preparado para ejecucin, una cola para cada condicin de bloqueo, e incluso, para generalizar, se puede considerar una cola de procesos en ejecucin (por cada CPU).
[20]
De esta forma, podemos definir el sistema operativo como un modelo de procesos que se representa mediante un sistema de colas, segn se muestra a continuacin.
En programacin concurrente, se define como a la porcin de cdigo de un programa de computador el cual accede a un recurso compartido (estructura de datos dispositivo) que no debe de ser accedido por ms de un hilo en ejecucin (thread). La seccin crtica por lo general termina en un tiempo determinado y el hilo, proceso tarea solo tendr que esperar un perodo determinado de tiempo para entrar. Se necesita de un mecanismo de sincronizacin en la entrada y salida de la seccin crtica para asegurar la utilizacin exclusiva del recurso, por ejemplo un semforo. El acceso concurrente se controla teniendo cuidado de las variables que se modifican dentro y fuera de la seccin crtica. La seccin crtica se utiliza por lo general cuando un programa multihilo actualiza mltiples variables sin un hilo de ejecucin separado que lleve los cambios conflictivos a esos datos. Una situacin similar, la seccin crtica puede ser utilizada para asegurarse de que un recurso compartido, por ejemplo, una impresora, puede ser accedida por un solo proceso a la vez. La manera en cmo se implementan las secciones puede variar dependiendo de los diversos sistemas operativos. Slo un proceso puede estar en una seccin crtica a la vez. Propiedades del acceso exclusivo a secciones crticas: Como criterios de validez de un mecanismo de sincronizacin nos referiremos al cumplimiento de las siguientes condiciones enunciadas por Dijkstra para el acceso exclusivo a una seccin crtica. Exclusin mutua. No puede haber ms de un proceso simultneamente en la SC.
No interbloqueo. Ningn proceso fuera de la SC puede impedir que otro entre a la SC. [21]
No inanicin. Un proceso no puede esperar por tiempo indefinido para entrar a la SC. Independencia del hardware. No se pueden hacer suposiciones acerca del nmero de procesadores o de la velocidad relativa de los procesos.
[22]
Propiedades. (Segn William Stallings, 2002) Los semforos son un mecanismo relativamente sencillo pero poderoso de asegurar la exclusin mutua entre procesos concurrentes para acceder a un recurso compartido. En vez de que lo usuarios inventen sus propios protocolos de sincronizacin (tarea difcil y traicionera) los semforos son una herramienta proporcionada por el diseador de sistemas. Los usuarios solo necesitan contribuir a controlar el acceso a los recursos compartidos obedeciendo un protocolo estndar y sencillo. Disciplina de Servicio de los Semforos. (Segun William Stallings, 2002) La definicin de semforo con espera activa no impone la aplicacin de ninguna ordenacin a los procesos que esperan, existe, por tanto, una posibilidad de que un proceso [23]
pueda quedar bloqueado debido a la competencia con otros. Esta situacin, en la cual algunos procesos progresan hacia su terminacin pero uno o ms procesos permanecen bloqueados fuera del recurso, se denomina Aplazamiento Indefinido. Este fenmeno tambin es conocido como Bloqueo Activo, y los procesos afectados se dicen que son Postergados. Para evitar bloqueos activos algunas implementaciones de semforos obligan a aplicar una disciplina de servicio entre los procesos en espera. La eleccin de una disciplina de servicio es muy importante ya que una disciplina sesgada puede posibilitar que un grupo de procesos conspire contra otros y usurpe permanentemente el recurso. La postergacin de procesos puede evitarse aadiendo el siguiente requisito a la implementacin de semforo ..: Una peticin para entrar a la seccin critica debe ser concedida en tiempo finito. Dada la suposicin de que cada proceso tarda un tiempo finito en ejecutar la seccin critica, este requisito puede sastifacerse utilizando la disciplina FIFO (First Input First Output - Primero en entrar... Primero en Salir) para elegir entre los procesos en espera. Este mtodo garantiza la entrada a la seccin crtica en tiempo finito, como tambin es conocido como Implementacin Estricta de Semforos. Implementacin de Semforos con Colas. (Segun William Stallings, 2002) La implementacin de los semforos con espera activa tienen dos importantes desventajas .: el potencial aplazamiento indefinido y la baja eficiencia debido al consumo de ciclos de procesador por parte de procesos bloqueados. Aunque un proceso bloqueado no experimenta ningn proceso real, no obstante continua consumiendo recursos del sistema a causa de la espera activa. Tanto el bloqueo activo como la ineficaz espera activa pueden verse aliviados por la implementacin de semforos con cola. Un proceso suspendido no consume ciclos de procesador, de modo que este mtodo es potencialmente ms eficiente que el de la espera activa.
[24]
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 en un monitor. (Como comenta F. Vallejo, 2001) 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 [25]
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. Tipos de monitores. Antes se dijo que una llamada a la funcin cond_signal con una variable de condicin haca que un proceso que estaba esperando por esa condicin reanudara su ejecucin. Ntese que el thread que reanuda su ejecucin necesitar obtener nuevamente el lock del monitor. Cualquier solucin debe garantizar la exclusin mutua. Segn quin contina con la ejecucin, se diferencian dos tipos de monitores: Hoare y Mesa. Tipo Hoare.
En la definicin original de Hoare, el thread que ejecuta cond_signal le cede el monitor al thread que esperaba. El monitor toma entonces el lock y se lo entrega al thread durmiente, que reanuda la ejecucin. Ms tarde cuando el monitor quede libre nuevamente el thread que cedi el lock volver a ejecutar.
[26]
El thread que reanuda la ejecucin puede Si el proceso que ejecuta cond_signal no hacerlo inmediatamente sin fijarse si la termin con su ejecucin se necesitarn dos condicin se cumple, porque desde que se cambios de contexto para que vuelva a tomar ejecut cond_signal hasta que lleg su turno el lock del monitor. Al despertar a un thread de ejecutar ningn proceso puede cambiarla. que espera en una variable de condicin, se El thread despertado ya estaba esperando debe asegurar que reanude su ejecucin desde antes, por lo que podra suponerse que inmediatamente. De otra forma, algn otro es ms urgente ejecutarlo a seguir con el thread podra cambiar la condicin. Esto proceso despertante. implica que la planificacin debe ser muy fiable, y dificulta la implementacin.
Tipo mesa: Butler W. Lampson y David D. Redell en 1980 desarrollaron una definicin diferente de monitores para el lenguaje Mesa que lidia con las desventajas de los monitores de tipo Hoare y aade algunas caractersticas. En los monitores de Lampson y Redell el thread que ejecuta cond_signal sobre una variable de condicin contina con su ejecucin dentro del monitor. Si hay otro thread esperando en esa variable de condicin, se lo despierta y deja como listo. Podr intentar entrar el monitor cuando ste quede libre, aunque puede suceder que otro thread logre entrar antes. Este nuevo thread puede cambiar la condicin por la cual el primer thread estaba durmiendo. Cuando reanude la ejecucin el durmiente, [27]
debera verificar que la condicin efectivamente es la que necesita para seguir ejecutando. En el proceso que durmi, por lo tanto, es necesario cambiar la instruccin if por while, para que al despertar compruebe nuevamente la condicin, y de no ser cierta vuelva a llamar a cond_wait. Adems de las dos primitivas cond_wait(c) y cond_signal(c), los monitores de Lampson y Redell poseen la funcin cond_broadcast(c), que notifica a los threads que estn esperando en la variable de condicin c y los pone en estado listo. Al entrar al monitor, cada thread verificar la condicin por la que estaban detenidos, al igual que antes. Los monitores del tipo Mesa son menos propensos a errores, ya que un thread podra hacer una llamada incorrecta a cond_signal o a cond_broadcast sin afectar al thread en espera, que verificar la condicin y seguir durmiendo si no fuera la esperada. Tipos De Monitores. Monitor tipo monitor. Este monitor fue implementado en Pascal
Concurrente, lenguaje desarrollado por Per Brinch Hansen. Es el monitor ms simple de todos pues solo tiene tres estados y las funciones internas son muy sencillas. Una caracterstica distintiva de este monitor es que el proceso que reinicia a otros debe salir del monitor, es decir abandona el estado activo. Monitor tipo manager. Este monitor es muy similar al monitor tipo monitor, la diferencia esencial es que un proceso que es reiniciado debe abandonar el monitor, es decir no se le permite que entre al estado activo.
[28]
Monitor tipo mediador Este monitor fue propuesto por C.A.R. Hoare, tiene la caracterstica de compensar las desventajas de los monitores tipo monitor y tipo managEer. Un proceso que reinicia a otros puede permanecer dentro del monitor y un proceso reiniciado tambin puede permanecer dentro del monitor.
Monitor tipo gladiador. Este monitor propuesto por Cavers y Brown tiene la caracterstica fundamental de solo tener un punto de consistencia interno (un punto de consistencia interno ocurre cuando el proceso que est activo abandona este estado y sigue dentro del monitor).
[29]
Coffman (1971) demostr que deben cumplirse cuatro condiciones para que haya un bloqueo mutuo: Condicin de exclusin mutua. Cada recurso est asignado nicamente a un solo proceso o est disponible.
Condicin de retener y esperar. Los procesos que actualmente tienen recursos que les fueron otorgados previamente pueden solicitar nuevos recursos. Condicin de no expropiacin. No es posible quitarle por la fuerza a un proceso los recursos que le fueron otorgados previamente. El proceso que los tiene debe liberarlos explcitamente. Condicin de espera circular. Debe haber una cadena circular de dos o ms procesos, cada uno de los cuales est esperando un recurso retenido por el siguiente miembro de la cadena.
[30]
Deben estar presentes estas cuatro condiciones para que ocurra un bloqueo mutuo. Si una o ms de estas condiciones estn ausentes, no puede haber bloqueo mutuo. Prevencin La estrategia de prevencin del interbloqueo consiste, a grandes rasgos, en disear un sistema de manera que est excluida, a priori, la posibilidad de interbloqueo. Los mtodos para prevenir el interbloqueo son de dos tipos. Los mtodos indirectos consisten en impedir la aparicin de alguna de las tres condiciones necesarias, antes mencionadas (condiciones 1 a 3). Los mtodos directos consisten en evitar la aparicin del crculo vicioso de espera (condicin 4). Retencin y Espera. La condicin de retencin 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 simultneamente. Esta solucin 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 podra haber avanzado con slo algunos de los recursos.
[31]
[32]
Retroceder cada proceso interbloqueado hasta algn 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 solucin radica en que puede repetirse el interbloqueo original. 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 mnimo costo. Apropiarse de recursos sucesivamente hasta que deje de haber interbloqueo. Para los puntos 3 y 4, el criterio de seleccin podra ser uno de los siguientes, consistentes en escoger el proceso con: Algunas de estas cantidades son ms fciles de medir que otras. El tiempo restante estimado deja lugar a dudas, especialmente. Adems, aparte de las medidas de prioridad, no existe otra indicacin del coste para el usuario frente al coste para el sistema en conjunto.
[33]
El tiempo de procesamiento utilizado y el que le resta. El tipoy nmero de recursos que posee. El nmero de recursos que necesita para finalizar. El procedimiento de la segunda opcin consiste en ir expropiando recursos de algunos procesos de forma sucesiva hasta que se consiga salir del interbloqueo. La eleccin de los recursos que se expropian se basa en criterios similares a los expuestos en la reiniciacin de los procesos.
[34]
Cuando ms de un proceso es ejecutable, el Sistema Operativo debe decidir cul de ellos deber ejecutarse primero. Hay que tener una planificacin de los procesos que quieren ejecutarse en el sistema. La planificacin es una funcin primordial del Sistema Operativo. La mayora de los recursos, si no es que todos, se planifican antes de que se utilicen. La asignacin de procesadores fsicos a los procesos hace posible que estos realicen su trabajo, y tal asignacin es un problema complejo manejado por el Sistema Operativo.
Concepto de Planificacin.
La planificacin hace referencia a un conjunto de polticas y mecanismos incorporados al sistema operativo que gobiernan el orden en que se ejecutan los trabajos que deben ser cumplimentados por el sistema informtico.
[35]
Objetivo de la Planificacin.
El objetivo principal de la planificacin es optimizar el rendimiento del sistema y proporcionar un buen servicio a todos los procesos que se encuentren en l. En general, la planificacin trata de cubrir los siguientes objetivos: Justicia. La planificacin debe ser lo ms justa posible con todos los procesos, sin favorecer a unos y perjudicar a otros. Mxima capacidad de ejecucin. Debe dar un servicio eficiente para que todos los trabajos se realicen lo ms rpidamente posible. Esto se puede lograr disminuyendo el nmero de cambios de proceso. Mximo nmero de usuarios interactivos. En los sistemas de tiempo compartido se tratara de que puedan estar trabajando el mayor nmero de usuarios al mismo tiempo. Predecibilidad. La planificacin debe realizarse de tal forma que en todo momento pueda saberse como ser su ejecucin. Minimizacin de la sobrecarga. La computadora debe tener poca sobrecarga ya que esta afecta directamente al rendimiento final del sistema: a menor sobrecarga mayor velocidad de proceso. Equilibrio en el uso de recursos. Para obtener un mayor rendimiento en el uso de los recursos y que estos estn ocupados equitativamente el mayor tiempo posible. Seguridad de las prioridades. Si un proceso tiene mayor prioridad que otro, este debe ejecutarse ms rpidamente. Evitar la postergacin indefinida. Esto se logra aumentando la prioridad de un proceso mientras espere por un recurso. La prioridad llegara a ser tan alta que al proceso le ser asignado el recurso que pidi. [36]
Criterios de planificacin.
Para realizar los objetivos de la planificacin, un mecanismo de planificacin debe considerar lo siguiente:
La limitacin de un proceso a las operaciones de Entrada / Salida: Cuando un proceso consigue la CPU, ?la utiliza solo brevemente antes de generar una peticin de Entrada / Salida? La limitacin de un proceso a la CPU: Cuando un proceso obtiene la CPU, ?tiende a usarla hasta que expira su tiempo? Si un proceso es por lote (batch) o interactivo: los usuarios interactivos deben recibir inmediato servicio para garantizar buenos tiempos de respuesta. Qu urgencia tiene una respuesta rpida?: Por ejemplo, un proceso de tiempo real de un sistema de control que supervise una refinera de combustible requiere una respuesta rpida, ms rpida que la respuesta requerida por un proceso en lotes (batch) que deber entregarse al dia siguiente. La prioridad de un proceso: A mayor prioridad mejor tratamiento. Frecuentemente un proceso genera fallos (carencias) de pgina: Probablemente los procesos que generan pocos fallos de pgina hayan acumulado sus conjuntos de trabajo en el almacenamiento principal. Los procesos que experimentan gran cantidad de fallos de pgina an no han establecido sus conjuntos de trabajo.
[37]
Un criterio indica favorecer a los procesos que han establecido sus conjuntos de trabajo. Otro criterio indica favorecer a los procesos con una tasa alta de fallos de pgina ya que rpidamente generaran una peticin de Entrada / Salida. Frecuentemente un proceso ha sido apropiado por otro de ms alta prioridad, lo cual significa lo siguiente: A menudo los procesos apropiados deben recibir un tratamiento menos favorable.
Cada vez que el Sistema Operativo asume la sobrecarga para hacer ejecutar este proceso, el corto tiempo de ejecucin antes de la apropiacin no justifica la sobrecarga de hacer ejecutar al proceso en primer lugar. Cuanto tiempo de ejecucin real ha recibido el proceso?: Un criterio considera que debe ser favorecido un proceso que ha recibido muy poco tiempo de CPU. Cunto tiempo adicional va a necesitar el proceso para terminar?: Los tiempos promedio de espera pueden reducirse priorizando los procesos que requieren de un tiempo de ejecucin mnimo para su terminacin, pero pocas veces es posible conocer la cantidad de tiempo adicional que cada proceso necesita para terminar. En pocas pasadas de los sistemas de procesamiento por lotes, con una entrada planificacin era sencillo: solo haba que ejecutar el siguiente trabajo en la cinta. En los sistemas de multiusuario de tiempo compartido, que se combinaban con un fondo de trabajos procesados en lote, el algoritmo era ms complejo. En forma invariable, existan varios usuarios en espera de servicio y podan existir tambin otros trabajos para ser procesados en lote. Incluso en los sistemas puros de tiempo compartido existen con frecuencia los trabajos colaterales, como el sistema de correo electrnico, que a menudo se ejecuta todo el tiempo para enviar o recibir correo o noticias. Cuando ms de un proceso es ejecutable, el Sistema Operativo debe decidir cul de ellos deber ejecutarse primero. Hay que tener una planificacin de los procesos que quieren ejecutarse en el sistema. La planificacin es una funcin primordial del Sistema Operativo. La mayora de los recursos, si [38]
no es que todos, se planifican antes de que se utilicen. La asignacin de procesadores fsicos a los procesos hace posible que estos realicen su trabajo, y tal asignacin es un problema complejo manejado por el Sistema Operativo. En forma de imgenes de tarjetas en una cinta magntica.
[39]
[40]
2.6.1 FIFO.
FIFO: First In First Out Mecanismo de scheduling en el cual los procesos se ordenan en una fila, en la cual se ejecutan cada uno de los procesos hasta su finalizacion secuencialmente. Es tremendamente ineficiente. Cuando se tiene que elegir a qu proceso asignar la CPU se escoge al que llevara ms tiempo listo. El proceso se mantiene en la CPU hasta que se bloquea voluntariamente. Para implementar el algoritmo slo se necesita mantener una cola con los procesos listos ordenada por tiempo de llegada. Cuando un proceso pasa de bloqueado a listo se sita el ltimo de la cola. Algoritmo de planificacin de FIFO. Tal vez la disciplina ms 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 est 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 prctica, pero muy pobre en cuanto a su comportamiento. Las caractersticas principales de este algoritmo son las siguientes: No es apropiativa. [41]
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 est en funcin del nmero de procesos y la duracin promedio que tenga.
[42]
Usando la planificacin SJF, planificaramos estos procesos de acuerdo al siguiente diagrama de Gantt:
El tiempo de espera es de 3 milisegundos para el proceso P1, de 16 milisegundos para el proceso P2, de 9 milisegundos para el proceso P3 y de 0 milisegundos para el proceso P4. Por tanto, el tiempo medio de espera es de (3+16+9+0)/4 = 7 milisegundos. Por comparacin, si estuviramos usando el esquema de planificacin FCFS, el tiempo de espera seria de 10.25 milisegundos El algoritmo de planificacin SJF es probablemente ptimo, ya que proporciona el tiempo medio de espera mnimo para un conjunto de procesos. Al anteponer un proceso corto a uno largo disminuye el tiempo de espera del proceso corto en mayor medida de lo que incrementa el tiempo de espera del proceso largo. Por esto, el tiempo medio de espera disminuye. La dificultad del algoritmo SJF es conocer la duracin de la siguiente solicitud de CPU. En una planificacin a largo plazo en un sistema de procesamiento por lotes, podemos usar una duracin el
[43]
lmite del tiempo del proceso que el usuario especifique en el momento de enviar el trabajo. La planificacin SJF se usa frecuentemente como mecanismo de planificacin a largo plazo. Aunque el algoritmo SJF es optimo, no se puede implementar en el nivel de planificacin del CPU a corto plazo, ya que no hay forma de conocer la duracin de la siguiente rfaga de CPU. Un mtodo consiste en intentar aproximar la planificacin SJF: podemos no conocer la duracin de la siguiente rfaga de CPU, pero podemos predecir su valor, por el procedimiento de confiar en que la siguiente rfaga de CPU sea similar en duracin a las anteriores. De esta manera, calculando una aproximacin de la duracin de la siguiente rfaga de CPU, podemos tomar el proceso que tenga la rfaga de CPU predicha ms corta. La siguiente rfaga de CPU se predice como una media exponencial de las duraciones medias anteriores. Sea tn la duracin de la n-sima rfaga de CPU y sea n+1 el valor predicho rapa la siguiente rfaga de CPU. Entonces, para , 01, se define: n+1 = tn + (1 - )tn Esta frmula define un promedio exponencial. El valor de tn contiene la informacin ms reciente; n almacena el historial pasado. El parmetro controla el peso relativo del historial reciente y pasado de nuestra prediccin. Si =0, entonces n+1 = n, y el historial reciente no tiene ningn efecto; si =1, entonces n+1 = n y solo la rfaga de CPU mas reciente importa. Frecuentemente, =1/2, el historial reciente y pasado tienen el mismo peso. El valor inicial 0 puede definirse como una constante o como un promedio global para todo el sistema. La siguiente figura muestra el promedio exponencial como =1/2 y 0 = 10.
[44]
2.6.3 RR.
Cada proceso tiene asignado un intervalo de tiempo de ejecucin, llamado cuantum o cuanto. Si el proceso agota su cuantum de tiempo, se elige a otro proceso para ocupar la CPU. Si el proceso se bloquea o termina antes de agotar su cuantum 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.
[45]
edicin interactivo llega a la cola de procesos preparados mientras se est ejecutando un proceso por lotes, el proceso por lotes ser desalojado. Otra posibilidad consiste en repartir el tiempo entre las colas. En este caso, cada cola obtiene una cierta porcin del tiempo de CPU, con la que puede entonces planificar sus distintos procesos Por ejemplo, en el caso de la colas de procesos de primer plano y segundo plano, la cola de primer plano puede disponer del 80 por ciento del tiempo de CPU para planificar por turnos sus procesos, mientras que la cola de procesos de segundo plano recibe el 20 por ciento del tiempo de CPU para gestionar sus procesos mediante el mtodo FCFS.
[47]
los procesos ms cortos. Los procesos largos terminan yendo automticamente a la cola 2 y se sirven, siguiendo el orden FCFS, con los ciclos de CPU no utilizados por las colas 0 y 1. En general, un planificador mediante colas multinivel realimentadas se define mediante los parmetros siguientes: El nmero de colas. El algoritmo de planificacin de cada cola. El mtodo usado para determinar cundo pasar un proceso a una cola de prioridad ms alta. El mtodo usado para determinar cundo pasar un proceso a una cola de prioridad ms baja. El mtodo usado para determinar en qu cola se introducir un proceso cuando haya que darle servicio. La definicin del planificador mediante colas multinivel realimentadas le convierte en el algoritmo de planificacin de la CPU ms general. Puede configurarse este algoritmo para adaptarlo a cualquier sistema especfico que se quiera disear. Lamentablemente, tambin es el algoritmo ms complejo, puesto que definir el mejor planificador requiere disponer de algn mecanismo para seleccionar los valores de todos los parmetros.
[49]
Conclusin.
Con esto llegamos al final del desarrollo de investigacin de esta unidad, los conocimientos obtenidos nos estn ayudando a comprender ms a fondo la funcionabilidad del sistema operativo. Estamos comprendiendo tambin algunas funciones especficas de los procesos y la forma en que estas se presentan, en cada uno de los diferentes comportamientos de la mquina. Al igual hemos aprendido que gran parte de las funciones del sistema operativo se llevan a cabo a travs de las comunicaciones y estas comunicaciones a travs de procesos. La importancia jerarqua que los procesos le otorgan a las diferentes actividades y la forma en que esta las administra para que se lleven a cabo las tareas. Y con esto llegamos al final de la investigacin de esta unidad esperamos ampliar ms nuestro conocimientos en el transcurso de las siguientes unidades.
[50]
Bibliografa.
http://administraciondeprocesos-naranjo.blogspot.mx/2008/10/241-exclusin-mutua-de-seccionescrticas.html sistemasoperativos.angelfire.com/html/2.4.3.html sistemasoperativos.angelfire.com/html/2.4.3.html http://administraciondeprocesos-barrueta.blogspot.mx/2008/10/2432-deteccin-deinterbloqueos.html http://administraciondeprocesos-barrueta.blogspot.mx/2008/10/2433-recuperacin-deinterbloqueo.html Sistemas Operativo, 2 Ed, Prentice Hall, Madrid, 1997. Sistemas operativos, diseo e implementacin 2da edicin - Andrew S. Tanenbaum & Albert S. Wood Hull. Sistemas operativos - 5ta edicin - Abraham Silbers chatz & Peter Baer Galvin.
[51]