Colegio Universitario Francisco de Miranda Unidad Curricular:: SISTEMAS OPERATIVOS Modulo: SISTEMAS OPERATIVOS II Apuntes Recopilados por: Profesor

Bernardo Gonzalez Rojas

UNIDAD 4: COORDINACION Y SINCRONIZACION DE PROCESOS.

TEMA N 1: CONCURRENCIA. 1.1. Introduccin.
Los conceptos claves en los que se basan los sistemas operativos modernos son el de proceso y el de hilo. Los temas fundamentales de diseo de sistemas operativos estn relacionados con la gestin de procesos:

Multiprogramacin: Es la gestin de varios procesos dentro de un sistema monoprocesador. La mayora de

los computadores personales, estaciones de trabajo, sistemas monoprocesador y sistemas operativos actuales de estas mquinas, tales como Windows 7, OS/2 y el Sistema 7 de Macintosh dan soporte a la multiprogramacin. Los sistemas operativos como UNIX y LINUX incorporan multiprogramacin de sistemas monoprocesador compartidos.

Multiproceso: Es la gestin de varios procesos dentro de un sistema multiprocesador. Hasta no hace

mucho, los sistemas multiprocesador se utilizaban nicamente en grandes sistemas, computadores centrales y minicomputadores. Los sistemas operativos como MVS y VMS dan soporte de multiproceso. Ms recientemente, el multiproceso ha empezado a ganarse la aprobacin de los servidores y las estaciones de trabajo. Windows NT es un ejemplo de un sistema operativo diseado para estos entornos.

Proceso distribuido: Es la gestin de varios procesos que ejecutan en sistemas de computadores mltiples
y remotas.

1.2. Definicin.
La concurrencia es el punto clave de los tres campos anteriores y fundamentales para el di-seo de sistemas operativos. La concurrencia comprende un gran nmero de cuestiones de diseo, incluyendo la comunicacin entre procesos, comparticin y competencia por los recursos, sincronizacin de la ejecucin de varios procesos y asignacin del tiempo de procesador a los procesos. Se ver que estas cuestiones no solo surgen en entornos de multi-procesadores y proceso distribuido, sino incluso en sistemas multiprogramados con un solo procesador. La concurrencia puede presentarse en tres contextos diferentes:

Varias aplicaciones: La multiprogramacin se cre para permitir que el tiempo de procesador de la

mquina fuese compartido dinmicamente entre varios trabajos o aplicaciones activas.

Aplicaciones estructuradas: Como ampliacin de los principios del diseo modular 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.

1.3. Ejemplo Concurrencia.

Para ilustrar estos conceptos y comparar los mtodos presentados en este tema, se usan dos problemas clsicos de concurrencia. En primer lugar, se presentar el problema del productor/consumidor como ejemplo tpico. El tema termina con el problema de los lectores/escritores. En un sistema multiprogramado con un nico procesador, los procesos se intercalan en el tiempo
Pgina 1 de 15

Colegio Universitario Francisco de Miranda Unidad Curricular:: SISTEMAS OPERATIVOS Modulo: SISTEMAS OPERATIVOS II Apuntes Recopilados por: Profesor Bernardo Gonzalez Rojas

para dar la apariencia de ejecucin simultnea (figura 1.1). Aunque no se consigue un proceso paralelo real y aunque se produce una cierta sobrecarga en los intercambios de procesos de un sitio a otro, la ejecucin intercalada produce beneficios importantes en la eficiencia del procesamiento y en la estructuracin de los programas. En un sistema con varios procesadores, no solo es posible intercalar los procesos, sino tambin superponerlos (figura 1.2).

Figura 1.1 - Intercalacin

Figura 1.2 Intercalacin y Superposicin

A primera vista, podra parecer que la intercalacin y la superposicin representan formas de ejecucin muy diferentes y que introducen problemas distintos. De hecho, ambas tcnicas pueden contemplarse como ejemplos de proceso concurrente y ambas plantean los mismos problemas. En el caso de un sistema monoprocesador, los problemas creados por la multiprogramacin parten del hecho de que la velocidad relativa de ejecucin de los procesos no puede predecirse. Depende de la actividad de otros procesos, de la forma en que el sistema operativo trata las interrupciones y de las polticas de planificacin. As surgen las siguientes dificultades:

i.- La comparticin de recursos globales est llena de riesgos. Por ejemplo, si dos procesos hacen uso al mismo
tiempo de la misma variable global y ambos llevan a cabo tanto lecturas como escrituras sobre la variable, el orden en que se ejecuten las lecturas y escrituras es crtico. En el siguiente apartado se ofrece un ejemplo de este problema.

ii.- Para el sistema operativo resulta difcil asignar los recursos de forma ptima. Por ejemplo, el proceso A puede
solicitar el uso de un canal de E/S en particular y suspenderse antes de hacer uso del canal. Si el sistema operativo bloquea el canal e impide su uso por parte de otros procesos, se tiene una cierta ineficiencia.

iii.-

Resulta difcil localizar un error de programacin porque los resultados no son normalmente reproducibles.

Todas las dificultades anteriores se presentan tambin en los sistemas multiprocesador, ya que tambin en ellos es impredecible la velocidad relativa de ejecucin de los procesos. Un sistema multiprocesador debe solucionar, adems, los problemas originados por el hecho de que varios procesos puedan estar ejecutando a la vez. Sin embargo, los problemas son, fundamentalmente, los mismos que en el caso anterior.

1.4.- Labores del Sistema Operativo.

Qu elementos de gestin y diseo surgen por causa de la concurrencia? Se pueden enumerar los siguientes:

i.-

El sistema operativo debe ser capaz de seguir la pista de los distintos procesos activos. Esto lo hace por medio de bloques de control de procesos, como se describi en la unidad anterior. se incluyen:

ii.- El sistema operativo debe asignar y quitar los distintos recursos a cada proceso activo. Entre estos recursos

Tiempo de procesador: Es funcin de la planificacin. Memoria: La mayora de los sistemas operativos emplean esquemas de memoria virtual. Archivos. Dispositivos de E/S.
iii.- El sistema operativo debe proteger los datos y los recursos fsicos de cada proceso contra injerencias no
intencionadas de otros procesos. Esto supone emplear tcnicas relativas a la memoria, archivos y dispositivos de E/S, que se estudian en los captulos correspondientes.

Pgina 2 de 15

Colegio Universitario Francisco de Miranda Unidad Curricular:: SISTEMAS OPERATIVOS Modulo: SISTEMAS OPERATIVOS II Apuntes Recopilados por: Profesor Bernardo Gonzalez Rojas

iv.- Los resultados de un proceso deben ser independientes de la velocidad relativa a la que se realiza la
ejecucin con respecto a otros procesos concurrentes. Para comprender cmo se puede abordar la independencia de la velocidad, hace falta estudiar las formas en las que los procesos pueden interactuar.

1.4.1.- Competencia entre procesos por los recursos

Los procesos concurrentes entran en conflicto cuando compiten por el uso del mismo recurso. Bsicamente, es posible describir esta situacin como sigue. Dos o ms procesos necesitan acceder a un recurso durante el curso de su ejecucin. Cada proceso no es consciente de la existencia de los otros y no se ve afectado por su ejecucin. De aqu se obtiene que cada proceso debe dejar tal y como est el estado de cualquier recurso que utilice. Como ejemplos de recursos se tienen a los dispositivos de E/S, la memoria, el tiempo de procesador y el reloj. No hay intercambio de informacin entre los procesos en competencia. Sin embargo, la ejecucin de un proceso puede influir en el comportamiento de los procesos que compiten. En particular, si dos procesos desean acceder a un nico recurso, el sistema operativo le asignar el recurso a uno de ellos y el otro tendr que esperar. Por tanto, el proceso al que se niega el acceso se retrasar. En el peor caso, el proceso bloqueado puede que no consiga nunca acceder al recurso y, por tanto, no terminar con xito nunca.

1.4.2.-Cooperacin entre procesos por comparticin

El caso de cooperacin por comparticin comprende a los procesos que interactan con otros sin tener conocimiento explicito de ellos. Por ejemplo, varios procesos pueden tener acceso a variables compartidas, archivos o bases de datos compartidas. Los procesos pueden emplear y actualizar los datos compartidos sin hacer referencia a los otros procesos, pero son conscientes de que estos otros pueden tener acceso a los mismos datos. As pues, los procesos deben cooperar pasa asegurar que los datos que se comparten se gestionan correctamente. Los mecanismos de control deben garantizar la integridad de los datos compartidos.

1.4.3.- Cooperacin entre procesos por comunicacin

En los dos primeros casos expuestos, cada proceso posee su propio entorno aislado, que no incluye a los otros procesos. Las interacciones entre los procesos son indirectas. En ambos casos, existe comparticin. En caso de competencia, los procesos estn compartiendo recursos sin tener conocimiento de la existencia de otros procesos. En el segundo caso, estn compartiendo valores y, aunque cada proceso no tiene conocimiento explicito de los otros, si es consciente de la necesidad de conservar la integridad de los datos. Cuando los procesos cooperan por comunicacin, en cambio, los distintos procesos participan en una labor comn que une a todos los procesos. La comunicacin es una manera de sincronizar o coordinar las distintas actividades. Normalmente, la comunicacin puede caracterizarse por estar formada por mensajes de algn tipo. Las primitivas para enviar y recibir mensajes pueden venir dadas como parte del lenguaje de programacin o por el ncleo del sistema operativo.

TEMA N 2 SEMAFOROS. 2.1. Introduccin.

Se vuelven a considerar ahora los mecanismos que se usan en el sistema operativo y en los lenguajes de programacin para dar soporte a la concurrencia. En este tema se trataran los semforos. En las dos siguientes secciones se discutir sobre los monitores y el paso de mensajes. El primer gran avance en la resolucin de los problemas de procesos concurrentes lleg en 1965, con el tratado de Dijkstra sobre la cooperacin entre procesos secunciales, Dijkstra estaba interesado en el diseo de un sistema operativo como un conjunto de procesos secunciales cooperantes y en el desarrollo de mecanismos eficientes y fiables para dar soporte a la cooperacin. Los procesos de usuario podrn utilizar estos mecanismos en tanto que el procesador y el sistema operativo los hagan disponibles. El principio fundamental es el siguiente: Dos o ms procesos pueden cooperar por medio de simples seales, de forma que se pueda obligar a detenerse a un proceso en una posicin determinada hasta que reciba una seal
Pgina 3 de 15

Colegio Universitario Francisco de Miranda Unidad Curricular:: SISTEMAS OPERATIVOS Modulo: SISTEMAS OPERATIVOS II Apuntes Recopilados por: Profesor Bernardo Gonzalez Rojas

especfica. Cualquier requisito complicado de coordinacin puede satisfacerse por medio de la estructura de seales adecuada. Para la sealizacin, se usan variables especiales llamados semforos. Para transmitir una seal por el Semforo s, los procesos ejecutan la primitiva signal(s). Para recibir una seal del semforo s, los procesos ejecutan la primitiva wait(s); si la seal correspondiente an no se ha transmitido, el proceso es suspendido hasta que tenga lugar la transmisin.

2.2. Funcionamiento de los Semforos.

Para lograr el efecto deseado, se pueden contemplar los semforos como variables que tienen un valor entero sobre el que se definen las tres operaciones siguientes:

i.- Un semforo puede inicializarse con un valor no negativo. ii.- La operacin wait decrementa el valor del semforo. Si el valor se hace negativo, el proceso que ejecuta el
wait se bloquea.

iii.-

La operacin signal incrementa el valor del semforo. Si el valor no es positivo, se des-bloquea a un proceso bloqueado por una operacin wait.

Aparte de estas tres operaciones, no hay forma de examinar o manipular los semforos.

2.3. Implementacin de Semforos.

La figura 2.1 propone una definicin ms formal de las primitivas de los semforos. Las primitivas wait y signal se suponen atmicas, es decir, no pueden ser interrumpidas y cada rutina puede considerarse como un paso indivisible. En la figura 2.2 se define una versin ms limitada, conocida como semforo binario. Un semforo binario solo puede tomar los valores 0 y 1. En principio, los semforos binarios son ms sencillos de implementar y puede demostrarse que tienen la misma potencia de expresin que los semforos generales.

Figura 2.1 Una Definicin Primitivas Semforos Figura 2.2 Una Definicin Primitivas Semforos Binarios

Pgina 4 de 15

Colegio Universitario Francisco de Miranda Unidad Curricular:: SISTEMAS OPERATIVOS Modulo: SISTEMAS OPERATIVOS II Apuntes Recopilados por: Profesor Bernardo Gonzalez Rojas

Tanto en los semforos como en los semforos binarios se emplea una cola para mantener los procesos esperando en el semforo. La definicin no dicta el orden en el que se quitan los procesos de dicha cola. La poltica ms equitativa es la FIFO: el proceso que ha estado bloqueado durante ms tiempo se libera de la cola. La nica exigencia estricta es que un proceso no debe quedar retenido en la cola de un semforo indefinidamente porque otros procesos tengan preferencia. _

2.4.- Exclusin Mutua

La figura 2.3 muestra una solucin sencilla al problema de la exclusin mutua por medio de un semforo s. Sean n procesos, identificados por el array P(s). En cada proceso, se ejecuta un wait(s) justo antes de su seccin crtica. Si el valor de s es negativo, se suspende el proceso. Si el valor es 1, se decrementa a 0 y el proceso entra inmediatamente en su seccin critica; puesto que s ya no es positivo, no se permitir a ningn otro proceso entrar en su seccin critica. program exclusion_mutua; El semforo se inicializa a 1. De este modo, el const n = ; (* nmero de procesos *); var s: semforo primer proceso que ejecute un wait podr (:= 1); entrar inmediatamente en la seccin crtica, procedure P (i: entero); poniendo el valor de s a 0. Cualquier otro begin proceso que intente entras en la seccin repeat critica La encontrar ocupada y se bloqueara, poniendo el valor de s a -1. Cualquier nmero wait(s) de procesos puede intentar entrar; cada uno <seccin critica>; de estos intentos infructuosos origina un signal(s); nuevo decremento del valor de s. <resto> forever El semforo se inicializa a 1. De este modo, el end; primer proceso que ejecute un wait podr entrar inmediatamente en la seccin crtica, begin (* programa principal *) poniendo el valor de s a 0. Cualquier otro parbegin proceso que intente entras en la seccin P(1); critica La encontrar ocupada y se bloqueara, P(2); poniendo el valor de s a -1. Cualquier nmero de procesos puede intentar entrar; cada uno P(n); de estos intentos infructuosos origina un parend nuevo decremento del valor de s. end. Figura 2.3 Exclusin Mutua por Medio de Semforos Cuando el proceso que entr al principio en su seccin critica salga, se incrementar s y se eliminar uno de los procesos bloqueados (si los hay) de la cola de procesos asociada al semforo, ponindolo en el estado listo. Cuando sea planificado de nuevo por el sistema operativo, podr entrar en la seccin critica.

Pgina 5 de 15

Colegio Universitario Francisco de Miranda Unidad Curricular:: SISTEMAS OPERATIVOS Modulo: SISTEMAS OPERATIVOS II Apuntes Recopilados por: Profesor Bernardo Gonzalez Rojas

El algoritmo de exclusin mutua por medio de semforos se puede ilustrar con el modelo del igl (figura 2.4). Adems de la pizarra, el igl tiene un potente congelador. Un proceso entra para realizar un wait, decrementa el valor de la pizarra en 1. Si el valor que hay ahora en la pizarra no es negativo, puede entrar en su seccin critica. En otro caso, entra en hibernacin en el congelador. Figura 2.4 Un Iglu Semforo Esto vaca el interior del igl, permitiendo que otros procesos entren. Cuando un proceso ha completado su seccin crtica, entra al igl para realizar un signal, incrementando el valor de la pizarra en 1. Si el valor no es positivo, libera un proceso del congelador. El programa de la figura 2.3 puede manejar igual de bien el requisito de que ms de un proceso pueda entrar en su seccin crtica en un instante. Este requisito se satisface simplemente inicializando el semforo con un valor especfico. De este modo, en cualquier instante, el valor de s.contador puede interpretarse como sigue:

s.contador _ 0: s.contador es el nmero de procesos que pueden ejecutar un wait(s) sin bloquearse (si no se
ejecuta ningn signal(s) mientras tanto).

s.contador <0: el valor absoluto de s.contador es el nmero de procesos bloqueados en s.cola.

TEMA N 3 MONITORES. 3.1. Introduccin.
Los semforos son una herramienta bsica, pero potente y flexible, para hacer cumplir la exclusin mutua y coordinar procesos. Sin embargo, como se propone en la figura 4.14, puede resultar difcil construir un programa correcto por medio de semforos. La dificultad est en que las operaciones wait y signal deben distribuirse por todo el programa y no es fcil advertir el efecto global de estas operaciones sobre los semforos a los que afectan. Los monitores son estructuras de un lenguaje de programacin que ofrecen una funcionalidad equivalente a la de los semforos y que son ms fciles de controlar. La estructura de monitor se ha implementado en varios lenguajes de programacin, incluido Pascal Concurrente, Pascal-plus, Modula-2 y Modula-3. Ms recientemente, se han implementado como una biblioteca de programas. Esto permite poner cierres de monitor a objetos cualesquiera. En particular, para algo parecido a una lista enlazada, se puede querer bloquear todas las listas enlazadas con un solo cierre o bien tener un cierre para cada elemento de cada lista. Se comenzar estudiando la versin de Hoare para despus examinar una leve modificacin.

3.2.- Monitores con Seales.

Un monitor es un mdulo de software que consta de uno o ms procedimientos, una secuencia de inicializacin y unos datos locales. Las caractersticas bsicas de un monitor son las siguientes:

i.- Las variables de datos locales estn solo accesibles para los procedimientos del monitor y no para
procedimientos externos.
Pgina 6 de 15

Colegio Universitario Francisco de Miranda Unidad Curricular:: SISTEMAS OPERATIVOS Modulo: SISTEMAS OPERATIVOS II Apuntes Recopilados por: Profesor Bernardo Gonzalez Rojas

ii.- Un proceso entra en el monitor invocando a uno de sus procedimientos. iii.- Solo un proceso puede estar ejecutando en el monitor en un instante dado; cualquier otro proceso que haya invocado al monitor quedara suspendido mientras espera a que el monitor est disponible
Las dos primeras caractersticas recuerdan a las de los objetos del software orientado a objetos. En realidad, un sistema operativo o lenguaje de programacin orientado a objetos puede implementar un monitor fcilmente como un objeto con caractersticas especiales. Si se cumple la norma de un proceso cada vez, el monitor puede ofrecer un servicio de exclusin mutua. Las variables de datos del monitor pueden ser accedidas solo por un proceso cada vez. As pues, una estructura de datos compartida puede protegerse situndola dentro de un monitor. Si los datos del monitor representan a algn recurso, el monitor ofrecer un servicio en exclusin mutua en el acceso a este recurso. Para que resulten tiles en el proceso concurrente los monitores deben incluir herramientas de sincronizacin. Por ejemplo, supngase que un proceso llama a un monitor y, mientras est en el monitor, debe suspenderse hasta que se cumpla alguna condicin. Hace falta un servicio para que el proceso no solo est suspendido, sino que libere el monitor y otro proceso pueda entrar. Ms tarde, cuando se cumpla la condicin y el monitor est de nuevo disponible, el proceso puede reanudarse y tiene que permitrsele volver a entrar en el monitor en el punto de la suspensin. Un monitor proporciona sincronizacin por medio de las variables de condicin que se incluyen dentro del monitor y que son accesibles slo desde dentro. Hay dos funciones para operar con las variables de condicin: wait(c): Suspende la ejecucin del proceso llamado bajo la condicin c. El monitor est ahora disponible para ser usado por otro proceso. signal(c): Reanuda la ejecucin de algn proceso suspendido despus de un wait bajo la misma condicin. Si hay varios procesos, elige uno de ellos; si no hay ninguno, no hace nada.

Pgina 7 de 15

Colegio Universitario Francisco de Miranda Unidad Curricular:: SISTEMAS OPERATIVOS Modulo: SISTEMAS OPERATIVOS II Apuntes Recopilados por: Profesor Bernardo Gonzalez Rojas

Ntese que las operaciones de monitor wait/signal son diferentes de las de los semforos. Si un proceso de un monitor ejecuta un signal y no hay tareas esperando en la variable de condicin, el signal se pierde La figura 3.1 ilustra la estructura de un monitor. Aunque un proceso puede entrar al monitor llamando a cualquiera de sus procedimientos, puede considerarse que el monitor tiene un nico punto de entrada que est custodiado para que slo un proceso pueda estar en el monitor en cada instante. Otros procesos que intenten entrar al monitor se aadirn a una cola de procesos suspendidos mientras esperan a que el monitor est disponible. Una vez que un proceso est dentro del monitor, puede suspenderse a s mismo temporalmente bajo la condicin x ejecutando wait(x); entonces se sita en una cola de procesos que esperan volver a entrar al monitor cuando la condicin cambie. Si un proceso que est ejecutando en el monitor detecta un cambio en una variable de condicin x, ejecuta signal(x), lo que avisa a la cola de condicin correspondiente de que la condicin ha cambiado. Figura 3.1 Estructura de un Monitor La figura 4.24 muestra una solucin con monitores. El mdulo monitor, buffer_acotado, controla el buffer empleado para almacenar y retirar caracteres. El monitor incluye dos variables de condicin: no_lleno es cierta cuando hay sitio para aadir al menos un carcter al buffer y no_vaco es cierta cuando hay al menos un carcter en el buffer. Un productor slo puede aadir caracteres al buffer por medio del procedimiento

TEMA N 4 PASO DE MENSAJES. 4.1. Introduccin.

Cuando los procesos interactan unos con otros, se deben satisfacer dos requisitos bsicos: la sincronizacin y la comunicacin. Los procesos tienen que sincronizarse para cumplir la exclusin mutua; los procesos cooperantes pueden necesitar intercambiar informacin. Un mtodo posible para ofrecer ambas funciones es el paso de mensajes. El paso de mensajes tiene la ventaja adicional de que se presta a ser implementado en sistemas distribuidos, as como en sistemas multiprocesador y monoprocesador de memoria compartida. Hay varias formas de sistemas de paso de mensajes. En esta seccin, se ofrecer una introduccin general que discute las caractersticas tpicas encontradas en estos sistemas. La funcionalidad real del paso de mensajes se ofrece, normalmente, por medio de un par de primitivas: send (destino, mensaje) receive (origen, mensaje)
Pgina 8 de 15

Colegio Universitario Francisco de Miranda Unidad Curricular:: SISTEMAS OPERATIVOS Modulo: SISTEMAS OPERATIVOS II Apuntes Recopilados por: Profesor Bernardo Gonzalez Rojas

Este es el conjunto mnimo de operaciones necesario para que los procesos puedan dedicarse al paso de mensajes. Un proceso enva informacin en forma de un mensaje a otro proceso designado como destino. Un proceso recibe informacin ejecutando la primitiva receive, que indica el proceso emisor (origen) y el mensaje.

4.2.- Sincronizacin.
La comunicacin de un mensaje entre dos procesos implica cierto nivel de sincronizacin entre ambos. El receptor no puede recibir un mensaje hasta que sea enviado por otro proceso. Adems, hace falta especificar qu le sucede a un proceso despus de ejecutar una primitiva sena o receive. Considrese en primer lugar la primitiva send. Cuando se ejecuta una primitiva sena en un proceso, hay dos posibilidades: O bien el proceso emisor se bloquea hasta que se recibe el mensaje o no se bloquea. Anlogamente, cuando un proceso ejecuta una primitiva receive, hay dos posibilidades:

i.-

Si previamente se ha enviado algn mensaje, ste es recibido y contina la ejecucin. mensaje o (b) el proceso contina ejecutando, abandonando el intento de recepcin.

ii.- Si no hay ningn mensaje esperando entonces, o bien (a) el proceso se bloquea hasta que llega un
As pues, tanto el emisor como el receptor pueden ser bloqueantes o no bloqueantes. Son habituales las siguientes tres combinaciones, aunque cualquier sistema concreto implementa slo una o dos combinaciones:

Envo bloqueante, recepcin bloqueante: Tanto el emisor como el receptor se bloquean hasta que se
entrega el mensaje; esta tcnica se conoce como rendezvous. Esta combinacin permite una fuerte sincronizacin entre procesos.

Envo no bloqueante, recepcin bloqueante: Aunque el emisor puede continuar, el receptor se bloquea
hasta que llega el mensaje solicitado. Esta es, probablemente, la combinacin ms til. Permite que un proceso enve uno o ms mensajes a varios destinos tan rpido como sea posible. Un proceso que debe recibir un mensaje antes de poder hacer alguna funcin til tiene que bloquearse hasta que llegue el mensaje. Un ejemplo es el de un proceso servidor que ofrezca un servicio o un recurso a otros procesos.

Envo no bloqueante, recepcin no bloqueante: Nadie debe esperar.

El send no bloqueante es la forma ms natural para muchas tareas de programacin concurrente. Por ejemplo, si se usa para solicitar una operacin de salida, tal como una impresin, permite al proceso solicitante realizar la solicitud en forma de mensaje y continuar. Un posible riesgo del send no bloqueante es que un error puede llevar a una situacin en la que el proceso genere mensajes repetidamente. Como no hay bloqueo para hacer entrar en disciplina al proceso, esos mensajes pueden consumir recursos del sistema, incluido tiempo del procesador y espacio en buffer, en detrimento de otros procesos y del sistema operativo. Adems, el send no bloqueante carga sobre el programador el peso de determinar qu mensaje se ha recibido: Los procesos deben emplear mensajes de respuesta para acusar La recepcin de un mensaje. Para la primitiva receive, la versin bloqueante parece ser la ms natural para muchas tareas de programacin concurrente. En general, un proceso que solicita un mensaje necesitar la informacin esperada antes de continuar. Sin embargo, si se pierde un mensaje, un proceso receptor puede quedarse bloqueado indefinidamente. Este problema puede resolverse por medio del receive no bloqueante. Sin embargo, el riesgo de esta solucin es que si un mensaje se enva despus de que un proceso haya ejecutado el correspondiente receive, el mensaje se perder. Otro mtodo posible consiste en permitir a un proceso comprobar si hay un mensaje esperando antes de ejecutar un receive y en permitir a un proceso especificar ms de un origen en una primitiva receive. Esta ltima tcnica resulta til si un proceso espera mensajes de ms de un origen y puede continuar si llega cualquiera de estos mensajes.

4.3.- Direccionamiento.
Evidentemente, es necesario disponer de alguna forma de especificar en la primitiva send qu proceso va a recibir el mensaje. De forma similar, la mayora de las implementaciones permiten a los procesos receptores indicar el origen del mensaje que se va a recibir.

Pgina 9 de 15

Colegio Universitario Francisco de Miranda Unidad Curricular:: SISTEMAS OPERATIVOS Modulo: SISTEMAS OPERATIVOS II Apuntes Recopilados por: Profesor Bernardo Gonzalez Rojas

Los distintos esquemas para hacer referencia a los procesos en las primitivas sena y receive se encuadran dentro de dos categoras: direccionamiento directo e indirecto. Con el direccionamiento directo, la primitiva sena incluye una identificacin especfica del proceso destino. La primitiva receive se puede gestionar de dos formas. Una posibilidad requiere que el proceso designe explcitamente un proceso emisor. As pues, el proceso debe conocer de antemano de qu proceso espera un mensaje. Esto suele ser eficaz para procesos concurrentes y cooperantes. En otros casos, sin embargo, es imposible especificar el proceso de origen por anticipado. Un ejemplo es un proceso servidor de impresoras, que aceptar mensajes de solicitud de impresin de cualquier otro proceso. Para tales aplicaciones, una tcnica ms efectiva consiste en usar direccionamiento implcito. En este caso, el parmetro origen de la primitiva receive tendr un valor de retomo cuando se haya realizado la operacin de recepcin. El otro enfoque es el direccionamiento indirecto. En este caso, los mensajes no se envan directamente del emisor al receptor, sino a una estructura de datos compartida formada por colas que pueden guardar los mensajes temporalmente. Estas colas se denominan generalmente buzones (mailboxes). De este modo, para que dos procesos se comuniquen, uno enva mensajes al buzn apropiado y el otro los coge del buzn. Una ventaja del direccionamiento indirecto es que se desacopla a emisor y receptor, permitiendo una mayor flexibilidad en el uso de los mensajes. La relacin entre emisores y receptores puede ser uno a uno, de muchos a uno, de uno a muchos o de muchos a muchos. Una relacin uno a uno permite que se establezca un enlace privado de comunicaciones entre dos procesos, lo que asla su interaccin de injerencias errneas de otros procesos. Una relacin de muchos a uno resulta til para interacciones cliente/servidor, donde un proceso ofrece un servicio a un conjunto de procesos. En este caso, el buzn se denomina puerto (figura 4.1). Una relacin uno a muchos permite un emisor y muchos receptores; es til para aplicaciones en las que un mensaje o alguna informacin se difunda a un conjunto de procesos. La asociacin de procesos a buzones puede ser esttica o dinmica. Los puertos suelen estar asociados estticamente con algn proceso en particular, es decir, el puerto se crea y se asigna al proceso permanentemente. De forma similar, una relacin uno a uno normalmente se define de forma esttica y permanente. Cuando hay varios emisores, la asociacin de un emisor a un buzn puede realizarse dinmicamente. Se pueden usar primitivas como conectar y desconectar con este propsito. Una cuestin afn es la de la propiedad del buzn. En el caso de un puerto, normalmente pertenece y es creado por el proceso receptor. De este modo, cuando se destruye el proceso, tambin se destruir el puerto. Para el caso general de los buzones, el sistema operativo puede ofrecer un servicio de creacin de buzones. Estos buzones pueden ser considerados como propiedad del proceso creador, en cuyo caso se destruyen junto con el proceso o pueden ser considerados como propiedad del sistema operativo, en cuyo caso se necesita una orden explcita para destruir el buzn. Figura 4.1- Comunicacin Indirecta Entre Procesos

4.4.- Formato de Mensajes.

El formato de los mensajes depende de los objetivos del servicio de mensajera y de si el servicio ejecuta en un ordenador independiente o en un sistema distribuido. Para algunos sistemas operativos, los diseadores han elegido mensajes cortos y de tamao fijo para minimizar el procesamiento y el coste de almacenamiento. Si se va

Pgina 10 de 15

Colegio Universitario Francisco de Miranda Unidad Curricular:: SISTEMAS OPERATIVOS Modulo: SISTEMAS OPERATIVOS II Apuntes Recopilados por: Profesor Bernardo Gonzalez Rojas

a pasar una gran cantidad de datos, los datos pueden ponerse en un archivo y el mensaje simplemente har referencia a este archivo. Una solucin ms flexible es permitir mensajes de longitud variable. La figura 4.2 muestra un formato tpico de mensajes para sistemas operativos que permiten mensajes de longitud variable. El mensaje se divide en dos partes: una cabecera, que alberga informacin sobre el mensaje y un cuerpo, que alberga el contenido real del mensaje. La cabecera puede contener una identificacin del origen y el destino deseados, un campo de longitud y un campo de tipo para distinguir entre varios tipos de mensajes. Puede haber tambin informacin de control adicional, como un campo apuntador para poder crear una lista enlazada de mensajes; un nmero de secuencia, para guardar constancia del orden y nmero de mensajes pasados entre origen y destino; y un campo de prioridad.

Figura 4.2- Formato Tpico de Mensaje

TEMA N 5 Seccin Crtica. 5.1. Definicin.

Se denomina seccin crtica, en programacin concurrente, a la porcin de cdigo de un programa de computador en la cual se accede a un recurso compartido (estructura de datos o dispositivo) que no debe ser accedido por ms de un hilo en ejecucin. La seccin crtica por lo general termina en un tiempo determinado y el hilo, proceso o tarea slo tendr que esperar un perodo determinado de tiempo para entrar. Se necesita un mecanismo de sincronizacin en la entrada y salida de la seccin crtica para asegurar la utilizacin en exclusiva del recurso. 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.

5.2. El Problema de la Seccin Crtica.

El problema de la seccin crtica es uno de los problemas que con mayor frecuencia aparece cuando se ejecutan procesos concurrentes. 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. Los procesos concurrentes entran en conflicto cuando compiten por el uso del mismo recurso, es decir, quieren acceder a un recurso al mismo tiempo. Y la ejecucin de un proceso puede influir en el comportamiento de los procesos que compiten y el sistema operativo le asignar el recurso a uno de ellos y el otro tendr que esperar. Por lo que el proceso que quede esperando, se retrasar, se bloqueara y en el peor de los casos nunca se terminar con xito Es en estos procesos concurrentes, donde, se plantean una serie de situaciones clsicas de comunicacin y sincronizacin, entre ellos el problema de la seccin crtica.
Pgina 11 de 15

Colegio Universitario Francisco de Miranda Unidad Curricular:: SISTEMAS OPERATIVOS Modulo: SISTEMAS OPERATIVOS II Apuntes Recopilados por: Profesor Bernardo Gonzalez Rojas

Para entender un poco mejor el concepto se presenta el siguiente ejemplo: Se tiene un Sistema Operativo que debe asignar un identificador de proceso (PID) a dos procesos en un sistema multiprocesador. Cuando el SO realiza esta accin en dos procesadores de forma simultnea sin ningn tipo de control, se pueden producir errores, ya que se puede asignar el mismo PID a dos procesos distintos. Este problema se debe a que constituyen una seccin crtica que debe ejecutarse en forma atmica, es decir, de forma completa e indivisible y ningn otro proceso podr ejecutar dicho cdigo mientras el primero no haya acabado su seccin.

5.3.- Solucin a la Seccin Crtica.

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. denomina salida de la seccin crtica. Este fragmento permitir que otros procesos entren a ejecutar el cdigo de la seccin crtica. Cualquier solucin que se utilice para resolver este problema debe cumplir los tres requisitos siguientes:

Cuando un proceso sale de la seccin crtica debe indicarlo mediante otro fragmento de cdigo que se

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.

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.

5.4.- Exclusin Mutua.

La exclusin mutua (introducida en el tema n 2) la podramos definir como una operacin de control que permite la coordinacin de procesos concurrentes, y que tiene la capacidad de prohibir a los dems procesos realizar una accin cuando un proceso haya obtenido el permiso. El control de la competencia involucra al sistema operativo inevitablemente, porque es el sistema operativo el que asigna los recursos. Adems, los procesos deben ser capaces por s mismos de expresar de algn modo los requisitos de exclusin mutua, como puede ser bloqueando los recursos antes de usarlos. Hacer que se cumpla la exclusin mutua crea dos problemas de control adicionales.

Interbloqueo. Si se tienen dos procesos P1 y P2 y dos recursos crticos, R1 y R2. Supngase que cada
proceso necesita acceder a ambos recursos para llevar a cabo una parte de su funcin. En tal caso, es posible que se presente la siguiente situacin: el sistema operativo asigna R1 a P2 y R2 a P1. Cada proceso est esperando a uno de los dos recursos. Ninguno liberar el recurso que ya posee hasta que adquiera el otro y ejecute su seccin crtica. Ambos procesos estn nterbloqueados.

Inanicin. Supngase que tres procesos, P1, P2 y P3, necesitan acceder peridicamente al recurso R.
Considrese la situacin en la que P1 est en posesin del recurso y tanto P2 como P3 estn parados, esperando al recurso. Cuando P1 abandona su seccin crtica, tanto P2 como P3 deben poder acceder a R. Supngase que se le concede el acceso a P3 y que, antes de que termine su seccin crtica, P1 solicita acceso de nuevo. Si se le concede el acceso a P1 despus de que P3 termine y si P1 y P3 se conceden el acceso repetidamente el uno al otro, se puede negar definidamente a P2 el acceso al recurso.

5.4.1.-Requisitos para la exclusin mutua.

Pgina 12 de 15

Colegio Universitario Francisco de Miranda Unidad Curricular:: SISTEMAS OPERATIVOS Modulo: SISTEMAS OPERATIVOS II Apuntes Recopilados por: Profesor Bernardo Gonzalez Rojas

El uso adecuado de la concurrencia entre procesos exige la capacidad de definir secciones crticas y hacer cumplir la exclusin mutua. Esto es fundamental para cualquier esquema de proceso concurrente. Cualquier servicio o capacidad que d soporte para la exclusin mutua debe cumplir los requisitos siguientes:

i.ii.iii.iv.v.vi.-

Debe cumplirse la exclusin mutua: Solo 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 procesos. Un proceso no debe poder solicitar acceso a una seccin crtica para despus ser demorado indefinidamente; no puede permitirse el interbloqueo o la inanicin. Cuando ningn proceso est en su seccin crtica, cualquier proceso que solicite entrar en la suya debe poder hacerlo sin dilacin. No se pueden hacer suposiciones sobre la velocidad relativa de los procesos o su nmero. Un proceso permanece en su seccin crtica solo por un tiempo finito.

5.4.2.- Soluciones a la exclusin mutua.

Hay varias formas de satisfacer los requisitos de exclusin mutua: Soluciones por Software. Una manera es dejar la responsabilidad a los procesos que deseen ejecutar concurrentemente, de esta manera los procesos deben coordinarse unos con otros para cumplir la exclusin mutua sin ayuda alguna, aunque estas soluciones son propensas a errores y a una fuerte carga de proceso (Algunos ejemplos de estas son: Algoritmo de Dekker y Algoritmo de Peterson). Soluciones por Hardware. Propone el uso de instrucciones de la mquina a tal efecto, estas tienen la ventaja de reducir la sobrecarga. El tercer mtodo consiste en dar algn tipo de soporte en el sistema operativo, entre estos mtodos se encuentran los semforos, monitores, paso de mensajes, etc.

RESUMEN.
Los temas centrales de los sistemas operativos modernos son la multiprogramacin, el multiproceso y el proceso distribuido. Un punto fundamental en estos temas y en las tecnologas de diseo de sistemas operativos es la concurrencia. Cuando se ejecutan varios procesos concurrentemente, en el caso real de un sistema multiprocesador o en el caso virtual de un sistema monoprocesador multiprogramado, aparecen cuestiones de resolucin de conflictos y de cooperacin. Los procesos concurrentes pueden interactuar de varias formas. Los procesos que no tienen conocimiento unos de otros pueden competir por recursos tales como el tiempo del procesador o los dispositivos de E/S. Los procesos pueden tener conocimiento indirecto de los otros porque comparten el acceso a unos objetos comunes, tales como un bloque de memoria principal o un archivo. Los procesos pueden tener un conocimiento directo de los otros y cooperar mediante intercambio de informacin. Los puntos clave que surgen en esta interaccin son la exclusin mutua y el interbloqueo. La exclusin mutua es una condicin en la cual hay un conjunto de procesos concurrentes y slo uno puede acceder a un recurso dado o realizar una funcin dada en cada instante de tiempo. Las tcnicas de exclusin mutua pueden usarse para resolver conflictos, tales como competencia por los recursos y para sincronizar procesos de modo que puedan cooperar. Se han desarrollado varios algoritmos en software para ofrecer exclusin mutua, de los cuales el ms conocido es el algoritmo de Dekker. Las soluciones por software suelen tener un alto coste y el riesgo de errores lgicos en el programa es tambin alto. Un segundo conjunto de mtodos para soportar la exclusin mutua suponen el uso de instrucciones especiales de la mquina. Estos mtodos reducen la sobrecarga, pero son an ineficientes porque emplean espera activa.

Pgina 13 de 15

Colegio Universitario Francisco de Miranda Unidad Curricular:: SISTEMAS OPERATIVOS Modulo: SISTEMAS OPERATIVOS II Apuntes Recopilados por: Profesor Bernardo Gonzalez Rojas

Otro mtodo para dar soporte a la exclusin mutua consiste en incluir las caractersticas dentro del sistema operativo. Dos de las tcnicas ms comunes son los semforos y el paso de mensajes. Los semforos se usan para la sealizacin entre procesos y pueden emplearse fcilmente para hacer respetar una disciplina de exclusin mutua. Los mensajes son tiles para el cumplimiento de la exclusin mutua y ofrecen tambin un medio efectivo de comunicacin entre procesos.

Pgina 14 de 15

Colegio Universitario Francisco de Miranda Unidad Curricular:: SISTEMAS OPERATIVOS Modulo: SISTEMAS OPERATIVOS II Apuntes Recopilados por: Profesor Bernardo Gonzalez Rojas

BIBLIGRAFIA.
Estos apuntes fueron recopilados de Internet, entre las pginas WEB que se presentan a continuacin:

1. SISTEMAS OPERATIVOS-Segunda edicin-William Stallings-PRENTICE HALL 2. http://es.wikipedia.org/wiki/Secci%C3%B3n_cr%C3%ADtica 3. http://www.mitecnologico.com/Main/ExclusionMutuaSeccionesCriticas

Pgina 15 de 15