Está en la página 1de 14

COMUNICACIÓN ENTRE

PROCESOS
Jesús Dagoberto Cepeda Hernández 1656924
COMUNICACIÓN ENTRE PROCESOS
Hay tres cuestiones aquí, la primera se alude a lo anterior: cómo un
proceso puede pasar información a otro.
La segunda está relacionada con hacer que dos o más procesos no se
interpongan entre sí; por ejemplo, dos procesos en un sistema de
reservaciones de una aerolínea, cada uno de los cuales trata de
obtener el último asiento en un avión para un cliente distinto.
La tercera trata acerca de obtener la secuencia apropiada cuando hay
dependencias presentes: si el proceso A produce datos y el proceso B
los imprime, B tiene que esperar hasta que A haya producido algunos
datos antes de empezar a imprimir.
Condiciones de carrera Regiones críticas
• En algunos sistemas operativos, los • ¿Cómo evitamos las condiciones de
procesos que trabajan en conjunto carrera?
pueden compartir cierto espacio de • La clave para evitar problemas aquí y en
almacenamiento en el que pueden leer y muchas otras situaciones en las que se
escribir datos. involucran la memoria compartida, los
• Ejemplo: un spooler de impresión. archivos compartidos y todo lo demás
Cuando un proceso desea imprimir un compartido es buscar alguna manera de
archivo, introduce el nombre del archivo prohibir que más de un proceso lea y
en un directorio de spooler especial. Otro escriba los datos compartidos al mismo
proceso, el demonio de impresión, tiempo.
comprueba en forma periódica si hay
archivos que deban imprimirse y si los
hay, los imprime y luego elimina sus
nombres del directorio.
Regiones críticas
Esa parte del programa en la que se accede a la memoria compartida se conoce como
región crítica o sección crítica. Si pudiéramos ordenar las cosas de manera que dos
procesos nunca estuvieran en sus regiones críticas al mismo tiempo, podríamos evitar las
carreras. Aunque este requerimiento evita las condiciones de carrera, no es suficiente para
que los procesos en paralelo cooperen de la manera correcta y eficiente al utilizar datos
compartidos. Necesitamos cumplir con cuatro condiciones para tener una buena solución:
1. No puede haber dos procesos de manera simultánea dentro de sus regiones críticas.
2. 2. No pueden hacerse suposiciones acerca de las velocidades o el número de CPUs.
3. 3. Ningún proceso que se ejecute fuera de su región crítica puede bloquear otros
procesos.
4. 4. Ningún proceso tiene que esperar para siempre para entrar a su región crítica.
Deshabilitando interrupciones
En un sistema con un solo procesador, la solución más simple es hacer
que cada proceso deshabilite todas las interrupciones justo después de
entrar a su región crítica y las rehabilite justo después de salir. Con las
interrupciones deshabilitadas, no pueden ocurrir interrupciones de
reloj.
Variables de candado
• Cuando un proceso desea entrar a su región crítica primero evalúa el
candado. Si este candado es 0, el proceso lo fija en 1 y entra a la
región crítica. Si el candado ya es 1 sólo espera hasta que el candado
se haga 0. Por ende, un 0 significa que ningún proceso está en su
región crítica y un 1 significa que algún proceso está en su región
crítica.
Alteración estricta
• Esta solución requiere que los dos procesos se alternen de manera
estricta al entrar en sus regiones críticas (por ejemplo, al poner
archivos en la cola de impresión). Ninguno podría poner dos archivos
en la cola al mismo tiempo. Aunque este algoritmo evita todas las
condiciones de carrera, en realidad no es un candidato serio como
solución.
Solución de Peterson
• En 1981, G.L. Peterson descubrió una manera mucho más simple de
lograr la exclusión mutua. El algoritmo de Peterson consiste de dos
procedimientos escritos en ANSI C.
Antes de utilizar las variables compartidas (es decir, antes de entrar a
su región crítica), cada proceso llama a entrar_region con su propio
número de proceso (0 o 1) como parámetro. Esta llamada hará que
espere, si es necesario, hasta que sea seguro entrar. Una vez que haya
terminado con las variables compartidas, el proceso llama a salir región
para indicar que ha terminado y permitir que los demás procesos
entren, si así lo desea.
DORMIR Y DESPERTAR
Este método no sólo desperdicia tiempo de la CPU, sino que también
puede tener efectos inesperados. Considere una computadora con dos
procesos: H con prioridad alta y L con prioridad baja. Las reglas de
planificación son tales que H se ejecuta cada vez que se encuentra en el
estado listo. En cierto momento, con L en su región crítica, H cambia al
estado listo para ejecutarse (por ejemplo, cuando se completa una
operación de E/S). Entonces H empieza la espera ocupada, pero como L
nunca se planifica mientras H está en ejecución, L nunca tiene la
oportunidad de salir de su región crítica, por lo que H itera en forma
indefinida. A esta situación se le conoce algunas veces como el
problema de inversión de prioridades
El problema del producto-consumidor
Como ejemplo de la forma en que se pueden utilizar estas primitivas,
consideremos el problema del productor-consumidor.
Dos procesos comparten un búfer común, de tamaño fijo. Uno de ellos
(el productor) coloca información en el búfer y el otro (el consumidor)
la saca (también es posible generalizar el problema de manera que
haya m productores y n consumidores, pero sólo consideraremos el
caso en el que hay un productor y un consumidor, ya que esta
suposición simplifica las soluciones).
SEMAFOROS
Un semáforo podría tener el valor 0, indicando que no se guardaron
señales de despertar o algún valor positivo si estuvieran pendientes
una o más señales de despertar.
Dijkstra propuso que se tuvieran dos operaciones, down y up.
La operación down en un semáforo comprueba si el valor es mayor que
0. De ser así, disminuye el valor (es decir, utiliza una señal de despertar
almacenada) y sólo continúa. Si el valor es 0, el proceso se pone a
dormir sin completar la operación down por el momento.
MUTEX Mutexes en Pthreads
• Un mutex es una variable que puede estar Pthreads proporciona varias funciones que se
en uno de dos estados: abierto
(desbloqueado) o cerrado (bloqueado). En pueden utilizar para sincronizar los hilos. El
consecuencia, se requiere sólo 1 bit para mecanismo básico utiliza una variable mutex,
representarla, pero en la práctica se utiliza
con frecuencia un entero, en donde 0 cerrada o abierta, para resguardar cada región
indica que está abierto y todos los demás crítica. Un hilo que desea entrar a una región
valores indican que está cerrado. Se crítica primero trata de cerrar el mutex asociado.
utilizan dos procedimientos con los
mutexes. Cuando un hilo (o proceso) Si el mutex está abierto, el hilo puede entrar de
necesita acceso a una región crítica, llama inmediato y el bloqueo se establece en forma
a mutex_lock. Si el mutex está
actualmente abierto (lo que significa que automática, evitando que otros hilos entren; si el
la región crítica está disponible), la mutex ya se encuentra cerrado, el hilo que hizo la
llamada tiene éxito y entonces el hilo
llamador puede entrar a la región crítica. llamada se bloquea hasta que el mutex esté
Por otro lado, si el mutex ya se abierto
PASAJE (transmisión) de mensajes
• Este método de comunicación entre procesos utiliza dos primitivas (send y
receive) que, al igual que los semáforos y a diferencia de los monitores, son
llamadas al sistema en vez de construcciones del lenguaje.
Como tales, se pueden colocar con facilidad en procedimientos de biblioteca,
como
send(destino, &mensaje);
y receive(origen, &mensaje);
• La primera llamada envía un mensaje a un destino especificado y la
segunda recibe un mensaje de un origen especificado (o de CUALQUIERA,
si al receptor no le importa). Si no hay un mensaje disponible, el receptor
se puede bloquear hasta que llegue uno. De manera alternativa, puede
regresar de inmediato con un código de error
BARRERAS
Nuestro último mecanismo de
sincronización está destinado a
los grupos de procesos, en vez
de las situaciones de tipo
productor-consumidor de dos
procesos. Algunas aplicaciones
se dividen en fases y tienen la
regla de que ningún proceso
puede continuar a la siguiente
fase sino hasta que todos los
procesos estén listos para
hacerlo. Para lograr este
comportamiento, se coloca una
barrera al final de cada fase.
Cuando un proceso llega a la
barrera, se bloquea hasta que
todos los procesos han llegado a
ella.