Tema 3. Paso de Tema 3. Paso de mensajesmensajes
I.T. Informática de Sistemas
Curso 2001-2002
2ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Bibliografían Principles of Concurrent and Distributed
Programmingn M. Ben-Ari. Prentice Hall, 1990n Capítulo 7
n Sistemas Operativosn A. Silberschatz, P. Galvin. Addison Wesley
Longman, 1999n Capítulo 4.6
3ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Sistemas de paso de mensajesn Los semáforos, monitores, regiones
críticas, etc. son todas herramientas que se basan en la existencia de memoria compartida.
n El modelo de memoria compartida es difícil o imposible de trasladar a un sistema distribuido, en el que no existe físicamente compartición de memoria.
4ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Sistemas de paso de mensajes (2)
n Como alternativa al modelo de memoria compartida, se define el modelo de paso de mensajes:n los procesos no comparten memoria
(variables, objetos, etc.)n la comunicación se hace mediante
operaciones explícitas de envío y recepción
5ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Modelo general
Emisor ReceptorCANAL
mensaje
enviar recibir
6ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Ventajas del paso de mensajesn Válido para cualquier arquitectura de
computadoresn sistemas distribuidosn arquitecturas paralelas sin memoria compartidan también en sistemas de memoria compartida
n No existe el problema universal del acceso en exclusión mutua a datos compartidos.
7ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Memoria Compartida OR/XORPaso de Mensajes
n Ambos esquemas de comunicación NO son mutuamente exclusivos
n Podrían utilizarse simultáneamente dentro de un mismo SO, o incluso dentro de un mismo proceso
8ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Cuestiones básicas de la comunicaciónn Sincronización entre emisor y receptor
n Comunicación síncrona/asíncrona
n Identificación en el proceso de comunicaciónn Comunicación directa/indirectan Comunicación simétrica/asimétrica
n Características del canaln Capacidad, uni/bidireccional, etc...
9ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Comunicación síncrona o asíncrona
n Com. síncrona. El intercambio de un mensaje es una operación atómica que exige la participación simultánea del emisor y el receptor (rendezvous).
n Com. asíncrona. El emisor puede enviar un mensaje sin bloquearse; el receptor lo puede recoger más tarde.
10ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Repercusiones de la comunicación asíncrona
n El emisor puede enviar varios mensajes:n necesidad de disponer de búferes
n ¿Cuándo sabe el emisor que su mensaje ha llegado/se ha atendido?n conveniencia de operaciones de “acuse de
recibo” o de respuesta(send à receive à send_reply àreceive_reply)
11ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Llamadas bloqueantes / no bloqueantes
n Las operaciones de envío y recepción pueden estar definidas como bloqueantes o no bloqueantes
n Un envío/recepción con bloqueo es un ejemplo de comunicación síncrona
n Un envió/recepción sin bloqueo es un ejemplo de comunicación asíncrona
12ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Identificación
n Comunicación directan Cada proceso que desea comunicarse debe
nombrar explícitamente el destinatario o el remitente de la comunicaciónn enviar(P, mensaje)
n Enviar un mensaje al proceso P
n recibir(Q, mensaje)n Recibir un mensaje del proceso Q
13ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Identificación
n Comunicación indirectan Con la comunicación indirecta, los
mensajes se envían a, y se reciben de, buzones (también llamados puertos)n enviar(A, mensaje)
n Enviar un mensaje al buzón A
n recibir(A, mensaje)n Recibir un mensaje del buzón A
14ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Comunicación indirecta
n P1, P2, P3 comparten un buzón A. P1 envía un mensaje a A, y P2 y P3 ejecutan cada uno un recibir de A. ¿Qué proceso recibirá el mensaje que envió P1?
n Un buzón puede ser propiedad de un proceso o del sistema
15ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Identificación
n Comunicación simétrican Los procesos tanto receptor como emisor
necesitan nombrar al otro para comunicarse
n Comunicación asimétrican Sólo el emisor nombra al destinatario
16ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Ejemplos
n Comunicación directa simétrican Enviar(P,mensaje)/Recibir(Q,mensaje)
n Comunicación directa asimétrican Enviar(P,mensaje)/Recibir(mensaje)n Enviar(P,mensaje)/Recibir(id,mensaje)
17ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Características del canal (1)
n Punto a punto, multipunto
n Unidireccional, bidireccional
n Capacidad del canaln ceron limitadan infinita (teórico)
18ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Características del canal(2)
n Mensajes:n Tamaño fijo o variablen Canales con tipo o sin tipon Paso por copia o por referencia (¡cuidado!)
19ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Características del canal de comunicación: ejemplos
n Comunicación directan Se establece automáticamenten Un canal se asocia a exactamente dos
procesosn Entre cada par de procesos sólo existe un
canaln El enlace puede ser unidireccional, pero
suele ser bidireccional
20ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Características del canal de comunicación: ejemplosn Comunicación indirecta
n Se establece un canal entre un par de procesos sólo si tienen un buzón compartido
n Un canal puede estar asociado a más de dos procesos
n Entre cada par de procesos en comunicación puede haber varios enlaces distintos, cada un de los cuales corresponderá a un buzón
n Los enlaces pueden ser unidireccionales o bidireccionales
21ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Elección de mensajesn Supongamos un proceso servidor que es
capaz de recibir peticiones de varios canales.
n Queremos que el proceso quede bloqueado hasta que alguna petición llegue.n ¿cómo lo resolvemos?n solución: espera selectiva (select), espera no
determinista (ALT de occam), “select” de UNIX, etc.
22ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Condiciones de errorn 1 máquina => los mensajes se implementan
(generalmente) en memoria compartidan Fallo => falla todo el sistema
n Entornos distribuidos => procesos residen en diferentes máquinasn Los mensajes se transfieren por líneas de comunicaciónn La probabilidad de que ocurra un error durante la
comunicación y el procesamiento es mucho mayor que en un entorno de una sola máquina
n El fallo de un enlace no causa necesariamente el fallo de todo el sistema
23ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Condiciones de errorn Cuando ocurre un fallo en un sistema, sea
centralizado o distribuido, el sistema debe intentar recuperarse del error
n Algunas situaciones de error:n El emisor o el receptor podría terminar antes de
que se procese un mensajen P espera un mensaje de Q (proceso terminado)n P envía un mensaje a Q (proceso terminado)
24ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Condiciones de errorn Mensajes perdidos
n Fallo hardware o de la línea de comunicación
n Tres métodos para enfrentar este suceso en función de quien asume la responsabilidad de detectar el fallo:n SOn Emisorn SO/Emisor
25ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Condiciones de error
n No siempre es necesario detectar los mensajes perdidos => protocolos de red que garantizan la confiabilidad
n ¿Cómo detectar la pérdida de mensajes?n El método de detección más común consiste
en emplear tiempos límite o plazos
26ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Condiciones de error
n Mensajes alteradosn es común el uso de códigos de verificación
de errores (paridad, etc...)
27ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Invocación remota: el modelo de Adan Características
n Esquema de comunicación síncrono (rendezvous), sin búferes
n Esquema de comunicación asimétrico (el emisor necesita conocer la identidad del destino pero no ocurre lo mismo con receptor)
n Durante la cita, el flujo de datos es bidireccional
28ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Llamada a Procedimiento Remoto (RPC)
n Motivación:n Aprovechar el paralelismo potencial
existente en un sistema distribuido
n ¿ Cómo ?n Posibilitando que un proceso llame a un
procedimiento que se ejecutará en otro procesador
29ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Invocación remota vs RPC’sn La invocación remota es una construcción de
los lenguajes concurrentes
n La RPC es una técnica para permitir llamadas a procedimientos en entornos distribuidos
n La palabra “remoto” tiene significados diferentes en ambos casos:n Invocación remota: “otro proceso”n RPC: “otro procesador”
30ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Invocación remota vs RPC’sn El punto de entrada llamado durante una invocación
remota sólo se ejecutará cuando su propietario lo permita
n El procedimiento llamado durante una RPC se puede ejecutar de inmediato
n El punto de entrada llamado durante una invocación remota es ejecutado por el proceso propietario de dicho punto de entrada;
n El procedimiento llamado durante una RPC se ejecuta en nombre del proceso llamador por un proceso subordinado creado por el entorno de ejecución
31ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Invocación remota vs RPC’sn El proceso llamador y el punto de entrada
llamado durante una invocación remota se pueden ejecutar en el mismo procesador. Esto no tiene sentido en el caso de una RPC
32ProgramaciónConcurrente© José Miguel Santos Espino – Alexis Quesada Arencibia
Dificultades implementación RPC’sn Paso de parámetros
n Valorn Referencia: ¡más complejo!
n Los formatos internos de los datos pueden ser muy diferentes en redes de máquinas heterogéneas
n Requerirían conversaciones complejas y un considerable trabajo adicional
n Fallos en la transmisión