PDF de programación - Comunicación mediante mensajes

ditdit

UPM

Comunicación 

mediante mensajes

Juan Antonio de la Puente

DIT/UPM

Transparencias basadas en el capítulo 9 del libro de A. Burns y A. Wellings Real­Time Systems and Programming Languages, 3ª edición (2001)

Objetivos

u Comprender los problemas relacionados con la 

comunicación entre procesos basada en el intercambio de 
mensajes

u Estudiar la forma de realizar este tipo de comunicación en 

Ada y C/POSIX

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 2

Comunicación mediante mensajes 

u Las tareas se pueden comunicar y sincronizar mediante 

mensajes

u Esta forma de comunicación no necesita memoria común
u Se usan los mismos mecanismos para la sincronización y 

la comunicación

u Hay tres aspectos de interés:

– Sincronización
– Identificación del proceso emisor y receptor
– Estructura de los mensajes

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 3

Diagramas de secuencia de mensajes

A

B

send

mensaje

receive

u Representan la interacción entre 

procesos mediante el 
intercambio de mensajes
u El tiempo va hacia abajo

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 4

Sincronización en el envío de mensajes

u El proceso receptor siempre espera si el mensaje no ha 

llegado todavía.

u Para el proceso emisor hay tres modelos básicos:
– Comunicación asíncrona: el emisor continúa su ejecución
– Comunicación síncrona (cita): el emisor espera a que el receptor 

reciba el mensaje

– Invocación remota (cita extendida): el emisor espera a que el 

receptor reciba el mensaje, y la respuesta de éste

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 5

Comunicación asíncrona

A

B

send

mensaje

receive

u Hace falta usar un tampón

– capacidad potencialmente 

ilimitada

– si es limitado puede bloquearse 

el emisor

u El emisor puede requerir un 

reconocimiento
– diseño complicado

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 6

Comunicación síncrona

A

B

send

suspendido

mensaje

receive

u No hace falta tampón
u Se puede construir a partir de la 

comunicación asíncrona:

A B
send(m); receive(m);
receive(ack); send(ack);

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 7

Invocación remota

A

B

u No hace falta tampón
u Se puede construir a partir de la 

comunicación síncrona:

send

suspendido

mensaje

receive

reply

A B
s_send(m); s_receive(m);
preparar r
s_receive(r); s_send(r);

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 8

Identificación del emisor y el receptor

u Identificación directa o indirecta

» directa: el emisor identifica explíctamente el receptor

  send mensaje to proceso

» indirecta: se utiliza un intermediario (buzón, canal, tubería, etc.)

  send mensaje to buzón

u Simetría

» Comunicación simétrica: el emisor identifica el receptor, y viceversa

  send mensaje to proceso (buzón)
receive mensaje from proceso (buzón)

» Comunicación asimétrica: el receptor acepta mensajes de cualquier 

emisor o buzón

» Este tipo de comunicación es adecuado para realizar servidores

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 9

Estructura de los mensajes

u Deberían poderse enviar objetos de cualquier tipo
u Es difícil de conseguir en un entorno distribuido

– diferentes representaciones de tipos de datos
– problemas con punteros

u Se puede hacer con bibliotecas estándar de 

“aplanamiento” de tipos
– convierten cualquier tipo en una secuencia de octetos

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 10

Índice

u Comunicación mediante mensajes
u Comunicación entre tareas en Ada

– cita extendida
– espera selectiva
– llamada selectiva

u Comunicación entre threads en C/POSIX

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 11

Comunicación entre tareas en Ada

u Se basa en un mecanismo de cita extendida

– invocación remota directa y asimétrica

u Una tarea puede recibir mensajes a través de entradas 

declaradas en su especificación
– la especificación de una entrada es similar a la de un procedimiento
– Ejemplo:

task type Screen is
entry Put (Char : Character; X,Y : Coordinate);
end Screen;

Display : Screen;

– otras tareas pueden llamar a la entrada

Display.Put('A',50,24);

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 12

Entradas

u Puede haber entradas homónimas, siempre que tengan distintos 

parámetros
– También puede haber entradas homónimas con subprogramas

u Se pueden definir familias de entradas con un discriminante discreto

  type Channel is range 0..7;
task Multiplexor is
entry Get(Channel)(Data : Input_Data);
end Multiplexor;

u Puede haber entradas privadas

task type Telephone_Operator is
entry Directory_Enquiry (Person : in Name;
Phone : out Number);
entry Report_Fault (Phone : in Number);
private
entry Allocate_Repair_Worker (Id : out Worker_Id);
end Telephone_Operator;

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 13

Llamada

u Para llamar a una entrada hay que identificar la tarea receptora 

(no hay cláusula use)

Display.Put('A',50,24);
Multiplexor.Get(3)(X);
Operator.Directory_Enquiry("Juan Pérez", No_de_Juan);

u Se puede renombrar una entrada como un procedimiento

procedure Enquiry (Person : in Name; Phone : out Number)
renames Operator.Directory_Enquiry;

u Si se llama a una entrada de una tarea que no está activa, se eleva la 

excepción Tasking_Error

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 14

Aceptación (1)

u Para que se lleve a cabo una cita, la tarea receptora debe 

aceptar la llamada al punto de entrada correspondiente

accept Put(Char : Character; X,Y : Coordinate) do
-- escribir Char en la posición (X,Y)
end Put;

accept Get(3)(Data : Input_Data) do
-- leer Data del canal 3
end Get;

– Debe haber al menos un accept por cada entrada (puede haber 

más)

– El índice identifica cuál de las entradas de una familia se acepta

» debe haber un accept para cada miembro de la familia

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 15

Aceptación (2)

u Una instrucción accept se puede poner en cualquier lugar 

del cuerpo de una tarea
– en particular, se puede poner dentro de otro accept (siempre que 

sea de distinta entrada)

– no se pude poner en un procedimiento

u El cuerpo del accept especifica las acciones que se 

ejecutan cuando se acepta la llamada
– La secuencia de instrucciones puede incluir manejadores de 

excepciones

u Si el cuerpo es nulo, se puede usar una forma 

simplificada:

accept E;

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 16

Diagrama de procesos

T2.E

T1

E

T2

accept E

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 17

Ejecución de una cita extendida

u Las dos tareas deben estar listas para realizar la comunicación.

– la que llega primero a la cita se suspende hasta que la otra ejecuta la 

instrucción complementaria (llamada o aceptación)

u Cuando las dos están listas

– se pasan los parámetros de entrada a la tarea llamada
– se ejecuta el cuerpo del accept
– se copian los parámetros de salida al cliente

u A continuación, las dos continúan su ejecución asíncronamente.
u Si varias tareas invocan el mismo punto de entrada de otra tarea, se 

colocan en una cola

u Una tarea que espera para poder realizar una cita permanece 

suspendida durante el tiempo que dura la espera

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 18

Sincronización (1)

A

B

B.E(X,Y)

X

Y

accept E(X : in T; Y : out T) do
Y := X;
end E;

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 19

Sincronización (2)

A

B

accept E(X : in T; Y : out T)

B.E(X,Y)

X

Y

do
Y := X;
end E;

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 20

Excepciones en citas

u Puede elevarse una excepción cuando se está ejecutando 

una cita
– si hay un manejador en el cuerpo del accept, la cita termina 

normalmente

– si la excepción no se maneja dentro del accept,

» la cita termina inmediatamente
» la excepción se vuelve a elevar en las dos tareas 

(puede ser anónima en la que llama)

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 21

Ejemplo

accept Directory_Enquiry (Person : in Name;

Phone : out Number) do
Data_Base.Lookup (Person, Phone_Record);
Phone := Phone_Record.Phone_Number;
exception
when Data_Base.Not_Found => Phone := No_Phone;
end Directory_Enquiry;

– Si durante la ejecución de Lookup se produce la excepción 

Not_Found, se recupera el error dando un valor nulo al parámetro 
Phone y se termina la cita

– El cliente y el servidor continúan normalmente
– Si se produce cualquier otra excepción, la cita termina y la 

excepción se propaga en los dos, inmediatamente después de la 
llamada en el cliente, y de la aceptación en el servidor

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 22

Espera selectiva

u A menudo no es posible prever en qué orden se van a 

invocar las distintas entradas de una tarea

u Esto ocurre cuando sobre todo en las tareas servidoras

– Un servidor es una tarea que acepta llamadas a una o más 

entradas, y ejecuta un servicio para cada una de ellas

– un cliente es una tarea que solicita servicios llamando a las 

entradas de un servidor

– Los servidores no saben en qué orden les van a llamar los clientes
» deben estar dispuestos a aceptar cualquier llamada cuando no están 

ocupados

u Es necesario que una tarea pueda esperar 

simultáneamente llamadas en varias entradas

STRL ­ Mensajes ­ 20/03/07

©2001­2002 Juan Antonio de la Puente

 23

Aceptación selectiva en Ada

u Es una estructuraa de control que permite la espera 

selectiva en varias alternativas