Memoria Compartida Distribuida Memoria Compartida Distribuida Universidad Simón Bolívar Departamento de Computación y T.I Sistemas de operación III CI-4822 Prof. Yudith Cardinale Sept - Dic 2010

Introducción: Taxonomía de Computadores Paralelos y Distribuidos Comp. Paralelos y Distribuidos Multiprocesadores (Mem. Compartida)‏ Switched Bus Multicomputadores (Mem. Privada)‏ Bus Fuertemente acoplados Débilmente acoplados

Multiprocesadores Tienen memoria compartida Son sistemas altamente acoplados: cuando se envía un mensaje el retardo es corto y la tasa es alta. Comunes en sistemas paralelos. Multicomputadores Cada procesador tiene su memoria privada. Sistemas débilmente acoplados: el retardo es notable y la tasa es baja. Son más comunes en sistemas distribuidos. Bus: es una sola red, cable o cualquier otro medio que conecta todas las máquinas. Switch: puede haber conexiones de máquina a máquina (en distintas organizaciones). Introducción: Taxonomía de Computadores Paralelos y Distribuidos

Introducción Sistemas con Memoria Compartida: Soporte de Software: Resuelven problenas de secciones críticas Primitivas de sincronización: semáforos, contadores, secuenciadores, monitores. Comunicación por espacios de memoria compartidos Soporte de Hardaware: Limitado en la escalabilidad Difícil de construir El acceso a la memoria es un cuello de botella ( Es difícil diseñar una máquina donde varios procesadores utilicen la misma memoria. Si la arquitectura está basada en bus, no es escalable. Con switches se obtiene una mayor escalabilidad pero son costosos, lentos, complejos)

Introducción Sistemas con Memoria Distribuida: Soporte de Software: Pase de mensajes: trae complicaciones adicionales como pérdida de mensajes, pérdida de orden, etc. RPC RMI Protocolos de comunicación: Buffering, bloqueo... Soporte de Hardware: Fácil de construir No está limitada la escalabilidad

Sistemas de Memoria Compartida Distribuida Toma las ventajas de los enfoques anteriores: software de los sistemas de memoria compartida y el hardware de los sistemas de memoria distribuida Colección de estaciones de trabajo conectadas por una red, compartiendo un único espacio de memoria virtual paginado La ubicación de los datos, su movimiento, etc, lo maneja el sistema de memoria compartida distribuida. Implementado sobre pase de mensajes

Introducción: Sistemas de Memoria Compartida Distribuida Soporte por Hardware: Paginación [Li, 1986] y [Li and Hudak, 1989] fueron los primeros en proponer el paradigma de Memoria Compartida Distribuida: Paginación: en el modelo más simple, una página reside sólo en un procesador. Una referencia a una página causa una falla de página que atrapa el SOP. Este último envía un mensaje a la máquina remota, para solicitar la página. Es un sistema fácil de programar y fácil de construir pero el desempeño es pobre. Puede causar mucho tráfico de red Impone restricciones al programador

Introducción: Sistemas de Memoria Compartida Distribuida Soporte por Software: Compartiendo estructuras de datos: No se comparte toda la memoria sólo se comparten algunas estructuras a un nivel de abstracción más alto Se puede hacer por replicación pero se debe resolver los problemas de consistencia Se puede hacer por compartimiento pero hay problemas de comunicación y cuello de botella

Introducción: Sistemas de Memoria Compartida Distribuida Soporte por Software (cont.): Compartiendo objetos encapsulados: Los datos no se acceden directamente, existen métodos para realizar las lecturas y actualizaciones El compartimiento puede ser a un nivel de abstracción muy alto.

Arquitecturas de Memoria Compartida Los multiprocesadores de Memoria Compartida constituyen la inspiración de los sistemas de memoria compartida distribuida

Arquitecturas de Memoria Compartida Memoria con circuitos (on-chip-memory): CPU Mem CPU Mem CPU Es posible pero es complicado, costoso e inusual

Arquitecturas de Memoria Compartida Multiprocesadores basados en buses: Problema con el cache: Posibilidad de Memoria Incoherente Solución: ● Protocolo de consistencia write-through cache ● Protocolo de consistencia write-once Snooping cache: Alivia la sobrecarga del bus y aumenta el rendimiento

Arquitecturas de Memoria Compartida Protocolo de consistencia write-through cache- opciones de implementación: Ante la escritura se invalidan los datos replicados Ante la escritura se actualizan todas las réplicas Caracterizar los bloques del cache: Inválido: no contiene datos válidos Limpio: la memoria está actualizada, el bloque puede estar en otros cachés Sucio: la memoria está incorrecta, ningún otro cache puede contenerlo

Arquitecturas de Memoria Compartida Protocolo de consistencia write-through cache: Actualiza en Memoria y en cache WRITE Hit Invalida la entrada en su cache Actualiza en Memoria y trae el dato a cache WRITE Miss Ninguna AcciónLee localmente del cacheREAD Hit Ninguna AcciónTrae el dato desde Memoria y actualiza en cache READ Miss Acción de otros caches Acción del cache del CPU que realiza el evento Evento Invalida la entrada en su cache

Arquitecturas de Memoria Compartida Protocolo de consistencia write-through cache: En lugar de invalidar se puede actualizar las copias ante un write, pero las actualizaciones son más costosas porque requieren de más ciclos de memoria Es simple de entender e implementar Todas las escrituras usan el bus lo que causa pobre desempeño Es poco escalable en cuanto a número de CPUs.

Arquitecturas de Memoria Compartida Protocolo de consistencia write-once: Supone que una vez que un CPU se apodera de un dato, es difícil que otro lo requiera El caché es dividido en bloques que pueden estar en uno de estos tres estados: Inválido: no contiene datos válidos Limpio: la memoria está actualizada, el bloque puede estar en otros caches Sucio: la memoria está incorrecta, ningún otro cache puede contenerlo La idea es que si varios quieren leer, comparten el dato y puede estar en varios caches. Si el dato es de escritura sólo un cache lo puede contener y realiza sólo actualizaciones locales

Arquitecturas de Memoria Compartida Protocolo de consistencia write-once: ABC W1 w1 Limpio W1 está en memoria y en el caché de B en estado limpio. La memoria está correcta ABC W1 Limpio w1 Limpio A lee W1 desde la memoria, B no es afectado. La memoria está correcta

Arquitecturas de Memoria Compartida Protocolo de consistencia write-once (cont.): ABC W1 A escribe un valor W2, B husmea en el bus, ve la escritura e invalida su entrada. La copia de A se marca como sucia. ABC W1 w1 Inválido W3 Sucio A escribe un nuevo valor. Ésta y todas las escrituras posteriores se harán localmente sin usar el bus. W2 Inválido Sucio

Arquitecturas de Memoria Compartida Protocolo de consistencia write-once (cont.): ABCW1 C lee o escribe a W3, A ve la solicitud al husmear el bus, proporciona el valor e invalida su entrada. C tiene ahora la única copia válida. inválido W3 inválido Sucio W3 El caché que tiene la última copia es el responsable de enviar una señal a la memoria para que no responda ante una solicitud de otro caché. Mientras el dato no se actualice en memoria la única copia permanerá en estado sucia. Permanecerá en este estado hasta que deba salir de caché por razones de espacio, en ese momento se actualiza en memoria.

Arquitecturas de Memoria Compartida Protocolo de consistencia write-once (cont.): La consistencia se logra haciendo que todos los cachés husmeen el bus. El protocolo se integra dentro de la unidad de administración de memoria (hardware)‏ Todo el algoritmo se realiza en un ciclo de memoria Este protocolo no es válido para memoria compartida distribuida

Arquitecturas de Memoria Compartida Multiprocesadores basados en anillo: Memnet (1988): tiene un espacio de direcciones que se divide en una parte privada y una compartida La parte privada se divide en regiones La parte compartida se divide en bloques de 32 bytes. Todas las máquinas están conectadas por un anillo donde circula un token de solicitudes Primera arquitectura de memoria compartida distribuida

Arquitecturas de Memoria Compartida MMU caché Home memory Blocks table CPU MEMORIA PRIVADA... b 0 1 n VEOIPosición b: número de bloque V: bit válido, el bloque está en el caché y actualizado E: bit exclusivo, copia única O: bit de origen I: bit de interrupción Los bloques read-only pueden estar en varias máquinas. Los bloques read-write deben estar en una sola máquina (no necesariamente la de origen)‏ Dispositivo Memnet

Arquitecturas de Memoria Compartida Protocolo de lectura: Examina la tabla de bloques para determinar si el bloque está presente, si está, la solicitud es satisfecha. Si no está presente: Espera el token de solicitudes, coloca la solicitud en el token, suspende el CPU. El paquete de solicitud contiene la dirección deseada y un campo vacío de 32 bytes A medida que el token circula, cada CPU verifica si contiene el dato. Si lo tiene lo coloca en el campo vacío y modifica el encabezado de la solicitud para inhibir la acción de los otros CPUs. Si no lo contiene pasa el token. Si el bit Exclusivo está encendido, se limpia. Si la máquina receptora no tiene espacio libre en el caché para alojar el nuevo dato, selecciona uno al azar (que no sea de los que tienen el bit de Origen encendido) y lo envía a su máquina origen.

Arquitecturas de Memoria Compartida Protocolo de escritura, se distinguen tres casos: El bloque deseado está presente y el bit Exclusivo está encendido (única copia), entonces se actualiza localmente. El bloque deseado está presente y el bit Exclusivo no está encendido (existen más copias), entonces se envía un paquete de invalidación para que las otras máquinas invaliden este bloque. Cuando el paquete de invalidación regresa, se enciende el bit Exclusivo y se actualiza el dato. Si el bloque no está presente, se envía un paquete que combina una solicitud y una invalidación. La primera máquina que tenga el bloque lo pone en la solicitud e invalida su entrada, el resto de las máquinas sólo invalidan su entrada. Cuando el paquete retorna al emisor inicial se realiza la actualización

Arquitecturas de Memoria Compartida Multiprocesadores con conmutador (NUMA): Tanto los multiprocesadores basados en bus como los basados en anillo no pueden escalar a más de 64 procesadores porque degradan el desempeño Se puede mejorar la capacidad del bus si se reduce la cantidad de comunicación (uso de caché)‏ Se puede mejorar la capacidad del bus si se incrementa la capacidad de comunicación (organizando los buses en jerarquía)‏

Arquitecturas de Memoria Compartida Multiprocesadores con conmutador-NUMA (cont): ABCM ABCM ABCM Bus intra cluster Bus inter clusters Cluster ABCM ABCM ABCM ABCM ABCM ABCM Bus inter super clusters

Arquitecturas de Memoria Compartida Multiprocesadores con conmutador-NUMA (cont): DASH ( Directory Architecture for Shared Memory)‏ Arquitectura DASH ( Directory Architecture for Shared Memory)‏ Compuesta de 16 clusters (0 al 15)‏ Cada cluster contiene un bus, 4 CPUs, 16 MB de memoria y dispositivos de I/O. La cantidad de memoria total es de 256 MB, dividida en 16 regiones de 16MB cada una. El cluster 0 contiene las direcciones desde 0 a 16MB, el cluster 1 contiene las direcciones desde 16MB hasta 32MB y así sucesivamente La unidad de transferencia es un bloque de 16 bytes

Arquitecturas de Memoria Compartida DASH (arquitectura NUMA)‏ Arquitectura DASH (arquitectura NUMA)‏ Directorios: cada cluster tiene un directorio que contiene la información de cuáles clusters tienen copias de sus bloques. El tamaño es de 1M de entradas de 18 bits cada una BLOQUES CLUSTERS ESTADO: UNCACHED: La única copia está aquí CLEAN: memoria correcta, puede haber más copias DIRTY: memoria incorrecta, sólo un caché tiene el bloque

Arquitecturas de Memoria Compartida DASH Arquitectura DASH ● En todo momento cada bloque tiene un propietario ● Para un bloque uncached o clean el cluster de origen del bloque es el propietario ● Para un bloque dirty el cluster que contiene la única copia es el propietario ● Para escribir en un bloque clean primero hay que encontrar e invalidar todas las copias existentes (el cluster propietario es el que en ese momento es el responsable del bloque y no necesariamente es el cluster origen)‏

Arquitecturas de Memoria Compartida DASH Arquitectura DASH ● Protocolo de lectura : Chequea en su propio caché, si no está Pone el requerimiento en el bus local, si algún caché local lo tiene se realiza una copia caché-to-caché. Si el bloque está clean sólo se realiza la copia, si el bloque está dirty se informa al directorio de origen para que cambie el estado a dirty and shared Si el bloque no está presente en ningún caché del cluster, se envía el requerimiento al cluster de origen del bloque (se determina por los 4 bits más altos de su dirección)‏ El cluster origen puede ser el mismo que realizó el requerimiento, en este caso no se envía físicamente el paquete de requerimiento

Arquitecturas de Memoria Compartida DASH Arquitectura DASH Protocolo de lectura (cont): El hardware del directorio del cluster de origen examina el estado del bloque: ● Uncached or clean: el hardware trae el bloque de la memoria principal, lo envía al cluster solicitante y marca en el directorio que tal bloque está cached en el cluster solicitante. ● Dirty: el hardware del directoio busca la identidad del cluster que lo contiene y le hace forward del requerimiento. El cluster final que contiene el bloque dirty envía el bloque al cluster solicitante, lo marca como clean (ahora es compartido) y envía un mensaje al cluster origen para que actualice la memoria y le cambie el estado a clean

Arquitecturas de Memoria Compartida DASH Arquitectura DASH Protocolo de escritura: Si está en su caché y es dirty, la escritura procede Si está en su caché y es dirty, la escritura procede Si está en su caché y es clean se envía un paquete al cluster origen requiriendo que todas las otras copias sean invalidadas Si está en su caché y es clean se envía un paquete al cluster origen requiriendo que todas las otras copias sean invalidadas Si no está en su caché pero está en el cluster se realiza una copia caché-to-caché o memory-to-caché. Si el estado es clean todas las copias deben invalidarse por el cluster origen Si no está en su caché pero está en el cluster se realiza una copia caché-to-caché o memory-to-caché. Si el estado es clean todas las copias deben invalidarse por el cluster origen Si no está en el cluster, se envía el requerimiento al cluster origen, se distinguen tres casos: Si no está en el cluster, se envía el requerimiento al cluster origen, se distinguen tres casos:

Arquitecturas de Memoria Compartida DASH Arquitectura DASH Protocolo de escritura (cont): Uncached: se marca dirty y se envía al cluster que lo requiere. Uncached: se marca dirty y se envía al cluster que lo requiere. Clean: se invalidan todas las copias y se sigue el proceso de uncached Clean: se invalidan todas las copias y se sigue el proceso de uncached Dirty: se hace forward del requerimiento al cluster que actualmente tiene el bloque. Este cluster invalida su propia copia y satisface el requerimiento Dirty: se hace forward del requerimiento al cluster que actualmente tiene el bloque. Este cluster invalida su propia copia y satisface el requerimiento

Arquitecturas de Memoria Compartida : Otros multiprocesadores NUMA (Non Uniform Memory Access) : Cm* System BBN Butterfly Propiedades de los multiprocesadores NUMA Son posibles los accesos a memorias remotas Los accesos a las memorias remotas son más lentos que los accesos a la memoria local Los tiempos de acceso remoto no son escondidos por caching. Los accesos se manejan con esquemas de paginación (page fault), replicación (o mapping) de páginas read-only, si son read-write se invalidan, se usa un page-scanner.

Comparación de los Sistemas de Memoria Compartida Single- bus Multi- Pro. Switched Multi- Pro. Numa Page- Based DSM Object- Based DSN Shared- Variable DSM Hardware-controlled caching Software-controlled caching Managed by MMU Managed by language runtime system Managed by OS Remote access in hardwareRemote access in software Cache block Cache block Page Data Structure Object Firefly DashButerflyIvyMunin Linda, Orca CORBA

SiNo Métodos de encapsulamiento ObjetoVar. Compartida Página Bloque Unidad de transferencia Sw Hw La migración la realiza Red Bus Medio de transferencia Runtime System OSMMU Quien convierte los accesos remotos a memoria en mensajes No Si Es posible una memoria no asociada a un CPU particular No Si El acceso remoto es posible en Hw GeneralR-W Operaciones posibles No Si Espacio lineal de memoria compartida MultiprocesadoresDSM NUMA Pág. Var. Comp. Obj.

DSM: Aspectos de Diseño e Implementación Replicación Estructura Localización de los datos Políticas de escritura Política de reemplazo de páginas Modelos de consistencia

Replicación Replicación Replicar los bloques de sólo lectura Replicar todos los bloques: en este caso se tienen que tomar acciones para mantener la consistencia de los datos Cpu1Cpu

Estructura Orientada a bytes Una palabra Un bloque (varias palabras)‏ Una página Un segmento (múltiples páginas)‏ Variables compartidas Objetos

Localización de los datos Localización del propietario: posee o bien la copia de los datos que se puede escribir, o una de las copias de lectura y una lista con los otros nodos que poseen copias de lectura. Es al único que se le permite actualizar los datos. ● Un propietario fijo: cada pieza de datos se asigna a un propietario fijo. A los otros procesadores no se les da acceso directo a los datos y deben comunicarse con el propietario cada vez que desean hacer operaciones de escritura.

Localización de los datos Propietario que varía dinamicamente: el problema es localizar al propietario. Se introduce el concepto de manager, que tiene la información sobre quién es el propietario actual de los datos. ●Centralizado: el manager es un único nodo. Los accesos a los datos se negocian con el manager. Es un cuello de botella. ManagerOwnerP Request Reply Request ManagerOwnerP Request Reply Request

Localización de los datos Distribuido: la información sobre los propietarios se distribuye entre los nodos. Cómo se localiza al propietario de un item de datos? Fijo: hay un esquema fijo para localizar al manager de los datos. El manager informa cuál es el propietario, quien puede variar dinámicamente. Dinámico: Broadcast: se envía un broadcast para encontrar quién es el propietario de los datos. Ineficiente cuando la red subyacente no soporta el broadcast. Dinámico: Cada procesador tiene el propietario probable de cada item. Es una especie de pista. Si la pista es incorrecta, al menos representa el comienzo de una cadena de procesadores a partir de la cual se llega hasta el propietario. Cuando se encuentra cuál es el propietario actual, se modifica la pista. Alternativa: un broadcast intermitente.

Localización de los datos Localización de las copias Broadcast: trabaja bien si los mensajes nunca se pierden (broadcast confiable)‏ Copysets: dice qué procesadores almacenan qué páginas. Cuando se necesita invalidar una página el propietario o el manager envía un mensaje a cada procesador que contenga la página y espera por un Ack. La invalidación culmina cuando se han recibido los acks.

Localización de los Datos Cpu 1Cpu 3Cpu Cpu copyset page

Políticas de Escritura Se debe asegurar que un procesador no lea un dato invalido después que se ha realizado una operación de escritura. Existen dos opciones: Escritura actualizante Escritura Invalidante

Políticas de Escritura Escritura actualizante : Las escrituras de un proceso se realizan en forma local y se envían a todos los procesos que posean una copia del dato. Permite múltiples lectores y múltiples escritores. Se requieren broadcast o multidifusiones ordenadas (en algunos casos se utiliza un ente centralizado que garantiza el orden). De esta forma todos los procesos ven todas las actualizaciones en el mismo orden que se realizan. Orca es un sistema que implementa escritura actualizante. Munin soporta escritura actualizante como una opción.

Políticas de Escritura Escritura invalidante : Múltiples lectores/un solo escritor. Cuando un proceso intenta escribir un dato, se envía un mensaje a quienes tienen copias para invalidarlas y se esperan los Acks, antes que la escritura tenga lugar. Las actualizaciones se propagan cuando se leen los datos y se pueden realizar varias actualizaciones consecutivas sin necesidad de realizar ninguna comunicación. Se tienen que invalidar copias de sólo lectura

Políticas de Reemplazo Mejores candidatos a víctima: Una página de la que existe otra copia cuyo dueño es otro procesador Una página replicada de la cual se es propietario. Cuando no existen réplicas: La página válida usada menos recientemente (LRU). Qué se hace con la victima? Escribirla a disco Pasarla al propietario: Estático Dinámico: procesador que tenga mas memoria libre.

Modelos de Consistencia de la Memoria Un modelo de consistencia de memoria [Mosberger 1993] especifica las garantías de consistencia que un sistema otorga sobre los valores que los procesos leen de los objetos, dado que en realidad acceden a una réplica de cada objeto y que múltiples procesos pueden actualizar los objetos.

Modelos de Consistencia de la Memoria La principal interrogante que se plantea al caracterizar un modelo de consistencia de memoria es: cuándo se realiza un acceso de lectura sobre una posición de memoria, qué accesos de escritura son candidatos para que sus valores sean proporcionados en la lectura? Cualquier lectura realizada antes. La última lectura, Etc.

Modelos de Consistencia de la Memoria Los modelos que estudiaremos son: Consistencia estricta Consistencia secuencial Consistencia causal PRAM Consistencia débil Consistencia relajada

Consistencia Estricta Cualquier lectura a la localidad de memoria x retorna el valor almacenado por la última operación de escritura (antes de la lectura). Supone la existencia de un tiempo global. Determinar cuál fue la escritura más reciente no siempre es posible. En un solo procesador la consistencia estricta es lo esperado. A = 1 A = 2 print(A)‏ AB x 2 segs T1 Read(x)‏ (A) ‏ T2 Write(x)‏ (B) ‏ T3 Llega a B petición de A para escribir X T0 Write(x)‏ (B) ‏

Consistencia Estricta En un sistema distribuido es razonable exigir consistencia estricta? Notación: P1, P2 : procesos W(x)a : A la variable x se le asigna el valor a R(y)b : Se lee b en la variable y Se supone que el valor inicila de todas las variables es 0. P1: W(x)1 P2: W(x)2 Tiempo

Consistencia Estricta P1: W(x)1 P3: R(x)2 P2: W(x)2 P1: W(x)1 P3: R(x)1 P2: W(x)2 P1: W(x)1 P2: R(x)0 R(x)1 T1: petición de escritura desde P1 T2: Un proceso en P2 lee valor de x T3: llega petición de escritura de P1 T4: Un proceso en P2 lee el valor de X

Consistencia Estricta Si hay un cambio en una zona de memoria, todas las lecturas observarán el nuevo valor sin importar cuán pronto se está haciendo la lectura (respecto a la escritura) o dónde están localizados los procesos que realizan las operaciones. Si se hace una lectura se obtiene el valor actual, sin importar cuán rápido se realiza la próxima escritura.

Consistencia Secuencial (Lamport, 1979)‏ La consistencia estricta es prácticamente imposible de implementar en un sistema distribuido. La experiencia demuestra que a un programador le bastan modelos más débiles

Consistencia Secuencial Cuando se ejecutan procesos en paralelo sobre diferentes máquinas, cualquier mezcla de ejecución es un resultado aceptable, no obstante todos los procesos deben ver la misma secuencia de referencias a memoria. Se respeta el orden de los programas. P1: W(x)1 P2: R(x)0 R(x)1 P1: W(x)1 P2: R(x)1 R(x)1 Write(x)‏Read(x)‏ Los dos resultados son válidos desde el punto de vista de consistencia secuencial

Consistencia Secuencial a=1 print(b,c)‏ (a)‏ c=1 print(a,b)‏ (c)‏ b=1 print(a,c)‏ (b)‏ a = 1 print (b,c)‏ b = 1 print (a,c)‏ c = 1 print(a,b)‏ Prints: a = 1 c = 1 print (a,b)‏ print (a,c)‏ a = 1 print(b,c)‏ a = 1 b = 1 print (a,c)‏ print (b,c)‏ c = 1 print(a,b)‏ Prints: Prints: y son resultados inválidos Los tres resultados son válidos y las aplicaciones deben funcionar bien en presencia de cualquiera de ellos Las operaciones son atómicas

Consistencia Secuencial Un sistema de consistencia secuencial se puede implementar utilizando un único servidor que administra los datos compartidos. Todos los procesos envían sus operaciones de lectura y escrtitura al servidor que las ordena en forma global.

Consistencia Causal (Hutto and Ahamad, 1990)‏ Si un evento B es causado o influenciado por un evento A, la causalidad requiere que todo el mundo vea primero el evento A y luego el B. Cuando encontramos una lectura seguida por una escritura, los dos eventos están potencialmente relacionados en forma causal. Un read está relacionado causalmente con la escritura que provee el dato que se ha leído. P1 escribe X P2 lee X escribe Y (Y puede depender del valor leído de X)‏

Consistencia Causal Si dos procesos escriben espontáneamente y simultáneamente una variable, estos accesos no están relacionados causalmente. Las operaciones que no están relacionadas causalmente se dice que son concurrentes

Consistencia Causal Las escrituras relacionadas causalmente deben ser vistas por todos los procesos en el mismo orden. Las escrituras concurrentes pueden ser vistas en un orden diferente, en diferentes máquinas. P1: W(x)1 W(x)3 P3: R(x)1 R(x)3 R(x)2 P2: R(x)1 W(x)2 P4: R(x)1 R(x)2 R(x)3 Hay consistencia causal pero no consistencia secuencial o consistencia estricta concurrentes

Consistencia Causal P1: W(x)1 P3: R(x)2 R(x)1 P2: R(x)1 W(x)2 P4: R(x)1 R(x)2 Violación de la Consistencia Causal P1: W(x)1 P3: R(x)2 R(x)1 P2: W(x)2 P4: R(x)1 R(x)2 Una sucesión de eventos correcta con Consistencia Causal

Consistencia Causal Implementación: grafo de dependencia para determinar cuáles operaciones son dependientes de otras y cuáles son concurrentes. Un ente centralizado.

Consistencia PRAM (Pipelined RAM) (Lipton and Sandberg 1988)‏ Las escrituras realizadas por un proceso, son recibidas por el resto en el orden en el cual éstas fueron ejecutadas, no obstante, las escrituras realizadas por diferentes procesos pueden ser vistas en órdenes diferentes por todos ellos P1: W(x)1 P3: R(x)2 R(x)1 P2: R(x)1 W(x)2 P4: R(x)1 R(x)2 Una sucesión correcta de eventos con Consistencia PRAM

Consistencia PRAM (Pipelined RAM) (Lipton and Sandberg 1988)‏ P1: W(x)1 W(x) 3 P3: R(x)2 R(x)1 R(x) 3 P2: R(x)1 W(x)2 P4: R(x)1 R(x)2 R(x) 3

Consistencia PRAM a = 1 print (b,c)‏ b = 1 print (a,c)‏ c = 1 print(a,b)‏ b = 1 print (a,c)‏ c = 1 print (a,b)‏ a = 1 print(b,c)‏ a = 1 b = 1 print (a,c)‏ print (b,c)‏ c = 1 print(a,b)‏ (a)‏ (c)‏ (b)‏ a = 1 if (b == 0) kill (p2)‏ b = 1 if (a == 0) kill (p1)‏ (a)‏(b)‏

Consistencia PRAM a = 1 if (b == 0) kill (p2)‏ b = 1 if (a == 0) kill (p1)‏ (a)‏(b)‏ P1 muere, P2 muere, o no muere ninguno. En el modelo PRAM pueden morir los dos procesos a = 1 if (b == 0) kill (p2)‏ b = 1 if.... b = 1 if (a == 0) kill (p1)‏ a = 1 If...

Consistencia Débil (Dubois et al. 1986)‏ Los modelos anteriores se consideran aún restrictivos porque requieren que las escrituras de un proceso se vean en orden. Esto no siempre es necesario. Ej. Cuando se está en una región crítica no es necesario propagar valores intermedios sino los valores finales. Para saber que se está en una región crítica se requiere que se establezcan instrucciones explícitas.

Consistencia Débil (Dubois et al. 1986)‏ Se introduce un nuevo tipo de variable: variables de sincronización. Los accesos a las variables de sincronización son secuencialmente consistentes: todos los procesos ven todos los accesos a las variables de sincronización en el mismo orden. No se permite el acceso a ninguna variable de sincronización hasta que todas las escrituras previas se hayan completado: Hacer una sincronización después de operaciones de escritura obliga a que los nuevos valores se propaguen a todas las memorias.

Consistencia Débil (Dubois et al. 1986)‏ El hacer una operación de sincronización antes de leer los datos, le garantiza a un proceso que leerá los últimos valores. Operación de sincronización: garantiza que las escrituras locales sean propagadas a todas las otras máquinas y se actualiza la memoria actual con escrituras hechas remotamente.

Consistencia Débil P1: W(x)1 W(x)2 S P2: S R(x)1 P1: W(x)1 W(x)2 S P3: R(x)2 R(x)1 S P2: R(x)1 R(x)2 S Variables ordinarias

Consistencia Relajada (Gharachorloo et al., 1990)‏ Se proveen dos operaciones: ● Acquire: la memoria se asegura que todas las copias locales de las variables protegidas se actualizan con las variables remotas. ● Release: con esta operación se propagan los cambios realizados a las variables protegidas al resto de las máquinas. El programador es el responsable de colocar estas operaciones correctamente en su programa

Consistencia Relajada Realizar un acquire no garantiza que los cambios realizados sean propagados al resto de las máquinas en forma inmediata. De forma similar, el realizar un release no garantiza que se importen cambios realizados por otras máquinas. P1: Acq(L) W(x)1 W(x)2 Rel(L)‏ P3: R(x)1 P2: Acq(L) R(x)2 Rel(L)‏

Consistencia Relajada Posible implementación: Existe un administrador de sincronización. En un acquire se solicita un acceso sobre un lock al manger. Si no hay competencia el manager lo otorga. Al llegar al release se propagan los cambios a otras máquinas. Al recibirse el Ack de todas las máquinas se informa al manager de la liberación del lock

Modelos de Consistencia Todos los procesos ven las escrituras de un mismo proceso en el orden en el que se realizaron. Las escrituras de distintos procesos no siempre se ven en el mismo orden. Los programadores (con estos dos últimos modelos) deben evitar instrucciones que sólo trabajan con consistencia secuencial PRAM Todos los procesos ven los accesos compartidos, relacionados causalmente, en el mismo orden Causal Todos los procesos ven todos los accesos en el mismo orden. Popular entre los programadores y ampliamente usado. Desempeño pobre. Secuencial Todos los accesos compartidos se observan en el orden en el que se realizaron. Imposible de implementar en DSM Estricta DescripciónConsistencia: Modelos que no usan operaciones de sincronización

Modelos de Consistencia Los datos compartidos están consistentes cuando se sale de la región crítica. Estos modelos pueden ser más eficientes pero requieren más esfuerzo del programador Relajada Se garantiza que los datos compartidos están consistentes después de la operación de sincronización Débil DescripciónConsistencia: Modelos con operaciones de sincronización

Conclusiones DSM es una abstracción de memoria compartida que sirve de alternativa a la comunicación basada en el pase de mensajes. Su rendimiento es comparable al rendimiento de pase de mensajes para ciertas aplicaciones paralelas. El rendimiento depende en gran medida de las aplicaciones. Entre los principales aspectos de diseño e implementación se encuentran: la estructura, los modelos de consistencia, la utilización de protocolos de escritura actualizante o invalidante y la granularidad.