¿Memoria compartida o mensajes?. - UAM-I

> M emoria compartida o mensajes?
E liz a b e t h P ¶e r e z Co r t ¶e s y Gr a c ie la R o m ¶a n A lo n s o
U A M-Iz t a p a la p a D e p t o . d e In g . E l¶ e c t r ic a A r e a d e Co m p u t a c i¶o n y S is t e m a s
g r a c , p e c e @xa n u m .u a m .m x
Re s u me n
En e ste a rt¶ ³c ulo se
de lo s de c o munic a c
utiliz a do s e n la c o
da s: la me mo ria c o
je s.
pre se nta n y
i¶o n y sinc ro
nstruc c i¶o n
mpa rtida y
c o mpa ra n do s de lo s mo niz a c i¶o n de pro c e so s m¶a s
de a plic a c io ne s distribuie l inte rc a mbio de me nsa -
1. Introducci¶
on
Las proliferaci¶on de las redes de computadoras en
todos los ¶
ambitos productivos pone a disposici¶
on
del constructor de sistemas de c¶omputo una nueva infraestructura compuesta por varias unidades de
c¶
omputo aut¶onomas que cuentan con un enlace de
comunicaci¶
on. Las unidades de c¶omputo pueden estar en un mismo gabinete (Figura 1.1) y en ese caso
se habla de una m¶aquina paralela. Tambi¶en es posible que se encuentren en un ¶area geogr¶a¯ca relativamente reducida, como un edi¯cio, unidas por una red
local (Figura 1.2). O bien es posible que se encuentren distribuidas en una zona mas amplia, por ejemplo a nivel del planeta, y en ese caso se tendr¶
a una
red de cobertura amplia (Figura 1.3).
F ig ura 1 . A rq uite c tura s distribuida s.
² Para interconectar aplicaciones existentes, como por ejemplo una base de datos con un servicio de correo electr¶
onico. Esta conexi¶on permitir¶
a, por ejemplo, enviar un mensaje a un Jefe de almac¶en cuando la cantidad de un producto disminuya de una cota.
² Para compartir los recursos y aumentar su disponibilidad.
Para obtener bene¯cio de estas infraestructuras aparecen las aplicaciones distribuidas. Una aplicaci¶
on
distribuida est¶a formada por un conjunto de procesos1 que se ejecutan posiblemente en unidades de
c¶
omputo diferentes y aut¶onomas y que se comunican y se sincronizan para realizar una tarea com¶
un.
² Para permitir la evoluci¶
on de las aplicaciones en
funci¶
on de las necesidades.
La construcci¶
on de una aplicaci¶
on distribuida tiene similitudes con la elaboraci¶
on del plan de actividades de un grupo de personas que deben realizar un trabajo. En ambos casos, es necesario tomar decisiones acerca de qui¶en har¶
a qu¶e e identi¯car las dependencias entre las diferentes tareas para ordenarlas de modo que se obtenga un mejor
resultado.
Las aplicaciones distribuidas se construyen por diversas razones [Cou94]:
² Por la naturaleza distribuida de la aplicaci¶
on,
como en el caso de la educaci¶on a distancia.
Una decisi¶
on de gran importancia es la de seleccionar
el medio de comunicaci¶
on y sincronizaci¶
on del que va
a disponer el grupo de individuos para comunicarse.
Imaginemos el caso en el que las personas est¶an cada
una en su o¯cina y cuentan con alguno de los medios
de comunicaci¶
on siguientes:
² Para reducir costos, como en el caso de una empresa en donde los perif¶ericos se comparten v¶³a
red evitando la instalaci¶on de todos los dispositivos en todas las unidades de c¶omputo.
² Para mejorar los rendimientos, como en el caso
de aplicaciones de c¶alculo intensivo.
1U
n p r oceso es u n p r ogr am a en ejecu ci¶
on
27
28
1. Un mensajero que les lleva y les trae mensajes.
2. Un micr¶
ofono para cada qui¶en y un altavoz de
uso com¶
un.
3. Localizadores para algunos y tel¶efonos para
otros.
4. Tel¶efonos para todo mundo.
ContactoS 38, 27{34 (2000)
y posteriormente, se describe una capa de env¶³o y recepci¶
on de mensajes utilizando esos conceptos. Esta secci¶
on concluye con un ejemplo de programaci¶
on distribuida utilizando el modelo de intercambio de mensajes.
2.1 Conceptos de base
La comunicaci¶
on por env¶³o y recepci¶
on de mensajes requiere del conocimiento de los siguientes
conceptos:
5. Un pizarr¶
on en el que todos pueden leer y
escribir.
Un enlace es la conexi¶
on que permite a un proceso comunicarse con otro. Con respecto al enlace es
importante conocer:
Dependiendo de los medios de comunicaci¶on de los
que se disponga, la manera en la que se llevar¶
a a
cabo el trabajo es distinta. Por ejemplo, si se opta por el medio 3, la comunicaci¶on ser¶a unidireccional entre algunos elementos, ya que s¶olo los que tienen tel¶efono enviar¶an mensajes. En el caso 2, los elementos tendr¶
an que considerar hablar en un cierto orden para que los mensajes sean comprendidos.
² El n¶
umero de entidades [n,m] (n entidades en
un extremo del enlace y m en el otro) involucradas en la comunicaci¶
on, a esto se le llama la cardinalidad del enlace y puede ser: [1,1], [1,n], o
[n,n].
Al dise~
nar una aplicaci¶on distribuida, tambi¶en es necesario tomar una serie de decisiones y una de las
mas importantes es la manera en la cual los procesos que forman la aplicaci¶on se van a comunicar y a
sincronizar. Como en el caso de la comunicaci¶on humana, existen varias maneras en las cuales los procesos se pueden comunicar. Las opciones mas utilizadas son el intercambio de mensajes y el uso de una
memoria compartida. El objetivo de este art¶³culo es
presentar y comparar ambos modelos.
El resto de este art¶³culo se estructura de la siguiente manera: en la secci¶on 2, presentamos el modelo de
env¶³o y recepci¶
on de mensajes. En la secci¶on 3, presentamos el modelo de memoria compartida. En ambos casos se ilustra el modelo con un ejemplo. En
la secci¶
on 4, se hace una re°exi¶on acerca de las ventajas y las desventajas de cada modelo desde diferentes puntos de vista: comprensi¶on, construcci¶
on
de aplicaciones, y e¯ciencia. Finalmente, presentamos nuestras conclusiones en la secci¶on 5.
2. Modelo de env¶³o y recepci¶
on de mensajes
As¶³ como el habla es el medio m¶as natural para que
los seres humanos se comuniquen; el env¶³o y la recepci¶
on de mensajes es el medio m¶as natural para permitir la comunicaci¶on entre un conjunto de procesos que se ejecutan en unidades de c¶omputo diferentes unidas por una red.
Para poder utilizar una capa de transmisi¶on de mensajes es necesario conocer una serie de conceptos de
base. Dichos conceptos se presentan a continuaci¶
on
² La capacidad del enlace es la cantidad de informaci¶
on que puede almacenar el mensaje. Si el
enlace no almacena mensajes se dice que es de
capacidad 0. Por otro lado, si almacena, es importante saber si la capacidad es limitada o ilimitada. Y si es limitada, >qu¶e pasa cuando esa
capacidad se agota?
² El sentido del enlace indica en qu¶e sentido se
pueden enviar los mensajes. Las posibilidades
son que sea unidireccional o bidireccional.
Una cardinalidad [x,y] y un sentido unidireccional
de x a y, denotan la posibilidad de comunicaci¶
on de
x emisores hacia y receptores.
El mensaje es la unidad de informaci¶
on que, a trav¶es
del enlace, se intercambia entre los procesos. Los
aspectos importantes a conocer de los mensajes en
un sistema son:
² El tipo de mensajes que se pueden transmitir
(voz, im¶
agenes, informaci¶
on, etc.),
² El tama~
no de los mensajes y si ¶este es ¯jo o
variable y
² El tipo de env¶³o de mensaje que se hace (por
ejemplo: valor o referencia).
Una vez establecido el enlace y armado el mensaje,
se realiza el env¶³o y la comunicaci¶
on se lleva a cabo.
El evento de comunicaci¶
on puede ser:
² S¶³ncrono, si para que la comunicaci¶
on se
efect¶
ue, se requiere que tanto el receptor como el emisor est¶en listos o As¶³ncrono, si ¶esta
no es condici¶
on necesaria.
>Memoria compartida o mensajes? Elizabeth P¶erez Cort¶es y Graciela Rom¶
an Alonso.
² Directo, si el mensaje llega directamente a la
entidad receptora o Indirecto, si se almacena en
un contenedor intermedio.
² Sim¶etrico, si el emisor especi¯ca qui¶en es el destinatario de su mensaje y el receptor a su vez
decide de qui¶en recibir o Asim¶etrico, si s¶
olo el
emisor nombra al receptor y el receptor recibe mensajes que le sean enviados por cualquier
emisor.
Un sistema de env¶³o y recepci¶on de mensajes se
puede caracterizar de acuerdo a los criterios de¯nidos previamente. Una vez que se conocen todos los aspectos del enlace, los mensajes y la comunicaci¶
on en un sistema de este tipo, se est¶
a en
posibilidades de elaborar la aplicaci¶on distribuida
con base en ¶el.
Por ejemplo, se sabe que el tel¶efono es un medio de
comunicaci¶
on en donde el enlace es [1,1], bidireccional y con capacidad de almacenamiento 0; los mensajes son orales de tama~
no variable y que se transmiten por valor; la comunicaci¶on es s¶³ncrona, directa y
asim¶etrica. Por otro lado, el localizador tiene un enlace unidireccional de cardinalidad [1,n] y con capacidad de almacenamiento limitada; los mensajes que
se transmiten son textuales, de tama~
no variable pero limitado y se env¶³an por valor; mientras que la comunicaci¶
on es as¶³ncrona, indirecta y asim¶etrica.
2.2 Las capas de transmisi¶
on de mensajes
Como hab¶³amos mencionado previamente, el modelo de env¶³o y recepci¶on de mensajes es el mas natural cuando se piensa en hacer comunicar procesos que
se ejecutan en m¶aquinas conectadas por una red. Esto explica que desde los primeros tiempos se hayan
hecho esfuerzos por construir servicios de env¶³o y recepci¶
on de mensajes. Estos servicios son capas de
software que presentan al usuario programador de
aplicaciones una interfaz simpli¯cada y que ocultan
las di¯cultades de lograr una transmisi¶on de mensajes con¯able y que garantice un orden de entrega. A continuaci¶on se caracteriza una de las herramientas m¶
as conocidas que ofrece tales servicios.
Una m¶
aquina virtual paralela: PVM
PVM, (Parallel Virtual Machine) es un sistema de
env¶³o y recepci¶on de mensajes que permite a una red
de m¶
aquinas heterog¶eneas ser usadas como una sola m¶
aquina paralela. Esta herramienta es una de
las mas utilizadas para de¯nir una m¶aquina virtual
paralela. Las funciones proporcionadas por PVM
permiten crear procesos autom¶aticamente sobre la
m¶
aquina virtual y permiten, mediante el intercambio de mensajes, la comunicaci¶on y sincronizaci¶
on de
estos.
29
En PVM los procesos son denominados tareas. Con
esta herramienta es posible de¯nir grupos de procesos permitiendo establecer enlaces de comunicaci¶
on con cardinalidades diferentes: [1,1], [1,n] y [n,1].
La comunicaci¶
on es directa, puede ser sim¶etrica
o asim¶etrica mientras que el env¶³o de un mensaje es as¶³ncrono y la recepci¶
on puede ser s¶³ncrona
o as¶³ncrona. Los mensajes tienen asociado un tipo, y son de talla limitada. En el env¶³o de un mensaje, la informaci¶
on se empaqueta en un bu®er y se desempaqueta a la recepci¶
on.
Algunas de las primitivas usadas en PVM son las
siguientes:
² pvm spawn(): la cual permite la creaci¶on
din¶
amica de procesos, asociando un identi¯cador u
¶nico a cada proceso.
² pvm psend(): usada para el empaquetamiento y env¶³o de un mensaje. Entre los par¶
ametros
de esta primitiva est¶
a involucrado el (los) identi¯cador (es) del (de los) proceso(s) al cual se
le(s) enviar¶
a el mensaje.
on y de² pvm precv(): usada para la recepci¶
sempaquetamiento de mensajes.
Entre los
par¶
ametros de esta primitiva es posible indicar el identi¯cador del proceso del cual se espera un mensaje o bien, indicar que cualquier mensaje puede ser recibido.
² pvm exit(): primitiva que permite a un proceso terminar y salir de PVM.
2.3 Una suma paralela usando env¶³o y recepci¶
on de mensajes
Ilustraremos el uso de un sistema de env¶³o y recepci¶
on de mensajes con un ejemplo muy simple en el
que m procesos cooperan para calcular la suma de
N n¶
umeros enteros.
En esta aplicaci¶
on se de¯ne un proceso coordinador quien se encarga de crear un n¶
umero (nprocs)
de procesos sumadores, entre los cuales dividir¶a el
trabajo. El coordinador env¶³a un mensaje a cada
sumador conteniendo un arreglo de tama~
no MaxDatos/nprocs de n¶
umeros (previamente capturados)
para que se realice la suma. Una vez transferidos los
datos, el coordinador queda en espera de los mensajes de cada sumador conteniendo las sumas parciales calculadas y conforme las va recibiendo, calcula la suma total y la imprime.
Por otro lado, cada proceso sumador, espera el
mensaje con el arreglo de n¶
umeros a sumar y una vez
recibido, realiza la suma y ¯nalmente, env¶³a el resultado al coordinador.
30
# include \pvm3.h"
#de¯ne MaxDatos 20
#de¯ne nprocs 4
#de¯ne numdatos (int) (MaxDatos / nprocs)
int buf[1];
int tida[nprocs], datos[numdatos];
main() // Proceso coordinador
int sum=0,i,k,cc;
/*Creaci¶
on de los procesos sumadores guardando su
identi¯cador en tida[i]) */
for (i = 0; i < nprocs; i++)
cc = pvm spawn(\sumador",NULL,0,"\,1,& tida[i]);
/*Env¶³o de los n¶
umeros a sumar a cada sumador */
for (i = 0; i < nprocs; i++)
for (k=0; k<numdatos ;k++) // captura de datos
scanf(\%d",&(datos[k]));
pvm psend(tida[i],2,datos,numdatos,PVM INT);
// env¶³o
g
ContactoS 38, 27{34 (2000)
3. Modelo de memoria compartida
Como mencionamos en nuestro ejemplo, un pizarr¶on
en donde todos los involucrados en un trabajo puedan leer o escribir informaci¶
on, es tambi¶en un medio de comunicaci¶
on. En este caso, los usuarios deben acordar una manera de utilizarlo que no ocasione con°ictos. Por ejemplo, si dos usuarios requieren leer un dato, pueden hacerlo de manera simultanea, sin embargo, si ambos pretenden cambiarlo, deben hacerlo de manera secuencial, es decir, uno despu¶es del otro.
Los mecanismos de sincronizaci¶
on que permiten a un
conjunto de procesos manipular recursos de manera no con°ictiva existen desde la creaci¶
on de los sistemas operativos multitarea . En general, los sistemas de memoria compartida utilizan los mecanismos
de sincronizaci¶
on m¶
as populares (sem¶
aforos, candados, barreras, etc.). A continuaci¶
on presentamos los
conceptos de base del modelo de memoria compartida. Posteriormente describimos gen¶ericamente los
sistemas de memoria compartida y ¯nalmente ilustramos su uso.
/*Recepci¶
on de las sumas parciales y c¶alculo de la
total*/
for (i = 0; i < nprocs; i++) f
cc = pvm precv(-1,-1,buf,1,PVM INT,0,0,0);
sum += buf[0]; g
3.1 Conceptos de base
La memoria compartida puede verse como un conjunto de variables accesibles para leerse o escribirse.
Desde el punto de vista de un programador de aplicaciones distribuidas (PAD), la memoria compartida se comporta como la memoria centralizada de una
computadora tradicional.
#include <pvm3.h>
#de¯ne MaxDatos 20
#de¯ne nprocs 4
#de¯ne numdatos (int)(MaxDatos/nprocs)
Una variable que va a ser utilizada por varios procesos es una variable compartida. La regi¶
on de c¶
odigo
de un proceso que manipula una variable compartida es denominada una secci¶
on cr¶³tica. Si en un
instante dado, m¶
as de un proceso ejecuta su secci¶
on cr¶³tica, es posible que haya con°ictos en la manipulaci¶
on de las variables compartidas. Para evitar los problemas, una secci¶
on cr¶³tica debe ser ejecutada en exclusi¶
on mutua. En otras palabras, s¶olo
un procesador a la vez puede manipular las variables compartidas.
printf(\La suma total es %dfgn",sum);
pvm exit(); //sale de PVM
exit(0);
g
main (int argc,char *argv[]) // Proceso bf sumador
int datos[numdatos],i,buf[1],cc; buf[0]=0;
/* Recepci¶
on de los n¶
umeros que le corresponde
sumar*/
cc
=
pvm precv(1,2,datos,numdatos,PVM INT,0,0,0);
for (i = 0 ; i < numdatos ; i++) //Realiza la suma
buf[0] += datos[i];
/*Env¶³o
de
la
suma
al
cordinador*/
pvm psend(pvm parent(),1,buf,1,PVM INT);
pvm exit(); //sale de PVM exit(0);
g
Un mecanismo que permite garantizar la exclusi¶on
mutua es el candado. Los procesos que comparten
variables se sincronizan a trav¶es de candados; el proceso que tiene el candado tiene el derecho a manipular las variables compartidas. Un proceso solicita un candado antes de entrar a una secci¶
on cr¶³tica
y lo libera al salir. Si el candado ha sido tomado previamente, el proceso que lo solicita debe esperar en una cola.
Adem¶
as de sincronizarse para garantizar el acceso en
exclusi¶
on mutua a las variables compartidas, los procesos que forman una aplicaci¶
on distribuida se sincronizan para noti¯car eventos. Por ejemplo, cuando un proceso A debe anunciar la terminaci¶
on de
>Memoria compartida o mensajes? Elizabeth P¶erez Cort¶es y Graciela Rom¶
an Alonso.
31
² Pedir y liberar candados (Tmk lock acquire y
Tmk lock release).
As¶³ como una serie de constantes que permiten identi¯car cada proceso Tmk proc id, y saber cu¶antos
procesos est¶
an activos Tmk nprocs.
En la secci¶
on siguiente ilustramos el uso y funcionamiento de la memoria compartida realizando la misma suma paralela descrita en la secci¶
on 2.3.
F ig ura 2 : M e mo ria V irtua l D istribuida .
su tarea a otro proceso B para que ¶este tome el resultado y siga su ejecuci¶on. En este caso se dice
que los procesos A y B se sincronizan. La barrera es un mecanismo que permite este tipo de sincronizaci¶
on. Un proceso que llega a una barrera se bloquea hasta que los otros procesos alcancen la misma barrera, en ese momento, todos contin¶
uan su
ejecuci¶
on.
3.2 Los sistemas de memoria compartida
Como ya mencionamos, una red de computadoras
no tiene memoria compartida, por ende, para permitir la construcci¶on de aplicaciones distribuidas utilizando este modelo de comunicaci¶on, es necesario simularla. Esta simulaci¶on es realizada por una capa
de software denominada Sistema de Memoria Virtual Distribuida (SMVD).
Dicho de una manera muy simple, un SMVD funciona de la siguiente manera: los procesos disponen
de un espacio virtual compartido (Figura 2) dentro del cual de¯nen las variables que van a utilizar. Cuando un proceso requiere utilizar una variable compartida, el SMVD investiga en d¶
onde se
encuentra y la trae a la memoria del proceso para que ¶este pueda utilizarla. Por supuesto, esta utilizaci¶
on se permite dentro de las reglas de accesos no
con°ictivos.
TreadMarksT M
TreadMarksT M es un SMVD construido en la Universidad de Rice, EUA. Este sistema permite declarar variables compartidas y proporciona primitivas para:
² Iniciar el sistema de memoria compartida y terminarlo (Tmk startup y Tmk exit).
² Pedir
y
liberar
memoria
compartida
(Tmk malloc y Tmk free) y para copiar un valor en las memorias privadas de los otros procesadores (Tmk distribute).
² Esperar en una barrera a los otros procesos
(Tmk barrier)
3.3 Una suma paralela usando memoria compartida
Considerando el modelo de memoria compartida, para efectuar la suma paralela, los procesos comparten una estructura (shared) que contiene el arreglo
(array) en donde est¶
an los datos, un entero (sum)
que contendr¶
a el resultado y un entero (turn) que
servir¶
a para la sincronizaci¶
on de los procesos. En
funci¶
on de la cantidad de n¶
umeros (arrayDim) y
de la cantidad de procesos (Tmk nprocs), se divide el trabajo de manera que cada proceso hace la suma de una secci¶
on del arreglo (contenida entre start
y end) y en cuanto termina agrega el resultado a la
suma global.
En este programa, el proceso coordinador inicializa
las estructuras de datos mientras los dem¶
as (sumadores) esperan en la barrera. Enseguida, cada proceso sumador calcula el rango del arreglo que le corresponde sumar. Posteriormente cada proceso sumador calcula la suma parcial y la agrega a la suma global (shared->sum). Finalmente, cuando todos los sumadores agregaron su resultado, el proceso coordinador imprime la suma global.
#include <stdio.h>
#include \Tmk.h"
#de¯ne Coordinador 0
struct shared
int sum;
int turn;
int* array;
*shared;
main(int argc, char **argv)
int start, end, i, p, arrayDim = 100;
Tmk startup(argc, argv);
/* El proceso coordinador inicializa las estructuras de datos */
if (Tmk proc id == Coordinador)
shared = (struct shared *) Tmk malloc(sizeof(shared));
if (shared == NULL)
Tmk exit(-1);
shared->array = (int *) Tmk malloc(arrayDim
* sizeof(int));
if (shared->array == NULL)
Tmk exit(-1);
32
/* Se inicializa el arreglo */
for (i = 0; i < arrayDim; i++)
scanf(\%d", shared->array[i]);
shared->turn = 0;
shared->sum = 0;
/* Y comparte el apuntador com¶
un con todos los procesos */
Tmk distribute(&shared, sizeof(shared));
g
Tmk barrier(0);
/* Cada proceso determina su rango del arreglo */
f
int id0 = Tmk proc id, id1 = Tmk proc id+1;
int perProc = arrayDim / Tmk nprocs;
int leftOver = arrayDim % Tmk nprocs;
start = id0 * perProc + id0 * leftOver / Tmk nprocs;
end = id1 * perProc + id1 * leftOver / Tmk nprocs;
g
Tmk barrier(0);
g
/* Calcula la suma local y se la agrega a la suma
global */ f
int mySum = 0;
for (i = start; i < end; i++)
mySum += shared->array[i];
/* Modi¯caci¶
on de la suma global */
Tmk lock acquire(0);
shared->sum += mySum;
Tmk lock release(0);
g
Tmk barrier(0);
if (Tmk proc id == Coordinador)
printf(\Sum is %dfgn", shared->sum);
Tmk free(shared->array);
Tmk free(shared);
g
Tmk exit(0);
g
4. Comparaci¶
on de los modelos de comunicaci¶
on
Una vez que hemos presentado los modelos de comunicaci¶
on discutiremos en esta secci¶on acerca de sus
cualidades y sus defectos desde la ¶optica de un programador de aplicaciones distribuidas.
4.1 Comprensi¶
on del modelo de comunicaci¶
on
En lo que respecta a la comprensi¶on del modelo de
comunicaci¶
on, ambos modelos representan una similitud con herramientas de comunicaci¶on usuales y
por lo tanto algunos de los conceptos de base son
f¶aciles de asimilar, sin embargo, se pueden observar las siguientes diferencias:
ContactoS 38, 27{34 (2000)
² Intercambio de mensajes: El env¶³o y la
recepci¶
on de mensajes se asemeja a la manera en que las personas comunican por algunos medios (tel¶efono), esto hace que los conceptos mensaje, env¶³o y recepci¶
on sean f¶
acilmente
asimilables.
Por otro lado, para programar una capa de
env¶³o y recepci¶
on de mensajes, se tienen que
asimilar una serie de conceptos nuevos que
pueden provocar una percepci¶
on compleja del
modelo.
Otra fuente de complejidad es la necesidad de
seleccionar de entre un gran n¶
umero de combinaciones disponibles, las caracter¶³sticas (del enlace, del mensaje y del evento de comunicaci¶on)
a utilizar.
² Memoria compartida: en el caso de las variables compartidas los conceptos son pocos y simples y la manera de evitar los con°ictos tambi¶en lo es. En este modelo la di¯cultad viene de
la comprensi¶
on de las herramientas de sincronizaci¶
on y su correcto uso.
4.2 Construcci¶
on de las aplicaciones
Al construir una aplicaci¶
on, un PAD debe tomar
en cuenta seg¶
un el modelo elegido, las siguientes
consideraciones:
² Intercambio de mensajes: Una de las di¯cultades en la construcci¶
on de aplicaciones distribuidas es la existencia de varios espacios de memoria (uno por m¶
aquina) que confronta al programador con la distribuci¶
on de los datos. El
programador debe tener en cuenta en d¶onde
est¶
an los datos, cu¶
ando se requiere intercambiar datos entre procesos, a qui¶en es necesario envi¶
arselos, y qu¶e debe de enviar. Un olvido
de parte del programador en este caso puede llevar a que los diferentes procesos tengan informaci¶
on incoherente e inducir ejecuciones err¶
oneas.
Esta situaci¶
on resulta inconveniente, especialmente en los casos en los que la tarea requiere de un alto grado de comunicaci¶
on, o la utilizaci¶
on de estructuras de datos complejas. En
este u
¶ltimo caso, por ejemplo cuando se requiere transferir un ¶
arbol, es necesario aplanar
la estructura para enviarla y reconstruirla a la
recepci¶
on.
² Memoria compartida: En el caso de la memoria compartida, el PAD tiene que identi¯car
las variables compartidas y asegurarse de que
toda manipulaci¶
on de dichas variables se hace en una secci¶
on cr¶³tica.
>Memoria compartida o mensajes? Elizabeth P¶erez Cort¶es y Graciela Rom¶
an Alonso.
Dependiendo de los mecanismos de sincronizaci¶
on proporcionados por la herramienta, esto
puede ser una labor m¶as o menos complicada.
Sin embargo, es tambi¶en cierto que un error en
el uso de las herramientas de sincronizaci¶
on puede inducir comportamientos err¶oneos.
En el trabajo reportado en [3] se enuncia que los
PAD cometen menos errores programando bajo el
modelo de memoria compartida.
4.3 E¯ciencia
En una aplicaci¶on distribuida programada con transmisi¶
on de mensajes, se transmiten s¶olo los mensajes
indispensables con la cantidad de informaci¶
on necesaria. Por otro lado, un SMVD est¶a construido sobre un servicio de intercambio de mensajes y para simular la memoria compartida, los componentes del SMVD intercambian mensajes. Por lo tanto, la cantidad de mensajes y de informaci¶
on transferida en un sistema de este tipo es superior a la
transferida en el caso del modelo a intercambio de
mensajes.
Durante la u
¶ltima d¶ecada se ha hecho mucho trabajo
de investigaci¶on para mejorar el rendimiento de los
SMVD y actualmente se cuenta con productos cuyos
rendimientos est¶an en el mismo rango de los de las
capas de transmisi¶on de mensajes .
Por ejemplo, un estudio realizado por los constructores de TreadMarksT M , hecho sobre una serie de aplicaciones distribuidas, encontr¶o que si bien, en todos los casos, PVM es m¶as e¯ciente, en un 40% de las
aplicaciones la diferencia entre ambos es de s¶
olo 10%
mientras que en el otro 40% la diferencia est¶
a entre un 10% y un 30%. El restante 20% est¶
a formado por aplicaciones en donde la cantidad de c¶
alculo
es muy d¶ebil con respecto a la comunicaci¶on y el rendimiento es muy malo para ambos modelos.
5. Conclusiones
Las aplicaciones distribuidas, compuestas por un
conjunto de procesos que cooperan para realizar una
tarea, forman una parte importante de las aplicaciones que se construyen hoy en d¶³a. Este tipo de aplicaciones permite obtener un mejor bene¯cio de las infraestructuras de c¶omputo actuales. Una de las decisiones importantes en el dise~
no de una aplicaci¶
on distribuida es el modelo de comunicaci¶on y sincronizaci¶
on que los procesos utilicen.
En este art¶³culo se presentan y comparan dos modelos: intercambio de mensajes y memoria compartida. Se implant¶o una misma aplicaci¶on usando las
Herramienta PVM y TreadMarksT M que siguen respectivamente los modelos antes dichos. La aplicaci¶
on consisti¶o en sumar en paralelo los elementos de
33
un vector de enteros, proporcionando al ¯nal el resultado de la suma.
En cuanto a simplicidad el modelo de memoria compartida presenta la ventaja de tener una menor cantidad de conceptos por asimilar que el modelo de
env¶³o y recepci¶
on de mensajes. En cuanto a la construcci¶
on de las aplicaciones, si los procesos comunican con mucha frecuencia o intercambian estructuras de datos complejas es m¶
as recomendable utilizar memoria compartida. Por otro lado, el modelo de env¶³o y recepci¶
on de mensajes observa mejores rendimientos en todos los casos.
Como modelo, la memoria compartida permite concentrarse m¶
as en la acci¶
on de comunicaci¶
on y menos en el medio. Esto favorece su preferencia para estudiar aspectos de tolerancia a fallas, cuando
los elementos defectuosos est¶
an en las computadoras y no en los canales.
De lo anterior podemos deducir que para elegir el
modelo de comunicaci¶
on y sincronizaci¶
on, es indispensable tomar en cuenta el per¯l de la aplicaci¶on.
Finalizamos mencionando que la mayor parte de las
aplicaciones distribuidas est¶
an construidas sobre capas de env¶³o y recepci¶
on de mensajes dado que este tipo de comunicaci¶
on se ha usado durante mucho tiempo y por ende, las herramientas de desarrollo est¶
an mucho mas maduras. Por otro lado, la relativa novedad del modelo de memoria compartida,
la poca difusi¶
on y la falta de herramientas de desarrollo hacen que la memoria compartida sea poco utilizada. Consideramos necesaria una amplia labor de difusi¶
on.
Bibliograf¶³a
1. Bershad B. N., Zekauskas M. J. et Sawdon
W. A., Midway: Shared Memory Parallel Programming with Entry Consistency for Distributed Memory Multiprocessor, (CMU-CS-91-170),
School of Computer Science, Carnegie Mellon
University, Pittsburgh, PA 15213, septiembre
1991.
2. Carter J. B., Bennett J. K. et Zwaenepoel W.,
\Implementation and Performance of Munin",
Proceedings of the ACM Symposium on Operating Systems (SOSP), vol 13 pp. 152-164, octubre 1991.
3. Chavez Navarro Sara, Memoria Virtual Distribuida v.s. Env¶³o y Recepci¶
on de Mensajes.,
Reporte Proyecto de Investigaci¶
on 2, UAMIztapalapa, 1999.
34
4. Coulouris G., Dollimore J & Kindberg T. Distributed Systems: Concepts and Principles, Addison Wesley, 1994.
5. Geist A., Beguelin A., Dongarra J., PVM 3
User's Guide and Reference Manual, 1994.
6. Honghui Lu, Sandhya Dwarkadas, Alan L.
Cox, Willy Zwaenepoel, Message Passing Versus Distributed Shared Memory on Networks of Workstations, Proceedings of the
1995 ACM/IEEE Supercomputing Conference San Diego, California, USA Diciembre 1995.
7. Johnson K. L., Kaashoek M. F. et Wallach D.
A., \CRL: High-Performance All-Sofware Distributed Shared Memory", Proceedings of the
15th ACM Symposium on Operating Systems.
Principles, pp. 213-227, 1995.
8. Keleher P., Cox L. A. et Zwaenepoel W., \Lazy
Release Consistency for Software Distributed
Shared Memory", Proceedings of the 19th. Annual International Symposium on Computer
Architecture, pp. 13-21, 1992.
ContactoS 38, 27{34 (2000)
9. Keleher P., Cox A. L., Dwarkadas S. et Zwaenepoel W., \TreadMarks: Distributed Shared Memory on Standard Workstations and Operating
Systems", In Proceedings of the Winter 1994
USENIX Conference, pp. 115-131, enero 1994.
10. Kohl (J. A.), Geist (G. A.).- XPVM 1.0 User's
Guide. Oak Ridge National Lab.
11. Li K, et Hudak P., \Memory Coherence in Shared Virtual Memory Systems", ACM Transactions on Computer Systems, Vol. 7(4), pp 321359. noviembre 1989.
12. Silberschatz A., Peterson J. L., Galvin P. B.
Sistemas Operativos: conceptos fundamentales.
Tercera Edici¶
on, Addison Wesley Iberoamericana, 1994.
cs