Comunicación entre Procesos

Ing. Sandra Rodríguez Avila SISTEMAS OPERATIVOS
CAPITULO 6:
COMUNICACIÓN ENTRE
PROCESOS

ANTECEDENTES
• Los procesos cooperativos pueden afectar o verse
afectados por los demás procesos que se están
ejecutando en el sistema ya que pueden compartir
directamente un espacio lógico de direcciones
(código y datos) mediante el empleo de hilos.
• El acceso concurrente a datos compartidos pueden
dar lugar a inconsistencias en los datos
Mecanismo para que los procesos se comuniquen
para sincronizar sus acciones.
• Los problemas de comunicación entre procesos o
IPC tienen que ver:
– Como asegurarse de que 2 o más procesos no
se estorben al efectuar actividades críticas.
– La secuencia correcta cuando existen
dependencias

• Supongamos que se quiere ofrecer una
solución al problema de productor
consumidor.
• Variable entera count, para realizar un
seguimiento del número de buffers llenos. Se
inicializa en 0. Se incrementa por el productor
después de que produce un nuevo buffer y
se disminuye por el consumidor después de
que consume un búfer.

Productor
while (true) {
/* produce an item and put in
nextProduced */
while (count == BUFFER_SIZE)
; // ninguna operacion
++count;
buffer [in] = item;
in = (in + 1) % BUFFER_SIZE;
}

Consumidor
while (true) {
while (count == 0)
; // ninguna operacion
--count;
item= buffer[out];
out = (out + 1) % BUFFER_SIZE;
}

6.1. Condiciones de competencia
• La rutina del productor y del consumidor son correctas
en forma separada, pero tal vez no cuando se ejecuten
de manera concurrente. La razón es que los hilos o
procesos comparten la variable count.
• ++ count puede implementarse
register1 = count
register1 = register1 + 1
count = register1
• --count puede implementarse
register2 = count
register2 = register2 - 1
count = register2

Ejecución intercalada con “count = 5” :
• S0: productor ejecuta register1 = count {register1 =
5}
S1: productor ejecuta register1 = register1 + 1
{register1 = 6}
S2: consumidor ejecuta register2 = count {register2
= 5}
S3: consumidor ejecuta register2 = register2 - 1
{register2 = 4}
S4: productor ejecuta count = register1 {count = 6 }
S5: consumidor ejecuta count = register2 {count =
4}

Otro ejemplo: Condiciones de
competencia
• Situación en donde varios hilos acceden y
manipulan los mismos datos de manera
concurrente y donde el resultado de la
ejecución depende del orden particular en
el que tiene lugar el acceso.
• Ejemplo: spooler de impresión. En el
directorio de spooler se almacena el nombre
del archivo que desea imprimir un proceso. El
demonio o servidor de impresión revisa
periódicamente el directorio para ver si hay

archivos por imprimir, imprimirlos y
luego borrar sus nombres.
a. El directorio tiene una serie de
entradas numeradas (0,1,2,..) para
guardar el nombre del archivo.
b. Hay 2 variables compartidas: “out”,
apunta al sgte archivo por imprimir
e “in”, apunta a la sgte entrada libre.
c. Suponiendo que las entradas del 0
al 6 están vacías y las entradas del
del 7 al 9 están llenas.

d. Casi simultáneamente, los procesos A y B
deciden colocar un archivo en la cola de
impresión.
e. El proceso A lee “in” y almacena el valor
10, en una variable local llamada
sgte_ranura_libre. En ese momento
ocurre una interrupción de reloj y la CPU
conmuta al proceso B. Este proceso
también lee “in” y obtiene 10,
almacenando el nombre de su archivo en
esa entrada, actualizando “in” en 11.

f. Más tarde, el proceso A se ejecuta,
examina sgte_ranura_libre que tiene
el valor 10 y escribe el nombre del
archivo sobre esa entrada, borrando
el anterior.
g. Luego A calcula sgte_ranura_libre:
11, asignándolo a “in”.
h. Finalmente el proceso B nunca
obtendrá sus salida.
 A esto se le denomina condiciones de
competencia

6.2. Secciones críticas
• ¿Cómo evitar las condiciones de
competencia?
• Prohibir que más de un proceso lea y
escriba datos compartidos al mismo tiempo:
EXCLUSION MUTUA.
• Parte del programa en la que se accede a la
memoria compartida: REGION O SECCION
CRITICA.
• Se debe cumplir con lo sgte para evitar las
condiciones de competencia
– Exclusión mutua: Dos procesos o hilos
nunca pueden estar simultáneamente
dentro de sus regiones críticas

b. Progreso: Ningún proceso o hilo que
se ejecute fuera de su región crítica
puede bloquear a otros procesos.
c. Espera indefinida: Ningún proceso o
hilo deberá tener que esperar
indefinidamente para entrar en su
región crítica.
• No pueden suponerse nada acerca de
las velocidades o el número de las
CPU.

A. Inhabilitación de interrupciones:
• Cada proceso debe inhabilitar las inte-
rrupciones justo después de ingresar a su
región crítica y volver a habilitarlas justo
antes de salir de ella.
• Este enfoque no es el adecuado ya que
confiere al usuario la facultad de desac-
tivar las interrupciones. Podría ser que el
usuario olvide de activarlas.
6.3. Exclusión mutua con espera
activa

B. Variables de candado:
• Se emplea una variable de candado
(vc) compartida inicializada en
cero(0).
• Cuando un proceso quiere entrar en
su R.C. debe probar el candado.
Si (vc=0) entonces
vc=1
entrar R.C.
sino
esperar hasta vc=0

0: ningún proceso está en su R.C.
1: algún proceso está en su R.C.
• Presenta la misma desventaja del
directorio de spooler: un proceso lee vc =
0, antes de que asigne el valor de 1 , se
planifica otro proceso, el cual también ve
a vc=0 y le asigna 1. Luego viene el
primer proceso asignando también 1 a vc.
Por lo tanto: 2 procesos estarán en su
R.C. al mismo tiempo.

C. Alternancia estricta:
• La variable turno=0 inicialmente,
indica a quien le toca entrar en la
R.C.
• El proceso 0 observa que turno=0
y entra en su R.C.
while(True) {
while(turno!=0) /*esperar*/
region_critica();
turno=1;
region_nocritica();
}

while(True) {
while(turno!=1) /*esperar*/
region_critica();
turno=0;
region_nocritica();
}
• El proceso 1 ve que turno = 0 y se
mantiene probando para detectar que
cambie a 1(turno): Espera Activa.

• Cuando el proceso 0 sale de su
R.C. asigna 1 a turno para que el
proceso 1 entre en su R.C.
• Esta técnica no es buena cuando
un proceso es mucho más lento
que el otro: no cumple la condición
(b), un proceso es bloqueado por
otro que no está en su R.C.

D. Solución de Peterson:
• El Algoritmo de Peterson consiste en 2
procedimientos escritos en Ansi C.
• Antes de usar las variables
compartidas, cada proceso invoca a
entrar_region, con su número de
proceso, 0 o 1, como parámetro,
debiendo esperar si es necesario.
• Después de haber terminado, el
proceso invoca a salir_region, para
indicar que ya terminó.

#define FALSE 0
#define TRUE 1
#define N 2
int turno;
int interesado(N);
void entrar_region(int proceso)
{ int otro;
otro = 1- proceso;
interesado(proceso)=TRUE;
turno = proceso;
while(turno==proceso&& interesado(otro)==FALSE)
}

void salir_region(int proceso)
{
interesado(proceso)=FALSE;
}
E. La Instrucción TSL:
• Para computadoras diseñadas para
soportar multiprocesadores.
• Instrucción: Test and Set Lock o TSL
• TSL lee el contenido de la palabra de
memoria, lo coloca en un registro y luego
almacena un valor distinto de 0 en esa dir.

• Las operaciones de leer la palabra y
guardar el valor en ella son indivisibles.
• La CPU que ejecuta TSL pone un
candado en el bus de memoria para que
ninguna otra pueda acceder a la memoria
hasta que termine.
• Se emplea la variable compartida: lock.
Cuando es 0, cualquier proceso puede
asignarle 1 usando TSL y luego leer o
escribir la mem. compartida. Cuando el
proceso termina, asigna otra vez 0 a lock.

• Subrutina en lenguaje ensamblador:
entrar_region:
tsl register, lock
cmp register, #0
jne entrar_region
ret
salir_region:
move, lock,#0
ret
• El proceso debe invocar a entrar_region y
salir_region en los momentos correctos
para que el método funcione.

• La solución de Peterson y la instruc. TSL
son correctas, pero tienen el defecto de
requerir espera activa, provocando
desperdicio de tiempo de CPU y efectos
inesperados como el problema de
inversión de prioridad.
• Algunas de las sentencias básicas de
comunicación que evitan la espera activa,
son: SLEEP y WAKEUP.
• Sleep: llamada al sistema que hace que el
6.4. Dormir y despertar

invocador se bloquee o suspenda hasta
que otro proceso lo despierte.
• Wakeup: llamada que tiene como
parámetro al proceso que se debe
despertar.
El problema del productor-consumidor
• Conocido también como buffer limitado.
• Dos procesos comparten un mismo
buffer de tamaño fijo: el productor coloca
información en el buffer y el consumidor,
la saca.

• Cuando el productor quiere colocar un
nuevo elemento en el buffer y este está
lleno, debe dormirse hasta ser
despertado por el consumidor cuando
haya retirado uno o más elementos.
• Si el consumidor desea sacar un
elemento del buffer y ve que está vacío,
se duerme hasta que el productor pone
algo en el buffer y lo despierta.
• Este enfoque trae los mismos problemas
de condiciones de competencia del caso
del directorio de spooler.

• Se requiere de una variable cuenta, para ver
el número de elementos en el buffer. Si N es
el máximo de elementos que puede contener
el buffer, entonces el código del consumidor
debe verificar si cuenta = N, si es así tendrá
que dormirse, sino agregar el elemento y
aumentar cuenta. De manera similar ocurre
con el consumidor.
• Cada uno de los procesos debe verificar si
el otro está durmiendo para despertarlo.
• El algoritmo en C es:

#define N 100
int cuenta=0;
void productor(void)
{
while(True) {
produce_item();
if (cuenta==N) sleep();
ingresa_item();
cuenta=cuenta+1;
if (cuenta==1) wakeup(consumidor);
}
}

void consumidor(void)
{
while(True) {
if (cuenta==0) sleep();
remueve_item();
cuenta=cuenta-1;
if (cuenta==N-1) wakeup(productor);
consume_item()
}
}

• La condición de competencia se da cuan-
do el buffer está vacío y el consumidor
acaba de leer cuenta, y se comienza a
ejecutar el productor, colocando un
elemento en el buffer aumentando cuenta
a 1, por lo que el productor invoca un
wakeup al consumidor, pero como este no
estaba dormido se pierde la señal. El
consumidor decide dormirse porque había
leído cuenta = 0 antes. Más tarde
problablemente, el productor llenará el
buffer y se dormirá.

• Para solucionar este problema, se
debería agregar un bit de espera de
despertar, si este está encendido, se
apagará pero el proceso estará
despierto.

6.5. Semáforos
• Dijkstra propuso usar una variable llamada
semáforo : 0 - no hay señales de despertar y
algún valor positivo – 1ó + señales.
• Dos operaciones: DOWN ó P y UP.ó V
• Down aplicada a un Semáforo verifica si el el
valor es mayor que 0, si es así decrementa el
valor (gasta una señal) y continúa. Si es 0, el
proceso se duerme sin completar la operac.
Down.

• La verificación del valor, su
modificación y la acción de dormirse,
se realizan como una acción atómica
indivisible.
• Up incrementa el valor del Semáforo,
si uno o más procesos están
durmiendo en espera se le permite
cumplir su operación Down. La
operación de incrementar el semáforo
y despertar un proceso es indivisible.

Resolución del problema del P-C
usando semáforos
• Las operaciones UP y DOWN se
imple-mentan como llamadas al
sistema para que el S.O. inhabilite las
interrupcio-nes mientras prueba el
semáforo, lo actualiza y pone el
proceso a dormir, si es necesario.
• Tres semáforos: full (0), para contar el
número de entradas llenas, empty(N),

número de ranuras vacías y mutex(1), para
que el productor y el consumidor no accedan
al buffer al mismo tiempo.
• Los semáforos que son usados por uno o
más procesos para asegurar que sólo uno de
ellos pueda entrar en su R.C: Semáforos
binarios(mutex).
• Los semáforos: full y empty se necesitan
para garantizar que ciertas secuencias suce-
sos ocurran o no ocurran: sincronización.
• El algoritmo es:

#define N 100
typedef int semaforo;
semaforo mutex=1;
semaforo empty = N;
Semaforo full=0;
void productor()
{
int item;
while(True) {
produce-item(&item);
down(&empty);
down(&mutex);
ingresa-item(item);
up(&mutex);

up(&full);
}
}
void consumidor()
{
int item;
while(True) {
down(&full);
down(&mutex);
remueve-item(&item);
up(&mutex);
up(&empty);
consume-item(item);
}
}

• Si el orden de los Down del productor se
invirtiera, se podría producir una situación de
bloqueo mutuo.
• Hoare y Hansen propusieron una primitiva de
sincronización de nivel más alto llamado
monitor.
• Monitor: colección de procedimientos,
variables y estructuras de datos agrupados
en un módulo especial, que puede ser
invocados por los procesos, pero estos no
6.6. Monitores

pueden acceder directamente a las estructu-
ras internas del monitor.
• Sólo un proceso puede estar activo en un
monitor en un momento dado.
• El compilador debe implementar la exclu-
sión mutua en las entrada a monitores,
usando un semáforo binario, por ejemplo.
• Para evitar que los procesos se bloqueen
mutuamente se introdujo las variables de
condición y 2 operaciones, WAIT y SIGNAL.

• Cuando un procedimiento de monitor des-
cubre que no puede continuar, el buffer está
lleno, ejecuta WAIT con alguna variable de
condición (full), haciendo que el proceso
invocador se bloquee y el otro proceso
(consumidor) entre el monitor. Este último,
puede despertar a su compañero, ejecutando
Signal con la variable de condición que su
compañero está esperando. Para evitar la
presencia de 2 procesos activos en el
monitor, un Signal sólo puede aparecer co-

mo última instrucción de un procedimiento
de monitor.
• Las variables de condición no son
contadores.
• El programa es:
monitor ProductorConsumidor
condition full, empty;
integer count;
procedure entrar;
begin
if count=N then wait(full)
ingresar_item;

cuenta:=cuenta + 1;
if count=1 then signal(empty)
end;
procedure remover;
begin
if count=0 then wait(empty)
remover_item;
cuenta:=cuenta - 1;
if count=N-1 then signal(full)
end;
cuenta:=0;
end monitor;

procedure productor;
begin
while true do
begin
produce_item;
ProductorConsumidor.entrar
end
end;
procedure consumidor;
begin
while true do

begin
ProductorConsumidor.remover;
consume_item
end
end;
• Las desventajas es que los monitores son
un concepto de lenguajes de programación
y casi todos los compiladores carecen de
estos y además sólo se diseñaron con la
intención de resolver el problema de
exclusión mutua en una o más CPU con
una memoria común.

6.7. Transferencias de mensaje
• Emplea 2 sentencias básicas: SEND y
RECEIVE (llamadas al sistema).
• send(destino, &mensaje); envía un mensaje
a un destino dado.
• receive(origen,&mensaje); recibe un mensaje
de un origen dado.
• Si no hay une mensaje disponible, el receptor
podría bloquearse hasta que uno llegue.

Aspectos de diseño
• Para protegerse contra la pérdida de
mensajes, el emisor y receptor puede
convenir, que el receptor envíe de regreso
un acuse de recibo o confirmación. Si el
emisor no recibe el acuse en un intervalo
de tiempo, se retransmitirá el mensaje.
• La verificación de autenticidad es otro
problema.
• El copiado de mensajes de un proceso a
otro es más lento que efectuar una
operación de semáforo: rendimiento.

Problema del productorconsumidor
• Todos los mensajes tienen el mismo
tamaño y el S.O. coloca en buffers los
mensajes enviados pero aún no recibidos.
• El consumidor inicia enviando N mensajes
vacíos al productor, cada vez que el
productor tiene un elemento que entregar
al consumidor, toma un mensaje vacío y lo
devuelve lleno, permaneciendo el número
de mensajes constante.
• Si el producto trabaja más rápido, todos

los mensajes quedarían llenos, esperando
al consumidor y bloqueándose el
productor, esperando un mensaje vacío.
#define N 100
void productor(void)
{
int item;
message m;
while(True) {
produce_item(&item);
receive(consumidor,&m);
build_message(&m, item);

send(consumidor, &m);
}
}
void consumidor(void)
{
int item;
message m;
for(i=0;i<N;i++) send(productor,&m);
while(True) {
receive(productor,&m);
extract_item(&m, item);
send(productor, &m);
consume_item(item);
}
}

• La transferencia de mensajes puede
tener muchas variantes en como se
dirigen los mensajes. A) Asignar a
cada proceso una dirección única y
hacer que los mensajes se dirijan a
los procesos. B) Emplear un buzón,
lugar de almacén temporal de
mensajes.

Comunicación entre Procesos

Más contenido relacionado

La actualidad más candente (20)

Similar a Comunicación entre Procesos (20)

Último (9)

Comunicación entre Procesos