UNIVERSIDAD NACIONAL DE UCAYALI

www.unu.edu.pe

Ingeniería de Sistemas

Curso : SD-904 Sistemas Distribuidos

CAP 05 : Memoria Compartida Distribuidos

Docente : Ing. Ind. Franklin Calle Zapata

Grupo : 05

Integrantes:Shuña Trocones, Roberto L. gokunkr@gmail.com(Lider) 100%

Pozo 0%

Vasquez Chuquipoma, Willian wvasquezch@gmail.com 0%

Pucallpa, 25 de Agosto del 2008

Introducción

• La memoria compartida distribuida (DSM) es una abstracción utilizada para compartir datos entre computadores que no comparten memoria física. Los procesos acceden a DSM para leer y actuali zar, dentro de sus espacios de direcciones, sobre lo que aparenta ser la memoria interna normal asignada a un proceso. Sin embargo, existe un sistema subyacente en tiempo de ejecución que asegura de forma transparente que procesos diferentes ejecutándose en computadores diferentes observen las actualizaciones realizadas entre ellas. Es como si 1os procesos accedieran a una única me moria compartida, pero de hecho la memoria física está distribuida (véase la Figura 1).

Figura 1. La abstracción de la memoria compartida

distribuida.

Memoria compartida distribuida

• Los sistemas de memoria compartida distribuida (DSM) representan la creación hibrida de dos tipos de computación paralelos: la memoria distribuida en sistemas multiprocesador y los sistemas distribuidos. Ellos proveen la abstracción de memoria compartida en sistemas con memorias distribuidas físicamente y consecuentemente combinan las mejores características de ambos enfoques. Debido a esto, el concepto de memoria compartida distribuida es reconocido como uno de los enfoques mas atractivos para la creación de sistemas escalables, de alto rendimiento de sistemas multiprocesador.

• La principal característica de DSM es que ahorra al programador todo lo concerniente al paso de mensajes al escribir sus aplicaciones, cuestión que en otro sistema debería tenerse muy presente.

• DSM es fundamentalmente una herramienta para aplicaciones paralelas o para aplicaciones o gru pos de aplicaciones distribuidas en las que se puede acceder directamente a datos individuales que ellas comparten.

• En general, DSM es menos apropiado para sistemas cliente-servidor, ya que los clientes ven al servidor como un gestor de recursos en forma de datos abstractos que se acceden a través de peticiones (por razones de modularidad y protección). Sin embargo, los servidores pue den proporcionar DSM compartido entre los clientes.

DSM FRENTE A PASO DE MENSAJES

• Como mecanismo de comunicación, DSM es comparable con los sistemas de paso de mensajes en lugar de con la comunicación basada en peticiones y respuestas, ya que su aplicación concreta al procesamiento paralelo impone el uso de comunicación asíncrona. Los sistemas de programación DSM y de paso de mensajes pueden compararse de la siguiente forma:

– Modelo de programación

– Eficiencia

Modelo de programación • La sincronización entre procesos se consigue, en el modelo de

mensajes, mediante las pro pias primitivas de paso de mensajes, utilizando las técnicas como la implementación del servidor de bloqueo. Para DSM, la sincronización se realiza a través de construcciones normales de programación de memoria compartida, como los bloqueos y los semáforos (a pesar de que su implementación es diferente en un entorno de memoria distribuida).

• Finalmente, al ser DSM persistente, los procesos que se comunican mediante DSM pueden ejecutarse en instantes temporales no solapados. Un proceso puede dejar datos en una posición de memoria acordada para que otro proceso la examine cuando se ejecute. Por el contrario, los procesos que se comunican mediante paso de mensajes deben ejecutarse al mismo tiempo.

Eficiencia • Los experimentos muestran que ciertos programas paralelos

desarrollados para DSM pueden tener prestaciones similares a aquellos otros programas que se ejecutan sobre la misma plataforma y son funcionalmente equivalentes pero que han sido construidos usando un modelo de paso de mensajes [Carter y otros 1991] (por lo menos cuando el número de computadores es relativamente bajo, alrededor de diez). Sin embargo, este resultado no puede generalizarse. Las prestaciones de un programa basado en DSM dependen de muchos factores; por ejemplo un factor importante es el patrón de compartición de datos (como si un dato es actualizado o no por varios procesos).

• Hay una diferencia en la visibilidad de los costes asociados con los dos tipos de modelos de programación.

• En el paso de mensajes, todos los accesos remotos son explícitos y por lo tanto el programador siempre sabe si una cierta operación es local al proceso o bien supone un gasto en comunicación

APROXlMAClONES A LA IMPLEMENTACIÓN DE DSM

• La memoria compartida distribuida se implementa utilizando uno de los siguientes métodos o bien una combinación de ellos, hardware especializado, memoria virtual paginada convencional o middleware:

• Hardware Gestionan las instrucciones de acceso a memoria LOAD y STORE de forma que se comuniquen con la memoria remota y los módulos de caché según sea necesa rio para almacenar y obtener datos. Esta comunicación se realiza sobre sistemas de intercone xión de alta velocidad similares a una red. El prototipo del multiprocesador Dash tiene 64 no dos; conectados mediante una arquitectura NUMA.

• Memoria virtual paginada muchos sistemas implementan DSM como una región de memoria virtual que ocupa el mismo rango de direcciones en el espacio de direcciones de cada proceso participante

• Middleware Las instancias de este nivel en los diferentes computadores acceden a los datos locales y se intercambian información siempre que sea necesario para el mantenimiento de la consistencia.

• En el ejemplo de la Figura 2 aparecen dos programas en C, Lector y Escritor, que se comunican a través de la DSM basada en páginas proporcionadas por el sistema Mether (Minnich y Farber 1989]. Escritor actualiza dos campos de una estructura asociada al principio de un segmen to DSM en Mether (comenzando en la dirección METHERBASE) y Lector, imprime periódica mente los valores que lee de esos dos campos

include "world.h" stru~t compartida ( int a, b; j ; Programa Escritor. main() l struct compartida "p; methersetup(): l* Inicialización del sistema Mether % p = (struct

compartida )NlETHERBASE; í" estructura de overlay en el segm~nto METHER 7 p-> a= p-> b= 0; . l' inicialización a cero de los campos de la estructura % while

(TRUE)( l' actualización continua de los campos de la estructura i p-> a=p-> a+ 1;

p-> b=p-> b- 1; / Programa Lector. main() struet compartida p; methersetup(); p=(struct compartida

jivlETHERBASE; while(TRUE)( l" lectura de los campos una vez por segundo % printf("a=°id,

b=~ódln", p->a, p->b); sleep(1);

Figura 2. Programa en el sistema Mether

CUESTIONES DE DISEÑO E IMPLEMENTACIÓN • En esta sección se discuten las opciones de diseño e implementación relativas a las

principales características de un sistema DSM. Es decir, se discute la estructura de los datos gestionados en DSM; el modelo de sincronización utilizado para acceder a DSM de forma consistente desde el nivel de aplicación; el modelo de consistencia de DSM, encargado de gobernar la consistencia de datos accedidos desde diferentes computadores; las opciones de actualización para la comunica ción de valores escritos en diferentes computadores; la granularidad de la compartición en una implementación DSM; y el problema del thrashing (fustigamiento).

1. ESTRUCTURA 1. Orientada a byte 2. Orientado a objetos 3. Datos inmutables

2. MODELO DE SINCRONIZACIÓN 3. MODELO DE CONSISTENCIA

1. Consistencia secuencial. 2. Coherencia 3. Consistencia débil

4. OPCIONES DE ACTUALIZACIÓN 1. Escritura actualizante 2. Escritura invalidante

5. GRANULARIDAD 6. THRASHING (FUSTIGAMIENTO)

1. ESTRUCTURA • Los sistemas que replican una colección de objetos como diarios y

archivos son sistemas que permiten a los programas cliente realizar operaciones sobre los objetos como si existiera únicamente una copia de cada objeto, aunque en realidad están accediendo a ré plicas físicas diferentes. Estos sistemas ofrecen garantías acerca de hasta qué punto se permite que se diferencien los objetos.

• Un sistema DSM es equivalente a estos sistemas de replicación.

• Cada proceso de aplicación dispone de una abstracción de una colección de objetos, pero en este caso la colección tiene un aspecto muy parecido al que ofrece la memoria. Es decir, los objetos pueden ser direccionados de una u otra forma. Las diferentes aproximaciones de DSM difieren entre sí en qué es lo que consi deran un objeto y en cómo se direccionan los objetos.

• Consideramos tres aproximaciones, que tienen una visión de DSM como formada por, respectivamente, una secuencia contigua de bytes, objetos de nivel de lenguaje o datos inmutables.

1.1. Orientada a byte • Este tipo de DSM se utiliza como la memoria virtual ordinaria, es decir, como una

cadena de bytes contiguos. Es la visión del sistema Mether explicada previamente. Tam bién es la imagen proporcionada por muchos otros sistemas DSM, incluyendo Ivy.

• Permite que las aplicaciones (y las implementaciones de los lenguajes) alma cenen cualquier tipo de estructura de datos sobre la memoria compartida. Los objetos compartidos son posiciones de memoria direccionables directamente (en la práctica, las posiciones de memoria pueden ser palabras multi-byte en lugar de bytes individuales). Las únicas operaciones permitidas sobre esos objetos son lee (o LOAD) y escribe (o STORE). Si x e y son dos posiciones de memoria, las dos operaciones tienen la siguiente notación:

• L(x)a - una operación de lectura del valor a desde la posición x.

• E(x)b - una operación de escritura que almacena el valor b en la posición x.

• Un ejemplo de ejecución es E(x)1, L(x)2. Este proceso escribe el valor 1 en la posición x y lee el valor 2 desde la misma posición. Otro proceso debe haber sido el encargado de escribir el valor 2 en la posición compartida.

1.2. Orientado a objetos • La memoria compartida se estructura como una colección de

objetos de nivel de lenguaje, como pilas o diccionarios, con una semántica de mayor nivel que la simple de lectura/escritura de variables.

• Los contenidos de la memoria compartida se modifican únicamente mediante invocaciones sobre dichos objetos y nunca a través del acceso directo a sus variables miembro.

• Una ventaja de esta visión de la memoria es que la semántica de objetos puede utilizarse para forzar la consistencia.

• La visión de DSM proporcionada por Orca es la de una colección de objetos compartidos en los que automáticamente se serializan las operaciones simultáneas realiza das sobre cualquiera de ellos.

1.3. Datos inmutables • En este caso DSM se muestra como una colección de datos inmutables

que los procesos pueden leer, sumar y eliminar. Algunos ejemplos son Agora (Bisiani y Forin l988) y, más importante, Linda y sus derivados, TSpaces y JavaSpaces.

• Los sistemas de tipo Linda proporcionan al programador una colección de tuplas llamado espacio de tuplas. Una tupla está formada por una secuencia de uno o más campos de datos con tipo, como < tino, 1958 >, < «teo», 1964 > y <4,9.8, «Sí» >. En el mismo espacio de tuplas puede existir cualquier combinación de tipos de tuplas. Los procesos comparten los datos mediante el acceso al mismo espacio de tuplas: sitúan las tuplas en el espacio utilizando la operación escribe y 1as leen o extraen utilizando las operaciones lee o toma.

• La operación escribe añade una tupla sin afectar al resto de tuplas existentes en el espacio. La operación lee devuelve el valor de una tupla sin afectar al contenido del espacio de tuplas. La operación toma también devuelve una tupla, pero la elimina del espacio.

• Cuando se lee o se toma una tupla desde su espacio, un proceso proporciona una especificación de tuplas y el espacio devuelve cualquiera que cumpla dicha especificación (se trata de una varian te del direccionamiento asociativo). Para permitir que los procesos sincronicen sus actividades, las operaciones lee y toma se bloquean hasta que se encuentre la tupla dentro del espacio. Una especificación de tupla está formada por el número de campos y los valores o tipos de los campos solicitados. Por ejemplo, toma (<String, integer>) podría extraer tanto <«tino», 1958> como < «teo», 1964 >; toma( < String, 1958 > ) extraería únicamente < <tino>, 1958 >.

• En Linda no se permite el acceso directo a las tuplas en un espacio de tuplas y los procesos las deben reemplazar en lugar de modificarlas. Sea, por ejemplo, un conjunto de procesos que accede a un contador compartido en un espacio de tuplas. El valor actual del contador (64) está en la tupla < «contador», 64 >. Para incrementar el contador en un espacio de tuplas misTups se debe ejecutar el siguiente fragmento de código:

  • < s, contador > : = misTups.take( < «contador», integer > ); • misTups write( < «contador», contador+ 1 > );   • El lector deberá comprobar que las condiciones de carrera no pueden

ocurrir, ya que toma extrae la tupla contador del espacio de tuplas.

2. MODELO DE SINCRONIZACIÓN • Muchas aplicaciones aplican restricciones sobre los valores almacenados en la

memoria comparti da. Esto ocurre tanto en aplicaciones basadas en DSM como en las mismas aplicaciones escritas para multiprocesadores de memoria compartida (o para cualquier programa concurrente que com parte datos, como los núcleos de los sistemas operativos y los servidores multi-hilo).

• Por ejemplo, si a y b son dos variables almacenadas en DSM, una restricción puede ser que siempre se cumpla a = b. Si dos o más procesos ejecutan el siguiente fragmento de código:

• a:= a + 1; • b:= b + 1;

• Entonces se puede llegar a una situación inconsistente. Supóngase que a y b se han inicializado a cero y que el proceso 1 incrementa a. Antes de que pueda incrementar b, el proceso 2 pone un 2 en a y un 1 en b.

  • La restricción ha dejado de cumplirse. La solución consiste en convertir este frag

mento de código en una sección crítica: sincronizar los procesos para asegurar que sólo uno de ellos puede estar a la vez ejecutándola.

3. MODELO DE CONSISTENCIA

• Un modelo de consistencia de memoria (Mosberger 1993) especifica las garantías de consisten cia que un sistema DSM realiza sobre los valores que los procesos leen desde los objetos, dado que en realidad acceden sobre una réplica de cada objeto y que múltiples procesos pueden actualizar los objetos. Téngase en cuenta que esto es diferente de la noción

de consistencia de alto nivel y dependiente de aplicación

• Figura 3.Dos procesos accediendo a variables compartidas

3.1. Consistencia secuencial. • La secuenciación es demasiado estricta en la mayor parte de las

ocasiones. El modelo de memoria más fuerte para DSM que se usa en la práctica es el de consistencia secuencial (Lamport 1979).

• Un sistema DSM se dice que es secuencialmente consistente si para cualquier ejecución existe algún entrelazado de las series de operaciones realizadas por todos los procesos que satisface los dos siguientes criterios:

• SCl: La secuencia entrelazada de operaciones es tal que si L(x)a ocurre en la secuencia, entonces o bien la última operación de escritura que ocurrió antes en la secuencia entrelazada fue E(x)a, o bienno ha ocurrido ninguna operación escritura antes que ella y a es el valor inicial de x.

• SC2: El orden de las operaciones en el entrelazado es consistente con el orden de programa en el que dichas operaciones fueron ejecutadas por cada cliente individual.

3.2. Coherencia • Una reacción al coste de la consistencia secuencial consiste en buscar un

modelo más débil pero con sus propiedades bien definidas. La coherencia es un ejemplo de una forma más débil de consistencia.

• Bajo la coherencia, cada proceso llega a acuerdos sobre el orden de las operaciones de escritura sobre la misma posición, pero no acuerdan necesariamente el orden de las operaciones de escritura sobre posiciones diferentes. Se puede pensar en la coherencia como una forma de consistencia secuencial realizada posición a posición.

• Los sistemas DSM coherentes pueden implementarse mediante un protocolo para implementar la consistencia secuencial aplicada de forma separada a cada unidad de datos replicados (por ejemplo, a cada página). El ahorro se produce del hecho de que los accesos a dos páginas diferentes se hacen de forma independiente y no existe retardo entre ellos al aplicarse el protocolo de forma separada a ambos.

Figura 4. Entrelazado bajo la consistencia secuencial.

3.3. Consistencia débil • Dubois y otros (1988) desarrollaron un modelo de consistencia débil en un intento de

evitar los costes de la consistencia secuencial en los multiprocesadores, pero conser vando el efecto de esta consistencia secuencial.

• Este modelo aprovecha el conocimiento de las ope raciones de sincronización para relajar la consistencia de memoria, mientras se muestra al progra mador para implementar una consistencia secuencial.

• Por ejemplo, si el programador utiliza un bloqueo para imple mentar una sección crítica entonces un sistema DSM puede asumir que ningún otro proceso puede acceder a los datos accedidos bajo la exclusión mutua. Será por lo tanto redundante que un sistema DSM propague las actualizaciones de dichos datos antes que el proceso deje la sección crítica.

• A pesar de que se mantienen valores inconsistentes durante algún tiempo para los datos, durante ese tiempo dichos datos no son utilizados; la ejecución aparenta ser secuencialmente consistente. Adve y Hill [1990] describen una generalización de esta idea llamada ordenamiento débil: « (Un sistema DSM) está ordenado débilmente respecto a un modelo de sincronización si y sólo si aparenta ser secuencialmente consistente para el software que aplica el modelo de sincronización.»

4. OPCIONES DE ACTUALIZACIÓN

• Para la propagación de las actualizaciones realizadas desde un cierto proceso sobre varios otros se han desarrollado dos posibles opciones: escritura actualizante y escritura invalidante. Ambos se pueden aplicar a varios modelos de consistencia DSM, incluyendo la consistencia secuencial. En detalle las opciones se describen así:

4.1.Escritura actualizante • Las actualizaciones de un proceso se realizan de forma local y se envían

por multidifusión a todos los gestores de réplica que posean una copia del dato, los cuales modifican inmediatamente el dato leído por los procesos locales (véase la Figura 5). Los procesos leen las copias locales de los datos, sin necesidad de comunicación. Además de permitir múltiples lectores, varios procesos pueden escribir el mismo dato de forma simultánea; esto se conoce como compartición de múltiples lectores/múltiples escritores.

Figura 5. DSM utilizando escritura actualizante

4.2. Escritura invalidante • En el esquema de invalidación, las actualizaciones únicamente se propagan

cuando los datos son leídos y además se pueden realizar varias actualizaciones consecutivas sin necesidad de realizar ninguna comunicación.

• Como contrapartida, se deben invalidar todas las copias de sólo lectura antes de que se pueda realizar una escritura. Esto puede ser potencialmente caro en el esquema de múltiples lectores/un único escritor.

• Sin embargo, si la relación lectura/escritura es suficientemente alta, el paralelismo que se obtiene permitiendo múltiples lectores simultáneos amortiza su coste.

• Cuando la relación lecturas/escrituras es relativamente baja, un esquema de tipo único lector/único escritor puede ser más apropiado: es decir, como máximo un proceso en cada instante puede obtener acceso de sólo lectura.

5. GRANULARIDAD • Teóricamente, todos los procesos comparten el contenido completo del

DSM. Sin embargo, según se van ejecutando los programas que comparten DSM, únicamente ciertas partes de los datos son en reali dad compartidas y únicamente durante ciertos períodos de la ejecución.

• En la práctica, la elección de la unidad de compartición debe realizarse en función de los tama ños de página física disponibles, a pesar de que, si el tamaño de la página es pequeño, se pueda utilizar como unidad un cierto número de páginas contiguas. La disposición de los datos respecto a las fronteras entre páginas es un factor importante para determinar el número de transferencias de páginas realizadas durante la ejecución de un cierto programa

Figura 6. Disposición de los datos sobre las páginas.

6. THRASHING (FUSTIGAMIENTO) • Un problema potencial de los protocolos de escritura invalidante es

el thrashing.

• Se dice que un sistema DSM está en thrashing cuando realiza un gasto desmesurado de tiempo en la invalidación y transferencia de datos compartidos en comparación con el tiempo empleado por los procesos de aplicación en la realización de trabajo útil.

• Ocurre cuando varios procesos compiten por el mismo dato o bien por datos que están bajo compartición falsa. Si, por ejemplo, un proceso lee de forma repetida el mismo dato que otro proceso está actualizando regularmente, entonces el dato será continuamente transferido desde el escritor e invalidado en el lector.

• Éste es un ejemplo de patrón de compartición para el que la escritura invalidante es menos apropiada que la escritura actualizante.

CONSISTENCIA SECUENCIAL E IVY.

1. EL MODELO DE SISTEMA 1. El problema de la escritura actualizante

2. INVALIDACIÓN DE ESCRITURA

3. PROTOCOLOS DE INVALIDACION

1. Uso de la multidifusión para localizar el propietario

4. UN ALGORITMO DE GESTIÓN DISTRIBUIDA DINÁMICO

5. THRASHlNG

1. EL MODELO DE SISTEMA • El modelo básico a considerar es aquel en el que una colección de

procesos comparten un segmen to de DSM (véase la Figura 7).

• El segmento se hace corresponder sobre el mismo rango de direcciones en cada proceso, de forma que sobre él se pueden almacenar valores de punteros signi ficativos.

• Los procesos se ejecutan en computadores equipados con unidades de gestión de memo ria paginada. Asumiremos que únicamente hay un proceso que accede al segmento DSM en cada computador.

• En realidad puede haber varios procesos de ese tipo en cada computador. Sin embargo, esos procesos podrían entonces compartir las páginas directamente (el mismo marco de página puede aparecer en las tablas de páginas de diferentes procesos). La única complicación sería la de coordinar el envío y la propagación de actualizaciones a una página cuando dos o más procesos locales acceden a ella. En esta descripción se ignoran este tipo de detalles.

Figura 7. Modelo del sistema de un DSM basado en páginas.

1.1. El problema de la escritura actualizante

• En la práctica, la escritura actualizante se utiliza en las implementaciones basadas en página, pero sólo donde se deja a la página con permisos de escritura después de un fallo de páginas inicial y se permite que se realicen varias escrituras antes de que la página actualizada sea propagada.

• Munin utiliza esta técnica de almacenamiento de escrituras. Para mejorar la eficiencia, Munin intenta evitar la propagación de la página completa, propagando únicamente la parte que haya sido modificada. Cuando un proceso realiza un primer intento de escritura sobre una página. Munin gestiona el fallo de páginas realizando una copia de la página y guardando la copia antes de habili tar el acceso de escritura.

• Posteriormente, cuando Munin está dispuesto para propagar la página, compara la página actualizada con la copia original y codifica las actualizaciones en forma de con junto de diferencias entre las dos páginas. Estas diferencias a menudo ocupan mucho menos espa cio que la página completa. Los procesos receptores regeneran la página actualizada partiendo de la copia antes de actualizar y del conjunto de diferencias.

2. INVALIDACIÓN DE ESCRITURA • Los algoritmos basados en invalidaciones utilizan la protección de

páginas para forzar la consisten cia en la compartición de datos. Cuando un proceso está actualizando una página, tiene localmente los permisos de lectura y escritura sobre dicha página; el resto de procesos no tienen permisos de acceso sobre la página.

• Cuando uno o más procesos están leyendo una página, sólo tienen permiso de lectura; el resto de procesos no tienen permiso de acceso (a pesar de que puedan adquirir los permisos de lectura).

• No son posibles otras combinaciones. Un proceso con la versión actualizada de una página p es marcado como su propietario y esto se indica mediante la notación propietario (p). Se trata del único escritor o bien de uno de los lectores. A1 conjunto de procesos que tienen una copia de una cierta página p se le denomina conjunto de copia y se utiliza la notación conjunto copia (p) para referirse a ellos.

• Las transiciones de estado posibles se muestran en la Figura 8. Cuando un proceso Pw inten ta escribir sobre una página p sobre la que o no tiene acceso o sólo tiene acceso de lectura, se genera un fallo de página. El manejador de fallos de página realiza los siguientes pasos:

Si el procesador Pw no tienen una copia actualizada de la página, se le transfiere.

Se invalidan el resto de copias: los permisos de acceso a las páginas se modifican para impe dir el acceso de los miembros de conjuntocopia(p).

conjuntocopia(p) : = { Pw }

propietario(p) : = Pw

El soporte en tiempo de ejecución de Pw sitúa la página con permisos de lectura y escritura en la posición correspondiente en su espacio de direcciones y reinicia la instrucción que ge neró el fallo.

Figura 8. Transiciones de estado bajo invalidación de escritura

3. PROTOCOLOS DE INVALIDACION • Quedan por resolver dos problemas importantes en un protocolo que implemente el

esquema de invalidación: – 1. Cómo localizar el propietario(p) para una cierta página p. – 2. Dónde almacenar conjuntocopia(p).

• Li y Hudak [1989] describen varías arquitecturas y protocolos para Ivy, que realizan diferentes aproximaciones sobre los problemas mencionados. La más simple que describiremos es el algoritmo mejorado de gestión centralizada. En esta solución, se utiliza un único servidor, llamado gestor, para almacenar la dirección (dirección de nivel de transporte) del propietario(p) para cada página p. El gestor podría ser uno de los procesos que ejecutan la aplicación o bien cualquier otro proceso. En este algoritmo el conjunto conjuntocopia(p) se almacena en propietario(p). Es decir, se almace nan los identificadores y las direcciones de transporte de los miembros de conjuntocopia(p).

• Tal y como se puede observar en la Figura 9, cuando asume un fallo de página el proceso local (al que nos referiremos como cliente) envía un mensaje al gestor conteniendo el número de página y el tipo de acceso solicitado (lectura o lectura-escritura). El cliente espera una respuesta. El gestor procesa la solicitud realizando una búsqueda de la dirección de propietario(p) y reenvian do la solicitud al propietario. Si se trata de un fallo de escritura, el gestor configura al cliente como nuevo propietario. Las siguientes solicitudes se insertan en una cola en el cliente a la espera de que éste complete la transferencia de la propiedad sobre él mismo.

Figura 9. Gestor Central y mensajes asociados

3.1. Uso de la multidifusión para localizar el propietario

• Considérense dos clientes C1 y C2 que utilizan multidifusión para localizar una página cuyo propietario es O. Supongamos que O recibe la solicitud de C1 en primer lugar y le transfiere la propiedad. Antes de que la página llegue, la solicitud de C2 llega a O y a C1.

• O descartará la solicitud de C2 ya que ha dejado de poseer la página.

• Li y Hudak consideraron que C1, debería retrasar el procesamiento de la solicitud de C2 hasta que haya obtenido la página ya que en otro caso debería descartar dicha solicitud al no ser el propietario y la solicitud de C2 se perdería. Sin embargo, queda todavía un problema sin resolver.

• La solicitud de C1 ha sido almacenada mientras tanto en una cola en C2. Después de que C1 haya finalmente proporcionado a C2, la página, C2 recibirá y procesará la solicitud de C1, ¡la cual ahora es obsoleta!

4. UN ALGORITMO DE GESTIÓN DISTRIBUIDA DINÁMICO • La idea se basa en la división de las sobrecargas de localización de

páginas entre aquellos computadores que acceden a ellas.

• Para cada página p, cada proceso mantiene una marca del propietario actual de la página, que en realidad es el propietario probable de p o propietario Probable (p).

• Inicialmente a cada proceso se le proporcionan las localizaciones exactas para las páginas.

• Sin embargo, estos valores son meros indicios, ya que las páginas se transfieren entre los nodos en cualquier momento. Como ocurre en los algoritmos anteriores, la propiedad se transfiere sólo cuando ocurre un fallo en escritura.

• El propietario de una página es localizado siguiendo una cadena de marcas que son actualiza das al nuevo propietario cuando la página es transferida entre computadores. La longitud de la cadena, es decir, el número de mensajes de reenvío que son necesarios para localizar al propietario, amenaza con crecer de forma indefinida.

• El algoritmo resuelve este problema mediante la actualización inmediata de las marcas según vayan estando disponibles los valores más actualizados.

• El procedimiento para actualizar las marcas y reenviar las solicitudes es el siguiente:

Cuando un proceso transfiere la propiedad de una página p a otro proceso, marca como nue vo propietarioProbable(p) al receptor de la página.

Cuando un proceso gestiona una solicitud de invalidación para una página p, marca como nuevo propietarioProbable(p) al solicitante.

Cuando un proceso que ha solicitado acceso de lectura a una página p la recibe, marca como nuevo propietarioProbable(p) al nodo que se la proporcionó.

Cuando un proceso recibe una solicitud para una página p de la que no es propietario. reen vía la solicitud al propietarioProbable(p) y marca como nuevo propietarioProbable(p) al so licitante.

• Las primeras tres actualizaciones son una consecuencia del protocolo en lo que se refiere a la transferencia de la propiedad de la página y la obtención de copias de sólo lectura.

• La actualización cuando se reenvía una solicitud se justifica en que, para las solicitudes de escritura, el solicitante será pronto el propietario, incluso si no lo es actualmente.

• De hecho, en el algoritmo de Li y Hudak, la actualización de propietarioProbable se realiza tanto si la solicitud es para acceso de lectura como si lo es para escritura

(a) Situación de los punteros propietario Probable justo antes de que en el proceso A se produzca un fallo de página para una página propiedad de E

(b) Fallo en escritura: situación de los punteros propietariosProbable después de reenviar la solicitud de escritura de A

c) Fallo en lectura: situación de los punteros propietariosProbable después de reenviar la solicitud de lectura de A

Figura 10. Actualizaciones de los punteros propietarioProbable.

5. THRASHlNG • Se puede argumentar que es responsabilidad del programador evitar el thrashing. El

programador debería anotar las posiciones de sus datos para ayudar al soporte DSM a minimizar tanto el número de veces que se copian las páginas como el número de transferencias de propiedad. Esta última aproximación es discutida en la siguiente sección en el contexto del sistema DSM Munin,

• Mirage [Fleisch y Popek 1989] adopta una aproximación al thrashing transparente a los programadores. Mirage asocia cada página con un pequeño intervalo de tiempo. Una vez que un proceso ha accedido a una página, se le permite retener el acceso para e1 intervalo dado, que puede ser considerado como un intervalo de tiempo. Cualquier otra solicitud realizada sobre la página duran te dicho intervalo de tiempo es rechazada. Una desventaja obvia de este esquema es que resulta muy difícil elegir la longitud del intervalo de tiempo. Si el sistema utiliza una longitud de tiempo elegida de forma estática, ese valor puede ser inapropiado en muchos casos. Por ejemplo un proce so podría escribir una página una única vez y no volver a acceder a ella; el resto de procesos ten drían entre tanto el acceso prohibido a dicha página. Análogamente, el sistema podría ceder a otro proceso el acceso a la página antes de acabar de usarla.

• Un sistema DSM podría elegir el tamaño del intervalo de tiempo de forma dinámica.

• Un posible punto de partida para su elección podría ser la observación de los accesos sobre la página (utilizando los bits de referencia de la unidad de gestión de memoria). Otro factor que podría conside rarse es el tamaño de la cola de procesos que esperan por la página.

LIBERACION DE CONSISTENCIA Y MUNIN • La consistencia relajada se basa en la reducción de las sobrecargas de

DSM explotando el he cho de que los programadores utilizan objetos de sincronización, como semáforos, bloqueos y barreras. Una implementación DSM puede utilizar el conocimiento del acceso a estos objetos para permitir que la memoria sea inconsistente en determinados puntos, pero asegurando la consistencia a nivel de aplicación mediante la utilización de estos objetos de sincronización.

1. ACCESOS A MEMORIA

1. Tipos de accesos a memoria 2. Realización de operaciones asíncronas

2. CONSISTENCIA RELAJADA

3. MUNIN 1. Anotaciones de compartición

1. ACCESOS A MEMORIA • Para comprender la consistencia relajada (o cualquier otro modelo de memoria que

utilice la sincronización) comenzamos realizando una clasificación de los accesos a memoria en función de su papel, si existe, en la sincronización.

• Además estudiaremos cómo los accesos a memoria se pueden realizar de forma asíncrona para mejorar las prestaciones y proporcionaremos un modelo operacional sencillo de cómo se producen los accesos a memoria.

• Tal y como hemos mencionado previamente, las implementaciones DSM para sistemas distribuidos de propósito general pueden utilizar, por razones de eficiencia, paso de mensajes en lugar de variables compartidas para implementar la sincronización. Sin embargo, resultará útil mantener en mente la sincronización basada en variables compartidas para 1a siguiente discusión. El pseudocódigo que aparece a continuación implementa bloqueos utilizando la operación testAndSet sobre variables. La función testAndSet pone la variable lock a l y devuelve 0 si valía previamente cero; en otro caso devuelve 1. Esto lo hace de forma atómica.

  adquiereBloqueo(var int bloqueo): // bloqueo se pasa por referencia while (testAndSet(bloqueo) = l ) skip; liberaBloqueo(var int bloqueo): //bloqueo se pasa por referencia lock. : = 0;

1.1. Tipos de accesos a memoria • La principal distinción se realiza entre accesos competitivos y accesos no

competitivos (ordinarios). Dos accesos son competitivos si:

– Pueden ocurrir de forma concurrente (no se fuerza el mantenimiento de un orden entre ellos).

– Al menos uno de ellos es una escritura.

• Por lo tanto dos operaciones de lectura no pueden nunca ser competitivas; una lectura y una escritura sobre la misma posición realizadas por dos procesos que se sincronizan entre las operaciones (y por lo tanto las ordenan) no son competitivas.

• Además dividimos los accesos competitivos entre accesos de sincronización y de no sincronización:

– Los accesos de sincronización son operaciones de lectura o escritura que contribuyen a la sincronización.

– Los accesos de no sincronización son operaciones de lectura o de escritura concurrentes pe ro que no contribuyen a la sincronización.

• La operación de escritura implícita en bloqueo : = 0 dentro de liberaBloqueo (arriba) es un acceso de sincronización. También lo es la operación de lectura implícita en testAndSet.

• Los accesos de sincronización son competitivos, ya que los procesos que potencialmente necesitan sincronizarse acceden a variables de sincronización de forma concurrente y deben actualizarlas: las operaciones de lectura por sí solas no permiten conseguir la sincronización.

• Pero no todos los accesos competitivos son accesos de sincronización ya que existen algunos tipos de algoritmos paralelos en los que los procesos realizan accesos competitivos a variables compartidas simple mente para actualizar y leer resultados de otro y no para sincronizar.

• Los accesos de sincronización también se dividen en accesos de adquisición y accesos de liberación, en función de su papel en el bloqueo potencial del proceso que realiza el acceso o en el desbloqueo de otros procesos.

1.2. Realización de operaciones asíncronas • Supondremos que nuestro DSM es, al menos, coherente. Esto significa que cada

proceso está de acuerdo en el orden de las operaciones de escritura sobre una misma posición. Dada esta suposición, podemos hablar de forma no ambigua del orden de las operaciones de escritura sobre una cierta posición.

• En un sistema de memoria compartida distribuida, podemos dibujar un diagrama temporal para cualquier operación de memoria o que ejecute el proceso P (véase la Figura 11).

• Decimos que una operación de escritura E(x)v se ha realizado con respecto al proceso P si desde ese punto las operaciones de lectura de P devuelven el valor v escrito por la operación de escritura, o bien el valor escrito por alguna operación posterior sobre x (nótese que otra operación puede escribir el mismo valor v).

• De forma similar, decimos que una operación de lectura L(x)v se ha realizado con respecto al proceso P cuando ninguna escritura posterior iniciada sobre la misma posición pueda proporcionar el valor v que P lee. Por ejemplo, P puede haber obtenido mediante prebúsqueda el valor que necesita leer.

• Finalmente, se dice que la operación o se ha realizado si lo ha hecho respecto a todos los procesos

Figura 11. Diagrama temporal de una operación de

lectura o escritura sobre DSM

2. CONSISTENCIA RELAJADA • Los requisitos que pretendemos cumplir son:

Preservar la semántica de sincronización de objetos del tipo de bloqueos y barreras.

Mejorar las prestaciones, para lo cual se permite un cierto grado de asincronía en las operaciones de memoria.

Limitar el solapamiento entre los accesos a memoria para garantizar ejecuciones cuyos resultados sean equivalentes a los obtenidos con consistencia secuencial.

• La memoria con consistencia relajada se ha diseñado para satisfacer estos requisitos. Gharachorloo y otros [1990] definen la consistencia relajada de la siguiente forma:

CRl: Antes de permitir que una operación ordinaria de lectura o escritura se realice respecto a cualquier otro proceso, deben haberse realizado todos los accesos de adquisición previos.

CR2: Antes de permitir que una operación de liberación sea realizada con respecto a cualquier otro proceso, deben haberse realizado todas las operaciones ordinarias de lectura y escritura previas.

CR3: Las operaciones de adquisición y liberación son secuencialmente consistentes entre ellas.

Figura 12. Procesos ejecutándose en un DSM con consistencia relajada.

Proceso 1: adquiereBloqueo(); // entra a la sección crítica a := a + 1; b := b + 1; liberaBloqueo() // sale de la sección crítica

  Proceso 2:

adquiereBloqueo(); // entra a la sección crítica print(“los valores a y b son”, a,b); liberaBloqueo() // sale de la sección crítica

3. MUNIN • El diseño del sistema DSM Munin [Carter y otros 1991] intenta

mejorar la eficiencia de DSM me diante la implementación del modelo de consistencia relajada. Además, Munin permite a los programadores anotar sus datos según el tipo de compartición, de forma que se pueden realizar opti mizaciones en las opciones de actualización seleccionadas para la gestión de la consistencia.

• Ha sido implementado sobre el núcleo V [Cheriton y Zwaenepoel 1985], que fue uno de los primeros núcleos que permitían a los hilos de nivel de usuario manejar los fallos de página y manipular las tablas de páginas.

• Los siguientes puntos se refieren a la implementación de la consistencia relajada en Munin:

• * Munin envía la información de actualización o invalidación tan pronto como se libere el bloqueo

3.1. Anotaciones de compartición

• Munin implementa diferentes protocolos de consistencia aplicados con una granularidad a nivel de datos individuales. Los protocolos están parametrizados según las siguientes opciones:

Protocolo de escritura actualizante o de invalidación de escritura.

Que puedan o no existir de forma simultánea varias copias de un dato modificable.

Que se retarden o no las actualizaciones o las invalidaciones (por ejemplo, bajo la consisten cia relajada).

Que los datos tengan o no un propietario fijo, al que se deben enviar todas las actualizaciones. .Que el mismo dato pueda o no ser modificado concurrentemente por varios escritores.

Que los datos puedan o no ser compartidos por un conjunto fijo de procesos;

Que los datos puedan o no ser modificados.

• Estas opciones son elegidas en función de la naturaleza de los datos y de sus patrones de comparti ción entre procesos. El programador puede elegir de forma explícita qué opciones usar para cada dato. Sin embargo, Munin proporciona un conjunto pequeño, estándar de anotaciones válidas para una gran variedad de aplicaciones y datos para que el programador las aplique sobre los datos; cada una de estas anotaciones supone una elección adecuada de los parámetros. Son las siguientes:

• Sólo lectura

• Migratorio

• Escritura compartida

• Productor-consumidor

• Reducción

• Resultado

• Convencional

Otros Modelos de Consistencia • Los modelos de consistencia de memoria se pueden dividir entre modelos

uniformes, caracterizados por no distinguir entre diferentes tipos de accesos a memoria y modelos híbridos, los cuales distinguen entre accesos ordinarios y de sincronización (al igual que otros tipos de accesos).

• Existen varios modelos uniformes más débiles que el modelo de consistencia secuencial. En la Sección 2.3 se presentó la coherencia como la consistencia secuencial sobre cada posición de memoria. Los procesos acuerdan el orden de todas las escrituras sobre una cierta posición, pero el orden de las escrituras desde diferentes procesadores sobre diferentes posiciones puede variar

• Otros modelos de consistencia uniforme son: – Consistencia causal – Consistencia de procesador – RAM encauzada

• Además de la consistencia relajada, otros modelos híbridos son los siguientes:

– Consistencia con admisión – Consistencia de ámbito – Consistencia débil

CONCLUSION • Se ha descrito y justificado el concepto de memoria compartida distribuida como una

abstracción de la memoria compartida que sirve de alternativa a la comunicación basada en mensajes en un sistema distribuido. El objetivo principal de DSM es el procesamiento paralelo y la compartición de los datos. Se ha demostrado que sus prestaciones son comparables a las del paso de mensajes para ciertas aplicaciones paralelas, pero es difícil conseguir una implementación efi ciente y sus prestaciones dependen en gran medida de las aplicaciones.

• Este trabajo se ha centrado en las implementaciones software de DSM (en particular aquellas basadas en el subsistema de memoria virtual) con un cierto soporte del hardware.

• Las principales cuestiones de diseño e implementación son la estructura de DSM, la forma de sincronizar las aplicaciones, el modelo de consistencia de memoria la utilización de protocolos de escritura actualizante o de invalidación de escritura, la granularidad de la compartición y el thrashing.

• DSM puede estructurarse como una serie de bytes, como una colección de objetos compartidos o como una colección de datos inmutables como las tuplas.

• Las aplicaciones en DSM necesitan la sincronización para cumplir los requisitos de consisten cia específicos de la aplicación. Para este propósito utilizan objetos como los bloqueos, implementados utilizando paso de mensajes por razones de eficiencia.