III.

ADMINISTRACION DE PROCESOS: INTRODUCCION

3.1. PROCESO: Para definir lo que es un proceso, hay que establecer la diferencia con el concepto de programa: - Un programa es una entidad pasiva compuesta nicamente por cdigo y unos datos, es decir, tiene un listado fijo y est almacenado en archivos. - Un proceso es una entidad activa, es el programa en ejecucin. 3.2. ESTADOS DE UN PROCESO: 3.2.1. Modelo de dos estados: El modelo ms sencillo que puede construirse tiene en cuenta que un momento dado un proceso puede estar ejecutndose en el procesador o no. Asi pues, un proceso puede estar en uno de dos estados: Ejecucin o No ejecucin.

Cuando el SO crea un nuevo proceso, este entra en el sistema en el estado de No Ejecucin. De este modo, el proceso existe, es conocido por el SO y est esperando la oportunidad de ejecutarse. En un momento dado, el sistema operativo decide otorgar el procesador a un proceso determinado con lo que dicho proceso pasar de estado No ejecucin a Ejecucin. Cada cierto tiempo, el proceso en ejecucin es interrumpido y el sistema operativo seleccionara un nuevo proceso para que tome el control del procesador. El proceso interrumpido pasa del estado de Ejecucin al de No ejecucin mientras que el proceso elegido realiza la transicin inversa. Incluso en este modelo tan simple, se aprecian ya algunos de los elementos importantes en el diseo de SSOO. Cada proceso debe representarse de forma que el sistema operativo tenga conocimiento de su estado actual y de su posicin en memoria. Aquellos procesos que no estn en estado de ejecucin debern almacenarse en algn tipo de estructura de datos mientras esperan que el sistema operativo les otorgue el Control sobre el procesador. 3.2.2. Modelo de 5 estados En este modelo un proceso puede encontrarse en cualquiera de los siguientes 5 estados.

Sistemas Operativos - CAP II

-18-

Ing. Grover Q.Y.

1. Estado Nuevo: este estado corresponder a procesos que acaban de ser definidos pero que an no han sido admitidos por el sistema operativo como procesos ejecutables. Para estos procesos se habrn realizado ciertas tareas de gestin interna como la asignacin de un identificador y la creacin de algunas estructuras de control. La principal motivacin para la existencia de este estado es la limitacin por parte del SO del nmero total de procesos activos por razones de rendimiento1 o por las Restricciones impuestas por la capacidad de la memoria. 2. Estado Listo o Preparado: En este estado se encontrarn aquellos procesos que dispongan de todos los recursos necesarios para comenzar o proseguir su ejecucin y se encuentran a la espera de que se les conceda el control del procesador. 3. Estado de Ejecucin: En este estado se encuentra el proceso que tiene el control del procesador. Dado que se considerarn arquitecturas que disponen de un nico procesador, en un instante determinado slo un proceso puede encontrarse en este estado. 4. Estado Espera o Bloqueado: En este estado se encuentran aquellos procesos que carecen de algn recurso necesario para su ejecucin siendo este recurso distinto del procesador o bien se encuentran a la espera de que tenga lugar un determinado evento. 5. Estado Terminado: A este estado pertenecen aquellos procesos excluidos por el SO del grupo de procesos ejecutables. Un proceso alcanza este estado cuando llega al punto normal de terminacin, cuando se abandona debido a un error irrecuperable o cuando un proceso con la debida autoridad hace que termine su ejecucin. En este punto, el proceso ya no es susceptible de ser elegido para ejecutarse. Sin embargo, el SO conserva cierta informacin asociada con l para su posible utilizacin, bien por otras aplicaciones como programas de utilidad para el anlisis de la historia y rendimiento del proceso o bien por

Sistemas Operativos - CAP II

-19-

Ing. Grover Q.Y.

parte del SO con fines estadsticos. Una vez extrada esta informacin, el SO ya no necesita mantener ms datos relativos al proceso y estos se borran del sistema. 3.3. Bloque de control de proceso (PCB) PCB = Process Control Block Definicin: Es una estructura de datos que permite al sistema operativo controlar diferentes aspectos de la ejecucin de un proceso. Estructura tpica del PCB de un proceso: El PCB se organiza en un conjunto de campos en los que se almacena informacin de diversos tipos. Los campos tpicamente mantenidos en el PCB de un proceso se muestran en la figura siguiente:

Informacin tpica mantenida en el PCB: Puede clasificarse en cuatro categoras: a) Informacin de identificacin: Esta informacin est integrada bsicamente por el identificador del proceso (PID), que es un nmero que identifica al proceso. Este nmero es diferente para todos los procesos que se encuentran en ejecucin. b) Informacin de estado de la CPU: Se trata de un conjunto de campos que almacenan el estado de los registros de la CPU cuando el proceso es suspendido. c) Informacin de control del proceso: Se trata de un conjunto de informacin que es utilizada por el sistema operativo para controlar diversos aspectos de funcionamiento del proceso. Pertenecen a esta categora de informacin los siguientes campos: - Estado del proceso: Listo, en ejecucin, etc.
Sistemas Operativos - CAP II -20Ing. Grover Q.Y.

Informacin de manejo de memoria: Como por ejemplo, la direccin fsica de memoria en la que se ubica la tabla de pginas del proceso. Informacin de E/S: Lista de ficheros abiertos, ventanas utilizadas, etc.

d) Informacin de uso de recursos: Se trata de un conjunto de informacin relativa a la utilizacin realizada por el proceso de los recursos del sistema, como por ejemplo, el porcentaje de utilizacin de la CPU, la cantidad de memoria usada o los bytes de E/S escritos y ledos por el proceso. 3.4. Operaciones sobre un proceso: Los S.O. con multitarea permiten numerosas operaciones dedicadas a la gestin de procesos. Entre ellas, las ms importantes: creacin, eliminacin, obtencin de informacin, modificacin, retardo y activacin. - Creacin de procesos: crear (id_proceso, atributos) El S.O. primero comprobar que no existen errores en la llamada (por ejemplo, comprueba que el procedimiento indicado no exista). A continuacin se crea el proceso, se pasan los atributos como parmetros, se reserva memoria para el proceso (tanto para el BCP como para el cdigo y los datos) y se aade a la cola de preparado. - Eliminacin de procesos: eliminar (id_proceso) ; Para eliminar un proceso es necesario que este sea hijo del proceso eliminador, ya que de no ser as podra volverse inconsistente el sistema. Una vez realizada la llamada, el S.O. verifica que no existen errores para a continuacin liberar los recursos retenidos por el proceso. Finalmente se destruye el BCP. - Obtencin de informacin: inf_proc (id_proceso,est_BCP) ; Devolver una copia del BCP del proceso requerido. El S.O. debe comprobar que no existen errores en los parmetros. - Modificacin de la informacin de un proceso : mod _inf (id_proceso, est_BCP) ; El proceso modificador debe enviar como parmetros el PID del proceso que modifica y un nuevo BCP que sustituya al actual. El S.O. comprobar los posibles errores producidos. - Retardar un proceso: retardar (tiempo): El proceso que realiza esta llamada se auto detiene durante el tiempo indicado y pierde el control de la CPU durante ese tiempo. Los ciclos de reloj de espera se anotan en el BCP (utilizados posteriormente en la planificacin de procesos). Finalmente, cuando el

Sistemas Operativos - CAP II

-21-

Ing. Grover Q.Y.

tiempo transcurre, el ncleo del S.O. introduce al proceso en la cola de procesos preparados para intentar ejecutarlo inmediatamente. - Activar procesos retardados: activar (id proceso): Esta funcin es privilegiada. El mecanismo para despertar procesos se activa en cada ciclo de reloj, recorrindose la cola de procesos retardados para activarlos o disminuir en una unidad el nmero de pulsos de espera. Devuelve un cdigo de error si el PID que se pasa no existe. OO 3.5. HILOS: La mayora de los sistemas operativos proporcionan caractersticas que permiten que un proceso tenga mltiples hilos de control. Un hilo es una unidad bsica de utilizacin de CPU, la cual contiene un id de hilo, su propio program counter, un conjunto de registros, y una pila; que se representa a nivel del sistema operativo con una estructura llamada TCB (thread control block). Los hilos comparten con otros hilos que pertenecen al mismo proceso la seccin de cdigo, la seccin de datos, entre otras cosas. Si un proceso tiene mltiples hilos, puede realizar ms de una tarea a la vez (esto es real cuando se posee ms de un CPU).

Veamos un ejemplo para clarificar el concepto: Un servidor web acepta solicitudes de los clientes que piden pginas web. Si este servidor tiene varios clientes y funcionara con un solo hilo de ejecucin, solo podra dar servicio a un cliente por vez, y el tiempo que podra esperar un cliente para ser atendido podra ser muy grande. Una posible solucin sera que el servidor funcione de tal manera que acepte una solicitud por vez, y que cuando reciba otra solicitud, cree otro proceso para dar servicio a la nueva solicitud. Pero crear un proceso lleva tiempo y utiliza muchos recursos, entonces, si cada proceso realizar las mismas tareas Por qu no utilizar hilos? Generalmente es ms eficiente usar un proceso que utilice mltiples hilos (un hilo para escuchar las solicitudes, y cuando llega una solicitud, el lugar de crear otro proceso, se crea otro hilo para procesar la solicitud). 3.5.1. Ventajas de usar hilos:

Sistemas Operativos - CAP II

-22-

Ing. Grover Q.Y.

Respuesta: el tiempo de respuesta mejora, ya que el programa puede continuar ejecutndose, aunque parte de l est bloqueado. Compartir recursos: los hilos comparten la memoria y los recursos del proceso al que pertenecen, por lo que se puede tener varios hilos de ejecucin dentro del mismo espacio de direcciones. Economa: Es ms fcil la creacin, cambio de contexto y gestin de hilos que de procesos. Utilizacin mltiples CPUs: permite que hilos de un mismo proceso ejecuten en diferentes CPUs a la vez. En un proceso mono-hilo, un proceso ejecuta en una nica CPU, independientemente de cuantas tenga disponibles.

3.5.2. Hilos a nivel de usuario y de kernel Hasta ahora hemos hablado de los hilos en sentido genrico, pero a nivel prctico los hilos pueden ser implementados a nivel de usuario o a nivel de kernel. Hilos a nivel e usuario: son implementados en alguna librera. Estos hilos se gestionan sin soporte del SO, el cual solo reconoce un hilo de ejecucin. Hilos a nivel de kernel: el SO es quien crea, planifica y gestiona los hilos. Se reconocen tantos hilos como se hayan creado. Los hilos a nivel de usuario tienen como beneficio que su cambio de contexto es ms sencillo que el cambio de contexto entre hilos de kernel. A dems, se pueden implementar an si el SO no utiliza hilos a nivel de kernel. Otro de los beneficios consiste en poder planificar diferente a la estrategia del SO. Los hilos a nivel de kernel tienen como gran beneficio poder aprovechar mejor las arquitecturas multiprocesadores, y que proporcionan un mejor tiempo de respuesta, ya que si un hilo se bloquea, los otros pueden seguir ejecutando.

3.6. COMUNICACIN ENTRE PROCESOS 3.6.1. CONCEPTOS BSICOS: Los distintos procesos, dentro de un computador, no actan, evidentemente, de forma aislada. Por un lado deben cooperar con el fin de alcanzar el objetivo de poder ejecutar las tareas de los usuarios. Por otro lado, compiten por el uso de unos recursos, limitados como los procesadores, la memoria o los ficheros. Las dos actividades de cooperacin y competicin llevan asociada la necesidad de algn tipo de comunicacin y sincronizacin entre los procesos. Los procesos que ejecutan de forma concurrente en un sistema se pueden clasificar como procesos independientes o cooperantes. Un proceso independiente es aquel que ejecuta sin requerir la ayuda o cooperacin de otros procesos. Un claro ejemplo de procesos independientes son los diferentes intrpretes de mandatos que se ejecutan de forma simultnea en un sistema. Los procesos son cooperantes cuando estn diseados para
Sistemas Operativos - CAP II -23Ing. Grover Q.Y.

trabajar conjuntamente en alguna actividad, para lo que deben ser capaces de comunicarse e interactuar entre ellos. Tanto si los procesos son independientes como cooperantes, pueden producirse una serie de interacciones entre ellos. Estas interacciones pueden ser de dos tipos: Interacciones motivadas porque los procesos comparten o compiten por el acceso a recursos fsicos o lgicos. Esta situacin aparece en los distintos tipos de procesos anteriormente comentados. Por ejemplo, dos procesos totalmente independientes pueden competir por el acceso a disco. En este caso, el sistema operativo deber encargarse de que los dos procesos accedan ordenadamente sin que se cree ningn conflicto. Esta situacin tambin aparece cuando varios procesos desean modificar el contenido de un registro de una base de datos. Aqu es el gestor de la base de datos el que se tendr que encargar de ordenar los distintos accesos al registro. Interaccin motivada porque los procesos se comunican y sincronizan entre s para alcanzar un objetivo comn. Por ejemplo, un compilador se puede construir mediante dos procesos: el compilador propiamente dicho, que se encarga de generar cdigo ensamblador, y el proceso ensamblador, que obtiene cdigo en lenguaje mquina a partir del ensamblador. En este ejemplo puede apreciarse la necesidad de comunicar y sincronizar a los dos procesos. Estos dos tipos de interacciones obligan al sistema operativo a incluir mecanismo y servicios que permitan la comunicacin y la sincronizacin entre procesos. Exclusin mutua.- Los recursos de un sistema pueden clasificarse como compartibles, lo que significa que pueden ser empleados por varios procesos de forma concurrente, o nocompartibles, lo que equivale a que su uso se restrinja a un solo proceso a la vez. El problema de la exclusin mutua es el de asegurar que los recursos no compartibles sean accedidos por un solo proceso a la vez. Aquella parte del programa en la cual se accede al recurso compartido se denomina seccin crtica. Hay que evitar que dos procesos entren simultneamente en su seccin crtica. Cuando varios procesos compiten por recursos es posible que se d una situacin en la que ninguno de ellos pueda proseguir debido a que los recursos que cada uno de ellos necesita estn ocupados por los otros, esta situacin se conoce con el nombre de interbloqueo o deadlock. Los algoritmos de exclusin mutua (comnmente abreviada como mutex por mutual exclusion) se usan en programacin concurrente para evitar el uso simultneo de recursos comunes, como variables globales, por fragmentos de cdigo conocidos como secciones crticas. Condiciones de competencia.- En algunos sistemas operativos, los procesos que estn colaborando podran compartir cierto almacenamiento comn en el que ambos pueden leer y escribir. El almacenamiento compartido puede estar en la memoria principal o puede ser un archivo compartido; la ubicacin de la memoria compartida no altera la naturaleza

Sistemas Operativos - CAP II

-24-

Ing. Grover Q.Y.

de la comunicacin ni los problemas que surgen. Para ver cmo funciona la comunicacin entre procesos en la prctica, consideremos un ejemplo sencillo pero comn, un spooler de Impresin. Cuando un proceso desea imprimir un archivo, introduce el nombre del archivo en un directorio de spooler especial. Otro proceso, el demonio de impresin, revisa peridicamente el directorio para ver si hay archivos por imprimir, y si los hay los imprime y luego borra sus nombres del directorio. A continuacin se indican los mecanismos bsicos de comunicacin: Memoria compartida.- Se basa en que los procesos que desean comunicarse compartan una misma regin de memoria fsica. Para llevar a cabo la comunicacin, uno escribe y otro lee de la regin de memoria compartida. Los procesos utilizan servicios del sistema operativo para compartir la regin. Paso de mensajes.- Los procesos utilizan una pareja de servicios del sistema operativo para Comunicarse. Estos servicios son conocidos habitualmente como Send y Receive. Para llevar a cabo la comunicacin un proceso ejecuta la funcin Send y el otro Receive, intercambiando de esta forma un bloque de informacin que recibe el nombre de mensaje. La interaccin entre procesos se plantea en una serie de situaciones clsicas de comunicacin y sincronizacin. Estas situaciones, junto con sus problemas, se describen a continuacin para demostrar la necesidad de comunicar y sincronizar procesos. 3.6.2. Problema de la SECCIN CRTICA: ste es uno de los problemas que con mayor frecuencia aparece cuando se ejecutan procesos concurrentes tanto si son cooperantes como independientes. Considrese un sistema compuesto por n procesos {P1, P2, ..., PN} en el que cada uno tiene un fragmento de cdigo, que se denomina seccin crtica. Dentro de la seccin crtica, los procesos pueden estar accediendo y modificando variables comunes, registros de una base de datos, un archivo, en general cualquier recurso compartido. La caracterstica ms importante de este sistema es que cuando un proceso se encuentra ejecutando cdigo de la seccin crtica, ningn otro proceso puede ejecutar en su seccin. Para resolver el problema de la seccin crtica es necesario utilizar algn mecanismo de sincronizacin que permita a los procesos cooperar entre ellos sin problemas. Este mecanismo debe proteger el cdigo de la seccin crtica y su funcionamiento bsico es el siguiente: Cada proceso debe solicitar permiso para entrar en la seccin crtica mediante algn fragmento de cdigo, que se denomina de forma genrica entrada en la seccin crtica. Cuando un proceso sale de la seccin crtica debe indicarlo mediante otro fragmento de cdigo, que se denomina salida de la seccin crtica. Este fragmento permitir que otros procesos entren a ejecutar el cdigo de la seccin crtica. La estructura general, por tanto, de cualquier mecanismo que pretenda resolver el problema de la seccin crtica es la siguiente:
Sistemas Operativos - CAP II -25Ing. Grover Q.Y.

Entrada en la seccin crtica Cdigo de la seccin crtica Salida de la seccin crtica Cualquier solucin que se utilice para resolver este problema debe cumplir los tres requisitos siguientes: Exclusin mutua: si un proceso est ejecutando cdigo de la seccin crtica, ningn otro proceso lo podr hacer. Progreso: si ningn proceso est ejecutando dentro de la seccin crtica, la decisin de qu proceso entra en la seccin se har sobre los procesos que desean entrar. Los procesos que no quieren entrar no pueden formar parte de esta decisin. Adems, esta decisin debe realizarse en tiempo finito. Espera acotada: debe haber un lmite en el nmero de veces que se permite que los dems procesos entren a ejecutar cdigo de la seccin crtica despus de que un proceso haya efectuado una solicitud de entrada y antes de que se conceda la suya. 3.6.3. Problema del PRODUCTOR-CONSUMIDOR: El problema del productor-consumidor es uno de los problemas ms habituales que surge cuando se programan aplicaciones utilizando procesos concurrentes. En este tipo de problemas, uno o ms procesos, que se denominan productores, generan cierto tipo de datos que son utilizados o consumidos por otros procesos, que se denominan consumidores. Un claro ejemplo de este tipo de problemas es el del compilador que se describi anteriormente. En este ejemplo el compilador hace las funciones de productor al generar el cdigo ensamblador que consumir el proceso ensamblador para generar el cdigo mquina. En la Figura se representa la estructura clsica de este tipo de procesos.

Proceso Productor
Flujo de datos

Proceso Consumidor

Mecanismo de comunicacin
Estructura clsica de procesos productor - consumidor.

En esta clase de problemas es necesario disponer de algn mecanismo de comunicacin que permita a los procesos productor y consumidor intercambiar informacin. Ambos procesos, adems, deben sincronizar su acceso al mecanismo de comunicacin para que la interaccin entre ellos no sea problemtica:
Sistemas Operativos - CAP II -26Ing. Grover Q.Y.

Cuando el mecanismo de comunicacin se llene, el proceso productor se deber quedar bloqueado hasta que haya hueco para seguir insertando elementos. A su vez, el proceso consumidor deber quedarse bloqueado cuando el mecanismo de comunicacin este vaco, ya que en este caso no podr continuar su ejecucin al no disponer de informacin a consumir. Por tanto, este tipo de problema requiere servicios para que los procesos puedan comunicarse y servicios para que se sincronicen a la hora de acceder al mecanismo de comunicacin; ms adelante se ilustrara algunas soluciones utilizando mecanismos de comunicacin. 3.6.4. El problema de los LECTORES-ESCRITORES: En este problema existe un determinado objeto, que puede ser un archivo, un registro dentro de un archivo, etc., que va a ser utilizado y compartido por una serie de procesos concurrentes.

Lector

Lector

Escritor

Lector

Escritor

Recurso
Algunos de estos procesos slo van a acceder al objeto sin modificarlo, mientras que otros van a acceder al objeto para modificar su contenido. Esta actualizacin implica leerlo, modificar su contenido y escribirlo. A los primeros procesos se les denomina lectores y a los segundos se les denomina escritores. En este tipo de problemas existe una serie de restricciones que han de seguirse: Slo se permite que un escritor tenga acceso al objeto al mismo tiempo. Mientras el escritor est accediendo al objeto, ningn otro proceso lector ni escritor podr acceder a l. Se permite, sin embargo, que mltiples lectores tengan acceso al objeto, ya que ellos nunca van a modificar el contenido del mismo. En este tipo de problemas es necesario disponer de servicios de sincronizacin que permitan a los procesos lectores y escritores sincronizarse adecuadamente en el acceso al objeto. Imaginemos, por ejemplo, un sistema de reservaciones de una lnea area, con muchos procesos competidores que desean leerlo y escribir en l. Es aceptable tener mltiples procesos leyendo la base de datos al mismo tiempo, pero si un proceso est actualizando

Sistemas Operativos - CAP II

-27-

Ing. Grover Q.Y.

(escribiendo en) la base de datos, ningn otro podr tener acceso a ella, ni siquiera los lectores. Supongamos que mientras un lector est usando la base de datos, llega otro lector. Puesto que tener dos lectores al mismo tiempo no est prohibido, se admite al segundo lector. Tambin pueden admitirse un tercer lector y lectores subsecuentes si llegan. Supongamos ahora que llega un escritor. El escritor no puede ser admitido en la base de datos, pues requiere acceso exclusivo, de modo que el escritor queda suspendido. Ms adelante, llegan lectores adicionales. En tanto haya al menos un lector activo, se admitirn lectores subsecuentes. A consecuencia de esta estrategia, en tanto haya un suministro constante de lectores, entrarn tan pronto como lleguen. El escritor se mantendr suspendido hasta que no haya ningn lector presente. Si llega un lector, digamos, cada 2 segundos, y cada lector tarda 5 segundos en efectuar su trabajo, el escritor nunca entrar. Para evitar esta situacin, el programa podra incluir una pequea modificacin: cuando llega un lector y un escritor est esperando, el lector queda suspendido detrs del escritor en lugar de ser admitido inmediatamente. As, un escritor tiene que esperar hasta que terminan los lectores que estaban activos cuando lleg, pero no a que terminen los lectores que llegaron despus de l. La desventaja de esta solucin es que logra menor concurrencia y por tanto un menor rendimiento.

3.6.5. SEMFOROS Dijkstra dio en 1968 una solucin al problema de la exclusin mutua con la introduccin del concepto de semforo binario. Est tcnica permite resolver la mayora de los problemas de sincronizacin entre procesos y forma parte del diseo de muchos sistemas operativos y de lenguajes de programacin concurrentes. Un semforo binario es un indicador (S) de condicin que registra si un recurso est disponible o no. Un semforo binario slo puede tomar dos valores: 0 y 1. Si, para un semforo binario, S = 1 entonces 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 con una cola de tareas o de condicin a la cual se aaden los procesos que estn en espera del recurso. Slo se permiten tres operaciones sobre un semforo Inicializar Espera (wait) Seal (signal) En algunos textos, se utilizan las notaciones P y V para las operaciones de espera y seal respectivamente, ya que sta fue la notacin empleada originalmente por Dijkstra para referirse a las operaciones. As pues, un semforo binario se puede definir como un tipo de datos especial que slo puede tomar los valores 0 y 1, con una cola de tareas asociada y con slo tres operaciones para actuar sobre l. Las operaciones pueden describirse como sigue:
inicializa (S: SemaforoBinario; v: integer) Sistemas Operativos - CAP II -28Ing. Grover Q.Y.

Poner el valor del semforo S al valor de v (0 o 1) espera (S) if S = 1 then S := 0 else suspender la tarea que hace la llamada y ponerla en la cola de tareas seal (S) if la cola de tareas est vaca then S := 1 else reanudar la primera tarea de la cola de tareas

Las operaciones son procedimientos que se implementan como acciones indivisibles y por ello la comprobacin y cambio de valor del indicador se efecta de manera real como una sola operacin, lo cual hay que tener presente a la hora de disear el planificador de tareas. En sistemas con un nico procesador bastar simplemente con inhibir las interrupciones durante la ejecucin de las operaciones del semforo. En los sistemas multiprocesador, sin embargo, este mtodo no resulta ya que las instrucciones de los procesadores se pueden entrelazar de cualquier forma. La solucin est en utilizar instrucciones hardware especiales, si se dispone de ellas, o en introducir soluciones software como las vistas anteriormente, que ya indicamos, que servan tanto para sistemas uniprocesador como para sistemas multiprocesador. La operacin inicializa se debe llevar a cabo antes de que comience la ejecucin concurrente de los procesos ya que su funcin exclusiva es dar un valor inicial al semforo. Un proceso que corre la operacin espera y encuentra el semforo a 1, lo pone a 0 y prosigue su ejecucin. Si el semforo est a 0 el proceso queda en estado de espera hasta que el semforo se libera. Dicho estado se debe considerar como uno ms de los posibles de un proceso. Esto es as debido a que un proceso en espera de un semforo no est en ejecucin ni listo para pasar a dicho estado puesto que no tiene la CPU ni puede pasar a tenerla mientras que no se lo indique el semforo. Tampoco es vlido el estado suspendido, ya que este estado est pensado para que lo utilicen llamadas al sistema operativo para suspender o reactivar un proceso que no tiene por qu tener una conexin con los semforos. El diagrama de transicin de estados de la figura se puede ampliar con un nuevo estado que denominamos de espera.

Figura 1. Transiciones para el estado de espera

Sistemas Operativos - CAP II -29Ing. Grover Q.Y.

Cuando se ejecuta la operacin seal puede haber varios procesos en la lista o cola, el proceso que la dejar para pasar al estado listo depender del esquema de gestin de la cola de tareas suspendidas que se haya implementado en el diseo del semforo, por ejemplo: prioridades, FIFO, etc. Si no hay ningn proceso en espera del semforo este se deja libre (S := 1) para el primero que lo requiera. 3.6.6. EXCLUSION MUTUA CON SEMFOROS: La exclusin mutua se realiza fcilmente utilizando 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 utilizarn tantos semforos como clases de secciones crticas se establezcan. El proceso P1 de la seccin anterior ahora toma la forma:
process P1 begin loop espera (S) ; Seccin Crtica seal (S) ; Suspendido Durmiente Listo Espera Ejecucin Espera Seal (* resto del proceso *) end end P1;

Implementacin del semforo binario

package Semaforo; public class SemaforoBinario { protected int contador = 0; public SemaforoBinario (int valorInicial) { contador = valorInicial; } synchronized public void WAIT () { while (contador == 0) try { wait(); } catch (Exception e) {} contador--; } synchronized public void SIGNAL () { contador = 1; notify(); /* aqu con despertar a uno es suficiente, pues todos esperan por la misma condicin */ Sistemas Operativos - CAP II -30Ing. Grover Q.Y.

} }

Implementacin del semforo general

package Semaforo; public class SemaforoGeneral extends SemaforoBinario { public SemaforoGeneral (int valorInicial) { super (valorInicial); } synchronized public void SIGNAL () { contador++; notify(); } }

3.6.7. SINCRONIZACIN CON SEMAFOROS El uso de semforos hace que se pueda programar fcilmente la sincronizacin entre dos tareas. En este caso las operaciones espera y seal no se utilizan dentro de un mismo proceso sino que se dan en dos procesos separados; el que ejecuta la operacin de espera queda bloqueado hasta que el otro proceso ejecuta la operacin de seal. A veces se emplea la palabra seal para denominar un semforo que se usa para sincronizar procesos. En este caso una seal tiene dos operaciones: espera y seal que utilizan para sincronizarse dos procesos distintos. Supongamos que un proceso quiere que se le notifique que ha tenido lugar un suceso determinado y que otro proceso es capaz de detectar que ha ocurrido dicho suceso; el ejemplo siguiente muestra como se puede implementar una sincronizacin entre los dos procesos utilizando un semforo. Ejemplo: (* Sincronizacin con semforo*)
module Sincronizacin; var sincro: semaforo; process P1 (* Proceso que espera *) begin .... espera(sincro); .... end P1; process P2 (* Proceso que seala *) begin .... seal(sincro); .... end P2; begin (* Sincronizacin*) inicializa(sincro, 0); cobegin P1; P2; coend end Sincronizacion. Sistemas Operativos - CAP II -31Ing. Grover Q.Y.

El semforo se inicializa a cero de modo que cuando el proceso P1 ejecuta la operacin de espera se suspende hasta que el proceso P2 ejecuta la operacin seal. La sincronizacin se realiza perfectamente incluso si el proceso P2 ejecuta la operacin seal antes de que el proceso P1 ejecute la operacin de espera, ya que en este caso el proceso P2 incrementa el semforo y permite que P1 decremente el semforo y siga su ejecucin cuando alcanza la operacin espera. El ejemplo que sigue muestra la solucin que el uso de semforos ofrece al problema clsico del productor-consumidor. Este problema aparece en distintos lugares de un sistema operativo y caracteriza a aquellos problemas en los que existe un conjunto de procesos que producen informacin que otros procesos consumen, siendo diferentes las velocidades de produccin y consumo de la informacin. Este desajuste en las velocidades, hace necesario que se establezca una sincronizacin entre los procesos de manera que la informacin no se pierda ni se duplique, consumindose en el orden en que es producida. Ejemplo: Suponemos que se tienen dos procesos P1 y P2; P1 produce unos datos que consume P2. P1 almacena datos en algn sitio hasta que P2 est listo para usarlos. Por ejemplo, P1 genera informacin con destino a una impresora y P2 es el proceso gestor de la impresora que se encarga de imprimirlos. Para almacenar los datos se dispone de un buffer o zona de memoria comn al productor y al consumidor. Se supone que para almacenar y tomar datos se dispone de las funciones Poner(x) y Tomar(x). Para saber el estado del buffer se usan las funciones Lleno, que devuelve el valor TRUE si el buffer est lleno, y Vacio, que devuelve el valor TRUE si el buffer est vaco. El productor y el consumidor corren a velocidades distintas, de modo que si el consumidor opera lentamente y el buffer est lleno, el productor deber bloquearse en espera de que haya sitio para dejar ms datos; por el contrario si es el productor el que acta lentamente, el consumidor deber bloquearse si el buffer est vaco en espera de nuevos datos. El programa que sigue muestra un intento de solucin sin utilizar semforos. (Problema del Productor-Consumidor: Solucin 1)
module Productor_Consumidor; var BufferComun: buffer; process Productor; var x: dato; begin loop produce(x); while Lleno do (* espera *) end; Poner(x); end end Productor; process Consumidor; Sistemas Operativos - CAP II -32Ing. Grover Q.Y.

var x: dato; begin loop while Vacio do (* espera *) end; Tomar(x); Consume(x) end end Consumidor; begin cobegin Productor; Consumidor; coend end Productor_Consumidor;

El productor espera en un bucle hasta que el buffer no est lleno y pueda poner el dato x; el consumidor tambin espera en un bucle a que el buffer no est vaco y pueda tomar un dato. La solucin no es satisfactoria porque: 1.- Las funciones Poner(x) y Tomar(x) utilizan el mismo buffer, lo que plantea el problema de la exclusin mutua. 2.- Ambos procesos utilizan una espera ocupada cuando no pueden acceder al buffer porque este est lleno o vaco. El primer problema puede resolverse utilizando un semforo para proteger el acceso al buffer y el segundo sincronizando la actividad de los dos procesos mediante el uso de semforos. En la solucin que sigue se utiliza el semforo AccesoBuffer para resolver el problema de la exclusin mtua en el acceso al buffer y los semforos Nolleno y Novacio para la sincronizacin entre los dos procesos. (Problema del Productor-Consumidor: Solucin con Semforos)
module Productor_Consumidor; var BufferComun: buffer; AccesoBuffer, Nolleno, Novacio: semaforo; process Productor; var x: dato; begin loop produce(x); espera(AccesoBuffer); if Lleno then seal(AccesoBuffer); espera(Nolleno); espera(AccesoBuffer) Sistemas Operativos - CAP II -33Ing. Grover Q.Y.

end; Poner(x); seal(AccesoBuffer); seal(Novacio) end end Productor; process Consumidor; var x: dato; begin loop espera(AccesoBuffer); if Vacio then seal(AccesoBuffer); espera(Novacio); espera(AccesoBuffer) end; Tomar(x); seal(AccesoBuffer); seal(Nolleno); Consume(x) end end Consumidor; begin inicializa(AccesoBuffer, 1); inicializa(Nolleno, 1); inicializa(Novacio, 0); cobegin Productor; Consumidor; coend end Productor_Consumidor;

En la solucin presentada, el acceso al buffer para tomar o poner un dato est protegido por las operaciones espera y seal del semforo AccesoBuffer. Antes de ejecutar las operaciones espera(Nolleno) y espera(Novacio) se libera el semforo AccesoBuffer para evitar que el sistema se bloquee. Esto puede ocurrir si, por ejemplo, el productor gana el acceso al buffer y permanece en espera de que ste no est lleno para poner un dato, a la vez que el consumidor no puede acceder al buffer por tenerlo el productor y, por lo tanto, tambin queda en espera de ganar el acceso no puediendo sacar del estado de lleno al buffer. VERSIN MS GENERAL DE 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 de semforo que lleve la cuenta del nmero de recursos disponibles. En este caso el semforo se inicializa con el nmero
Sistemas Operativos - CAP II -34Ing. Grover Q.Y.

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 que uno de ellos se libera. 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. Las operaciones pueden describirse como sigue:
inicializa (S: SemaforoBinario; v: integer) Poner el valor del semforo S al valor de v (N) numero_suspendidos := 0 espera (S) if S > 0 then S := S-1 else numero_suspendidos:=numero_suspendidos+1; suspender la tarea que hace la llamada y ponerla en la cola de tareas seal (S) if numero_suspendidos > 0 then numero_suspendidos := numero_suspendidos - 1 pasar al estado listo un proceso suspendido else S := S + 1

3.6.8. MONITORES: Un monitor es un conjunto de procedimientos que proporciona el acceso con exclusin mutua a un recurso o conjunto de recursos (datos o dispositivos) compartidos por un grupo de procesos. Los procedimientos van encapsulados dentro de un mdulo que tiene la propiedad especial de que slo un proceso puede estar activo cada vez para ejecutar un procedimiento del monitor. El monitor se puede ver como una valla alrededor del recurso (o recursos), de modo que los procesos que quieran utilizarlo deben entrar dentro de la valla, pero en la forma que impone el monitor. Muchos procesos pueden querer entrar en distintos instantes de tiempo, pero slo se permite que entre un proceso cada vez, debindose esperar a que salga el que est dentro antes de que otro pueda entrar. La ventaja para la exclusin mutua que presenta un monitor frente a los semforos u otro mecanismo es que sta est implcita: la nica accin que debe realizar el programador del proceso que usa un recurso es invocar una entrada del monitor. Si el monitor se ha codificado correctamente no puede ser utilizado incorrectamente por un programa de aplicacin que desee usar el recurso. Cosa que no ocurre con los semforos, donde el programador debe proporcionar la correcta secuencia de operaciones espera y seal para no bloquear al sistema. Los monitores no proporcionan por si mismos un mecanismo para la sincronizacin de tareas y por ello su construccin debe completarse permitiendo, por ejemplo, que se puedan usar seales para sincronizar los procesos. As, para impedir que se pueda producir un bloqueo, un proceso que gane el acceso a un procedimiento del monitor y necesite
Sistemas Operativos - CAP II -35Ing. Grover Q.Y.

esperar a una seal, se suspende y se coloca fuera del monitor para permitir que entre otro proceso; por ello, los procesos P4 y P6 de la figura *** esperan una condicin situados fuera del monitor. Una variable que se utilice como mecanismo de sincronizacin en un monitor se conoce como variable de condicin. A cada causa diferente por la que un proceso deba esperar se asocia una variable de condicin. Sobre ellas slo se puede actuar con dos procedimientos: espera y seal. En este caso, cuando un proceso ejecuta una operacin de espera se suspende y se coloca en una cola asociada a dicha variable de condicin. La diferencia con el semforo estriba en que ahora la ejecucin de esta operacin siempre suspende el proceso que la emite. La suspensin del proceso hace que se libere la posesin del monitor, lo que permite que entre otro proceso. Cuando un proceso ejecuta una operacin de seal se libera un proceso suspendido en la cola de la variable de condicin utilizada. Si no hay ningn proceso suspendido en la cola de la variable de condicin invocada la operacin seal no tiene ningn efecto. El monitor debe usar un sistema de prioridades en la asignacin del recurso que impida que un proceso en espera de lograr entrar se vea postergado indefinidamente por otros procesos nuevos que deseen utilizarlo. SINTAXIS DEL MONITOR La sintaxis de un monitor es como sigue:
monitor: nombre_monitor; declaracin de los tipos y procedimientos que se importan y exportan declaracin de las variables locales del monitor y de las variables de condicin procedure Prc1(..); begin ... end; procedure Prc2(..); begin ... end; .... procedure Prcm(..); begin ... end; begin inicializacin del monitor end.

El monitor no tiene por qu exportar todos sus procedimientos sino slo aquellos que sean pblicos manteniendo como privados aquellos a los que slo pueden acceder otros procedimientos definidos dentro del monitor. Para indicar los procedimientos del monitor que se exportan y actuan por lo tantos como puertas de entrada al monitor usaremos la sentencia export Prc1, Prc2,....,Prcn. Utilizaremos la palabra condicin para definir las variables de condicin del monitor. El cuerpo del monitor contiene una secuencia de instrucciones de inicializacin que se ejecutan una sola vez y antes de que se realice alguna llamada a los procedimientos del monitor.
Sistemas Operativos - CAP II -36Ing. Grover Q.Y.

Se denomina condiciones a la biblioteca donde se encuentra la definicin de las variables de condicin y de los procedimientos espera y seal de los monitores. La variable ocupado indica el estado del semforo. Puesto que est inicialmente en falso, el primer proceso que realiza una invocacin a la operacin sespera puede acceder al recurso controlado por el monitor y como la variable ocupado se pone a verdadero, cualquier otro proceso que ejecute la operacin sespera debe esperar a que se ejecute una operacin sseal para poder acceder al recurso. Cuando esto ocurre la variable ocupado pasa a tener el valor falso y la condicin libre recibe una seal, lo que hace que uno de los procesos que esperan en su cola pase a completar la ejecucin de sespera y pueda acceder al recurso. Ejecuciones sucesivas de sseal van despertando a procesos en espera hasta que no haya ms procesos en la cola de la condicin libre. Cuando no hay ningn proceso en espera de la variable de condicin la ejecucin de sseal slo tiene por efecto poner la variable ocupado a false, lo que permite que el primer proceso que ejecute sespera pueda acceder al recurso. Un monitor es un objeto que implementa acceso a todos sus mtodos. En Java, son objetos de una clase cuyos mtodos pblicos son todos synchronized . Un objeto con mtodos synchronized proporciona un cerrojo que permite implantar monitores con comodidad. Los mtodos wait, notify, notifyAll permiten sincronizar el monitor, de acuerdo a la semntica de los mismos ya conocidos.

SEMFOROS VS. MONITORES Un semforo es un objeto que es utilizado para sincronizar el acceso a un recurso compartido, mientras que un monitor constituye la interfaz de acceso al propio recurso compartido. Los monitores ofrecen mayor seguridad (reliability), robustez y escalabilidad; complementan al encapsulamiento de un objeto, sincronizando el acceso al mismo. Los semforos permiten limitar el nmero de procesadores que acceden concurrentemente a un recurso compartido, estableciendo un protocolo de adquisicin (wait) y liberacin (signal).

Sistemas Operativos - CAP II

-37-

Ing. Grover Q.Y.

3.7. PROBLEMAS CLSICOS DE IPC: ANLISIS Y SOLUCIONES 3.7.1. PROBLEMA DE LA CENA DE LOS FILSOFOS: El problema de los filsofos cenando es un problema clsico de Comunicacin entre procesos, propuesto por Dijkstra en 1965 para representar el problema de la sincronizacin de procesos en un sistema operativo. Cabe aclarar que la interpretacin est basada en pensadores chinos, quienes coman con dos palillos, donde es ms lgico que se necesite el del comensal que se siente al lado para poder comer.

Enunciado del problema: Cinco filsofos se sientan alrededor de una mesa y pasan su vida cenando y pensando. Cada filsofo tiene un plato de fideos y un tenedor a la izquierda de su plato. Para comer los fideos son necesarios dos tenedores y cada filsofo slo puede tomar los que estn a su izquierda y derecha. Si cualquier filsofo coge un tenedor y el otro est ocupado, se quedar esperando, con el tenedor en la mano, hasta que pueda coger el otro tenedor, para luego empezar a comer. Si dos filsofos adyacentes intentan tomar el mismo tenedor a una vez, se produce una condicin de carrera: ambos compiten por tomar el mismo tenedor, y uno de ellos se queda sin comer. Si todos los filsofos cogen el tenedor que est a su derecha al mismo tiempo, entonces todos se quedarn esperando eternamente, porque alguien debe liberar el tenedor que les falta. Nadie lo har porque todos se encuentran en la misma situacin (esperando que alguno deje sus tenedores). Entonces los filsofos se morirn de hambre. La solucin consiste en encontrar un algoritmo que permita que los filsofos nunca se mueran de hambre. Algunas posibles soluciones: Por turno cclico: Se empieza por un filsofo, que si quiere puede comer y despus pasa su turno al de la derecha. Cada filsofo slo puede comer en su turno. Problema: si el nmero de filsofos es muy alto, uno puede morir de hambre antes de su turno.
Sistemas Operativos - CAP II -38Ing. Grover Q.Y.

Varios turnos: Se establecen varios turnos. Para hacerlo ms claro supongamos que cada filsofo que puede comer (es su turno) tiene una ficha que despus pasa a la derecha. Si por ejemplo hay 7 comensales podemos poner 3 fichas en posiciones alternas (entre dos de las fichas quedaran dos filsofos). Se establecen turnos de tiempo fijo. Por ejemplo cada 5 minutos se pasan las fichas (y los turnos) a la derecha. En base al tiempo que suelen tardar los filsofos en comer y en volver a tener hambre, el tiempo de turno establecido puede hacer que sea peor solucin que la anterior. Si el tiempo de turno se aproxima al tiempo medio que tarda un filsofo en comer esta variante da muy buenos resultados. Si adems el tiempo medio de comer es similar al tiempo medio en volver a tener hambre la solucin se aproxima al ptimo. Colas de tenedores: Cuando un filsofo quiere comer se pone en la cola de los dos tenedores que necesita. Cuando un tenedor est libre lo toma. Cuando toma los dos tenedores, come y deja libre los tenedores. Visto desde el otro lado, cada tenedor slo pueden tener dos filsofos en cola, siempre los mismos, esto crea el problema comentado de que si todos quieren comer a la vez y todos empiezan tomando el tenedor de su derecha se bloquea el sistema (deadlock). Resolucin de conflictos en colas de tenedores: Cada vez que un filsofo tiene un tenedor espera un tiempo aleatorio para conseguir el segundo tenedor. Si en ese tiempo no queda libre el segundo tenedor, suelta el que tiene y vuelve a ponerse en cola para sus dos tenedores. Si un filsofo A suelta un tenedor (porque ha comido o porque ha esperado demasiado tiempo con el tenedor en la mano) pero todava desea comer, vuelve a ponerse en cola para ese tenedor. Si el filsofo adyacente B est ya en esa cola de tenedor (tiene hambre) lo toma y si no vuelve a cogerlo A. Es importante que el tiempo de espera sea aleatorio o se mantendr el bloqueo del sistema. El portero del comedor: Se indica a los filsofos que abandonen la mesa cuando no tengan hambre y que no regresen a ella hasta que vuelvan a estar hambrientos (cada filsofo siempre se sienta en la misma silla). La misin del portero es controlar el nmero de filsofos en la sala, limitando su nmero a n-1, pues si hay n-1 comensales seguro que al menos uno puede comer con los dos tenedores.

Sistemas Operativos - CAP II

-39-

Ing. Grover Q.Y.

3.7.2. PROBLEMA DEL PELUQUERO DORMIDO:

El problema consiste en una barbera en la que trabaja un barbero que tiene un nico silln de barbero y varias sillas para esperar. Cuando no hay clientes, el barbero se sienta en una silla y se duerme. Cuando llega un nuevo cliente, ste o bien despierta al barbero o si el barbero est afeitando a otro cliente se sienta en una silla (o se va si todas las sillas estn cliente ocupadas por clientes esperando).

Esta solucin utiliza tres semforos: customers, que cuenta a los clientes en espera (excluyendo al que est siendo atendido, que no est esperando), barbers, el nmero de peluqueros que estn ociosos, esperando clientes (0 o 1), y mutex, que se usa para la exclusin mutua. Tambin necesitamos una variable, waiting (esperando), que tambin cuenta los clientes que estn esperando, y que en esencia es una copia de customers. entes Necesitamos esta variable porque no es posible leer el valor actual de un semforo. En esta solucin, un cliente que entra en la peluquera debe contar el nmero de clientes que esperan. Si este nmero es menor que el nmero de sillas, se queda; si no, se va. . Cuando el peluquero llega a trabajar en la maana, ejecuta el procedimiento barber (peluquero) que lo obliga a bloquearse en espera de customers hasta que llegue alguien. Luego se duerme. Cuando un cliente llega, ejecuta customer (cliente), cuya primera instruccin es adquirir mutex para entrar en una regin crtica. Si otro cliente llega poco tiempo despus, no podr hacer nada hasta que el primero haya liberado mutex. A continuacin, el cliente verifica si continuacin, el nmero de clientes en espera es menor que el nmero de sillas. Si no es as, el cliente libera mutex y se sale sin su corte de pelo. Si hay una silla disponible, el cliente incrementa la variable entera waiting y luego ejecuta UP con el semforo customers, lo que despierta al peluquero. En este punto, tanto el peluquero como el cliente estn despiertos. Cuando el cliente libera mutex, el peluquero lo toma, realiza algo de aseo e inicia el corte de pelo. Una vez terminado el corte de pelo, el cliente sale del procedimiento y de la peluquera. A corte diferencia del anterior, no hay un ciclo para el cliente porque cada uno slo recibe un corte de pelo. El peluquero s opera en un ciclo, tratando de atender al siguiente cliente. Si hay uno presente, el peluquero realiza otro corte de pelo; si no, se duerme. no

Sistemas Operativos - CAP II

-40-

Ing. Grover Q.Y.

Como acotacin, vale la pena sealar que si bien los problemas de lectores y escritores y del peluquero dormido no implican transferencia de datos, pertenecen al rea de IPC porque implican sincronizacin entre varios procesos.

Sistemas Operativos - CAP II

-41-

Ing. Grover Q.Y.