UNIVERSIDAD NACIONAL AMAZONICA DE

MADRE DE DIOS

FACULTAD DE INGINIERIA DE SISTEMAS E INFORMATICA

COMUNICACIÓN ENTRE PROCESOS

CURSO: Sistemas Operativos

DOCENTE:
ING. Jair Ferreyros Yucra

ESTUDIANTES:
Romario Diaz Holgado
Becker A. Vega Maceda
Sadam H. Sucaticona Apaza
Bellagraciela Longa Gallardo

SEMESTRE: 2019 I
 DEDICATORIA

El presente trabajo lo dedicamos principalmente a Dios, por ser el inspirador y darnos fuerza para continuar
en este proceso de obtener uno de los anhelos más deseados.
A nuestros padres, por su amor, trabajo y sacrificio en todos estos años, gracias a ustedes hemos logrado
llegar hasta aquí́ y convertirnos en lo que somos. Ha sido el orgullo y el privilegio de ser sus hijos (as), son
los mejores padres.
A nuestros hermanos (as) por estar siempre presentes, acompañándonos y por el apoyo moral, que nos
brindaron a lo largo de esta etapa de nuestras vidas.
A todas las personas que nos han apoyado y han hecho que el trabajo se realice con éxito en especial a
aquellos que nos abrieron las puertas y compartieron sus conocimientos.

AGRADECIMIENTO

2
Agradecemos a Dios por bendecirnos la vida, por guiarnos a lo largo de nuestra existencia, ser el apoyo y
fortaleza en aquellos momentos de dificultad y de debilidad.
Gracias a nuestros padres, por ser los principales promotores de nuestros sueños, por confiar y creer en
nuestras expectativas, por los consejos, valores y principios que nos han inculcado.

3
INDICE

4
 RESUMEN
El presente trabajo tratara sobre el tema de comunicación entre procesos, consiste en la descripción
y análisis de la definición, alternativas y paradigmas que necesitan los procesos para comunicarse
con otros procesos. Tiene como objetivo evitar las condiciones de carrera en las regiones críticas o
los archivos compartidos; lo que buscamos es la exclusión mutua en los procesos, porque el hecho
de compartir recursos nos trae muchos riesgos.

5
 Marco Teórico

1. Comunicación entre procesos

Con frecuencia, los procesos necesitan comunicarse con otros procesos. Analizaremos algunas
de las cuestiones relacionadas con esta comunicación entre procesos o IPC.
La primera es 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.
1.1. Condiciones de carrera
En algunos sistemas operativos, los procesos que trabajan en conjunto pueden compartir
cierto espacio de almacenamiento en el que pueden leer y escribir datos. El almacenamiento
compartido puede estar en la memoria principal (posiblemente en una estructura de datos
del kernel) o puede ser un archivo compartido; la ubicación de la memoria compartida no
cambia la naturaleza de la comunicación o los problemas que surgen. ¿Cómo evitamos las
condiciones de carrera? La clave para evitar problemas aquí y en muchas otras situaciones
en las que se involucran la memoria compartida, los archivos compartidos y todo lo demás
compartido es buscar alguna manera de prohibir que más de un proceso lea y escriba los
datos compartidos al mismo tiempo.
1.2. Regiones críticas
Cuando 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.
Necesitamos cumplir con cuatro condiciones para tener una buena solución y evitar las
condiciones de carrera:
1. No puede haber dos procesos de manera simultánea dentro de sus regiones
críticas.
2. No pueden hacerse suposiciones acerca de las velocidades o el número de CPUs.
3. Ningún proceso que se ejecute fuera de su región crítica puede bloquear otros
procesos
4. Ningún proceso tiene que esperar para siempre para entrar a su región crítica.
1.3. Exclusión mutua con espera ocupada
mientras un proceso esté ocupado actualizando la memoria compartida en su región crítica,
ningún otro proceso puede entrar a su región crítica y ocasionar problemas.
1.3.1. 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

6
 después de salir. Con las interrupciones deshabilitadas, no pueden ocurrir
interrupciones de reloj. Después de todo, la CPU sólo se conmuta de un
proceso a otro como resultado de una interrupción del reloj o de otro tipo, y
con las interrupciones desactivadas la CPU no se conmutará a otro proceso

1.3.2. Variables de candado

Considere tener una sola variable compartida (de candado), que al principio es 0.
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.
1.3.3. La instrucción TSL
Algunas computadoras tienen instrucciones financieras TSL REGISTRO,
CANDADO. La CPU que ejecuta los TSL bloquea el bus de memoria para que otras
CPU puedan ingresar a la memoria.
Y la otra alternativa es XCHG; que intercambia contenido con 2 ubicaciones en
forma atómica.
1.4. 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

1.5. Semáforos
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. Tiene dos operaciones,
Down y up (generalizaciones de sleep y wakeup, respectivamente). 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.
1.6. Mutexes
Es una versión simplicada del semáforo. Administra exclusión mutua para cierto recurso
compartido o pieza de código. Puede estar en dos estados.
Abierto (Desbloqueado): es cuando la variable es 0
Cerrado (bloqueado): son todos los valores excepto el 0
Son buenos para permitir y bloquear acceso a la región critica. Mutexes en Pthreads
proporciona varias funciones para la sincronización de hilos (procesos).

7
1.7. Monitores
Es una colección de procedimientos, variables y estructuras de datos que se agrupan en un
tipo especial de módulo o paquete. Los procesos pueden llamar a los procedimientos en un
monitor cada vez que lo desean, pero no pueden acceder de manera directa a las estructuras
de datos internas del monitor desde procedimientos declarados fuera de éste.
Pasaje(transmisión)
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. (TANENBAUM, 2009, pág. 117).

8
 CONCLUSION

La comunicación entre procesos ha ido mejorando cada día con el tiempo de forma positiva,
permitiendo poder evitar situaciones en donde dos o más procesos estén leyendo o escribiendo
algunos datos compartidos a la vez. Para esto se ha ido creando diversas formas de evitar las
condiciones de carrera con algoritmos que han ido evolucionando y mejorando constantemente.

La comunicación entre procesos nace de la necesidad de querer que los procesos no actúen de
forma independiente, sino que estén constantemente compartiendo datos convertidos en
información.

9
10