Asignatura

Sistema Operativo I

Capitulo #5
Tema
Sincronización entre procesos
Participante
Luis Jarlin Tejeda Encarnación

Matricula
2018 – 6747

Profesor
José Doñé
Fecha
11/02/2019
Índice
Presentación................................................................................................................. 1
Índice e Introducción ................................................................................................. 2
Comunicación entre procesos .................................................................................. 3

Mecanismos de sincronización ................................................................................ 4

Sección crítica ........................................................................................................... 5

Semáforos .................................................................................................................. 6

Monitores ................................................................................................................... 7

Regiones críticas ....................................................................................................... 8

Problemas clásicos de la comunicación entre procesos…………………….....…...8

Introducción
La comunicación entre procesos es una función básica de los sistemas
operativos que provee un mecanismo que permite a los procesos comunicarse y
sincronizarse entre sí, los mecanismos de sincronización (sección crítica,
semáforos, monitores, regiones críticas, problemas clásicos de la comunicación
entre procesos es útil para modelar procesos que compiten por el acceso
exclusivo a un número limitado de recursos, como una unidad de cinta u otro
dispositivo de E/S
Comunicación entre procesos

La comunicación entre procesos es una función básica de los sistemas

operativos que provee un mecanismo que permite a los procesos comunicarse y
sincronizarse entre sí, normalmente a través de un sistema de bajo nivel de paso
de mensajes que ofrece la red subyacente.

Las técnicas de IPC están divididas dentro de métodos para: paso de mensajes,
sincronización, memoria compartida y llamadas de procedimientos remotos
(RPC).

En un sistema, los procesos pueden ejecutarse independientemente o

cooperando entre sí. Los intérpretes de comandos son ejemplos típicos de
procesos que no precisan la cooperación de otros para realizar sus funciones.
En cambio, los procesos que sí cooperan necesitan comunicarse entre sí para
poder completar sus tareas.

La comunicación entre procesos puede estar motivada por la competencia o el

uso de recursos compartidos o porque varios procesos deban ejecutarse
sincronizadamente para completar una tarea.

Para que puedan realizarse ambos tipos de interacciones, es necesario que el

sistema operativo provea de servicios para posibilitar la comunicación entre
procesos.

El sistema operativo provee mínimamente dos primitivas, "enviar" y "recibir",

normalmente llamadas send y receive. Asimismo, debe implementarse un enlace
de comunicación entre los procesos de la comunicación (pipe). Este enlace
puede ser unidireccional o multidireccional según permita la comunicación en
uno o en varios sentidos.

La comunicación puede ser:

- Síncrona: Quien envía permanece bloqueado esperando a que llegue una

respuesta del receptor antes de realizar cualquier otro ejercicio.

- Asíncrona: Quien envía continúa con su ejecución inmediatamente después de

enviar el mensaje al receptor.
- Persistente: El receptor no tiene que estar operativo al mismo tiempo que se
realiza la comunicación, el mensaje se almacena tanto tiempo como sea
necesario para poder ser entregado (por ejemplo, un e-mail).

- Momentánea (transient): El mensaje se descarta si el receptor no está operativo

al tiempo que se realiza la comunicación. Por lo tanto no será entregado.

- Directa: Las primitivas “enviar” y “recibir” especifican el nombre del proceso con
el que se comunican.

Ejemplo: enviar(mensaje, A) envía un mensaje al proceso A. Es decir se debe

especificar cuál va a ser el proceso fuente y cuál va a ser el proceso destino.

Las operaciones básicas send y receive se definen de la siguiente manera:

send(P, mensaje); envía un mensaje al proceso P (P es el proceso destino).

receive (Q, mensaje); espera la recepción de un mensaje por parte del proceso
Q (Q es el proceso fuente).

Nota: receive puede esperar de un proceso cualquiera un mensaje, pero el send

sí debe especificar a quién va dirigido y cuál es el mensaje.

- Indirecta: Es aquella donde la comunicación está basada en una herramienta o

instrumento ya que el emisor y el perceptor están a distancia.

- Simétrica: Todos los procesos pueden enviar o recibir. También llamada

bidireccional para el caso de dos procesos.
- Asimétrica: Un proceso puede enviar, los demás procesos sólo reciben.
También llamada unidireccional. Suele usarse para hospedar servidores en
Internet.

Mecanismos de sincronización

Sección critica

Se denomina sección crítica o región crítica, en programación concurrente de

ciencias de la computación, a la porción de código de un programa de ordenador
en la que se accede a un recurso compartido (estructura de datos o dispositivo)
que no debe ser accedido por más de un proceso o 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, por ejemplo un
semáforo, monitores, el algoritmo de Dekker y Peterson, los candados.
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, pueda ser accedida por un
solo proceso a la vez.

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.

El método más común para evitar que dos procesos accedan al mismo tiempo a
un recurso es el de la exclusión mutua.

Semáforos

Los semáforos son un mecanismo de sincronización de procesos inventados por

Edsger Dijkstra en 1965. Los semáforos permiten al programador asistir al
planificador del sistema operativo en su toma de decisiones de manera que
permiten sincronizar la ejecución de dos o más procesos. A diferencia de los
cerrojos, los semáforos nos ofrecen un mecanismo de espera no ocupada.

Los semáforos son un tipo de datos que están compuestos por dos atributos:

Un contador, que siempre vale >= 0.

 Una cola de procesos inicialmente vacía.

Y disponen de dos operaciones básicas que pasamos a describir en

pseudocódigo:

down(semáforo s)

si s.contador == 0:

añade proceso a s.cola_procesos

proceso a estado bloqueado

sino:

s.contador--

Nótese que siempre que queramos forzar una transición de un proceso ha estado
bloqueado, tenemos que hacer que dicho proceso realice una operación down
sobre un semáforo cuyo contador vale cero.

up(semáforo s)

si hay procesos en s.cola_procesos:

Retira proceso de s.cola_procesos

Proceso a estado preparado

sino:

s.contador++

}
Nótese que una operación up sobre un semáforo en el que hay procesos en su
cola resulta en que se retire uno de los procesos (el primero de la cola, es decir,
el que lleva más tiempo en la cola), realizando éste la transición a estado
preparado. Es un error frecuente pensar que una operación up resulte en que el
proceso retirado de la cola pase a estado activo. Recuerde que las transiciones
de estado activo a preparado y viceversa son siempre controladas por el
planificador del sistema operativo.

Además, se disponen de un constructor y un destructor que permiten la creación

y la liberación de un semáforo.

Monitores

Un monitor es un mecanismo de alto nivel de Software para control de

concurrencia que contiene una colección de datos y los procedimientos
necesarios para realizar la asignación de un determinado recurso o grupo de
recursos compartidos por varios procesos.

Son una estructura de un lenguaje de programación similar a los semáforos en

cuanto a funcionalidad, pero son más simples de manejar y controlar, son más
estructurados, es decir un tipo de dato abstracto que encapsula datos privados
y proporciona métodos públicos (Monitor = Encapsulación). La idea de un
Monitor fue presentada primero por Dijkstra en 1971 donde hizo una propuesta
de una unidad de programación denominada “Secretary” para encapsular datos
compartidos, junto con los procedimientos para acceder a ellos. Posteriormente
por Brinch Hansen (1973) que propuso las clases compartidas ("shared class"),
una construcción análoga a la anterior. Luego esto fue mejorado por Hoare y en
1974 fue quien acuñó el nombre de “Monitor”. Posteriormente, Hansen incorpora
los monitores al lenguaje Pascal concurrente en el año 1975.

Los Monitores se caracterizan porque proveen sincronización de procesos con

exclusión mutua, es decir, que sólo se permite que un proceso puede estar
activo, en el caso que se tenga un recurso o un grupo de recursos que están
siendo compartidos por un conjunto de procesos, otorgando una solución al
problema que produce la concurrencia.

Los procesos no pueden usar directamente la representación de un tipo Monitor

por lo tanto un procedimiento definido dentro de un monitor sólo tiene acceso a
las variables declaradas localmente y a los parámetros formales. De manera
similar, sólo los procedimientos locales pueden tener acceso a las variables
locales de un Monitor.

Resumiendo las Características básicas de un Monitor son:

Es un Módulo de software.

Tipo Abstracto de Dato (TAD).

Mecanismo de alto nivel (impuesto por el compilador).

Estructura Fundamental de Sincronización.

Exclusión mutua (impuesta por la estructura del Monitor): sólo un proceso

puede acceder al Monitor en cada momento, cualquier otro que lo invoque debe
esperar.
 Variables de datos locales sólo se acceden a través de los procedimientos del
Monitor.

Un proceso entra al monitor invocando uno de sus procedimientos.

El tipo de dato "Monitor" contiene la declaración de variables compartidas cuyos

valores definen el estado de una instancia de dicho tipo. Tiene un cuerpo de
procedimientos o funciones que operan dichas variables. La representación de
un tipo Monitor no puede ser utilizada directamente por los distintos procesos,
es por eso que dentro de un Monitor sólo se puede acceder a variables locales
y a sus parámetros formales.

Regiones Críticas

Son bloques de código que al ser declarados como regiones críticas respecto de
una variable, el compilador introduce en ella los mecanismos de
sincronización necesarios para que su ejecución se realice en régimen de
exclusión mutua respecto de otras regiones críticas declaradas respecto de la
misma variable.

Las regiones críticas se definen para garantizar la actualización segura a una

variable compartida. Si una variable se declara como variables compartida

(Shared), su acceso solo se puede realizar en regiones críticas y por

tanto, todos los accesos son realizador en régimen de exclusión mutua. Fue
introducida por Brinch Hansen en 1972.

Las regiones críticas son un mecanismo seguro para comunicar procesos

concurrentes, ya que,

 Una variable que se requiera que sea accedida bajo régimen de exclusión
mutua se puede declarar como compartida (shared) y el compilador
garantiza que en ningún punto del programa se puede utilizar dicha
variable salvo dentro de las regiones críticas correspondientes.
 Cuando una región se declare como crítica, el compilador incluirá
de forma automática y transparente para el programador, el conjunto de
semáforos o mecanismos equivalentes que sean necesarios para
garantizar que se va a ejecutar en régimen de exclusión mutua

La definición de una región crítica implica la declaración de dos elementos:

 La variable compartida respecto de la que se define la zona crítica:

Var registro: shared Tipo_Registro;

 Cada bloque de código que se requiere que se ejecute en régimen de

exclusión mutua.

egion registro do Bloque_de_código;

Un proceso que trata de ejecutar una región crítica, compite con otros procesos
que también lo intentan:

 Si gana el acceso ejecuta su bloque en régimen exclusivo.

  Si pierde el acceso se encola en la lista asociada a la variable compartida
y se suspende a la espera de que la región crítica quede libre.

Regiones críticas relativas a variable compartidas diferentes se pueden ejecutar

concurrentemente.

Problemas clásicos de la comunicación entre procesos

Comunicación entre procesos

La comunicación entre procesos (comúnmente IPC, del inglés Inter-Process

Communication) es una función básica de los sistemas operativos. Los procesos
pueden comunicarse entre sí a través de compartir espacios de memoria, ya
sean variables compartidas o buffers, o a través de las herramientas provistas
por las rutinas de IPC. La IPC provee un mecanismo que permite a los procesos
comunicarse y sincronizarse entre sí, normalmente a través de un sistema de
bajo nivel de paso de mensajes que ofrece la red subyacente.

La comunicación se establece siguiendo una serie de reglas (protocolos de

comunicación). Los protocolos desarrollados para internet son los mayormente
usados: IP (capa de red), protocolo de control de transmisión (capa de
transporte) y protocolo de transferencia de archivos, protocolo de transferencia
de hipertexto (capa de aplicación).

Los procesos pueden estar ejecutándose en una o más computadoras

conectadas a una red. Las técnicas de IPC están divididas dentro de métodos
para: paso de mensajes, sincronización, memoria compartida y llamadas de
procedimientos remotos (RPC). El método de IPC usado puede variar
dependiendo del ancho de banda y latencia (el tiempo desde el pedido de
información y el comienzo del envío de la misma) de la comunicación entre
procesos, y del tipo de datos que están siendo comunicados.

El problema de la cena de los filósofos

En 1965 Dijkstra planteó y resolvió un problema de sincronización llamado el
problema de la cena de los filósofos, que se puede enunciar como sigue. Cinco
filósofos se sientan a la mesa, cada uno con un plato de espaghetti. El espaghetti
es tan escurridizo que un filósofo necesita dos tenedores para comerlo. Entre
cada dos platos hay un tenedor. En imagen se muestra la mesa.

Los filósofos se disponen a comer

La vida de un filósofo consta de periodos alternos de comer y pensar. Cuando

un filósofo tiene hambre, intenta obtener un tenedor para su mano derecha, y
otro para su mano izquierda, cogiendo uno a la vez y en cualquier orden. Si logra
obtener los dos tenedores, come un rato y después deja los tenedores y continúa
pensando. La pregunta clave es: puede el lector escribir un programa para cada
filósofo que permita comer equitativamente a los filósofos y no se interbloque

El problema de los lectores y los escritores

El problema de la cena de los filósofos es útil para modelar procesos que

compiten por el acceso exclusivo a un número limitado de recursos, como una
unidad de cinta u otro dispositivo de E/S. Otro problema famoso es el de los
lectores y escritores (Courtois et al., 1971), que modela el acceso a una base de
datos. Supóngase una base de datos, con muchos procesos que compiten por
leer y escribir en ella. Se puede permitir que varios procesos lean de la base de
datos al mismo tiempo, pero si uno de los procesos está escribiendo (es decir,
modificando) la base de datos, ninguno de los demás debería tener acceso a
ésta, ni siquiera los lectores.

En esta solución, el primer lector que obtiene el acceso a la base de datos realiza
un wait sobre el semáforo bd. Los lectores siguientes sólo incrementan un
contador, nl. Al salir los lectores, éstos decrementan el contador, y el último en
salir realiza un signal sobre el semáforo, lo que permite entrar a un escritor
bloqueado, si existe.

Una hipótesis implícita en esta solución es que los lectores tienen prioridad sobre
los escritores. Si surge un escritor mientras varios lectores se encuentran en la
base de datos el escritor debe esperar. Pero si aparecen nuevos lectores, y
queda al menos un lector accediendo a la base de datos, el escritor deberá
esperar hasta que no haya más lectores interesados en la base de datos.

Comunicación-cliente-servidor
En el modelo cliente-servidor, los procesos llamados servidores ofrecen una
serie de servicios a otros procesos que se denominan clientes. El proceso
servidor puede residir en la misma máquina que el cliente o en una distinta, en
cuyo caso la comunicación deberá realizarse a través de una red de
interconexión. Muchas aplicaciones y servicios de red, como el correo
electrónico y la transferencia de archivos, se basan en este modelo.
Conclusión

La comunicación entre procesos es una función básica de los sistemas

operativos que provee un mecanismo que permite a los procesos comunicarse y
sincronizarse entre sí, los mecanismos de sincronización (sección crítica,
semáforos, monitores, regiones críticas, problemas clásicos de la comunicación
entre procesos es útil para modelar procesos que compiten por el acceso
exclusivo a un número limitado de recursos, como una unidad de cinta u otro
dispositivo de E/S

Bibliografía

https://es.wikipedia.org/wiki/Secci%C3%B3n_cr%C3%ADtica

https://1984.lsi.us.es/wiki-ssoo/index.php/Sem%C3%A1foros

http://wiki.inf.utfsm.cl/index.php?title=Monitores

https://www.ctr.unican.es/asignaturas/procodis_3_ii/doc/procodis_2_04.pdf

http://siom-udm.blogspot.com/2016/06/v-behaviorurldefaultvmlo.html