P. 1
Unidad 5-Coordinacion y Sincronizacion de Procesos - Copia

Unidad 5-Coordinacion y Sincronizacion de Procesos - Copia

|Views: 3.453|Likes:
Publicado porJulio Yu Wu

More info:

Published by: Julio Yu Wu on Jul 19, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

07/04/2013

pdf

text

original

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. Introducción.
Los conceptos claves en los que se basan los sistemas operativos modernos son el de proceso y el de hilo. Los temas fundamentales de diseño de sistemas operativos están relacionados con la gestión de procesos:

 Multiprogramación: Es la gestión de varios procesos dentro de un sistema monoprocesador. La mayoría de
los computadores personales, estaciones de trabajo, sistemas monoprocesador y sistemas operativos actuales de estas máquinas, tales como Windows 7, OS/2 y el Sistema 7 de Macintosh dan soporte a la multiprogramación. Los sistemas operativos como UNIX y LINUX incorporan multiprogramación de sistemas monoprocesador compartidos.

 Multiproceso: Es la gestión 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. Más recientemente, el multiproceso ha empezado a ganarse la aprobación de los servidores y las estaciones de trabajo. Windows NT es un ejemplo de un sistema operativo diseñado para estos entornos.

 Proceso distribuido: Es la gestión de varios procesos que ejecutan en sistemas de computadores múltiples
y remotas.

1.2. Definición.
La concurrencia es el punto clave de los tres campos anteriores y fundamentales para el di-seño de sistemas operativos. La concurrencia comprende un gran número de cuestiones de diseño, incluyendo la comunicación entre procesos, compartición y competencia por los recursos, sincronización de la ejecución de varios procesos y asignación 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 multiprogramación se creó para permitir que el tiempo de procesador de la
máquina fuese compartido dinámicamente entre varios trabajos o aplicaciones activas.

 Aplicaciones estructuradas: Como ampliación de los principios del diseño modular y la programación
estructurada, algunas aplicaciones pueden implementarse eficazmente como un conjunto de procesos concurrentes.

 • Estructura del sistema operativo: Las mismas ventajas de estructuración son aplicables a los
programadores de sistemas y se ha comprobado que algunos sistemas operativos están implementados como un conjunto de procesos.

1.3. Ejemplo Concurrencia.
Para ilustrar estos conceptos y comparar los métodos presentados en este tema, se usan dos problemas clásicos de concurrencia. En primer lugar, se presentará el problema del productor/consumidor como ejemplo típico. 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
Página 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 ejecución simultánea (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 ejecución intercalada produce beneficios importantes en la eficiencia del procesamiento y en la estructuración de los programas. En un sistema con varios procesadores, no solo es posible intercalar los procesos, sino también superponerlos (figura 1.2).

Figura 1.1 - Intercalación

Figura 1.2 – Intercalación y Superposición

A primera vista, podría parecer que la intercalación y la superposición representan formas de ejecución muy diferentes y que introducen problemas distintos. De hecho, ambas técnicas 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 multiprogramación parten del hecho de que la velocidad relativa de ejecución 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 políticas de planificación. Así surgen las siguientes dificultades:

i.- La compartición 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 crítico. En el siguiente apartado se ofrece un ejemplo de este problema.

ii.- Para el sistema operativo resulta difícil 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 difícil localizar un error de programación porque los resultados no son normalmente reproducibles.

Todas las dificultades anteriores se presentan también en los sistemas multiprocesador, ya que también en ellos es impredecible la velocidad relativa de ejecución de los procesos. Un sistema multiprocesador debe solucionar, además, 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 gestión y diseño 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 función de la planificación.  Memoria: La mayoría 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 físicos de cada proceso contra injerencias no
intencionadas de otros procesos. Esto supone emplear técnicas relativas a la memoria, archivos y dispositivos de E/S, que se estudian en los capítulos correspondientes.

Página 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
ejecución con respecto a otros procesos concurrentes. Para comprender cómo 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. Básicamente, es posible describir esta situación como sigue. Dos o más procesos necesitan acceder a un recurso durante el curso de su ejecución. Cada proceso no es consciente de la existencia de los otros y no se ve afectado por su ejecución. 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 información entre los procesos en competencia. Sin embargo, la ejecución 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.-Cooperación entre procesos por compartición
El caso de cooperación por compartición comprende a los procesos que interactúan 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.- Cooperación entre procesos por comunicación
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 compartición. En caso de competencia, los procesos están compartiendo recursos sin tener conocimiento de la existencia de otros procesos. En el segundo caso, están 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 comunicación, en cambio, los distintos procesos participan en una labor común que une a todos los procesos. La comunicación es una manera de sincronizar o coordinar las distintas actividades. Normalmente, la comunicación puede caracterizarse por estar formada por mensajes de algún tipo. Las primitivas para enviar y recibir mensajes pueden venir dadas como parte del lenguaje de programación o por el núcleo del sistema operativo.

TEMA N° 2 SEMAFOROS. 2.1. Introducción.
Se vuelven a considerar ahora los mecanismos que se usan en el sistema operativo y en los lenguajes de programación para dar soporte a la concurrencia. En este tema se trataran los semáforos. En las dos siguientes secciones se discutirá sobre los monitores y el paso de mensajes. El primer gran avance en la resolución de los problemas de procesos concurrentes llegó en 1965, con el tratado de Dijkstra sobre la cooperación entre procesos secuénciales, Dijkstra estaba interesado en el diseño de un sistema operativo como un conjunto de procesos secuénciales cooperantes y en el desarrollo de mecanismos eficientes y fiables para dar soporte a la cooperación. Los procesos de usuario podrán utilizar estos mecanismos en tanto que el procesador y el sistema operativo los hagan disponibles. El principio fundamental es el siguiente: Dos o más procesos pueden cooperar por medio de simples señales, de forma que se pueda obligar a detenerse a un proceso en una posición determinada hasta que reciba una señal
Página 3 de 15

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

específica. Cualquier requisito complicado de coordinación puede satisfacerse por medio de la estructura de señales adecuada. Para la señalización, se usan variables especiales llamados semáforos. Para transmitir una señal por el Semáforo s, los procesos ejecutan la primitiva signal(s). Para recibir una señal del semáforo s, los procesos ejecutan la primitiva wait(s); si la señal correspondiente aún no se ha transmitido, el proceso es suspendido hasta que tenga lugar la transmisión.

2.2. Funcionamiento de los Semáforos.
Para lograr el efecto deseado, se pueden contemplar los semáforos como variables que tienen un valor entero sobre el que se definen las tres operaciones siguientes:

i.- Un semáforo puede inicializarse con un valor no negativo. ii.- La operación wait decrementa el valor del semáforo. Si el valor se hace negativo, el proceso que ejecuta el
wait se bloquea.

iii.-

La operación signal incrementa el valor del semáforo. Si el valor no es positivo, se des-bloquea a un proceso bloqueado por una operación wait.

Aparte de estas tres operaciones, no hay forma de examinar o manipular los semáforos.

2.3. Implementación de Semáforos.
La figura 2.1 propone una definición más formal de las primitivas de los semáforos. Las primitivas wait y signal se suponen atómicas, es decir, no pueden ser interrumpidas y cada rutina puede considerarse como un paso indivisible. En la figura 2.2 se define una versión más limitada, conocida como semáforo binario. Un semáforo binario solo puede tomar los valores 0 y 1. En principio, los semáforos binarios son más sencillos de implementar y puede demostrarse que tienen la misma potencia de expresión que los semáforos generales.

Figura 2.1 – Una Definición Primitivas Semáforos Figura 2.2 – Una Definición Primitivas Semáforos Binarios

Página 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 semáforos como en los semáforos binarios se emplea una cola para mantener los procesos esperando en el semáforo. La definición no dicta el orden en el que se quitan los procesos de dicha cola. La política más equitativa es la FIFO: el proceso que ha estado bloqueado durante más tiempo se libera de la cola. La única exigencia estricta es que un proceso no debe quedar retenido en la cola de un semáforo indefinidamente porque otros procesos tengan preferencia. _

2.4.- Exclusión Mutua
La figura 2.3 muestra una solución sencilla al problema de la exclusión mutua por medio de un semáforo s. Sean n procesos, identificados por el array P(s). En cada proceso, se ejecuta un wait(s) justo antes de su sección crítica. 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 sección critica; puesto que s ya no es positivo, no se permitirá a ningún otro proceso entrar en su sección critica. program exclusion_mutua; El semáforo se inicializa a 1. De este modo, el const n = …; (* número de procesos *); var s: semáforo primer proceso que ejecute un wait podrá (:= 1); entrar inmediatamente en la sección crítica, procedure P (i: entero); poniendo el valor de s a 0. Cualquier otro begin proceso que intente entras en la sección repeat critica La encontrará ocupada y se bloqueara, poniendo el valor de s a -1. Cualquier número wait(s) de procesos puede intentar entrar; cada uno <sección critica>; de estos intentos infructuosos origina un signal(s); nuevo decremento del valor de s. <resto> forever El semáforo se inicializa a 1. De este modo, el end; primer proceso que ejecute un wait podrá entrar inmediatamente en la sección crítica, begin (* programa principal *) poniendo el valor de s a 0. Cualquier otro parbegin proceso que intente entras en la sección P(1); critica La encontrará ocupada y se bloqueara, P(2); poniendo el valor de s a -1. Cualquier número … 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 – Exclusión Mutua por Medio de Semáforos Cuando el proceso que entró al principio en su sección critica salga, se incrementará s y se eliminará uno de los procesos bloqueados (si los hay) de la cola de procesos asociada al semáforo, poniéndolo en el estado listo. Cuando sea planificado de nuevo por el sistema operativo, podrá entrar en la sección critica.

Página 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 exclusión mutua por medio de semáforos se puede ilustrar con el modelo del iglú (figura 2.4). Además 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 sección critica. En otro caso, entra en hibernación en el congelador. Figura 2.4 – Un Iglu Semáforo Esto vacía el interior del iglú, permitiendo que otros procesos entren. Cuando un proceso ha completado su sección crítica, 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 más de un proceso pueda entrar en su sección crítica en un instante. Este requisito se satisface simplemente inicializando el semáforo con un valor específico. De este modo, en cualquier instante, el valor de s.contador puede interpretarse como sigue:

 s.contador _ 0: s.contador es el número de procesos que pueden ejecutar un wait(s) sin bloquearse (si no se
ejecuta ningún signal(s) mientras tanto).

 s.contador <0: el valor absoluto de s.contador es el número de procesos bloqueados en s.cola.
TEMA N° 3 MONITORES. 3.1. Introducción.
Los semáforos son una herramienta básica, pero potente y flexible, para hacer cumplir la exclusión mutua y coordinar procesos. Sin embargo, como se propone en la figura 4.14, puede resultar difícil construir un programa correcto por medio de semáforos. La dificultad está en que las operaciones wait y signal deben distribuirse por todo el programa y no es fácil advertir el efecto global de estas operaciones sobre los semáforos a los que afectan. Los monitores son estructuras de un lenguaje de programación que ofrecen una funcionalidad equivalente a la de los semáforos y que son más fáciles de controlar. La estructura de monitor se ha implementado en varios lenguajes de programación, incluido Pascal Concurrente, Pascal-plus, Modula-2 y Modula-3. Más 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 versión de Hoare para después examinar una leve modificación.

3.2.- Monitores con Señales.
Un monitor es un módulo de software que consta de uno o más procedimientos, una secuencia de inicialización y unos datos locales. Las características básicas de un monitor son las siguientes:

i.- Las variables de datos locales están solo accesibles para los procedimientos del monitor y no para
procedimientos externos.
Página 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 características recuerdan a las de los objetos del software orientado a objetos. En realidad, un sistema operativo o lenguaje de programación orientado a objetos puede implementar un monitor fácilmente como un objeto con características especiales. Si se cumple la norma de un proceso cada vez, el monitor puede ofrecer un servicio de exclusión 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 situándola dentro de un monitor. Si los datos del monitor representan a algún recurso, el monitor ofrecerá un servicio en exclusión mutua en el acceso a este recurso. Para que resulten útiles en el proceso concurrente los monitores deben incluir herramientas de sincronización. Por ejemplo, supóngase que un proceso llama a un monitor y, mientras está en el monitor, debe suspenderse hasta que se cumpla alguna condición. Hace falta un servicio para que el proceso no solo esté suspendido, sino que libere el monitor y otro proceso pueda entrar. Más tarde, cuando se cumpla la condición y el monitor está de nuevo disponible, el proceso puede reanudarse y tiene que permitírsele volver a entrar en el monitor en el punto de la suspensión. Un monitor proporciona sincronización por medio de las variables de condición que se incluyen dentro del monitor y que son accesibles sólo desde dentro. Hay dos funciones para operar con las variables de condición: wait(c): Suspende la ejecución del proceso llamado bajo la condición c. El monitor está ahora disponible para ser usado por otro proceso. signal(c): Reanuda la ejecución de algún proceso suspendido después de un wait bajo la misma condición. Si hay varios procesos, elige uno de ellos; si no hay ninguno, no hace nada.

Página 7 de 15

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

Nótese que las operaciones de monitor wait/signal son diferentes de las de los semáforos. Si un proceso de un monitor ejecuta un signal y no hay tareas esperando en la variable de condición, 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 sólo un proceso pueda estar en el monitor en cada instante. Otros procesos que intenten entrar al monitor se añadirán 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 condición x ejecutando wait(x); entonces se sitúa en una cola de procesos que esperan volver a entrar al monitor cuando la condición cambie. Si un proceso que está ejecutando en el monitor detecta un cambio en una variable de condición x, ejecuta signal(x), lo que avisa a la cola de condición correspondiente de que la condición ha cambiado. Figura 3.1 – Estructura de un Monitor La figura 4.24 muestra una solución con monitores. El módulo monitor, buffer_acotado, controla el buffer empleado para almacenar y retirar caracteres. El monitor incluye dos variables de condición: no_lleno es cierta cuando hay sitio para añadir al menos un carácter al buffer y no_vacío es cierta cuando hay al menos un carácter en el buffer. Un productor sólo puede añadir caracteres al buffer por medio del procedimiento

TEMA N° 4 PASO DE MENSAJES. 4.1. Introducción.
Cuando los procesos interactúan unos con otros, se deben satisfacer dos requisitos básicos: la sincronización y la comunicación. Los procesos tienen que sincronizarse para cumplir la exclusión mutua; los procesos cooperantes pueden necesitar intercambiar información. Un método 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 sección, se ofrecerá una introducción general que discute las características típicas 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)
Página 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 mínimo de operaciones necesario para que los procesos puedan dedicarse al paso de mensajes. Un proceso envía información en forma de un mensaje a otro proceso designado como destino. Un proceso recibe información ejecutando la primitiva receive, que indica el proceso emisor (origen) y el mensaje.

4.2.- Sincronización.
La comunicación de un mensaje entre dos procesos implica cierto nivel de sincronización entre ambos. El receptor no puede recibir un mensaje hasta que sea enviado por otro proceso. Además, hace falta especificar qué le sucede a un proceso después de ejecutar una primitiva sena o receive. Considérese 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. Análogamente, cuando un proceso ejecuta una primitiva receive, hay dos posibilidades:

i.-

Si previamente se ha enviado algún mensaje, éste es recibido y continúa la ejecución. mensaje o (b) el proceso continúa ejecutando, abandonando el intento de recepción.

ii.- Si no hay ningún 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 sólo una o dos combinaciones:

 Envío bloqueante, recepción bloqueante: Tanto el emisor como el receptor se bloquean hasta que se
entrega el mensaje; esta técnica se conoce como rendezvous. Esta combinación permite una fuerte sincronización entre procesos.

 Envío no bloqueante, recepción bloqueante: Aunque el emisor puede continuar, el receptor se bloquea
hasta que llega el mensaje solicitado. Esta es, probablemente, la combinación más útil. Permite que un proceso envíe uno o más mensajes a varios destinos tan rápido como sea posible. Un proceso que debe recibir un mensaje antes de poder hacer alguna función ú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.

 Envío no bloqueante, recepción no bloqueante: Nadie debe esperar.
El send no bloqueante es la forma más natural para muchas tareas de programación concurrente. Por ejemplo, si se usa para solicitar una operación de salida, tal como una impresión, 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 situación 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. Además, 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 recepción de un mensaje. Para la primitiva receive, la versión bloqueante parece ser la más natural para muchas tareas de programación concurrente. En general, un proceso que solicita un mensaje necesitará la información 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 solución es que si un mensaje se envía después de que un proceso haya ejecutado el correspondiente receive, el mensaje se perderá. Otro método 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 más de un origen en una primitiva receive. Esta última técnica resulta útil si un proceso espera mensajes de más 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 mayoría de las implementaciones permiten a los procesos receptores indicar el origen del mensaje que se va a recibir.

Página 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 categorías: direccionamiento directo e indirecto. Con el direccionamiento directo, la primitiva sena incluye una identificación específica del proceso destino. La primitiva receive se puede gestionar de dos formas. Una posibilidad requiere que el proceso designe explícitamente 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 impresión de cualquier otro proceso. Para tales aplicaciones, una técnica más efectiva consiste en usar direccionamiento implícito. En este caso, el parámetro origen de la primitiva receive tendrá un valor de retomo cuando se haya realizado la operación de recepción. El otro enfoque es el direccionamiento indirecto. En este caso, los mensajes no se envían 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 envía mensajes al buzón apropiado y el otro los coge del buzón. Una ventaja del direccionamiento indirecto es que se desacopla a emisor y receptor, permitiendo una mayor flexibilidad en el uso de los mensajes. La relación entre emisores y receptores puede ser uno a uno, de muchos a uno, de uno a muchos o de muchos a muchos. Una relación uno a uno permite que se establezca un enlace privado de comunicaciones entre dos procesos, lo que aísla su interacción de injerencias erróneas de otros procesos. Una relación 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 buzón se denomina puerto (figura 4.1). Una relación uno a muchos permite un emisor y muchos receptores; es útil para aplicaciones en las que un mensaje o alguna información se difunda a un conjunto de procesos. La asociación de procesos a buzones puede ser estática o dinámica. Los puertos suelen estar asociados estáticamente con algún proceso en particular, es decir, el puerto se crea y se asigna al proceso permanentemente. De forma similar, una relación uno a uno normalmente se define de forma estática y permanente. Cuando hay varios emisores, la asociación de un emisor a un buzón puede realizarse dinámicamente. Se pueden usar primitivas como conectar y desconectar con este propósito. Una cuestión afín es la de la propiedad del buzón. En el caso de un puerto, normalmente pertenece y es creado por el proceso receptor. De este modo, cuando se destruye el proceso, también se destruirá el puerto. Para el caso general de los buzones, el sistema operativo puede ofrecer un servicio de creación 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 explícita para destruir el buzón. Figura 4.1- Comunicación Indirecta Entre Procesos

4.4.- Formato de Mensajes.
El formato de los mensajes depende de los objetivos del servicio de mensajería y de si el servicio ejecuta en un ordenador independiente o en un sistema distribuido. Para algunos sistemas operativos, los diseñadores han elegido mensajes cortos y de tamaño fijo para minimizar el procesamiento y el coste de almacenamiento. Si se va

Página 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 solución más flexible es permitir mensajes de longitud variable. La figura 4.2 muestra un formato típico de mensajes para sistemas operativos que permiten mensajes de longitud variable. El mensaje se divide en dos partes: una cabecera, que alberga información sobre el mensaje y un cuerpo, que alberga el contenido real del mensaje. La cabecera puede contener una identificación del origen y el destino deseados, un campo de longitud y un campo de tipo para distinguir entre varios tipos de mensajes. Puede haber también información de control adicional, como un campo apuntador para poder crear una lista enlazada de mensajes; un número de secuencia, para guardar constancia del orden y número de mensajes pasados entre origen y destino; y un campo de prioridad.

Figura 4.2- Formato Típico de Mensaje

TEMA N° 5 Sección Crítica. 5.1. Definición.
Se denomina sección crítica, en programación concurrente, a la porción de código 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 más de un hilo en ejecución. La sección crítica por lo general termina en un tiempo determinado y el hilo, proceso o tarea sólo tendrá que esperar un período determinado de tiempo para entrar. Se necesita un mecanismo de sincronización en la entrada y salida de la sección crítica para asegurar la utilización en exclusiva del recurso. El acceso concurrente se controla teniendo cuidado de las variables que se modifican dentro y fuera de la sección crítica. La sección crítica se utiliza por lo general cuando un programa multihilo actualiza múltiples variables sin un hilo de ejecución separado que lleve los cambios conflictivos a esos datos. Una situación similar, la sección crítica 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 Sección Crítica.
El problema de la sección crítica es uno de los problemas que con mayor frecuencia aparece cuando se ejecutan procesos concurrentes. La manera en cómo se implementan las secciones puede variar dependiendo de los diversos sistemas operativos. Sólo un proceso puede estar en una sección crítica 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 ejecución 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 clásicas de comunicación y sincronización, entre ellos el problema de la sección crítica.
Página 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 acción en dos procesadores de forma simultánea sin ningún 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 sección crítica que debe ejecutarse en forma atómica, es decir, de forma completa e indivisible y ningún otro proceso podrá ejecutar dicho código mientras el primero no haya acabado su sección.

5.3.- Solución a la Sección Crítica.
Para resolver el problema de la sección crítica es necesario utilizar algún mecanismo de sincronización que permita a los procesos cooperar entre ellos sin problemas. Este mecanismo debe proteger el código de la sección crítica y su funcionamiento básico es el siguiente:  Cada proceso debe solicitar permiso para entrar en la sección crítica, mediante algún fragmento de código que se denomina de forma genérica entrada en la sección crítica. denomina salida de la sección crítica. Este fragmento permitirá que otros procesos entren a ejecutar el código de la sección crítica. Cualquier solución que se utilice para resolver este problema debe cumplir los tres requisitos siguientes:

 Cuando un proceso sale de la sección crítica debe indicarlo mediante otro fragmento de código que se

 Exclusión mutua: Si un proceso está ejecutando código de la sección crítica, ningún otro proceso lo podrá
hacer.

 Progreso: Si ningún proceso está ejecutando dentro de la sección crítica, la decisión de qué proceso entra
en la sección se hará sobre los procesos que desean entrar.

 Espera acotada: Debe haber un límite en el número de veces que se permite que los demás procesos entren
a ejecutar código de la sección crítica después de que un proceso haya efectuado una solicitud de entrada y antes de que se conceda la suya.

5.4.- Exclusión Mutua.
La exclusión mutua (introducida en el tema n° 2) la podríamos definir como una operación de control que permite la coordinación de procesos concurrentes, y que tiene la capacidad de prohibir a los demás procesos realizar una acción 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. Además, los procesos deben ser capaces por sí mismos de expresar de algún modo los requisitos de exclusión mutua, como puede ser bloqueando los recursos antes de usarlos. Hacer que se cumpla la exclusión mutua crea dos problemas de control adicionales.

 Interbloqueo. Si se tienen dos procesos P1 y P2 y dos recursos críticos, R1 y R2. Supóngase que cada
proceso necesita acceder a ambos recursos para llevar a cabo una parte de su función. En tal caso, es posible que se presente la siguiente situación: 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 sección crítica. Ambos procesos están ínterbloqueados.

 Inanición. Supóngase que tres procesos, P1, P2 y P3, necesitan acceder periódicamente al recurso R.
Considérese la situación en la que P1 está en posesión del recurso y tanto P2 como P3 están parados, esperando al recurso. Cuando P1 abandona su sección crítica, tanto P2 como P3 deben poder acceder a R. Supóngase que se le concede el acceso a P3 y que, antes de que termine su sección crítica, P1 solicita acceso de nuevo. Si se le concede el acceso a P1 después 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 exclusión mutua.
Página 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 críticas y hacer cumplir la exclusión mutua. Esto es fundamental para cualquier esquema de proceso concurrente. Cualquier servicio o capacidad que dé soporte para la exclusión mutua debe cumplir los requisitos siguientes:

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

Debe cumplirse la exclusión mutua: Solo un proceso, de entre todos los que poseen secciones críticas 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 sección no crítica debe hacerlo sin estorbar a los otros procesos. Un proceso no debe poder solicitar acceso a una sección crítica para después ser demorado indefinidamente; no puede permitirse el interbloqueo o la inanición. Cuando ningún proceso está en su sección crítica, cualquier proceso que solicite entrar en la suya debe poder hacerlo sin dilación. No se pueden hacer suposiciones sobre la velocidad relativa de los procesos o su número. Un proceso permanece en su sección crítica solo por un tiempo finito.

5.4.2.- Soluciones a la exclusión mutua.
Hay varias formas de satisfacer los requisitos de exclusión 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 exclusión 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 máquina a tal efecto, estas tienen la ventaja de reducir la sobrecarga. El tercer método consiste en dar algún tipo de soporte en el sistema operativo, entre estos métodos se encuentran los semáforos, monitores, paso de mensajes, etc.

RESUMEN.
Los temas centrales de los sistemas operativos modernos son la multiprogramación, el multiproceso y el proceso distribuido. Un punto fundamental en estos temas y en las tecnologías de diseño 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 resolución de conflictos y de cooperación. 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 información. Los puntos clave que surgen en esta interacción son la exclusión mutua y el interbloqueo. La exclusión mutua es una condición en la cual hay un conjunto de procesos concurrentes y sólo uno puede acceder a un recurso dado o realizar una función dada en cada instante de tiempo. Las técnicas de exclusión 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 exclusión mutua, de los cuales el más conocido es el algoritmo de Dekker. Las soluciones por software suelen tener un alto coste y el riesgo de errores lógicos en el programa es también alto. Un segundo conjunto de métodos para soportar la exclusión mutua suponen el uso de instrucciones especiales de la máquina. Estos métodos reducen la sobrecarga, pero son aún ineficientes porque emplean espera activa.

Página 13 de 15

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

Otro método para dar soporte a la exclusión mutua consiste en incluir las características dentro del sistema operativo. Dos de las técnicas más comunes son los semáforos y el paso de mensajes. Los semáforos se usan para la señalización entre procesos y pueden emplearse fácilmente para hacer respetar una disciplina de exclusión mutua. Los mensajes son útiles para el cumplimiento de la exclusión mutua y ofrecen también un medio efectivo de comunicación entre procesos.

Página 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 páginas WEB que se presentan a continuación:

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

Página 15 de 15

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->