PDF de programación - Capitulo 9. Sincronización y comunicación basadas en mensajes

CAPÍTULO 9. Sincronización y comunicación basada en mensajes.

9

Sincronización y comunicación basadas en mensajes............................................................. 2
Sincronización de procesos............................................................................................ 2
Nombrado de procesos y estructuraj de mensajes........................................................... 4
Estructura del mensaje ........................................................................................... 5
Espera selectiva ............................................................................................................. 5
Llamamadas a metodos remotos .................................................................................... 6

9.2.1

9.1
9.2

9.4
9.5



Rafael Álvarez García
Última revisión 061207
[email protected]


Nota importante:

Este documento no pretende reemplazar al material propuesto por la UNED para la
asignatura Sistemas en Tiempo Real.



1


Cualquier sugerencia, comentario o corrección sobre este documento, envíelo a
[email protected] para poder realizar los cambios necesarios.



9 Sincronización y comunicación basadas en mensajes


La alternativa a la sincronización y comunicación mediante variables compartidas se basa en el
paso de mensajes. La aproximación esta tipificada por el uso de una única construcción, tanto para
la sincronización como para la comunicación. En esta amplia categoría existe, sin embargo, una
gran variedad de modelos de lenguaje. Esta variedad en la semántica del paso de mensajes surge, y
esta dominada, por tres temas:

(1) El modelo de sincronización.

(2) El método de nombrado de los procesos.

(3) La estructura del mensaje.

Inicialmente, se consideraran cada uno de estos tres temas. Después, se discutirán los modelos de
paso de mensajes de varios lenguajes, incluyendo Ada y occam2, con respecto al modelo POSIX para
tiempo real. Java no soporta explícitamente un modelo de paso de mensajes, aunque se podrían producir
clases que implementaran ese modelo. Sin embargo, como no se introducen nuevas características del
lenguaje, no se hablara de Java en este capítulo.

9.1

Sincronización de procesos

En todos los sistemas basados en mensajes, existe un tipo de sincronización implícita: un proceso
receptor no puede obtener un mensaje antes de que dicho mensaje haya sido enviado. Aunque esto es
bastante obvio, habrá que compararlo con el uso de una variable compartida; en este caso, un proceso
receptor puede leer una variable y no saber si ha sido escrita por el proceso emisor. Si un proceso
ejecuta una recepción de mensaje incondicional cuando no existe ningún mensaje disponible, entonces
permanecerá suspendido hasta que llegue el mensaje.

De la semántica de la operación «envía» surgen las variaciones en el modelo de sincronización de

procesos, que pueden ser clasificadas como sigue:

• Asíncrona (o sin espera): el emisor continua inmediatamente, independientemente de si se ha

recibido o no el mensaje.

• Sincronía: el emisor continua solo cuando se ha recibido el mensaje.



2

•

Invocación remota: el emisor continua únicamente cuando se ha devuelto una respuesta
desde el receptor. El «envío» de la invocación remota modela el paradigma de comunicación
petición – respuesta.

Para apreciar la diferencia entre estas aproximaciones, considérese .la siguiente analogía.
Echar una carta al correo es un envío asíncrono: una vez que la carta ha sido depositada en el
buzón, el remitente continua con su vida, y solo mediante una contestación a dicha carta el
remitente podrá saber si, en realidad, llego la primera carta. Desde el punto de vista del receptor,
una carta solo puede informar al lector sobre un suceso ya pasado; no dice nada sobre la situación
actual del remitente. (Todo el mundo ha recibido postales de vacaciones de gente que había
regresado a su trabajo hacia ya dos semanas.)

El teléfono es una analogía adecuada para la comunicación síncrona. Aquí, el emisor espera que
se realice el contacto y se verifique la identidad del receptor antes de enviar el mensaje. Si el receptor
puede responder inmediatamente (es decir, durante la misma llamada), la sincronización es una
invocación remota. Dado que el emisor y el receptor «se reúnen» en una comunicación sincronizada, esta
suele conocerse como rendezvous, cita, encuentro o reunión. La forma de invocación remota se
conoce
arbitrarias
antes de que se envíe la respuesta (es decir, durante la cita).

extendida, ya que

computaciones

se pueden

realizar

como

cita

Claramente, hay una reilación entre estas formas de envío. Dos eventos asíncronos pue-
den construir una relación síncrona si siempre se envía (y se espera) un mensaje de reconoci-
miento.

PI P2

envia_asinc (mensaje) espera (mensaje)

espera (reconocimiento) envía_asinc (reconocimiento)

Además, se pueden utilizar dos comunicaciones sincronas para construir una invocación

remota:

PI P2

envia_asinc (mensaje) espera (mensaje)

espera (respuesta) ....

construye respuesta

....

envía_sinc (respuesta)



Como se puede utilizar un envío asíncrono para construir los otros dos se podría plantear que
este modelo proporciona la mayor flexibilidad. y que debiera ser uno de los que adoptaran los
lenguajes y los sistemas operativos. Sin embargo, utilizando ese modelo existen varias desventajas:



3

(1) Se necesitan potencialmente infinitos búferes para almacenar los mensajes que no se han

leído todavía (quizás porque el receptor hay a terminado).


(2) Como la comunicación asíncrona esta anticuada, la mayoría de los envíos se programan

para esperar un reconocimiento (es decir, una comunicación síncrona).


(3) Se necesitan mas comunicaciones con el modelo asíncrono, por lo que los programas son

mas complejos.


(4) Es mas difícil probar la corrección del sistema completo.

Hay que señalar que, si se desea la comunicación asíncrona en un lenguaje de paso de mensajes
sincronizado, los procesos buffer se pueden construir fácilmente. Sin embargo, la implementación
de un proceso tiene un coste, y, por consiguiente, tener muchos procesos buffer podría tener un
efecto perjudicial sobre las prestaciones globales del sistema.



9.2 Nombrado de procesos y estructura de mensajes



El nombrado de procesos implica dos subtemas: dirección frente a indirección, y simetría. En

un esquema de nombrado directo, el emisor de un mensaje nombra explícitamente al receptor:


envía <mensaje> a <nombre-proceso>



Con un esquema de nombrado indirecto, el emisor nombra a alguna entidad intermedia

(conocida como canal, buzón, enlace o tubería):


envía <mensaje> a <buzón>

Hay que señalar que incluso con un buzón, el mensaje que pasa puede ser aun síncrono (es
decir, el emisor esperara hasta que el mensaje sea leído). El nombrado directo tiene la ventaja de la
simplicidad, mientras que el nombrado indirecto facilita la descomposición del software; un buzón
se puede ver como una interfaz entre distintas partes del programa.


Un esquema de nombrado es simétrico si tanto el emisor como el receptor se pueden nombrar

entre si (directa o indirectamente):


envía <mensaje> a <nombre-proceso>
espera <mensaje> de <nombre-proceso>
envía <mensaje> a <buzón>
espera <mensaje> de <buzón>

Es asimétrico si el receptor no nombra una fuente especifica pero acepta mensajes de cualquier

proceso (o buzón):


espera <mensaje>

El nombrado asimétrico se adapta al paradigma cliente servidor, donde los procesos «servidor»
proporcionan servicios como respuesta a los mensajes de cualquier numero de procesos «cliente».



4

Por tanto, una implementación, debe ser capaz de mantener una cola de procesos esperando por el
servidor.

Si el nombrado es indirecto, entonces hay que considerar otros temas. El intermediario deberla tener:

• Una estructura «muchos a uno» (es decir, cualquier numero de procesos podría escribir en el,
pero solo un proceso podría leer de el); esto todavía concuerda con el paradigma cliente
servidor.

• Una estructura «muchos a muchos» (es decir, muchos clientes y muchos servidores).

• Una estructura «uno a uno» (es decir, un cliente y un servidor). Hay que señalar que con esta

estructura no es necesario que el sistema de soporte de ejecución mantenga colas.

• Una estructura «uno a muchos»: esta situación es útil cuando un proceso desea enviar una

solicitud a un grupo de procesos trabajadores y no le importa que proceso sirve la solicitud.

Estructura del mensaje

9.2.1

De forma ideal, un lenguaje debiera permitir que cualquier objeto de datos de cualquier tipo definido
(predefinido o del usuario) sea transmitido en un mensaje. Alcanzar este ideal es difícil,
particularmente si los objetos de datos tienen representaciones diferentes en el emisor y en el receptor, y
mas difícil aún si la representación incluye punteros (Herlihy y Liskov, 1982). Por estas dificultades,
algunos lenguajes (como occam1) han restringido el contenido de los mensajes a objetos fijos no
estructurados de tipo definido por el sistema. Los lenguajes mas moderaos han eliminado e