INSTITUTO TECNOLOGICO DE COSTA RICA DEPARTAMENTO DE COMPUTACION PROGRAMA DE MAESTRIA

Memoria Compartida Distribuida en Ambientes de Bajo Costo

Tesis para optar al grado de Magister Scientiae en Computacin o

Federico Meza Montoya

Cartago, Costa Rica Febrero, 2001

APROBACION DE BORRADOR DE TESIS

Memoria Compartida Distribuida en Ambientes de Bajo Costo

Alvaro Campos, Ph.D. Profesor Asesor (Visto Bueno)

Francisco Torres, Ph.D. Director Maestr (Referendo) a

APROBACION DE TESIS

Memoria Compartida Distribuida en Ambientes de Bajo Costo

Tribunal Examinador

Marcelo Jenkins Coronas, Ph.D. Profesional Externo

Miembro Tribunal Profesor

Miembro Tribunal Profesor

Alvaro Campos, Ph.D. Profesor Asesor

Francisco Torres, Ph.D. Director Maestr (Referendo) a

A todos los que me han ayudado a ser lo que hoy soy. A mis paps, por darme la vida, su amor, apoyo y sacricio. a A Cao, por ser todo lo que me hac falta, y permitirme estar con ella. a A don Alvaro, por su direccin, amistad e innita paciencia. o A los gatos y perras por acompaarme mientras escrib n a.

Esta tesis se pudo desarrollar gracias al nanciamiento de FondecytChile, a travs e del Proyecto 299074. Asimismo, gracias a una beca otorgada por la Universidad de Costa Rica, por conducto del Sistema de Estudios de Postgrado. Se hace extensivo el agradecimiento al Departamento de Ciencia de la Computacin de la Universidad o Catlica de Chile y, en especial, al Dr. Alvaro Campos. o

ii

RESUMEN Los sistemas de Memoria Compartida Distribuida, MCD, implementan una semna tica de memoria compartida sobre hardware de intercambio de mensajes. De esta forma se obtiene las ventajas de costo, facilidad de construccin y escalabilidad de los sisteo mas multicomputador dbilmente acoplados, pero a la vez, la facilidad de programacin e o inherente a los multiprocesadores de memoria compartida. En esta tesis se presenta el diseo e implementacin de DSM-PEPE, un sistema de MCD para computadores personales n o enlazados mediante redes estndares. El sistema cumple con dos objetivos primordiales. a Primero, es util como plataforma de experimentacin en tpicos relacionados con MCD. o o Su diseo permite la modicacin e incorporacin de componentes, as como la recolecn o o cin de estad o sticas de las ejecuciones. Segundo, DSM-PEPE constituye un ambiente de ejecucin de programas paralelos, con un enorme potencial computacional a un costo o muy bajo. DSM-PEPE tiene granularidad a nivel de pgina e incorpora un protocolo de a consistencia secuencial. Nuevos protocolos pueden ser agregados de manera muy simple, derivando una clase de objetos preexistente. El sistema opera sobre computadores personales controlados por el sistema operativo Windows NT. La comunicacin se lleva o a cabo empleando protocolos estndares por lo que puede aprovecharse las redes exisa tentes. El sistema es multithreaded, y su diseo se hizo pensando en la incorporacin de n o procesos del usuario compuestos por mltiples threads de ejecucin. La programacin u o o en DSM-PEPE es sencilla, dada la semntica de memoria compartida que implementa. a Unas pocas funciones componen la interfaz de programacin. La sincronizacin distrio o buida se ofrece en dos mecanismos: Barreras y locks. Portar a DSM-PEPE aplicaciones previamente escritas para un multiprocesador de memoria compartida no presenta mayores complicaciones. Se presenta dos series de experimentos basados en programas de multiplicacin de matrices y de ordenamiento de nmeros. Los resultados muestran el o u correcto funcionamiento del sistema y el potencial poder de computacin que ofrece la o memoria compartida distribuida.

iii

ABSTRACT Distributed Shared Memory (DSM) systems provide shared memory semantics on top of message-passing hardware. The advantages of loosely coupled multicomputers are preserved on DSM systems, along with the easy of programming inherent to shared memory multiprocessors. This thesis presents the design and implementation of DSM-PEPE, a DSM system based multicomputer, supported by standard networks of personal computers. The system can be seen from two distinct perspectives. First, it is useful as an experimentation environment on DSM related issues. Its clean design makes possible component modication and inclusion. Second, DSM-PEPE can be used as a low-cost parallel program execution environment oering a high degree of computing power. DSM-PEPE works at the page level and provides a sequential consistency protocol. Adding a new protocol to the system is an easy task. A new class of objects must be derived from a pre-existent class. The system works on personal computers running the Windows NT operating system. Communication is accomplished through a set of standard protocols in order to exploit existent networks. DSM-PEPE is multithreaded at the system level, and its design will allow multithreaded user programs in the future. Shared memory semantics makes programming for the system an easy task. The application programming interface includes only a few functions. Distributed synchronization is provided through two mechanisms: Barriers and locks. Also, porting existing shared-memory multiprocessor programs to DSM-PEPE is straightforward. Two series of experiments are shown; they are based on matrix multiplication and sorting algorithms. The results proved the correctness of the system, as well as its potential computational power. Keywords: Distributed Systems, Distributed Shared Memory, Parallel

Programming, Experimentation, Consistency Protocols.

iv

TABLA DE CONTENIDOS
Dedicatoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i ii iii iv v

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tabla de Contenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Lista de Tablas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 2. Sistemas Paralelos y Distribuidos . . . . . . . . . . . 2.1. Arquitectura de los Sistemas de Alto Desempeo . . . n 2.2. Arquitectura de Interconexin en los Sistemas MIMD . . o 2.2.1. Multiprocesadores Unidos por un Bus . . . . . . 2.2.2. Multiprocesadores con Conexin Conmutada . . o 2.2.3. Multicomputadores Unidos por un Bus . . . . . 2.2.4. Multicomputadores con Conexin Conmutada . o 2.3. Programacin de los Sistemas Paralelos y Distribuidos o 2.4. Evaluacin de Costos y Desempeo . . . . . . . . . . . o n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix 1 13 15 21 21 22 25 25 27 30 32 35 35 38 38 39 40 43 43 45 46 47 51 51

3. Memoria Compartida Distribuida . . . . . . . . . . . . . 3.1. Granularidad . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1. MCD Basada en Pginas . . . . . . . . . . . . . . . . a 3.1.2. MCD Basada en Variables Compartidas . . . . . . . 3.1.3. MCD Basada en Objetos . . . . . . . . . . . . . . . . 3.2. Modelos de Consistencia . . . . . . . . . . . . . . . . . . . 3.2.1. Consistencia Secuencial . . . . . . . . . . . . . . . . 3.2.2. Consistencia PRAM . . . . . . . . . . . . . . . . . . . 3.2.3. Consistencia Causal . . . . . . . . . . . . . . . . . . 3.2.4. Consistencias Release y Lazy Release . . . . . . . . 3.2.5. Consistencia Scope . . . . . . . . . . . . . . . . . . 3.3. Multithreading y Migracin de Threads en Sistemas de MCD o 3.3.1. Migracin bajo Consistencia Secuencial . . . . . . . o 3.3.2. Migracin bajo Release Consistency . . . . . . . . . o v

3.3.3. Migracin bajo Lazy Release Consistency o 3.4. Implementaciones de Sistemas de MCD . . . . . . 3.4.1. TreadMarks . . . . . . . . . . . . . . . . 3.4.2. CVM . . . . . . . . . . . . . . . . . . . . . 3.4.3. Quarks . . . . . . . . . . . . . . . . . . . 3.4.4. Brazos . . . . . . . . . . . . . . . . . . . 3.4.5. Millipede . . . . . . . . . . . . . . . . . 3.4.6. DSM-Threads . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52 53 53 54 55 55 56 56 57 57 61 63 64 64 64 65 66 68 70 71 72 73 76 76 77 77 77 78 80 83 85 86 87 87 87 88 88 91 93 94 95

4. Arquitectura de DSM-PEPE . . . . . . . . . . . . . . . . 4.1. Aspectos de Diseo . . . . . . . . . . . . . . . . . . . . n 4.2. Organizacin . . . . . . . . . . . . . . . . . . . . . . . o 4.2.1. Subsistema de Comunicacin . . . . . . . . . . . o 4.2.2. Subsistema de Paginacin . . . . . . . . . . . . o 4.2.3. Subsistema de MCD . . . . . . . . . . . . . . . . 4.2.4. Subsistema de Sincronizacin . . . . . . . . . . o 4.3. Multithreading . . . . . . . . . . . . . . . . . . . . . . 4.4. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5. Protocolos de Consistencia . . . . . . . . . . . . . . . . 5. Implementacin . . . . . . . . . . . . . . . . . . . . . . o 5.1. Aspectos Espec cos de Windows NT . . . . . . . . . . . 5.1.1. Manejo Estructurado de Excepciones . . . . . . 5.1.2. Memoria Virtual . . . . . . . . . . . . . . . . . 5.1.3. Memory-Mapped Files . . . . . . . . . . . . . . 5.1.4. Multithreading . . . . . . . . . . . . . . . . . . . 5.1.5. Sincronizacin . . . . . . . . . . . . . . . . . . . o 5.1.6. Comunicacin . . . . . . . . . . . . . . . . . . . o 5.2. Execution Manager . . . . . . . . . . . . . . . . . . . . 5.3. Objeto MemoryManager . . . . . . . . . . . . . . . . . 5.4. Objeto DSMregion . . . . . . . . . . . . . . . . . . . . 5.5. Objeto Page . . . . . . . . . . . . . . . . . . . . . . . . 5.6. Threads . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1. MsgMgrThread . . . . . . . . . . . . . . . . . . . 5.6.2. PageMgrThread . . . . . . . . . . . . . . . . . . 5.7. Sincronizacin . . . . . . . . . . . . . . . . . . . . . . . o 5.7.1. Barreras . . . . . . . . . . . . . . . . . . . . . . 5.7.2. Locks . . . . . . . . . . . . . . . . . . . . . . . . 5.8. Objeto PostOffice . . . . . . . . . . . . . . . . . . . . 5.9. Protocolo de Consistencia Secuencial . . . . . . . . . . 5.9.1. ReadFault . . . . . . . . . . . . . . . . . . . . . 5.9.2. RemoteReadFault . . . . . . . . . . . . . . . . . 5.9.3. WriteFault . . . . . . . . . . . . . . . . . . . . . vi

5.9.4. RemoteWriteFault . . . . . . . . . . . . . . . . . . . . . . . . . 5.10. Otras Clases de Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . 5.11. Funciones main y DSMmain . . . . . . . . . . . . . . . . . . . . . . . . .

97 99 99

6. Programacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 o 6.1. Interfaz de Programacin . . . . . . . . . . . . . . . . . . . . . . . . . . 102 o 6.2. Programa Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 7. Experimentacin y Resultados . . . . . . . . . . . . . . . . . . . . . . 107 o 7.1. Multiplicacin de Matrices . . . . . . . . . . . . . . . . . . . . . . . . . 108 o 7.2. Shearsort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 8. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Bibliograf a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

vii

LISTA DE TABLAS
5.1. Otras Clases de Objetos Empleadas en la Implementacin . . . . . . . o 7.1. 7.2. 7.3. 7.4. 7.5. Caracter sticas de los Computadores Multiplicacion de Matrices 256 256 Multiplicacin de Matrices 400 400 o Multiplicacin de Matrices 512 512 o Shearsort 16 Nmeros (4 4) . . . . u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 107 110 111 112 115

viii

LISTA DE FIGURAS
1.1. 1.2. 1.3. 1.4. 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9. Posible Conguracin para un Multicomputador . . . . . o Multiplicacin de Matrices Usando Memoria Compartida o Multiplicacin de Matrices Usando Paso de Mensajes . . o Sistema de Memoria Compartida Distribuida . . . . . . . Arquitectura de von Neumann . . . . . . . . . . . . . . . Mejoras a la Arquitectura de von Neumann . . . . . . . Taxonom de los Sistemas Computacionales . . . . . . . a Multiprocesador Unido por Bus . . . . . . . . . . . . . . Multiprocesador con Conexin Conmutada . . . . . . . . o Arquitectura Omega . . . . . . . . . . . . . . . . . . . . Arquitectura del Sistema Cm*, Primera Mquina NUMA a Multicomputador Unido por Bus . . . . . . . . . . . . . Hipercubo de Dimensin 4 . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 5 7 15 16 18 21 22 23 24 25 26 34 36 38 41 42 43 44 45 46 48 51 52 53 61 62 66 72 73 74 78 79 80 81 82

3.1. Sistema de Memoria Compartida Distribuida . . . . . . . 3.2. Memoria Compartida Distribuida Basada en Pginas . . a 3.3. Problema de False Sharing . . . . . . . . . . . . . . . . . 3.4. Ejecucin bajo Consistencia Secuencial . . . . . . . . . . o 3.5. Escenario de Prueba para Consistencia . . . . . . . . . . 3.6. Ejecucin bajo Consistencia PRAM . . . . . . . . . . . . . o 3.7. Ejecucin bajo Consistencia Causal . . . . . . . . . . . . o 3.8. Ejecucin bajo Consistencia Release . . . . . . . . . . . . o 3.9. Propagacin de Actualizaciones bajo RC y LRC . . . . . . o 3.10. Distribucin del Retardo en un Requerimiento Remoto . o 3.11. Cdigo del Thread que va a Migrar . . . . . . . . . . . . o 3.12. Acciones de Consistencia al Migrar un Thread bajo RC . 3.13. Acciones de Consistencia al Migrar un Thread bajo LRC

4.1. Programa Distribuido en Ejecucin . . . . . . . . . . . . . . . . . . . . o 4.2. Organizacin Interna de un Nodo . . . . . . . . . . . . . . . . . . . . . o 4.3. Objetos Dentro de un Proceso en un Nodo . . . . . . . . . . . . . . . . 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8. Manejador de Excepciones . . . . . . . . . . . . . Espacio de Direcciones en un Proceso de Win32 . Arquitectura de Manejo de Memoria de Win32 . . Interfaz de la Clase de Objetos MemoryManager . Atributos de Estado del Objeto MemoryManager Visin Grca del Objeto MemoryManager . . . . o a Atributos de Estado del Objeto DSMregion . . . Visin Grca del Objeto DSMregion . . . . . . . o a ix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.9. Interfaz de la Clase de Objetos DSMregion . . . . . . . . . . . . . . 5.10. Atributos de Estado del Objeto Page . . . . . . . . . . . . . . . . . 5.11. Interfaz de la Clase de Objetos Page . . . . . . . . . . . . . . . . . 5.12. Atributos de Estado del Objeto PostOce . . . . . . . . . . . . . . 5.13. Interfaz de la Clase de Objetos PostOce . . . . . . . . . . . . . . 5.14. Atributos de Estado del Objeto SeqPage . . . . . . . . . . . . . . . 5.15. Funcin ReadFault del Protocolo de Consistencia Secuencial . . . . o 5.16. Funcin RemoteReadFault del Protocolo de Consistencia Secuencial o 5.17. Funcin WriteFault del Protocolo de Consistencia Secuencial . . . . o 5.18. Funcin RemoteWriteFault del Protocolo de Consistencia Secuencial o 5.19. Llamado a DSMmain() desde la Funcin main() del Sistema . . . . o 6.1. 6.2. 6.3. 6.4. Interfaz de Programacin . . . . . . . . . . o Primitivas de Sincronizacin Distribuida . o Estructura de un Programa de Aplicacin o Programa para Multiplicacin de Matrices o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

83 84 85 89 90 92 93 95 96 98 100 102 103 104 106 108 109 113 114

7.1. Tipos de Particionamiento de una Matriz: (a) Striped en Striped C clico, (c) Checkboard . . . . . . . . . . . . . . . . 7.2. Particionamiento de las Matrices . . . . . . . . . . . . . . 7.3. Comparacin del Sistema de MCD y el Monoprocesador . o 7.4. Algoritmo Shearsort para N=16 Nmeros Enteros . . . . . u

Bloque, (b) . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Cap tulo 1 Introduccin o

Desde sus inicios, la computacin ha visto impulsado su desarrollo por una creo ciente necesidad de poder computacional. Las mejoras en la velocidad de procesamiento de los computadores ha venido acompaada de nuevos problemas por resolver, nuevos n retos y, en general, an mayores requerimientos computacionales. u El uso de los computadores afecta todas las areas del quehacer humano. Sin em bargo, inicialmente, slo algunos cient o cos, acadmicos e ingenieros militares, ten e an acceso a los costosos equipos computacionales. Su principal atractivo era la potencialidad de ejecutar millones de instrucciones en un segundo. Se descubrieron nuevos nmeros primos, se construyeron sosticadas armas y se disearon nuevos tratamientos u n mdicos, todo a partir del novedoso poder de procesamiento digital. e En los inicios del siglo XXI los problemas han cambiado, ms no as la creciente a necesidad de poder de cmputo. Los cient o cos se enfrentan con retos cada vez ms a desaantes, como la manipulacin del genoma humano, el procesamiento de seales o n recibidas del espacio exterior, la modelacin de fenmenos climticos y de polucin, o o o a o la elaboracin de complejos algoritmos criptogrcos para el comercio electrnico. Este o a o tipo de problemas impulsa el desarrollo de la computacin de alto desempeo. o n Es posible pensar que el desarrollo exponencial que ha tenido la electrnica pueda o satisfacer las nuevas demandas, tanto en el presente como en el futuro. La realidad 1

podr ser otra. Si bien es cierto en la actualidad es posible construir computadores a personales cientos de veces ms rpidos que los primeros supercomputadores, tambin a a e es una realidad que existen limitaciones f sicas que impiden un desarrollo indenido. Basta con mencionar el l mite impuesto por la velocidad de la luz, o el calentamiento que sufren los componentes debido al alto nivel de integracin y miniaturizacin. o o Desde hace ms de treinta aos, se ha implementado poderosos computadores a n paralelos, capaces de multiplicar el desempeo de los veloces procesadores contemn porneos, basndose en la nocin de la multiplicidad. La idea es bastante simple: El a a o uso de mltiples unidades de procesamiento trae consigo un incremento en el potenu cial de computacin. Sin embargo, el diseo de sistemas multiprocesador tambin tiene o n e sus limitaciones. Un multiprocesador es costoso de construir, puede reunir apenas un pequeo nmero de unidades de procesamiento y no es escalable. n u Una solucin es el uso de sistemas dbilmente acoplados o distribuidos. En este o e tipo de sistemas, varios computadores independientes aportan poder computacional para construir un multicomputador de mayores capacidades. Componentes de hardware y de software llevan a cabo el acoplamiento de las unidades independientes, y hacen que el sistema funcione como una unidad. Los recientes avances en materia de interconexin o mediante redes hacen que esta opcin sea cada vez ms factible como plataforma de o a computacin de alto desempeo. o n Los microprocesadores actuales, con su alta tasa de ejecucin de instrucciones, o hacen posible la construccin de un multicomputador de bajo costo. Hoy en d se o a puede reunir en una red un conjunto de computadores personales de ultima generacin o y formar poderosas plataformas de ejecucin paralela. Esto, unido a las altas tasas de o comunicacin que ofrecen las redes ms novedosas, permite disimular el bajo nivel de o a acoplamiento que tienen los procesadores. A pesar de no contar con memoria compartida, los procesos que se ejecutan en el sistema pueden comunicarse en forma expedita. La Figura 1.1 muestra una posible conguracin para un multicomputador dbilmente o e acoplado.

Computador Independiente

Computador Independiente

Computador Independiente

Memoria Local CPU

Memoria Local CPU

Memoria Local CPU

Red

Figura 1.1: Posible Conguracin para un Multicomputador o

Los programas que se ejecutan sobre un multiprocesador, ya sea fuerte o dbilmene te acoplado, se conocen como programas paralelos. Para poder aprovechar un multiprocesador y obtener la solucin a un determinado problema, primero es necesario escribir o un algoritmo paralelo, es decir, un algoritmo que divida el trabajo en tareas que puedan ser ejecutadas en paralelo por las distintas unidades de procesamiento con que cuenta el sistema. Este procedimiento no es sencillo; sin embargo, puesto que existen computadores paralelos desde hace mucho tiempo, el area de la computacin paralela tambin o e cuenta con un largo historial y se conocen soluciones paralelas para un sinnmero de u problemas. La situacin cambi radicalmente con la llegada de los multicomputadores. La o o principal diferencia introducida es la ausencia de una memoria compartida que los procesos paralelos puedan utilizar para comunicarse. La comunicacin es fundamental o en la mayor de los algoritmos paralelos. Son muy pocos los problemas que pueden a descomponerse en un conjunto de subproblemas completamente independientes. Por lo general, la solucin de una subtarea involucra la interaccin con una o ms de las o o a otras subtareas que se ejecutan en paralelo. La comunicacin en un multicomputador o se limita al intercambio de mensajes por la red, algo totalmente opuesto al paradigma de comunicacin existente en los multiprocesadores. o En la actualidad es posible escribir programas paralelos para multicomputadores utilizando varias plataformas de programacin distribuida basadas en paso de mensajes. o 3

var A[1:n,1:n]:int, B[1:n,1:n]:int, C[1:n,1:n]:int := ([n,n]0) Proceso[pid:1..n]:: var i:int, j:int if (pid = 1) call inicializar(); fi fa i:=1 to n, j:=1 to n C[pid,i] := C[pid,i] + A[pid,j] * B[j,pid] af Figura 1.2: Multiplicacin de Matrices Usando Memoria Compartida o

Puede citarse PVM [26] y MPI [62]. A pesar del buen desempeo que ofrecen estos n ambientes, aprovechando la velocidad de las redes actuales e introduciendo niveles muy bajos de overhead, el problema ahora es otro: Facilidad de programacin. o El paradigma de paso de mensajes involucra el concepto de que el programador tenga control absoluto del ujo de datos entre los procesos. Su tarea ya no es unica mente escribir un algoritmo que resuelva el problema, sino tambin preocuparse de la e comunicacin expl o cita. Esta situacin no est presente en los programas basados en o a memoria compartida. Para ilustrar la diferencia entre ambos paradigmas, la Figura 1.2 muestra el cdigo, escrito segn la notacin para programas concurrentes presentada o u o en [3], de uno de los procesos que componen un programa paralelo para multiplicar dos matrices cuadradas utilizando comunicacin mediante memoria compartida. La subdio visin de tareas se hizo siguiendo la estructura de las las de la matriz resultado. Cada o una de las las del resultado es calculada por un proceso diferente. La matriz se supone de tamao n n, por lo que existirn n procesos como el mostrado, ejecutndose cada n a a uno en paralelo en un procesador diferente. Como puede verse, el algoritmo es bastante simple y las matrices a multiplicar se almacenan en memoria compartida, desde donde cada proceso puede accederlas conforme las necesita. El primer proceso ejecuta un cdigo asimtrico pues est encargado de inicializar las matrices desde alguna fuente o e a conocida. 4

chan canal[1:n](int) Proceso[1]:: var A[1:n,1:n]:int, B[1:n,1:n]:int, C[1:n,1:n]:int := ([n,n]0) var i:int, j:int, cpu:int call inicializar(); fa cpu:=2 to n, j:=1 to n send canal[cpu](A[cpu,j]) fa i:=1 to n send canal[cpu](B[i,j]); af af fa i:=1 to n, j := 1 to n C[1,i] := C[1,i] + A[1,j] * B[j,1] af fa cpu:=2 to n, j:=1 to n receive canal[cpu](C[cpu,j]) af Proceso[pid:2..n]:: var A[1:n]:int, B[1:n,1:n]:int, C[1:n]:int := ([n]0) var i:int, j:int, k:int fa j:=1 to n receive canal[pid](A[j]) fa i:=1 to n receive canal[pid](B[i,j]) end af fa i:=1 to n, j:=1 to n C[i] := C[i] + A[j] * B[j,pid] send canal[1](C[i]) af Figura 1.3: Multiplicacin de Matrices Usando Paso de Mensajes o

Por otra parte, para implementar una solucin al mismo problema empleando paso o de mensajes, es necesario primero tomar algunas decisiones. En primer lugar, puesto que no existe una memoria compartida, debe decidirse dnde se almacenar la matriz o a y cmo. Una posibilidad es designar a uno de los procesadores para que almacene las o matrices y atienda las peticiones del resto de los procesadores cuando necesiten leerlas o escribirlas. Se debe resaltar que este enfoque introduce un cuello de botella.al sistema, lo cual puede reducir su desempeo. Otra forma, tal vez ms efectiva, es almacenar las n a matrices en forma distribuida. Las matrices que se van a multiplicar, puesto que en este caso no cambian, podr replicarse en todos los nodos, aunque con un costo excesivo de an almacenamiento. La Figura 1.3 muestra un programa que sigue este enfoque y resuelve el problema empleando paso de mensajes. Al igual que en el caso anterior, el primer proceso est encargado de inicializar las matrices y, en este caso, de distribuirlas al a resto de los procesos participantes. Cada proceso debe almacenar una la de la primera matriz y la segunda matriz completa. A su vez, del resultado debe calcular una unica la. El primer proceso almacena las tres matrices y recolecta el resultado nal. El ejemplo anterior establece un punto bastante importante relacionado con la programacin de multicomputadores: La ausencia de memoria compartida hace que la o programacin sea ms dif o a cil. La solucin a este problema es la Memoria Compartida o Distribuida, o MCD [50]. La MCD ofrece una semntica de memoria compartida sobre un a multicomputador con comunicacin mediante paso de mensajes. Su implementacin se o o logra gracias a una capa de software que provee un espacio global de direccionamiento virtual a los programas. Cada uno de los computadores participantes aporta una parte de su memoria local para construir este espacio y el sistema de MCD se encarga de interceptar los accesos y, si es del caso, intercambiar mensajes para completarlos. La Figura 1.4 muestra tres de los computadores que componen un sistema de MCD. La MCD es un paso evolutivo a partir de un multicomputador de paso de mensajes. Tiene las ventajas de costo, facilidad de construccin y escalabilidad de los multicomo putadores dbilmente acoplados, y a esto aade la facilidad de programacin de los e n o multiprocesadores con memoria compartida. 6

Proceso

Proceso

Proceso

Memoria Local

Memoria Local

...

Memoria Local

Software MCD

Software MCD

Software MCD

Figura 1.4: Sistema de Memoria Compartida Distribuida Sin embargo, la MCD tambin presenta problemas. El principal aspecto en contra e es el desempeo. Puesto que en la implementacin de un sistema de MCD se introduce n o una capa de software que intercepta los accesos a memoria, es inevitable introducir cierto nivel de overhead. Los programas con semntica de intercambio de mensajes a pueden optimizarse para minimizar la comunicacin. Los sistemas de MCD ocultan el o paso de mensajes al programador, por un lado aislndolo de su complejidad, pero por a otro impidindole mejorar el desempeo de sus programas. En cierto sentido hay una e n analog entre esta situacin y la que se presenta entre los lenguajes ensambladores y los a o de alto nivel. El uso de lenguajes de alto nivel facilita la programacin pero disminuye o la eciencia de los programas. Con un lenguaje ensamblador se puede obtener cdigo o muy eciente, pero la programacin es ms complicada. o a Dentro de los sistemas de MCD han destacado aquellos que utilizan una granularidad a nivel de pgina. Estos sistemas emplean como unidad de datos compartidos la a pgina de memoria. Los datos que se encuentran almacenados en una misma pgina a a no pueden ser discriminados por el sistema. A diferencia de sistemas con otros niveles de granularidad, como los objetos [11] o las variables compartidas [8], los sistemas con granularidad de pgina son ms fciles de implementar, pues se aprovecha el hardware a a a de memoria virtual de los computadores. 7

Durante ms de diez aos se ha venido estudiando posibles mejoras que permitan a n disminuir la brecha de desempeo entre los sistemas de paso de mensajes y los de n MCD [30], [12], [40], [77]. Algunos sistemas han logrado acercarse lo suciente como para que la ventaja de contar con una semntica de memoria compartida justique pagar un a pequeo precio en los tiempos de ejecucin [54]. n o Uno de los aspectos fundamentales a la hora de mejorar el desempeo de un n sistema de MCD es el uso de replicacin. Manteniendo rplicas de los datos compartidos, o e ya sean estos variables, objetos o pginas, es posible evitar comunicacin innecesaria a a o travs de la red. Sin embargo, la aparicin de las rplicas introduce el problema de su e o e consistencia. La semntica de memoria compartida que recibe el programador debe estar a acorde con un modelo de consistencia establecido. Dicho modelo viene a ser una especie de contrato entre el programador y el sistema de MCD, respecto al comportamiento de la memoria [1]. Los modelos de consistencia tradicionales resultan ser muy costosos en una implementacin de MCD. La alta tasa de intercambio de mensajes de consistencia degrada o considerablemente el sistema. Por este motivo, a menudo se utilizan modelos de consistencia ms relajados, que disminuyen la comunicacin pero que requieren de un a o comportamiento particular de los programas. La aplicabilidad de estos modelos a los distintos tipos de programas es un area activa de estudio [39], [31], [59]. Otras caracter stica que favorece el desempeo de los sistemas de MCD es el uso de n multithreading [73]. Los threads son procesos livianos que se encuentran disponibles en muchos sistemas operativos en la actualidad, as como a nivel de bibliotecas de nivel de usuario. Su principal caracter stica es el poco costo de manipulacin que involucran. Los o cambios de contexto entre threads de un mismo proceso son expeditos. El estado de un thread incluye unos pocos registros y un stack. Adems, su uso facilita la estructuracin a o de los programas y mejora la utilizacin del procesador. Para el caso de los sistemas o de MCD, los threads ayudan a aprovechar el tiempo de espera por datos almacenados en otros nodos [76]. Si a esto se suma una caracter stica de migracin, el uso de threads o puede disminuir la comunicacin, al aumentar la localidad de referencia [77], [34]. o 8

Estos y muchas otros aspectos pueden contribuir a que un sistema de MCD sea una alternativa efectiva para la computacin de alto desempeo. Sin embargo, para poder o n investigar sobre este tipo de caracter sticas es necesario contar con una plataforma de experimentacin adecuada. Para que un ambiente de experimentacin sea util debe ser o o exible. Debe permitir la modicacin o incorporacin de componentes. Su instalacin o o o no debe requerir hardware o software costoso o sosticado. De ser posible, debe aprovecharse el equipo y las redes existentes, o al menos con ligeros cambios. Su diseo n debe ser adecuado, empleando interfaces claras entre los componentes, de modo que las modicaciones sean expeditas. Evidentemente se debe contar con el cdigo fuente. o En la actualidad no existe ningn sistema con las caracter u sticas mencionadas. En sus inicios, los sistemas de MCD se implementaron en plataformas Unix, debido principalmente a que en la mayor de universidades y centros de investigacin predominaban a o las estaciones Unix, y eran los unicos equipos que cumpl con las expectativas de an costo y desempeo. Hoy en d el panorama ha cambiado notoriamente. El desarrollo n a que ha tenido la industria de los microprocesadores y la aparicin de sistemas operao tivos robustos, bien diseados y con facilidades de programacin, hacen que se pueda n o considerar como alternativa el uso de computadores personales y sistemas operativos de bajo costo como Windows NT y Linux. En esta tesis se presenta el diseo y la implementacin de DSM-PEPE un sistema n o de MCD orientado a plataformas de bajo costo y redes preexistentes. DSM-PEPE toma su nombre de las siglas de Distributed Shared Memory Parallel Environment for Program Execution. Su nombre resume en gran parte sus caracter sticas. Se trata de un ambiente paralelo para la ejecucin de programas con semntica de memoria compartida. Desde o a otro punto de vista, es una mquina virtual paralela que ejecuta programas de memoria a compartida. Los procesadores son de tipo Intel y el sistema operativo Windows NT. La eleccin del sistema operativo se hizo tomando en cuenta la gran base instalada de o computadores NT con que se cuenta actualmente. En muchos ambientes es imposible por ahora portar grandes laboratorios a otros sistemas como Linux en forma permanente. Uno de los objetivos principales de DSM-PEPE es la utilizacin de hardware preexistente o 9

en forma no dedicada. Desde sus inicios, DSM-PEPE se diseo como una plataforma de experimentacin. n o Su arquitectura por niveles y su implementacin orientada a objetos hacen que la moo dicacin e incorporacin de nuevos componentes sea sencilla. Sin embargo, DSM-PEPE o o tambin puede convertirse en una poderosa plataforma para la ejecucin de programas e o paralelos. Aprovechando las caracter sticas de escalabilidad de los multicomputadores, es posible construir un sistema distribuido compuesto por decenas de computadores de bajo costo unidos por una red Ethernet convencional. Puesto que la comunicacin se o lleva a cabo empleando protocolos estndares, es posible tambin aprovechar mayores a e anchos de banda en redes ms novedosas. a DSM-PEPE es un sistema de MCD con granularidad a nivel de pgina. En su ima plementacin se aprovecha el hardware de administracin de memoria virtual, y alo o gunas caracter sticas del sistema operativo Windows NT, como el manejo estructurado de excepciones, los threads a nivel de kernel, los archivos proyectados a memoria y la biblioteca de comunicacin WinSock. o La programacin se basa en una semntica de memoria compartida. Los prograo a mas denen regiones de datos compartidos y solicitan memoria como si fueran heaps. La sincronizacin distribuida es provista a travs de dos mecanismos: Barreras y locks. La o e intefaz de programacin para la MCD incluye unicamente dos funciones, y las primitivas o de sincronizacin se utilizan de una manera convencional. Un sistema de ejecucin remoo o ta, combinado con un programa administrador de ejecuciones con interfaz de ventanas hace sencilla la tarea de ejecutar los programas distribuidos. La experimentacin con DSM-PEPE puede hacerse de distintas maneras. La ino corporacin de protocolos de consistencia se reduce a implementar las funciones que o atienden los distintos eventos de consistencia que se pueden producir en uno de los nodos del sistema. DSM-PEPE suministra una implementacin de un protocolo de cono sistencia secuencial con invalidacin [46]. En un futuro cercano se dispondr, adems, o a a de protocolos PRAM [53] y Lazy Release [39]. La implementacin del protocolo secuencial o sirvi para corroborar el diseo de las interfaces. o n 10

El sistema es multithreaded, y fue diseado de modo que se pueda incorporar n una caracter stica que permita que los programas del usuarios tambin puedan estar e compuestos por mltiples threads de ejecucin. Adems, se planea agregar un mecau o a nismo de migracin de threads. A este respecto, la potencialidad de experimentacin o o es muy amplia, abarcando temas como la relacin entre la migracin y los modelos de o o consistencia. Como ambiente de ejecucin, DSM-PEPE ha demostrado que puede convertirse en o una mquina paralela de muy bajo costo. En un problema particular, una multiplicaa cin de matrices de tamao 512 512, sobre una mquina virtual compuesta por 4 o n a computadores, DSM-PEPE encuentra el resultado en un menor tiempo de ejecucin que o el mejor algoritmo secuencial que se pudo implementar. El resto de esta tesis est organizada de la siguiente manera. El cap a tulo 2 introduce al lector al tema de los sistemas paralelos y distribuidos, as como de la computacin o de alto desempeo. Se estudia una taxonom de los sistemas computacionales y, en parn a ticular, de los sistemas distribuidos, as como las distintas arquitecturas en que pueden estar basados estos sistemas. Se trata adems aspectos relacionados con la programaa cin de los sistemas distribuidos y las mtricas que se utiliza para medir su desempeo. o e n El cap tulo 3 sienta las bases de conocimiento sobre el area de la memoria compartida distribuida, analizando aspectos como granularidad de los datos compartidos, modelos de consistencia, multithreading y migracin de threads. Asimismo se describe algunas o implementaciones de sistemas de MCD y sus caracter sticas relevantes. En el cap tulo 4 se presenta el diseo del sistema DSM-PEPE, el punto central de n esta tesis. Cada uno de los subsistemas que componen DSM-PEPE es tratado en detalle y se muestra la relacin entre los objetos que participan en cada instancia del sistema. o La implementacin en s del sistema se describe en el cap o tulo 5. Los aspectos de inters e del sistema operativo Windows NT se tratan al inicio, para luego dar paso al detalle de las implementaciones de los componentes y clases de objetos ms importantes. El a protocolo de consistencia secuencial incorporado en DSM-PEPE es cubierto a cabalidad. El cap tulo 6 hace las veces de un manual de programacin para DSM-PEPE . Se o 11

describe la interfaz de programacin, el modelo de programa y los mecanismos de sino cronizacin. Se incluye un programa ejemplo para hacer ms concreta la discusin. Los o a o resultados preliminares de experimentacin se incluyen en el cap o tulo 7. Dos aplicaciones particulares, una multiplicacin de matrices y un algoritmo de ordenamiento, se ejecuo taron con distintos parmetros y conguraciones. Se ofrece resultados sobre tiempos de a ejecucin y cantidad de mensajes intercambiados, as como algunas interpretaciones de o los datos. Finalmente, en el cap tulo 8 se presenta las conclusiones nales de esta tesis y el trabajo futuro que se propone.

12

Cap tulo 2 Sistemas Paralelos y Distribuidos

La Computacin Paralela y Distribuida (PDC ) no es un concepto nuevo. A meo diados de la dcada del 60 ya se hab propuesto o implementado varios tipos de mule a tiprocesadores y procesadores vectoriales con el objetivo de acelerar la ejecucin de los o programas [22]. Sin embargo, en la ultima dcada el area ha experimentado un desarro e llo acelerado como consecuencia de los grandes avances en la tecnolog computacional, a principalmente por la disponibilidad de componentes electrnicos ms rpidos, conao a a bles y baratos, as como por nuevas y ms rpidas tecnolog de redes. Para el futuro a a as cercano se espera todav un mayor desarrollo del area de la PDC, y se pronostica que a este paradigma de computacin inuir notablemente en el diseo de los computadores o a n del futuro. A pesar de que el costo de los monoprocesadores es muy bajo hoy en d en a relacin a sus capacidades, los mejores componentes, aunque necesarios, no son el unico o factor involucrado en la computacin de alto desempeo o HPC. Existen limitaciones o n f sicas, como la velocidad de la luz, que imponen cotas superiores en el desempeo de n procesadores individuales [43]. Con la PDC se logra ir un paso ms adelante en el tratamiento de muchos problea mas importantes, conocidos como grandes retos, y que tienen como caracter stica comn u requerimientos intensivos de computacin. Se puede citar modelamiento y simulacin o o 13

del clima, tratamiento del genoma humano, modelacin de semi y superconductores, o dispersin de polucin y diseo farmacutico. Estas y muchas otras aplicaciones reo o n e quieren un poder computacional superior al que es posible obtener con computadores convencionales. Por ejemplo [62], [43], la modelacin del clima en una regin equivalente a los o o Estados Unidos y Canad juntos es sin duda un problema real. Si se pretende obtener a pronsticos peridicos, cada hora, por las prximas 48 horas y modelando la atmsfera o o o o hasta una altura de 20 Kms, el problema se vuelve inmanejable para un computador tradicional. Empleando un computador con capacidad para ejecutar mil millones de operaciones por segundo, la prediccin tomar cerca de 23 d Si se disminuye el o a as. per odo a 30 minutos en vez de una hora, el tiempo de solucin crece exponencialmente. o En sus inicios, la computacin paralela y la computacin distribuida fueron trao o tadas como dos areas independientes de estudio. Por un lado, la computacin paralela o involucra la divisin en tareas de los problemas, de modo que sea posible escribir algoo ritmos para resolverlos que se ejecuten en paralelo en varios procesadores cooperando entre s [43]. A los programas que implementan estos algoritmos se les llama programas paralelos. La ejecucin de los programas paralelos se asociaba tradicionalmente a un o multiprocesador, un computador con varios procesadores y una memoria comn. u Por otra parte, se considera un sistema distribuido como un conjunto de computadores independientes que son vistos por los usuarios como un unico sistema [73]. La unin de estos computadores lleva impl o cita la existencia de mltiples procesadou res y memorias, as como la participacin de un componente de software encargado de o implementar la transparencia para el usuario del sistema distribuido. Los avances tecnolgicos hacen que la nocin de dos areas independientes sea cada o o vez ms borrosa. La brecha entre las dos disciplinas se ha cerrado y es por esta razn a o que son tratadas aqu como un conjunto: Computacin Paralela y Distribuida, o PDC. o Por lo tanto, la PDC resulta ser el conjunto de aspectos involucrados en la obtencin o de computacin de alto desempeo (HPC), necesaria para la resolucin de problemas o n o con requerimientos intensivos de computacin en ciencias e ingenier o a. 14

CPU
Datos e Instrucciones ALU Memoria Principal

Entrada / Salida

... ...
Registros Operacionales Unidad de Control

Direcciones

Figura 2.1: Arquitectura de von Neumann

2.1.

Arquitectura de los Sistemas de Alto Desempe o n

La gran mayor de los computadores contemporneos son muy similares entre a a

s y su arquitectura y modo de operacin se basan en el diseo bsico formulado a o n a nales de los aos 40 por John von Neumann [28]. El enfoque de von Neumann se basa n en la nocin simple de una unidad de control que obtiene y analiza cada instruccin y o o sus operandos a partir de una unidad de memoria, lo que se conoce como fetching, y los env a una unidad de procesamiento para que la instruccin sea ejecutada con sus a o operandos. El resultado se env de nuevo a la memoria. a Un computador basado en el diseo de von Neumann tiene tres componentes prinn cipales, ilustrados en la Figura 2.1: Una unidad de procesamiento central (CPU), una memoria principal, y un subsistema de entrada y salida. Las instrucciones se ejecutan secuencialmente, una operacin a la vez. Tanto las instrucciones como los datos y direco ciones viajan entre la memoria y el procesador a travs de buses o canales. Normalmente e existe un bus para direcciones y uno para datos e instrucciones. El desempeo de un computador de este tipo se ve afectado por dos factores: La n tasa de ejecucin de las instrucciones, directamente relacionada con las capacidades del o procesador, y la velocidad a la que se puede intercambiar informacin entre la memoria o y el procesador. A este ultima caracter stica se le llama el cuello de botella de von 15

Memoria Cache CPU

Memoria

CPU

Memoria Memoria

Memoria Memoria

(a) Memory Interleaving

(b) Memory Interleaving y Cache

Memoria

Cache

Memoria Memoria

f d1

...

f1

f0

(c) Procesador con Pipelining de d Estados

Figura 2.2: Mejoras a la Arquitectura de von Neumann Neumann y puede atacarse desde distintos frentes. En primera instancia, es posible aumentar el nmero de canales sobre los que u se puede transmitir informacin simultneamente. A esta tcnica se le conoce como o a e memory interleaving (Figura 2.2 a). Otra alternativa es el uso de memoria cach, mee moria pequea pero muy rpida que funciona como un buer para la memoria principal n a (Figura 2.2 b). Finalmente, la tasa de ejecucin de las instrucciones puede mejorarse o traslapando la ejecucin de una instruccin con el fetching de la siguiente instruccin o o o a ser ejecutada. A esta tcnica se le conoce como execution pipelining (Figura 2.2 c). e Estas mejoras se utilizan comnmente en los computadores de alto desempeo, u n aunque tienen limitaciones. Tanto el memory interleaving como el pipelining son utiles slo si se lleva a cabo un conjunto pequeo de operaciones sobre grandes arreglos de o n datos. Las memorias cach estn limitadas por su costo y por las restricciones de la e a tecnolog actual. Por estos motivos, as como por los factores inherentes al diseo a n 16

secuencial, esta alternativa no resulta factible para computacin de alto desempeo en o n la actualidad. En el caso de los sistemas de PDC, el enfoque empleado para resolver un problema es completamente diferente, y el tiempo requerido para obtener una solucin se ve o disminuido signicativamente respecto al uso de los monoprocesadores tradicionales en los computadores secuenciales. En forma general, una arquitectura paralela o distribuida consiste de un conjunto de unidades de procesamiento, ya sean procesadores o computadores, que cooperan para resolver un problema, trabajando simultneamente en partes distintas del problema. a Evidentemente no existe l mite, al menos en principio, en el nmero de acciones que u pueden ejecutarse en paralelo. Por esto, el concepto ofrece un grado arbitrario de mejora en la velocidad computacional. Los computadores operan ejecutando instrucciones sobre los datos. Un ujo de instrucciones indica al computador lo que tiene que hacer en cado paso. Flynn clasic las arquitecturas de un computador basndose en la forma en que la mquina o a a relaciona sus instrucciones con los datos que estn siendo procesados [23]. La cantidad a de ujos de instrucciones y de datos en el sistema da origen a cuatro categor dentro as de la Taxonom de Flynn: SISD, SIMD, MISD y MIMD, ilustrada en la Figura 2.3. En a general, las unidades de procesamiento trabajan bajo el control de una unica unidad de control o, en forma independiente, con unidades de control independientes. Los monoprocesadores tradicionales y, en general, todas las mquinas basadas en a el diseo de von Neumann pertenecen a la categor SISD: Single instruction stream, n a single data stream, un unico ujo de instrucciones sobre un unico ujo de datos. Un algoritmo que se ejecuta en uno de estos computadores recibe el nombre de algoritmo secuencial. Es evidente que en este caso, asociadas con el procesador, existen una unica unidad de control, una unica unidad aritmtico lgica y una memoria privada. e o Una mquina SIMD consiste de un arreglo de N procesadores, N ujos de datos a que pueden verse como N memorias, una red de interconexin, y una unica unidad de o control que despacha instrucciones a cada procesador. Los procesadores operan sobre 17

Sistemas Computacionales

SISD
Computadores Monoprocesador

SIMD
Arreglos de Procesadores

Sistemas Distribuidos y Paralelos

MIMD

MISD
Arreglos Sistolicos

Fuertemente Acoplados Multiprocesadores (memoria compartida)

Debilmente Acoplados Multicomputadores (memoria privada)

Unidos por Bus

Conexion Conmutada

Unidos por Bus

Conexion Conmutada

Figura 2.3: Taxonom de los Sistemas Computacionales a distintos conjuntos de datos, obtenidos de ujos de datos distintos, en forma sincrnica. o Precisamente de ah se deriva el nombre SIMD: Single instruction stream, multiple data stream, un unico ujo de instrucciones sobre mltiples ujos de datos. u Por ejemplo, en un computador SIMD con N procesadores, cada procesador ejecuta la misma instruccin, al mismo tiempo, pero con sus propios datos. En esta categor o a puede ubicarse a computadores paralelos como el Illiac IV [5], uno de los primeros computadores SIMD, as como el MPP [6], y la CM-2 [15]. Para explotar una mquina SIMD es necesario reescribir los algoritmos convena cionales para que se puedan manipular distintos datos en forma simultnea. Una gran a cantidad de problemas se adaptan a este escenario, por lo que ha servido de incentivo para el diseo y la construccin de este tipo de mquinas. Como aplicaciones puede n o a citarse el rastreo de objetivos, el procesamiento de imgenes y una gran variedad de a operaciones sobre bases de datos. En un computador MISD, cada uno de los procesadores tiene su propia unidad 18

de control y comparte con el resto de los procesadores una memoria comn donde u residen los datos. El paralelismo se logra permitiendo que cada procesador lleve a cabo operaciones distintas sobre el mismo dato en forma simultnea. El nombre MISD se deriva a de multiple instruction stream, single data stream. Los arreglos sistlicos podr ser el o an unico ejemplo de este tipo de arquitectura [44]. Las mquinas MIMD son las ms generales y poderosas en el paradigma de la coma a putacin paralela. Permiten tratar problemas que no pueden resolverse ecientemente o en ambientes SIMD puesto que sus operaciones no pueden organizarse fcilmente como a operaciones repetitivas sobre datos estructurados uniformemente. En una mquina MIMD hay mltiples procesadores, mltiples ujos de instrucciones a u u y mltiples ujos de datos. De ah el nombre MIMD: Multiple instruction stream, multiple u data stream. Los procesadores son del mismo tipo usado en un computador SISD basado en el diseo de von Neumann, es decir, cada uno tiene su propia unidad de control, n unidad aritmtico lgica y su propia memoria local. Cada procesador puede ejecutar e o su propio programa, con sus propios datos y contador de programa (program counter). Por esto, los procesadores se consideran ms poderosos y a su vez ms generales que a a los que se utilizan en computadores SIMD. De los cuatro modelos mencionados en la Taxonom de Flynn, dada su genea ralidad, el modelo MIMD es el ms popular para la construccin de mquinas paralelas a o a comerciales, seguido del modelo SIMD, mientras que el modelo MISD es el menos popular. Tericamente, cualquier algoritmo paralelo puede ejecutarse ecientemente en un o modelo MIMD. Por esto, este modelo puede usarse para construir computadores paralelos para una amplia gama de aplicaciones. Se dice que dichos computadores tienen una arquitectura de propsito general. o Adems de las arquitecturas de propsito general, a menudo es util construir a o sistemas de PDC en una conguracin espec o camente diseada para resolver cierto n tipo de problema. El resultado es un computador que resuelve de forma muy eciente un tipo particular de problema pero que, en general, no es conveniente para ningn otro u n. Se dice que estos computadores tienen una arquitectura de propsito especco. o 19

Bell [7] presenta una clasicacin adicional de los sistemas MIMD basada en la exiso tencia o no de memoria compartida entre los procesadores, y Tanenbaum [73] incorpora una subdivisin a partir de la arquitectura de interconexin entre los procesadores. De o o esta forma, a los sistemas cuyos procesadores tienen acceso a una memoria comn se les u llama multiprocesadores, mientras que a los que no cuentan con memoria compartida se les llama multicomputadores. Las categor que se derivan de esta clasicacin pueden tambin asociarse con el as o e nivel de acoplamiento entre los procesadores, o ms espec a co an, con los tiempos de u comunicacin entre ellos. Un multiprocesador en el que las unidades de procesamiento o se encuentran sobre una placa de circuitos se dice fuertemente acoplado. En este caso las tasas de transferencia son muy altas. Por otra parte, un sistema multicomputador, conectado mediante una red, se dice dbilmente acoplado y la comunicacin tiende a e o ser ms lenta. a En el pasado, cuando se requer de un computador paralelo para ejecutar prograa mas con altos requerimientos de computacin, la velocidad de comunicacin entre los o o procesadores obligaba a la utilizacin de multiprocesadores fuertemente acoplados. Sin o embargo, las nuevas tecnolog de redes y los protocolos de comunicacin optimizados as o permiten hoy en d utilizar multicomputadores dbilmente acoplados como mquinas a e a paralelas, aunque el tiempo de comunicacin entre los procesadores sea relativameno te alto. Los factores de costo en la construccin de este tipo de sistemas, as como o su potencial de escalabilidad los hace una alternativa atractiva para la computacin o paralela. Esta tendencia ha llevado a replantear el trmino acoplamiento. Ser mejor decir e a que un computador MIMD est fuertemente acoplado si el grado de interacciones entre a los procesadores es alto. De otro modo se considera dbilmente acoplado. La velocidad e de los enlaces de comunicacin determinar si una mquina particular es apropiada o a a para un determinado tipo de problema. 20

CPU
Cache

CPU
Cache

CPU
Cache

Memoria

Bus

Figura 2.4: Multiprocesador Unido por Bus

2.2.

Arquitectura de Interconexin en los Sistemas MIMD o

Los sistemas MIMD ofrecen la alternativa ms poderosa y exible para la construca

cin de sistemas paralelos. Un aspecto que no puede dejarse de lado es la arquitectura o de conexin entre los procesadores, puesto que tambin inuye en el desempeo y aplio e n cabilidad del sistema [73]. Los elementos de procesamiento se pueden conectar mediante un bus o una red de conmutadores. En el primer caso, existe una unica red, cable u otro medio que conecta los procesadores. La opcin conmutada consiste en mantener conexiones individuales o entre los procesadores o entre los procesadores y las memorias. En este caso existen distintas formas de enlazar los procesadores, e incluso a menudo, mltiples formas de u llegar de un procesador a otro, por lo que es necesario tomar decisiones de conmutacin o cuando se lleva a cabo una comunicacin. Esta caracter o stica da lugar a la siguiente clasicacin para los sistemas MIMD. o

2.2.1.

Multiprocesadores Unidos por un Bus

Este tipo de sistema consiste de un conjunto de procesadores conectados a un bus al que tambin se conecta la memoria. Puesto que slo hay una memoria, su compore o tamiento es coherente, es decir, cuando se lee una posicin de la memoria se obtiene el o valor ms recientemente escrito en esa posicin. a o Sin embargo, este enfoque tiene un serio problema de escalabilidad. Con unos pocos procesadores el bus se satura y el desempeo se reduce drsticamente. Por ejemplo, n a 21

Memorias

C CPUs C

Conmutador

Figura 2.5: Multiprocesador con Conexin Conmutada o la conguracin ms grande para el popular sistema SGI Challenge XL es de slo 36 o a o procesadores [32]. Para minimizar este problema se emplean tcnicas de cach, nore e malmente empleando protocolos de tipo write-through con snooping [52]. La Figura 2.4 muestra la arquitectura de un multiprocesador unido por bus.

2.2.2.

Multiprocesadores con Conexin Conmutada o

Es necesario utilizar una conexin conmutada cuando la cantidad de procesadores o en el multiprocesador es mayor que la que puede soportar un unico bus. Este l mite se estima normalmente en unos 64 procesadores. En un sistema multiprocesador con conexin conmutada, existen conexiones que o salen y entran de cada procesador y de cada mdulo de memoria, como se muestra en la o Figura 2.5. En cada interseccin de las l o neas de conexin se ubica un conmutador que o puede ser activado o desactivado por hardware. Cuando un procesador desea acceder un mdulo particular de memoria, el conmutador correspondiente se activa para permitir o el acceso. La comunicacin entre dos unidades no interere con la comunicacin entre o o otra pareja de unidades. 22

CPUs

Memorias

C
Conmutador 2x2

Figura 2.6: Arquitectura Omega Al igual que en el caso anterior, el problema aqu es la escalabilidad. Cuando el nmero de procesadores y mdulos de memoria crece mucho, la cantidad de conmuu o tadores necesarios puede volverse prohibitiva por su costo. As se puede incluir ms , a procesadores que en el caso de un bus, pero no indenidamente. Por ejemplo, el Convex SPP1200 no permite redes conmutadas de ms de 8 procesadores [75]. En este caso es a necesario unir dos redes en un anillo, incurriendo en un costo adicional para accesos entre redes distintas. Adicionalmente es posible utilizar un enfoque jerrquico con varios niveles de cona mutadores, pagando un costo en el desempeo al tener que activar mltiples conmutan u dores para cada acceso a memoria. Un ejemplo de esto es la arquitectura Omega [47] mostrada en la Figura 2.6. En comparacin con la arquitectura de un unico nivel, ahora o es posible reducir la cantidad de conmutadores necesarios. Para el caso de n procesadores y n mdulos de memoria, con un unico nivel son necesarios n2 conmutadores. o Utilizando la arquitectura Omega se necesita unicamente (n log 2 n)/2 conmutadores. Otro enfoque es el implementado por las mquinas NUMA, en el que las memorias a estn asociadas con procesadores. Cada procesador puede acceder en forma rpida a a a su memoria asociada, pero el costo para acceder memoria de otro procesador es ms a alto. La Figura 2.7 muestra la arquitectura del sistema Cm, la primera propuesta de una mquina NUMA [35]. Las mquinas NUMA introducen otro tipo de problema. Es a a necesario optimizar la ubicacin de los programas y los datos, de modo que la mayor de o a 23

Cluster

CPU

E/S

Bus Local

Buffer Intercluster

CPU

E/S

MMU Microprogramada

CPU

E/S

Memoria Local

Figura 2.7: Arquitectura del Sistema Cm*, Primera Mquina NUMA a

24

 Estacion de Trabajo

Estacion de Trabajo

Estacion de Trabajo

Memoria Local CPU

Memoria Local CPU

Memoria Local CPU

Red

Figura 2.8: Multicomputador Unido por Bus los accesos sean locales. Para lograr esto es necesario implementar complejos algoritmos.

2.2.3.

Multicomputadores Unidos por un Bus

La construccin de multiprocesadores fuertemente acoplados es dif y costosa. o cil Por otra parte, es sencillo y ms barato concebir un sistema multicomputador dbila e mente acoplado, en el que los procesadores ya cuentan con una conexin a su memoria o y lo unico que debe hacerse es formar los enlaces necesarios para la comunicacin entre o los procesadores. Un multicomputador unido por bus conecta los distintos procesadores mediante un bus de relativa baja velocidad, comparado con el bus de un multiprocesador fuertemente acoplado. El medio de comunicacin es, normalmente, una red de area local. o Las tecnolog de redes actuales permiten velocidades de comunicacin muy altas. Sin as o embargo, la conexin podr ser simplemente una Ethernet de 10 o 100 Mbps, y los o a procesadores podr ser estaciones de trabajo tradicionales. La Figura 2.8 muestra an la conguracin de un multicomputador cuyos componentes se encuentran acoplados o dbilmente mediante un bus. e

2.2.4.

Multicomputadores con Conexin Conmutada o

En un multicomputador cada procesador tiene acceso directo y exclusivo a su memoria privada. La conexin entre los distintos nodos que forman el sistema puede o lograrse tambin a travs de conmutadores, con el objetivo de combatir la saturacin e e o 25

Figura 2.9: Hipercubo de Dimensin 4 o de un unico medio de comunicacin como lo podr ser un bus. o a La arquitectura ms popular para ordenar los nodos de un multicomputador con a conexin conmutada es el hipercubo, como el que se muestra en la Figura 2.9 para o el caso de 4 dimensiones. En este caso, el hipercubo puede ser visto como dos cubos ordinarios de dimensin 3, cada uno con 8 vrtices y 12 aristas, en donde cada vrtice es o e e un procesador y cada arista es una conexin. Los vrtices correspondientes en cada uno o e de los dos cubos se conectan para formar el hipercubo de dimensin 4. Para expandir o el hipercubo a una dimensin adicional, es decir, 5, basta con agregar otro hipercubo o de dimensin 4 y unir los vrtices correspondientes. o e En un hipercubo de dimensin n, cada procesador tiene n conexiones a otros proo cesadores. De esta forma, el nmero de conexiones crece slo en forma logar u o tmica con el nmero de procesadores. Como corolario de esto, puesto que slo los procesadores u o vecinos se encuentran conectados, la transmisin de un mensaje puede requerir varios o saltos para llegar a su destino. Sin embargo, la longitud mxima del camino que dea ber recorrer el mensaje tambin crece en forma logar a e tmica conforme crece el nmero u de procesadores en el hipercubo. Actualmente se encuentran disponibles hipercubos con 1024 y ms procesadores y a el estudio de estas arquitecturas se ha convertido en un area muy activa de investigacin o en los ultimos aos. Puede citarse como ejemplo nCUBE [60], [61] e iPSC de Intel [65]. n Como ejemplo de un multicomputador con conexin conmutada con una arquio tectura distinta al hipercubo puede considerarse el sistema SP [14] de IBM, que utiliza una red Omega cuya conguracin ms grande ha llegado a 512 nodos. o a 26

2.3.

Programacin de los Sistemas Paralelos y Distribuidos o

El concepto de programacin paralela est o a ntimamente ligado al concepto de

proceso. Los procesos son las entidades activas encargadas de ejecutar los algoritmos paralelos. Un proceso es una instancia en ejecucin de un programa, activo en un o procesador. Luego, un programa paralelo es un programa que, en algn momento de su u ejecucin, tiene asociado ms de un proceso, es decir, tiene ms de una instancia activa. o a a Evidentemente, para poder escribir programas paralelos es necesario contar con mecanismos para manipulacin de procesos. Las primitivas ms importantes son las o a que, precisamente, permiten crear y destruir procesos. Por otra parte, en la mayor de a los casos, los procesos que componen un programa paralelo interactan entre s para u poder completar su objetivo. Esto involucra tanto comunicacin para el intercambio de o datos, como sincronizacin para su correcta ejecucin. o o Los lenguajes de programacin que se utilizan para escribir programas paralelos o deben ofrecer todas estas facilidades. Sin embargo, la forma en que son accesibles a los programadores puede variar enormemente, dependiendo en gran medida del nivel de acoplamiento de los procesadores. Los sistemas fuertemente acoplados comparten una memoria comn de rpido u a acceso. Los procesos se comunican entre s escribiendo y leyendo en esa memoria. La sincronizacin se lleva a cabo empleando semforos u otras primitivas de ms alto nivel o a a como los monitores. Su programacin es similar a la de un sistema monoprocesador con o multitarea. La manipulacin de procesos, su sincronizacin y comunicacin en sistemas o o o multiprocesador con memoria compartida han sido estudiados por varias dcadas. Todo e libro de sistemas operativos hace una extensa cobertura de las distintas alternativas existentes para cada uno de estos tpicos [69], [74]. Esto se debe principalmente a la o ventaja cronolgica que tiene este tipo de sistemas en cuanto a disponibilidad comercial o y factibilidad. Apenas en la ultima dcada es que han surgido en forma masiva redes e de alta velocidad que permitan construir mquinas paralelas sin memoria compartida. a Por otra parte, cuando los procesadores estn dbilmente acoplados, en un multia e 27

computador, la situacin cambia notablemente. En este caso, el sistema est compuesto o a por computadores independientes enlazados por una red de comunicacin y sin memoria o comn para que los procesos puedan comunicarse o sincronizarse. No existe un espacio u comn de direcciones y el manejo global de los procesos no es trivial. u En un multicomputador, la unica forma de comunicacin existente es el paso de o mensajes a travs de la red. Esto introduce una mayor complejidad en tpicos como e o el control de ujo, mensajes perdidos, manejo de buers y bloqueo de procesos. En particular, la programacin de este tipo de sistemas es muy distinta a la programacin o o de los multiprocesadores. El programador debe ser conciente del intercambio expl cito de informacin y debe dirigirlo, por lo que los programas tambin se vuelven ms o e a complejos. Existen robustas plataformas para paso de mensajes que permiten la escritura de programas paralelos sobre multicomputadores. La ms popular de todas es PVM, a que toma su nombre de las siglas de Parallel Virtual Machine, o Mquina Virtual a Paralela [26]. El sistema PVM incorpora una biblioteca multiplataforma que permite la escritura de programas paralelos para sistemas heterogneos. A su vez, mediante una e serie de procesos administradores ejecutndose en todos los computadores participantes, a PVM es tambin una plataforma de ejecucin. e o Adems, existe un estndar para la construccin de mquinas paralelas basadas en a a o a paso de mensajes: MPI, Message Passing Interface, o Interfaz de Paso de Mensajes [62]. Es posible encontrar implementaciones de este estndar en una diversidad de sistemas, a de mediana y pequea capacidad, como Unix, Linux y Windows. n Como una alternativa de ms alto nivel, se han propuesto abstracciones como las a llamadas a procedimientos remotos, o RPC y la memoria compartida distribuida. Las RPC [10] ocultan la comunicacin al programador a travs de una biblioteca de funciones. o e Para utilizar un servicio remoto, un proceso tan slo llama a la funcin apropiada de la o o biblioteca, la cual empaca la operacin y sus parmetros en un mensaje que es enviado o a por la red. La funcin se bloquea a esperar el resultado, el cual es codicado y pasado al o proceso que hizo el llamado, de modo que parezca que toda la operacin es local. Aunque o 28

sta es una buena alternativa para simplicar la programacin, tiene limitantes en el e o paso como parmetro de estructuras complejas, principalmente aquellas que utilizan a punteros a memoria en su implementacin. Tambin hay problemas de desempeo en o e n el paso de grandes arreglos de datos pues deben ser enviados en su totalidad cuando en un sistema tradicional ser manejados por referencia. an Por otra parte, la memoria compartida distribuida (MCD) [51] pretende ofrecer a los programas un espacio global de direcciones construido a partir de la memoria distribuida de los computadores que forman el sistema. Al igual que las RPC, su funcionamiento se basa generalmente en el uso de una biblioteca de funciones y, adems, en la capacidad a de poder interceptar los accesos que hacen los programas a la memoria. Cuando se accede un dato que no se encuentra localmente, la biblioteca se encarga de traerlo en forma trasparente al programa. Este tpico es el tema central de esta tesis por lo que o ser tratado en el cap a tulo 2. El tema de la sincronizacin tampoco es trivial cuando no se cuenta con meo moria compartida. Existen diversas alternativas para la implementacin de exclusin o o mutua [73], empleando algoritmos centralizados y distribuidos. Asimismo, otras primitivas como las barreras, introducen complejidad adicional por el alto grado de interaccin o entre los procesos participantes. En este caso, la implementacin tiende a ser centralio zada. Finalmente, el manejo de los procesos en sistemas dbilmente acoplados involucra e la manipulacin de identicadores globales, para todo el sistema, y el uso de primitivas o que podr no ser las mismas que se utilizan normalmente en los multiprocesadores. an La forma ms conocida para crear un proceso es la que implementa el sistema operativo a Unix [41]. En Unix se dispone de la llamada al sistema fork, que genera un duplicado del proceso que hace el llamado, pero con un identicador distinto. Una vez ejecutndose, el a nuevo proceso puede llamar a exec para cargar un nuevo programa sobre s mismo. Este mecanismo est ampliamente difundido y es familiar a la mayor de los programadores a a de aplicaciones paralelas. Otros sistemas, como Windows NT [29], cuentan con llamadas al sistema ms complejas, como CreateProcess, que crea un nuevo proceso a partir de a 29

un programa en disco y permite adems congurar su entorno de ejecucin. a o Un ejemplo de la forma en que debe manejarse la asignacin de los identicadores o es el mecanismo utilizado en PVM [26]. En este sistema, los procesos reciben el nombre de tareas, y se identican mediante un nmero entero, el TID o task identier. Los mensajes u se env y reciben usando estos identicadores. Puesto que los TIDs deben ser unicos an en el contexto global de la mquina virtual, son suministrados por un demonio local, a pvmd, y no son elegidos por el usuario.

2.4.

Evaluacin de Costos y Desempe o o n

La justicacin para el uso de sistemas paralelos es el mayor poder computacional. o

Con esto se quiere decir que se obtiene una mejora en los tiempos de ejecucin. Sin o embargo, es necesario formalizar los parmetros que se utilizan para medir estas mejoras, a de modo que sea posible llevar a cabo una comparacin justa y precisa. o Los sistemas paralelos introducen nuevas complejidades de administracin, como o lo es la asignacin de tareas, que no existen en sistemas monoprocesador. Este problema o consiste en determinar en cul procesador debe ejecutarse un proceso particular, con a el objetivo de obtener un mejor desempeo. Este aspecto se vuelve cr n tico en multicomputadores, puesto que la red de comunicacin introduce retardos considerables que o podr degradar el rendimiento si no se considera el nivel de comunicacin entre los an o procesos al llevar a cabo la asignacin. Adems, una mala asignacin puede provocar o a o subutilizacin de los recursos computacionales, es decir, procesadores ociosos. Como o agravante se encuentra el hecho de que la asignacin de tareas a procesadores es un o problema NP-completo [25]. Es posible tratar de remediar una mala asignacin previa o utilizando mecanismos como la migracin de procesos [4], [19], tpico que se trata en o o el cap tulo 2. Puesto que la aceleracin, o speed up, es el objetivo detrs del uso de los sistemas o a paralelos, el tiempo debe ser el factor determinante a medir. El tiempo de ejecucin o de un programa se dene como el tiempo transcurrido desde el momento en que se 30

inicia el programa hasta el momento en que termina [78]. Si los distintos procesos que componen el programa no empiezan o terminan simultneamente, el tiempo de ejecucin a o se considera desde el momento en que inicia el primer proceso hasta el momento en que termina el ultimo. Para medir la mejor que se est obteniendo con el programa paralelo es necea a sario compararlo con el mejor algoritmo secuencial disponible para resolver el mismo problema. As la aceleracin obtenida se dene como [78]: , o A=
Tiempo de ejecucin del mejor algoritmo secuencial disponible o Tiempo de ejecucin del algoritmo paralelo o

Es evidente que una mayor aceleracin implica un mejor algoritmo paralelo. En o forma ideal se esperar obtener la mxima aceleracin, N , cuando se resuelve un proa a o blema empleando N procesadores en paralelo. En la prctica esto no es posible por a dos razones. En primer lugar, no siempre es posible descomponer el problema en N tareas, cada una de las cuales utiliza una fraccin igual a 1/N del tiempo. Adems, en o a la mayor de los casos, la estructura del programa paralelo impone restricciones sobre a la aceleracin, por ejemplo, el overhead de sincronizacin o de comunicacin. o o o

31

Cap tulo 3 Memoria Compartida Distribuida

En el cap tulo 2 se detalla las arquitecturas MIMD, compuestas por mltiples proceu sadores independientes, cada uno con su propia unidad de control y con la capacidad de ejecutar programas diferentes en paralelo. Los multiprocesadores fuertemente acoplados cuentan con una memoria compartida que es accesible por todos los procesadores. La construccin de este tipo de computadores es muy dif costosa y tiene serios probleo cil, mas de escalabilidad. Por ejemplo, si se utiliza un bus para enlazar los componentes, el sistema est limitado a unas pocas docenas de procesadores. Adems, incorporar nuevos a a elementos es poco factible en la prctica. a Por el contrario, en el caso de los multicomputadores dbilmente acoplados, se e tiene un conjunto de computadores independientes, cada uno con su memoria privada, y comunicados mediante una red. En este caso no hay nada compartido y el unico medio que tienen los procesadores para interactuar es la red, empleando mensajes. Construir multicomputadores es ms simple y barato y puede aprovecharse las redes a existentes. En la actualidad existen sistemas compuestos por cientos de procesadores, tanto en forma comercial como experimental. Puede citarse como ejemplo el proyecto NOW en Berkeley [16]. Adems, varios sistemas operativos incorporan en sus versiones a ms recientes la capacidad de trabajar en clusters, como en el caso de Linux. a Sin embargo no todo es conveniencia para los multicomputadores. Son ms fciles a a 32

de construir y relativamente ms baratos, pero la comunicacin no es tan expedita como a o en el caso de los multiprocesadores con memoria compartida. Dado que el unico medio de comunicacin es la red, los programas paralelos deben utilizar intercambio de mensajes o para comunicarse, y primitivas distribuidas construidas sobre la interfaz de paso de mensajes para poder sincronizarse. Esto queda en evidencia dado que los distintos procesos que componen un programa paralelo en ejecucin sobre un multicomputador o tienen espacios de direcciones distintos.

Los sistemas de Memoria Compartida Distribuida (MCD) [50], [51] son sistemas que, mediante software, emulan semntica de memoria compartida sobre hardware que a ofrece soporte slo para comunicacin mediante paso de mensajes. Este modelo permite o o utilizar una red de estaciones de trabajo de bajo costo como una mquina paralela con a grandes capacidades de procesamiento y amplia escalabilidad, siendo a la vez fcil de a programar. El objetivo principal de estos sistemas es permitir que un multicomputador pueda ejecutar programas escritos para un multiprocesador con memoria compartida.

Cada uno de los nodos en un sistema de MCD aporta una parte de su memoria local para construir un espacio global de direcciones virtuales que ser empleado por a los procesos paralelos que se ejecuten en el sistema, en la forma que se muestra en la Figura 3.1. El software de MCD se encarga de interceptar las referencias a memoria que hacen los procesos, y satisfacerlas, ya sea local o remotamente. Si los accesos a memoria hacen referencia a posiciones almacenadas remotamente, es necesario llevar a cabo una transferencia a travs de la red, con el consecuente overhead que esto conlleva. Por e esta razn los sistemas de MCD tienen un comportamiento no uniforme respecto a los o accesos a memoria. Sin embargo, a diferencia de los sistemas NUMA, en este caso los procesadores no tienen acceso a memoria remota en forma directa. Es necesario que medie un componente de software para permitir los accesos que no son locales. 33

Procesador 1

Espacio Global de Direcciones

           

CPU

       

Memoria

CPU

Figura 3.1: Sistema de Memoria Compartida Distribuida

Procesador 2

Memoria

34
CPU Procesador N Memoria

3.1.

Granularidad
El modelo original propuesto por Li [51] es un modelo basado en pginas. La a

primera implementacin de un sistema de MCD basado en pginas fue Ivy [50]. Otras o a posibilidades son los sistemas basados en variables compartidas (e.g., Munin [8]), y los basados en objetos (e.g., Linda [11]). En los sistemas basados en pginas la granularidad de la memoria se dene a a nivel de pgina de memoria. Esto quiere decir que la m a nima unidad referenciable por el sistema de MCD es la pgina, no pudiendo hacer distincin entre variables distintas a o almacenadas en la misma pgina. a A pesar de que el uso de una granularidad a nivel de pgina puede introducir a problemas como el false sharing [12], tambin permite mantener el overhead producido e por la administracin de la memoria distribuida dentro de parmetros razonables. Esto o a se debe a que es posible hacer uso de las caracter sticas del hardware para el manejo de la memoria virtual, disponibles en la mayor de los computadores. a

3.1.1.

MCD Basada en Pginas a

Para implementar un sistema de MCD es posible hacer uso del hardware de administracin de memoria. La gran mayor de los computadores modernos basan su o a arquitectura de memoria en paginacin o alguna variante de paginacin. En este tipo o o de sistemas, el hardware ofrece una serie de facilidades relacionadas con las pginas a de memoria, normalmente aprovechadas unicamente por el sistema operativo. Puede citarse la manipulacin del estado de las pginas (e.g., invalidacin, activacin) y la o a o o sealizacin de eventos relacionados con pginas (e.g., el acceso a una pgina invlida). n o a a a En un sistema de MCD basado en pginas, la unidad de memoria que utiliza el a sistema es, precisamente, la pgina. Las pginas migran dinmicamente a travs de a a a e la red en demanda, puesto que en realidad los procesos pueden acceder unicamente a pginas almacenadas en la memoria local del computador donde se estn ejecutando. a a El software de MCD es el encargado de dirigir estos ujos de pginas en los momentos a 35

Espacio de Direcciones Global y Compartido 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0 5

2 9

1 6 10

3 8

4 11 14

7 12

13

15 Memoria

CPU 1

CPU 2

CPU 3

CPU 4

Figura 3.2: Memoria Compartida Distribuida Basada en Pginas a

apropiados. Puesto que la memoria compartida en un multiprocesador se comporta secuencialmente consistente, los primeros enfoques para la MCD incorporaban un modelo de consistencia secuencial [13]. Los aspectos de consistencia de la memoria se trata en la seccin 3.2, ms adelante en este cap o a tulo. La implementacin original de Ivy [50] intentaba emular el cach de un multio e procesador. En este caso, cuando un proceso referencia una direccin que no es local, o se provoca una interrupcin y el software de MCD trae la pgina involucrada y posteo a riormente reinicia la instruccin relacionada. Por ejemplo [73], considere el sistema con o cuatro procesadores de la Figura 3.2, el cual cuenta con un espacio de direcciones de 16 pginas. Si un proceso en el computador 1 accede a las pginas 0, 2, 5 o 9, las rea a ferencias se hacen localmente. Una referencia a la pgina 10 (o a cualquier otra pgina a a que no sea 0, 2, 5 o 9), provocar una interrupcin y la pgina deber ser transferida a o a a al computador 1. El alto trco de pginas por la red que se puede presentar en un sistema de MCD a a obliga a mantener copias o rplicas de las pginas frecuentemente usadas con el objetivo e a de reducir los retardos provocados por las transferencias de red, en la misma forma en que un cach ayuda a mejorar el desempeo de un sistema multiprocesador fuertemente e n acoplado, minimizando el tiempo de transferencia entre el procesador y la memoria. Es 36

evidente que no existe problema en replicar pginas de slo lectura, como el cdigo de a o o los programas. Sin embargo, en general, la incorporacin de las rplicas introduce un o e problema de consistencia para las mltiples copias que puede existir de cada pgina. u a La actualizacin de las pginas replicadas que son modicadas puede llevarse a o a cabo de distintas maneras. En primer lugar, puede emplearse un protocolo de actualizacin: Se env las pginas actualizadas a todos los nodos que mantienen copias. Otra o a a opcin es simplemente enviar mensajes de invalidacin para las copias, de modo que la o o actualizacin se lleve a cabo por demanda. Finalmente, puede enviarse estructuras que o codiquen los cambios a las pginas y que permitan construir la versin actualizada a o a partir de una pgina original y mltiples modicaciones. A estas estructuras se les a u conoce como dis [12]. Sea cual sea el caso, aqu se emplea simplemente el trmino e actualizacin. o Los dis se emplean con frecuencia en protocolos que soportan mltiples escritores u simultneos sobre una misma pgina [40], [12], con el objetivo de reducir el problema de a a false sharing, o comparticin falsa. Este problema es caracter o stico de cualquier sistema de MCD que use una granularidad mayor al tamao de las variables compartidas, como n es el caso de los sistemas con granularidad a nivel de pgina. El problema se provoca a porque una pgina puede contener variables compartidas no relacionadas entre s y a , que provocarn interrupciones y transferencias innecesarias. La Figura 3.3 muestra una a pgina que contiene dos variables no relacionadas, llamadas A y B. Un proceso en el a procesador 1 referencia constantemente la variable A, tanto para lectura como para escritura y otro proceso en el procesador 2 hace lo propio sobre la variable B. En este escenario, la pgina que contiene ambas variables ser transferida repetidamente entre a a los dos computadores. Por su simplicidad de implementacin, en el diseo del sistema DSM-PEPE se ha eleo n gido la pgina como unidad de granularidad. Por esto, en adelante se trata unicamente a este tipo de sistema. Sin embargo, a continuacin se detalla las otras dos modalidades o de sistemas existentes. 37

Procesador 1 A B Programa que referencia A

Procesador 2 A B Programa que referencia B Dos variables compartidas no relacionadas

Pagina compartida

Figura 3.3: Problema de False Sharing

3.1.2.

MCD Basada en Variables Compartidas

El problema del false sharing puede eliminarse si se utiliza una granularidad ms a na, tan na como las entidades que usualmente se comparten en los programas paralelos: Las variables. De ser as el problema ahora consiste en cmo mantener registro , o de las variables replicadas. Adems, es probable que sea ms conveniente utilizar una a a pol tica de actualizacin y no de invalidacin, puesto que en la implementacin debe o o o ser posible identicar escrituras a variables individuales. Un ejemplo de un sistema de MCD que utiliza una granularidad a nivel de variable compartida es Munin, una de las primeras implementaciones de MCD. Munin [8] permite la ubicacin de variables individuales en pginas diferentes, de modo que se pueda utilizar o a el hardware de paginacin para identicar los accesos a las variables compartidas. o

3.1.3.

MCD Basada en Objetos

Puesto que en muchos lenguajes de programacin los datos se encuentran organio zados como objetos y no como variables simples, los sistemas de MCD basados en objetos intentan transportar datos por la red utilizando como unidad de manipulacin el objeto o y no las pginas o las variables. a Los procesos que se ejecutan en los distintos computadores que componen el sistema tienen acceso a un espacio de objetos compartidos, en lugar de a un espacio 38

lineal de direcciones. El sistema es responsable de la ubicacin y administracin de eso o tos objetos compartidos. Un proceso puede invocar mtodos de un objeto compartido, e independientemente de la ubicacin del proceso y del objeto. o Los objetos estn protegidos por el ocultamiento de informacin, por lo que los a o procesos no pueden acceder directamente al estado interno de ningn objeto compartido. u Esto facilita algunas optimizaciones dentro del sistema. Por ejemplo, puede relajarse el modelo de consistencia sin que el programador tenga conocimiento alguno. Al igual que en el caso de la granularidad a nivel de variables compartidas, cuando se utiliza el objeto como unidad para compartir es posible eliminar el false sharing. Adems, tambin en este caso es factible utilizar un protocolo de actualizacin en vez a e o de uno de invalidacin. Sin embargo, quiz la mayor ventaja de este modelo es su moduo a laridad y exibilidad, a la vez que permite una integracin limpia con la sincronizacin. o o La principal desventaja es el aumento en el overhead que se produce por la manipulacin an ms indirecta de la memoria. En realidad, este es un problema inherente al o u a uso de objetos. Un ejemplo de un sistema de MCD basado en objetos es Linda [11], un sistema basado en una memoria compartida altamente estructurada y que es accedida a travs e de un pequeo conjunto de primitivas que se agregan a lenguajes tradicionales como C n y Fortran. El espacio de objetos se llama tuple space, o espacio de tuplas. Los procesos pueden insertar y remover tuplas al espacio, desde cualquier computador.

3.2.

Modelos de Consistencia
Los sistemas de MCD mantienen rplicas de pginas, variables u objetos, segn sea e a u

el caso, con el objetivo de minimizar los retardos provocados por las transferencias por la red. Cuando una de las rplicas es modicada se presenta un problema de consistencia. e Este problema no es trivial si se considera que la actualizacin debe hacerse utilizando o una red generalmente lenta, si se compara con la velocidad de procesamiento de los computadores e incluso con la velocidad de acceso a la memoria local. La solucin que o 39

a menudo se aplica es sacricar un poco la consistencia con el propsito de mejorar el o desempeo. Si ste es el caso, es necesario establecer reglas sobre el comportamiento de n e la memoria. El modelo de consistencia establece la forma en que se hace visibles a los distintos procesadores o nodos del sistema las actualizaciones hechas a la memoria compartida. Dado un cierto modelo de consistencia, los programadores y el sistema acuerdan un determinado comportamiento para la memoria [1]. As bajo un modelo de consistencia , estricto, cada actualizacin es vista en forma instantnea por todos los nodos en el o a sistema. Aunque ste es el ideal para cualquier programador, y de hecho es el compore tamiento acostumbrado de la memoria en los sistemas multiprocesador, en la prctica a es imposible de implementar en una red de computadores en donde no existe un tiempo global absoluto [53], [45]. A continuacin se detalla algunos de los modelos de consistencia de mayor acepo tacin en sistemas de MCD. La seleccin se hizo de acuerdo al impacto de las impleo o mentaciones conocidas de cada modelo. En [57] puede encontrarse un estudio bastante completo al respecto, el cual puede complementarse con las referencias dadas para los modelos de ms reciente aparicin. La notacin que se utiliza para los ejemplos es la a o o propuesta en [30]: Los distintos procesos se representan en forma vertical y las operaciones que stos efectan, en forma horizontal con el tiempo incrementndose hacia la e u a derecha. Por ejemplo, para indicar que se escribe un valor a en la direccin o pgina o a x, y que se lee un valor b desde la direccin o pgina y, respectivamente, se usa los o a siguientes s mbolos: W (x)a R(y)b

3.2.1.

Consistencia Secuencial

Los primeros sistemas de MCD, como es el caso de Ivy [50], empleaban un modelo de consistencia de memoria muy r gido, ligeramente ms relajado que el modelo esa 40

P1: P2: P3:

W (x) 1 W (y) 2 R (y) 2 R (x) 0 R (x) 1

Figura 3.4: Ejecucin bajo Consistencia Secuencial o tricto, el modelo de consistencia secuencial, SC, propuesto por Lamport [46]. Bajo este modelo, las actualizaciones a la memoria compartida son vistas en el mismo orden en todos los procesadores. Esta es la unica restriccin que se impone. Sin embargo, este o orden puede variar en distintas ejecuciones, dado el paralelismo con que se realizan las actualizaciones. Formalmente, una memoria es secuencialmente consistente si satisface la siguiente condicin: o El resultado de cualquier ejecucin es el mismo que si las operaciones de o todos los procesadores se ejecutaran en algn orden secuencial, y las operau ciones de cada procesador individual aparecen en esta secuencia, en el orden especicado por su programa. Para poder cumplir con este modelo es necesario hacer del conocimiento de todos los procesadores la ocurrencia de cada actualizacin, garantizando que todos vean la o misma secuencia de escrituras. Esto provoca una alta tasa de comunicacin por la red y o por consiguiente un desempeo muy pobre del sistema en general. En la denicin del n o modelo no se involucra al tiempo, como puede verse en el ejemplo de la Figura 3.4, la cual muestra una ejecucin posible para un programa bajo consistencia secuencial. En o todos los ejemplos relacionados con consistencia, las variables se suponen con un valor inicial de 0. Con el objetivo de mejorar el rendimiento, disminuyendo la cantidad de mensajes de consistencia que es necesario enviar, se ha propuesto modelos de consistencia ms a relajados, en el sentido de que son menos rigurosos en la actualizacin de la memoria o 41

P1: P2:

W (x) 1 W (y) 1

R (y) ? R (x) ?

Retardo de Mensaje

Figura 3.5: Escenario de Prueba para Consistencia compartida. La idea de los modelos relajados fue introducida por Lipton y Sandberg [53]. En sus propias palabras:

No importa qu tan astuto o complejo sea un protocolo, si implementa una e memoria compartida coherente, debe ser lento. Una memoria compartida consistente no puede ser rpida y escalable a la vez. a

Para ilustrar este hecho, considere un programa con dos variables, x, y [30], ambas inicializadas en 0. El procesador P 1 escribe 1 en x y despus lee el valor de y. Por su e parte, P 2 escribe 1 en y y lee el valor de x. El escenario planteado puede verse en la Figura 3.5. Una memoria consistente no permitir una ejecucin en la que ambos a o procesos lean un valor 0. Suponiendo que la suma de el m nimo tiempo posible para leer y el m nimo tiempo posible para escribir sea menor que el tiempo de retardo por la comunicacin, ambos procesos debern leer un 0. Durante el retardo no es posible o a conocer los eventos que han ocurrido los otros procesadores. Cuando se emplean modelos relajados, los programadores deben tener conciencia de la relajacin introducida al comportamiento de la memoria y programar de acuerdo o al modelo que se haya establecido. Las restricciones sern mayores conforme se relaje a el modelo, pero a la vez se disminuir la cantidad de comunicacin necesaria para a o mantener la memoria consistente. Cabe resaltar que, por lo general, estas restricciones no representan un gran obstculo, dadas las tcnicas de programacin normalmente a e o aplicadas. 42

P1: P2: P3: P4:

W (x) 1 R (x) 1 W (x) 2 R (x) 1 R (x) 2 R (x) 2 R (x) 1

Figura 3.6: Ejecucin bajo Consistencia PRAM o

3.2.2.

Consistencia PRAM

La consistencia PRAM (Pipelined RAM ) [53] es un modelo de memoria relajado que encausa, como en una tuber las escrituras a memoria que hace un procesador, a, permitiendo que sus efectos se retarden arbitrariamente ante la percepcin de los otros o procesadores. Las escrituras hechas por un procesador son recibidas por todos los dems a procesadores en el orden en que se produjeron, pero las escrituras de distintos procesadores podr ser vistas en un orden diferente por procesadores diferentes. an La consistencia PRAM es muy fcil de implementar. No ofrece garant sobre el a a orden en el cual procesos distintos ven las escrituras. Tan slo asegura que dos o ms o a escrituras de una misma fuente llegarn en orden, como si viajaran por una tuber a a. Su comportamiento se diferencia al de la consistencia secuencial, en que la consistencia PRAM permite estados globales que ser secuencialmente inconsistentes. Este hecho an puede observarse en la Figura 3.6, que muestra una secuencia de eventos vlida bajo a consistencia PRAM, pero que no es vlida bajo consistencia secuencial. a

3.2.3.

Consistencia Causal

El modelo de consistencia causal, CC [30], determina las actualizaciones que deben propagarse de acuerdo a una relacin de causalidad entre los accesos a memoria. La o consistencia secuencial requiere que todos los procesadores estn de acuerdo en el orden e de los efectos observados. Por el contrario, la consistencia PRAM unicamente requiere un acuerdo respecto al orden de los efectos observados para procesadores individuales. Los 43

P1: P2: P3: P4:

W (x) 1 R (x) 1 R (x) 1 R (x) 1 W (x) 2

W (x) 3

R (x) 3 R (x) 2

R (x) 2 R (x) 3

Figura 3.7: Ejecucin bajo Consistencia Causal o eventos ocurridos en procesadores diferentes pueden observarse en distintos ordenes. La consistencia causal es una posibilidad intermedia. Lamport [45] introdujo la nocin de causalidad potencial, para capturar el ujo o de informacin en sistemas distribuidos. Este concepto puede aplicarse al contexto de o la memoria compartida distribuida, relacionando la recepcin de mensajes con lecturas o y el env de mensajes con escrituras. Los eventos ocurridos en un mismo procesador o estn ordenados en forma total por la causalidad potencial. Por otra parte, las lecturas a de escrituras remotas tambin estn relacionadas por la causalidad potencial: P 1 : e a W (x)1 P 2 : R(x)1. Puesto que P 2 lee el valor de la variable x, previamente escrita por P 1, y su accionar puede verse inuenciado por esta lectura, todas las escrituras que efecte P 2 de aqu en adelante, estarn causalmente relacionadas con la escritura que u a hizo P 1. La consistencia causal requiere que todos los procesadores estn de acuerdo en e el orden de aquellos efectos causalmente relacionados, pero permite que los eventos no relacionados, llamados concurrentes, sean vistos en ordenes diferentes. La Figura 3.7 ilustra este hecho mediante una secuencia de eventos vlida bajo consistencia causal. En a este caso, la escritura que hace P 2 sobre la variable x, est causalmente relacionada con a la escritura que hizo P 1 sobre x. Por esto, todos los procesadores deben ver esta secuencia de escrituras en el mismo orden. Los procesos P 3 y P 4 ven una secuencia distinta de valores para x pues las escrituras W (x)3 en P 1 y W (x)2 en P 2, son concurrentes. En [59] se presenta un protocolo de MCD que implementa consistencia causal 44

P1: P2: P3:

Acq (L)

W (x) 1

W (x) 2

Rel (L) Acq (L) R (x) 2 Rel (L) R (x) 1

Figura 3.8: Ejecucin bajo Consistencia Release o con un nivel bajo de overhead, menor al de otras implementaciones conocidas. En este caso, cuando un nodo env el contenido de una pgina, aprovecha de enviar, mediante a a piggybacking, una lista de todas las pginas que el receptor debe invalidar. La lista a incluye todas las pginas escritas por operaciones desconocidas para el receptor y que a potencialmente preceden causalmente a la operacin de escritura ms reciente conocida o a por el emisor sobre la misma pgina. a

3.2.4.

Consistencias Release y Lazy Release

El modelo de consistencia release, RC [27], se basa en el supuesto de que los accesos a variables compartidas se protegen en secciones cr ticas empleando primitivas de sincronizacin, como por ejemplo locks. En tal caso, todo acceso est precedido por una o a operacin acquire y seguido por una operacin release. Es responsabilidad del prograo o mador que esta propiedad se cumpla en todos los programas. Puesto que ningn otro proceso, ni local ni remoto, puede acceder a las variables u que han sido modicadas mientras se encuentren protegidas en la seccin cr o tica, la actualizacin de cualquier modicacin puede postergarse hasta el momento en que o o se lleva a cabo la operacin release. La operacin release no se da por completada o o hasta que la actualizacin haya sido propagada a todos aquellos procesadores en donde o haya rplicas. Con RC, la propagacin de un conjunto de modicaciones a memoria e o compartida se lleva a cabo con un costo jo. La Figura 3.8 muestra un ejemplo de una secuencia de eventos correcta bajo este modelo de consistencia. El proceso P 3 incumpli el contrato de consistencia y accedi a una variable compartida en una porcin o o o 45

P1: P2:

Acq (L)

W (x) 1

Rel (L) LRC RC Acq (L) R (x) 1 Rel (L)

Figura 3.9: Propagacin de Actualizaciones bajo RC y LRC o de cdigo sin proteger. En consecuencia obtuvo un valor inconsistente para la variable o le da. El modelo de consistencia Lazy Release, LRC [39], es una modicacin del anteo rior, que intenta no hacer trabajo innecesario, evitando actualizar copias que no sern a utilizadas posteriormente. En este caso, la actualizacin se retarda en cada procesador o hasta que algn proceso ejecute un acquire, que es el momento en que verdaderamente u se requieren los datos actualizados en ese procesador. Esto es particularmente util cuan do una seccin cr o tica se encuentra ubicada en un ciclo del programa. Con el modelo RC en cada iteracin se llevar a cabo la actualizacin. Con LRC, la actualizacin se hace o a o o slo si algn otro proceso desea entrar a la seccin cr o u o tica al nal de una iteracin. La o Figura 3.9 muestra la diferencia en el momento de propagacin de las actualizaciones o entre los modelos de consistencia Release y Lazy Release. Mientras que en el primero la actualizacin se hace visible a los otros procesadores antes que nalice la operacin o o release en P 1, en el segundo se hace durante la ejecucin de la operacin acquire en P 2. o o El sistema comercial TreadMarks [37] y el sistema acadmico CVM [38] implementan e ambos un modelo de consistencia lazy release para administrar su memoria compartida distribuida.

3.2.5.

Consistencia Scope

El modelo de consistencia Scope, ScC [31], se basa en la denicin de ambitos de o consistencia, o simplemente scopes. Un scope es el entorno respecto al cual se llevan a cabo referencias a memoria. Es decir, unicamente se garantiza que las modicaciones realizadas dentro de un scope sern visibles dentro de ese scope. Puede visualizarse un a 46

scope como todas las secciones cr ticas que se encuentran protegidas por un mismo lock. El intervalo en el cual un scope est abierto en un proceso dado se denomina una a sesin, por ejemplo, cuando un proceso se est ejecutando en su seccin cr o a o tica, lo hace dentro de una sesin para el scope correspondiente. Cualquier modicacin llevada a o o cabo dentro de una sesin del scope se hace visible a otros procesos que activen sesiones o en ese scope. No se garantiza que sean visibles las actualizaciones hechas fuera de la sesin. o El sistema Brazos [71], un sistema de MCD actualmente en evolucin, incorpora o un protocolo de consistencia basado en el modelo de consistencia Scope.

3.3.

Multithreading y Migracin de Threads en Sistemas de MCD o

Los sistemas operativos modernos han evolucionado hacia el soporte de procesos

multithreaded. Los threads son procesos livianos que comparten un espacio de direcciones y recursos del sistema operativo [73]. Los threads que forman un proceso se diferencian unicamente en los registros y el stack. Los cambios de contexto son poco costosos para el caso de threads de un mismo proceso, y la cooperacin entre ellos es o expedita pues comparten memoria sin proteccin. o En un sistema de MCD el uso de multithreading ayuda a mejorar el rendimiento, permitiendo aprovechar el retardo producido por los requerimientos remotos. Cuando un thread se bloquea porque el sistema debe hacer una peticin por una pgina ubicada en o a otro de los nodos del sistema, otro thread puede continuar aprovechando el procesador local. A pesar de que este cambio de contexto involucra algn costo, el mayor retardo u se da en el tiempo de transmisin y de procesamiento del requerimiento en el nodo o remoto [76]. Este hecho puede apreciarse en la Figura 3.10. El retardo provocado por un requerimiento remoto puede dividirse en overhead local para el env del requerimiento (L E ), o tiempo de transmisin a travs de la red (T1 ), overhead remoto por la recepcin del reo e o querimiento (RR ), procesamiento remoto del requerimiento (RP ), overhead remoto por 47

P1

P2

LE

T1

RR

RP

Figura 3.10: Distribucin del Retardo en un Requerimiento Remoto o el env de la respuesta (RE ), tiempo de transmisin de la respuesta (T2 ) y overhead o o local por la recepcin de la respuesta (LR ). o Si bien es cierto que con las tecnolog de red actuales, los tiempos de transferenas cia son insignicantes comparados con los overheads de env y recepcin (LE , RR , RE , o o y LR ), an as si se supone que los overheads son iguales en ambos nodos, el tiempo u , de procesamiento local, LE + LR , es menos de la mitad del tiempo de retardo total del requerimiento. El resto podr aprovecharse ejecutando otros threads. a El uso de multithreading tambin ayuda en la estructuracin de las aplicaciones e o paralelas y en el balanceo de carga entre los procesadores [34], [2]. Adems, es posible a aprovechar las arquitecturas paralelas simtricas, o SMP, ampliamente disponibles en la e actualidad. Si el computador cuenta con varios procesadores, todos ellos son aprovechados al existir varios threads esperando ejecucin. o Por otra parte, puesto que los threads son pequeos y fciles de administrar, es n a posible incorporar al sistema una caracter stica de migracin de threads, es decir, poder o mover un thread que se est ejecutando en un nodo hacia otro nodo del sistema. Desde a hace ms de una dcada se han venido desarrollando sistemas que implementan migraa e cin de procesos o de threads. Puede citarse: Charlott [4], Sprite [19], Ariadne [55], y o Arachne [18]. El objetivo detrs de la migracin es mejorar la localidad de los accesos a o a memoria compartida, ubicando en un unico nodo aquellos threads que acceden a los mismos datos [77]. De esta forma se reduce la cantidad de comunicacin entre los nodos o y por lo tanto se mejora el desempeo global del sistema [34]. Por supuesto que lo n idneo es que esta migracin se haga de forma transparente al programador, y de esta o o 48

RE T2 LR

    

forma los programas no deban modicarse para adaptarse ante la eventualidad de una migracin. o La estrategia para la migracin, es decir, decidir cundo es el momento apropiado o a para migrar un thread, es un aspecto complejo. Los primeros enfoques buscaban conseguir una carga balanceada entre los procesadores que componen el sistema [21], [20]. En el caso de un sistema de MCD debe considerarse, adems, la localidad de referencia de a los accesos [34], [67]. Una posibilidad es considerar la historia de los accesos remotos a los datos, y mediante una heur stica tomar decisiones sobre la redistribucin dinmica o a de los threads [68]. En todo caso, an superados los aspectos relativos a la estrategia de migracin, el u o proceso de migracin en s es complicado. Para migrar un thread es necesario suspenderlo o en su ubicacin actual y reiniciarlo en su nueva ubicacin en el mismo estado que estaba o o anteriormente. El problema es que, si se est empleando un modelo de consistencia a relajado, no hay garant de que la visin de la memoria compartida que tiene luego a o de la migracin sea la misma que ten en su ubicacin original. La situacin var o a o o a dependiendo del modelo de consistencia que se est empleando. e Un enfoque que puede ayudar a facilitar la tarea de la migracin es mantener o todos los datos de un thread en la memoria compartida, incluyendo su stack. De este modo, cuando el thread deba migrar, el sistema de MCD se encarga de gran parte del trabajo de migracin en forma transparente. Lo unico que deber migrarse por separado o a ser el estado del procesador, es decir, los registros. a Cuando un thread migra de un nodo a otro, la visin de la memoria compartida que o tiene en su nueva ubicacin depende del modelo de consistencia que se est empleando. o e Por esta razn, es posible que sea necesario tomar acciones de sincronizacin, impl o o citas y expl citas, para poder cumplir cabalmente con el modelo establecido. El caso ms simple es el del modelo de consistencia secuencial. Bajo este modelo se a han implementado sistemas de migracin, como es el caso de Millipede [34], dado que o no presenta problemas mayores. Con SC, las actualizaciones a la memoria se propagan sin retardos, respecto al proceso de migracin, por lo que un thread que migra a otro o 49

nodo encuentra la misma visin de la memoria que ten en su ubicacin original. En o a o otras palabras, el thread llega a un nodo que ha visto las actualizaciones a la memoria en el mismo orden en que fueron vistas en el nodo origen del que proviene. Sin embargo, los casos en que se est empleando un modelo de consistencia ms relajado que el secuencial a a requieren de un estudio ms cuidadoso. a En primera instancia es necesario denir un marco general para el estudio de la migracin, de modo que pueda llevarse a cabo comparaciones y, a la vez, se evite o algunos problemas que podr producirse en situaciones extremas. Existen algunas an restricciones sobre el proceso de migracin que deben ser tomadas en cuenta. o Primero, se supone que las migraciones nunca ocurren cuando el proceso a migrar se encuentra dentro de una seccin cr o tica. Esta restriccin es lgica y no resulta o o muy limitante, si se piensa que durante una seccin cr o tica el proceso se encuentra en poder de recursos locales que no pueden ser migrados. La generalidad que se puede obtener no justica el costo de permitir la migracin bajo estas circunstancias. Una reso triccin similar se aplica cuando un thread tiene asignados recursos del sistema que se o administran localmente. Este es el caso de impresoras, archivos locales, etc. Bajo estas circunstancias, al thread no le es permitido migrar. Adems, la interaccin entre las aca o ciones de consistencia que lleva a cabo el sistema de MCD y los procesos de migracin no o deben interferir entre s Para esto, se restringe la migracin de threads para que ocurra . o unicamente cuando no existan acciones de consistencia en ejecucin o pendientes de o nalizacin. Las condiciones bajo las cuales esta condicin puede relajarse comprende o o un area activa de investigacin. o Por otra parte, cabe suponer que el thread migrado llega a un nodo en el que se encuentran copias de las pginas que utiliza. En caso contrario el anlisis resulta trivial, a a pues las pginas se obtienen por demanda desde una fuente consistente, en concordancia a con el protocolo empleado. Cabe resaltar que la migracin de un thread puede provocar o que el sistema de MCD se vea forzado a transferir pginas que de otro modo no hubiera a transferido. Finalmente, se supone que las modicaciones a datos compartidos se llevan a cabo siempre dentro de secciones cr ticas. Esta condicin es incluso necesaria para o 50

Acq(L) W(x) Rel(L) ... Acq(L) R(x) Rel(L)

// Primera seccin crtica o

// Segunda seccin crtica o

Figura 3.11: Cdigo del Thread que va a Migrar o

protocolos como RC, LRC y ScC. A continuacin se analiza el proceso de migracin para o o algunos modelos de consistencia particulares.

3.3.1.

Migracin bajo Consistencia Secuencial o

Cuando se emplea SC la migracin de threads no presenta mayor problema desde el o punto de vista de la consistencia. Con SC, las actualizaciones a la memoria se propagan en forma atmica respecto a la migracin, a todos los nodos que mantienen copias o o locales de las pginas modicadas. Cuando un thread es migrado, en el nodo destino se a encuentran copias secuencialmente consistentes de las pginas que emplea, por lo que a no es necesario tomar acciones adicionales de consistencia.

3.3.2.

Migracin bajo Release Consistency o

Cuando el sistema se encuentra bajo RC, la suposicin de que no se produce mio gracin dentro de secciones cr o ticas garantiza la consistencia de la memoria en el nodo destino. En RC, la propagacin de las actualizaciones se lleva a cabo al momento del o release, es decir, al nalizar la seccin cr o tica. El release no se da por terminado hasta que la memoria se encuentra consistente en todos los nodos que mantienen copias de las pginas modicadas. Por lo tanto, la migracin no es posible hasta que se haya llea o vado a cabo esta sincronizacin. Cuando la migracin se lleva a cabo, el thread migrado o o 51

P1: P2:

Acq (L)

W (x)

Rel (L) Acq (L) R (x) Rel (L)

Figura 3.12: Acciones de Consistencia al Migrar un Thread bajo RC encuentra la memoria en un estado consistente, de acuerdo al modelo RC. Considere el ejemplo de la Figura 3.11, en el cual un proceso primero escribe y despus lee en una pgina x en particular, en ambos casos dentro de una seccin cr e a o tica. Si el thread migra en algn punto entre ambas secciones cr u ticas, encuentra la memoria consistente en el nodo destino, pues sta se actualiza al nalizar la primera seccin e o cr tica, como se muestra en la Figura 3.12. Recuerde que el nodo destino tiene copia de la pgina y por lo tanto debe recibir una actualizacin. a o

3.3.3.

Migracin bajo Lazy Release Consistency o

El caso de LRC requiere mayor estudio. No es posible aplicar el mismo razonamiento que para el caso de RC, pues las modicaciones no se llevan a cabo al terminar la seccin o cr tica, sino justo antes de empezar la siguiente. El aspecto importante en este caso es la obligatoriedad de emplear secciones cr ticas para modicar datos compartidos. Cuando un thread recin migrado intenta acceder a datos compartidos debe primero adquirir un e lock para entrar a la seccin cr o tica, y en ese momento se lleva a cabo la propagacin o de las modicaciones hechas en otros procesadores, entre los que puede encontrarse el nodo origen del thread, si es del caso. Cumpliendo con el protocolo, el acquire no se da por terminado hasta que esta propagacin ha concluido. o Volviendo al ejemplo de la Figura 3.11. Si el thread migra entre ambas secciones cr ticas se producir una situacin como la de la Figura 3.13. Antes de iniciar la segunda a o seccin cr o tica el modelo de consistencia actualiza la memoria en el nodo destino para que el thread migrado tenga la misma visin que ten en el nodo origen. Obsrvese o a e que en este caso el sistema de MCD toma acciones de consistencia adicionales como 52

P1: P2:

Acq (L)

W (x)

Rel (L) Acq (L) R (x) Rel (L)

Figura 3.13: Acciones de Consistencia al Migrar un Thread bajo LRC consecuencia de la migracin del thread, suponiendo que ningn otro thread en el nodo o u de destino haya accedido a la pgina primero. a

3.4.

Implementaciones de Sistemas de MCD

Desde la aparicin del primer sistema de MCD, Ivy [50], ha aparecido una diversidad o

de sistemas para una gran variedad de plataforma de hardware y software. Algunos han dejado marca por sus innovaciones y otros han pasado desapercibidos. En la actualidad el desarrollo se ha orientado hacia plataformas de bajo costo, como estaciones de trabajo Unix y computadores personales con sistemas operativos como Linux o Windows NT. Las innovaciones en tecnolog de redes y los bajos cosas tos de procesadores de alto rendimiento como el Pentium, hace que la construccin o de mquinas paralelas basadas en arquitecturas comerciales sea una alternativa muy a conveniente. A continuacin se presenta una breve descripcin de algunos de los sistemas de MCD o o que han surgido durante los ultimos aos. La seleccin se ha hecho dada la aplicabilidad n o que tienen hoy en d estos sistemas y porque estn en concordancia con los objetivos a a de esta tesis.

3.4.1.

TreadMarks

TreadMarks [37] es el sistema de MCD que ha tenido mayor difusin en el tiemo po ms reciente. Fue diseado para soportar computacin paralela sobre una red de a n o estaciones de trabajo Unix. Incorpora la primera implementacin del modelo de consiso tencia Lazy Release, as como de protocolos que permiten a mltiples escritores actuar u 53

sobre una misma pgina en forma simultnea, mediante el uso de dis [40]. Con esto a a se combate el problema de false sharing. El sistema ha sido portado a distintas plataformas, entre las que se puede citar IBM, DEC, SUN, HP, SGI y x86 con FeeBSD y Linux Slackware. Adems, se encuena tra disponible una versin para Windows NT. La programacin de aplicaciones puede o o llevarse a cabo en C, C++, Java y Fortran. El sistema TreadMarks fue desarrollado en Rice University, y se distribuye en forma comercial. Un aspecto que vale resaltar es que este sistema ha obtenido excelentes resultados de desempeo al compararlo con plataformas de paso de mensajes [54]. n

3.4.2.

CVM

El sistema CVM [36] fue desarrollado en University of Maryland y su nombre se deriva de las siglas de Coherent Virtual Machine. Es un sistema de MCD con soporte para multithreading unicamente a nivel del sistema. Esto quiere decir que los programas que se ejecuten sobre CVM no pueden ser a su vez multithreaded. El sistema est orgaa nizado como una biblioteca de nivel de usuario, que se enlaza con los programas del usuario para permitirles emplear la semntica de memoria compartida sobre el multia computador. La comunicacin se lleva a cabo empleando protocolos construidos sobre o el protocolo estndar UDP. Esto le da una gran exibilidad respecto a la forma en que a pueden conectarse los computadores participantes. Desde sus inicios, CVM fue pensado como un sistema experimental. Est escrito en a C++ y cuentas con varios protocolos de consistencia de memoria, incluyendo versiones de un unico escritor y de varios escritores simultneos para el modelo de consistencia a Lazy Release. El sistema se adapta a una diversidad de sistemas Unix, entre los que se cuentan Digital Unix, Solaris y AIX. A pesar de que uno de sus objetivos era la extensibilidad, la inclusin de nuevos o protocolos o la modicacin del cdigo existente no resulta una tarea sencilla. Adems, o o a slo es posible tener acceso al cdigo fuente de la primera versin del sistema. o o o 54

Un proyecto posterior, D-CVM, o Dynamic CVM incorpora multithreading a nivel del programa de usuario y migracin de threads [77], sobre las mismas plataformas que o soportan CVM.

3.4.3.

Quarks

Quarks [42] es un sistema de MCD, con cdigo fuente disponible, desarrollado en o University of Utah. Est implementado como una biblioteca de nivel de usuario y pera mite conectar estaciones de trabajo Unix para formar una mquina paralela. El sistema a ha sido portado a SunOS/SPARC, HP-UX/PA-RISC y IRIX/MIPS. Entre sus caracter sticas principales est la incorporacin de mltiples protocolos a o u de consistencia de memoria y el uso de multithreading para aprovechar los retardos de comunicacin. El sistema permite escribir programas en C y C++, empleando macros m4 o para especicar paralelismo y sincronizacin. o

3.4.4.

Brazos

Brazos [71] es un ambiente de programacin paralela de alto desempeo desarroo n llado en Rice University para ejecutarse en procesadores Intel con el sistema operativo Windows NT. La comunicacin se lleva a cabo empleando redes Ethernet de 100Mbps o y 1Gbps. El sistema Brazos es multithreaded, tanto a nivel del sistema en s como de los , programas del usuario. Dentro de sus caracter sticas distintivas se encuentra el uso de primitivas IP multicast, para reducir la cantidad de comunicacin, e incorpora un o protocolo que implementa el modelo de consistencia Scope. Alternativamente permite emplear un modelo de consistencia Release. La implementacin de Brazos est compuesta por tres partes. En primer lugar, o a una biblioteca a nivel del usuario que brinda soporte para las aplicaciones. Luego, un servicio de ejecucin remota para administrar las sesiones que se ejecutan en cada o mquina. Finalmente, una interfaz basada en ventanas. a 55

3.4.5.

Millipede

El sistema Millipede [24] fue desarrollado en Technion en Israel. Es una mquina a virtual paralela que se ejecuta sobre un cluster distribuido de computadores personales y SMPs. El sistema operativo de las estaciones participantes es Windows NT, y la tecnolog a de interconexin original es FastEthernet a 100Mbps. El sistema no requiere que los o nodos que forman la mquina virtual sean dedicados. a Millipede es un sistema completamente multithreaded, y soporta migracin de tho reads. Se han desarrollado una serie de interfaces de programacin para varios lenguajes o como ParC (Parallel C ). Una caracter stica distintiva de Millipede es el uso de una granularidad na, llamada Millipage, que aprovecha el hardware de administracin de memoria virtual o como lo hacen los sistemas con una granularidad de pgina [33]. a

3.4.6.

DSM-Threads

DSM-Threads [58] es un sistema de MCD desarrollado en Humboldt-Universitt zu a Berlin con el objetivo de portar aplicaciones multithreaded escritas para un multiprocesador, hacia un ambiente distribuido de computacin paralela compuesto por estaciones o Unix. Los programas escritos para DSM-Threads hacen uso de unas pocas macros y, en general, del estndar POSIX Threads, para la especicacin del paralelismo. Se incluye a o varios protocolos de manejo de consistencia y una interfaz de comunicacin estndar o a que hace al sistema independiente del medio utilizado para enlazar los computadores. En el futuro se espera que el cdigo est disponible bajo una licencia de tipo GPL, con o e cdigo fuente disponible para su modicacin y ampliacin. o o o

56

Cap tulo 4 Arquitectura de DSM-PEPE

DSM-PEPE es un sistema de MCD para la ejecucin de programas paralelos sobre o un multicomputador compuesto por procesadores Intel ejecutando el sistema operativo Windows NT. El sistema es multithreaded, aunque por ahora los procesos del usuario estn coma puestos por un unico thread. En un futuro cercano se incorporar el uso de procesos de a usuario multithreaded, as como una facilidad para la migracin de threads [56]. o La granularidad a la que se comparten datos es la pgina, escogida por su simplia cidad y para poder hacer uso del hardware de administracin de memoria, y no requerir o participacin adicional de parte del compilador. Los programas para DSM-PEPE se escrio ben en lenguaje C o C++, y el mdulo de memoria compartida distribuida se diseo como o n una biblioteca de nivel de usuario. La ejecucin de los programas se controla a travs de un programa de administrao e cin. Este programa cuenta con una interfaz de ventanas y es, a su vez, el encargado de la o recoleccin de informacin estad o o stica sobre las ejecuciones de los programas paralelos.

4.1.

Aspectos de Dise o n
Actualmente existen plataformas de ejecucin distribuida de programas paralelos o

sobre clusters de estaciones de trabajo. La que cuenta con mayor aceptacin es sin o 57

duda TreadMarks [37], que funciona sobre redes Unix y Windows NT y se distribuye en forma comercial mediante el pago de una licencia. Otros ejemplos son CVM [36], Quarks [42] y DSM-Threads [58], para plataformas Unix, Brazos [71] y Millipede [24] para computadores personales ejecutando Windows NT. Sin embargo, ninguno de estos sistemas puede emplearse para experimentar en profundidad con las caracter sticas de un sistema de MCD. En casos como TreadMarks y Brazos, el cdigo fuente no se encuentra disponible en forma gratuita y sin restrico ciones. En el caso de CVM y Quarks, es posible tener acceso al cdigo, sin embargo, el o complicado diseo arquitectnico de estos programas hace que sea muy complejo su n o estudio y modicacin. o Uno de los objetivos de DSM-PEPE es proveer a la comunidad acadmica de un e sistema de MCD que funcione sobre redes de estaciones de trabajo de bajo costo, y que sea posible modicar y agregar componentes en forma simple. De este modo, DSM-PEPE se convierte en una herramienta de experimentacin de gran utilidad y que, a la vez, o puede operar sobre redes existentes de computadores personales sin modicacin alo guna. El cdigo fuente se distribuye bajo una licencia pblica del tipo GPL, o GNU o u Public License. Cualquiera puede utilizar o modicar el cdigo, pero la licencia de los o programas resultantes debe seguir siendo GPL. Por otra parte, aprovechando las capacidades de los procesadores actuales y tecnolog novedosas de interconexin en red, DSM-PEPE puede constituir una poderosa as o mquina virtual paralela para la ejecucin de programas diseados originalmente para a o n multiprocesadores con memoria compartida. De este modo, se evita la complejidad inherente a escribir programas empleando el paradigma de paso de mensajes y se aprovecha el extenso trabajo que se ha desarrollado por dcadas en el ambito de la programacin e o paralela sobre multiprocesadores fuertemente acoplados. Sin embargo, los sistemas de MCD tienen desventajas respecto a sus contrapartes basados en paso de mensajes. El principal aspecto en contra es el desempeo. Al consn truir un sistema de MCD es inevitable introducir cierto grado de overhead provocado por la capa de software que implementa la semntica de memoria compartida. A pesar a 58

de que algunos sistemas de MCD han obtenido excelentes resultados en la prctica [54], a es necesario concentrar los esfuerzos en todo tipo de mejoras de desempeo que hagan n que la opcin de la MCD sea una alternativa factible para el procesamiento paralelo diso tribuido. Dentro de esta categor se ubica el uso de multithreading para aprovechar a los retardos producidos por la atencin de requerimientos remotos, el uso de migracin o o de threads para aumentar la localidad de referencia, el uso de protocolos de consistencia relajados que minimicen la comunicacin relacionada con consistencia y el uso de o protocolos de red de bajo overhead, para minimizar el costo incurrido en las transmisiones. Algunos de estos aspectos han sido considerados e incorporados en el diseo de n DSM-PEPE y otros lo sern a corto plazo. a Asimismo, el sistema permite el uso de distintos protocolos de consistencia para distintas regiones del espacio compartido. De esta forma se puede tratar en forma especial los distintos patrones de acceso que un programa paralelo pudiera tener sobre sus datos compartidos. Algunos sistemas, como CVM [36] y Quarks [42] permiten el uso de mltiples prou tocolos de consistencia, e incluso facilitan la asignacin de protocolos distintos a niveles o de granularidad tan bajos como la pgina. Sin embargo, la interfaz de los objetos relaa cionados no es limpia como en el caso de DSM-PEPE, por lo que las tareas de inclusin o y modicacin de protocolos no es sencilla. Adems, un nivel de granularidad tan bajo o a introduce mayor overhead al tener que mantener ms estructuras de datos para cada a pgina del sistema. a Para que una herramienta de experimentacin sea util, debe ser exible y fcil o a de utilizar. DSM-PEPE fue diseado utilizando tcnicas de orientacin a objetos, con el n e o propsito de hacer que sus componentes cuenten con interfaces limpias que les permitan o ser modicados o reemplazados fcilmente. Adems, debe permitir manipular la mayor a a cantidad de componentes distintos. Con DSM-PEPE es posible experimentar libremente con los protocolos de consistencia, protocolos de comunicacin y, a corto plazo, con o pol ticas de migracin de threads. o Para que el sistema tenga utilidad como plataforma de computacin de alto desemo 59

peo es necesario que la semntica de memoria compartida sea acorde con los modelos n a preestablecidos. Adems, la intefaz de programacin o API debe ser simple y fcil de a o a usar. Los programas que ejecuta DSM-PEPE estn escritos en el lenguaje C o C++, y a suministran la semntica de memoria compartida a travs de funciones de biblioteca. a e De esta forma, programas previamente escritos para un multiprocesador fuertemente acoplado pueden ser portados fcilmente a DSM-PEPE. a La memoria se manipula solicitando memoria a partir de regiones de MCD, en la forma en que se har al utilizar un heap. De esta forma la semntica es familiar al a a programador y los programas se pueden portar fcilmente. Otros sistemas emplean mea canismos diferentes para proveer la MCD. Por ejemplo, DSM-Threads [58] incorpora la utilizacin de macros dentro del cdigo del programa para denir las variables comparo o tidas. Otra opcin podr ser la denicin de nuevos tipos de datos aplicables slo a o a o o variables compartidas. Los programas paralelos dentro del sistema utilizan un paradigma SPMD, un unico programa que acta en forma paralela sobre distintos datos. Sin embargo, es evidente u que el programa puede ejecutar instrucciones distintas sobre los datos dependiendo de caracter sticas particulares como el identicador de proceso. El sistema se implement bajo Windows NT con el objetivo de aprovechar redes de o estaciones de trabajo existentes. Tradicionalmente los sistemas de MCD se implementaron bajo el sistema operativo Unix. Esto se deb a la amplia base instalada de estaciones de a este tipo en el ambiente acadmico, al alto desempeo que alcanzaban, la robustez del e n sistema operativo en areas cr ticas y las facilidades que ofrece para la introduccin de o niveles intermedios de software. Con la evolucin del sistema operativo Windows NT el o panorama cambi radicalmente pues ahora se cuenta con una plataforma de computador o personal ms robusta y con caracter a sticas similares a Unix en las areas cr ticas mencionadas. Windows NT cuenta con soporte nativo para multithreading a nivel del kernel, un excelente mecanismo de manejo de excepciones y comunicacin a travs de sockets. o e Como ventaja adicional se encuentra el bajo costo que tienen las redes de este tipo de computadores. La unica alternativa viable para sustituir a Windows NT y permanecer 60

Nodo Modulo de Ejecucion Remota Proceso MCD

Nodo Modulo de Ejecucion Remota Proceso MCD

Nodo Modulo de Ejecucion Remota Proceso MCD

Red Computador Administrador de Ejecucion Interfaz

Figura 4.1: Programa Distribuido en Ejecucin o dentro de los objetivos planteados, la presenta Linux, puesto que puede aprovecharse el mismo tipo de hardware y sin costo de licencias de software. Sin embargo, por tener acceso a redes Windows NT preexistentes, el desarrollo se orient hacia esta plataforma. o

4.2.

Organizacin o
El sistema DSM-PEPE es un ambiente de ejecucin paralela sobre un entorno diso

tribuido. Est compuesto por distintos computadores enlazados por una red y denoa minados nodos. Este ambiente constituye una mquina virtual paralela en donde los a programas se ejecutan empleando una semntica de memoria compartida. a La Figura 4.1 muestra la organizacin de un programa distribuido ejecutndose o a sobre el sistema DSM-PEPE. Un servidor centralizado se ejecuta en uno de los computadores de la red y se encarga de iniciar las aplicaciones. Este proceso recibe el nombre de Execution Manager, o Administrador de Ejecucin. El Execution Manager interacta o u con procesos esclavos, llamados mdulos de ejecucin remota, en cada uno de los como o putadores participantes para iniciar las aplicaciones remotamente. Estos procesos se ejecutan en forma permanente en los nodos del sistema, como servicios de Windows NT, algo que viene a ser el equivalente a los daemons del sistema Unix. Estos componentes forman el subsistema de ejecucin remota de DSM-PEPE. o 61

 Aplicacion MCD Sincronizacion Paginacion Comunicacion TCP / UDP Kernel

Figura 4.2: Organizacin Interna de un Nodo o Una interfaz basada en ventanas facilita al usuario la administracin de sus ejeo cuciones distribuidas. El unico requisito que se impone es que los programas de usuario que se van a ejecutar deben encontrarse en una ubicacin compartida a todos los nodos o o, al menos, bajo una misma ruta absoluta de disco en cada uno de ellos. El Execution Manager se encarga de transmitir, a cada proceso que se crea remotamente, toda la informacin que requiere para su interaccin con el resto de los o o procesos en los otros nodos. En particular, le asigna un identicador unico, en la forma de un nmero entero, y le indica los puertos en los que debe escuchar por informacin u o concerniente a consistencia de memoria y sincronizacin. El resto de la informacin, a o o saber, la que necesita para comunicarse con el resto de los nodos, la obtiene de archivos de conguracin. o Los nodos participantes en la ejecucin de un programa son homogneos y todos o e tienen el mismo cdigo de programa. De hecho, cada uno de los procesos se inicia a o partir del mismo mdulo ejecutable. La Figura 4.2 muestra la estructura interna de un o proceso en ejecucin en uno de los nodos del sistema. o Cuando el kernel del sistema operativo intercepta una excepcin relacionada con o memoria virtual, por ejemplo, el acceso a una pgina invlida, el mdulo de paginacin a a o o de DSM-PEPE toma el control y decide la accin a seguir. Puede ser que tenga que o 62

interactuar con el protocolo de consistencia implementado en el mdulo de MCD, quin a o e su vez puede intercambiar mensajes con otros nodos para implementar la consistencia. La sincronizacin global requiere tambin de comunicacin con los otros nodos y una o e o interaccin directa con el mdulo de MCD. Recuerde que algunos modelos de consistencia o o basan su funcionamiento en la ocurrencia de acciones de consistencia particulares. Un aspecto caracter stico del sistema DSM-PEPE es la creacin distribuida de proceo sos. Otros sistemas, como Quarks hacen uso de un servidor centralizado para coordinar la creacin de procesos y primitivas de sincronizacin [42]. La ventaja de la adminiso o tracin distribuida es que se evita la aparicin de cuellos de botella y se elimina la o o dependencia de un servidor particular. El espacio global de direcciones compartidas a que tienen acceso los distintos procesos en un programa se divide en fragmentos llamados regiones. Cada regin es un o fragmento de memoria que ser administrado en forma dinmica e independiente. En a a particular, los datos almacenados en una misma regin sern manejados por un mismo o a protocolo de consistencia. Sin embargo, regiones distintas pueden tener protocolos de consistencia distintos. Las regiones son manipuladas como heaps, utilizando funciones para asignar y liberar memoria.

4.2.1.

Subsistema de Comunicacin o

El subsistema de comunicacin est construido sobre el conjunto de protocolos o a estndar TCP/UDP, empleando sockets. Se cuenta con la abstraccin de una ocina de a o correos o PostOce, que permite enviar y recibir mensajes as como hacer broadcast. Cada nodo tiene un identicador unico que se utiliza para dirigir las comuni caciones y que es asignado por el administrador de ejecucin al iniciar la aplicacin o o distribuida. Las operaciones de sincronizacin y las de manejo de consistencia utilizan o distintos PostOces en cada nodo, de modo que sus mensajes asociados no intereran entre s Sin embargo, como se puede ver en la Figura 4.2, los subsistemas de sincroni. zacin y comunicacin interactan entre s o o u . 63

El uso de protocolos estndares permite que se pueda construir mquinas paralelas a a sobre redes preexistentes de estaciones de trabajo. Asimismo, es posible aprovechar sin modicacin nuevas tecnolog de red que aparezcan en el futuro. o as

4.2.2.

Subsistema de Paginacin o

El funcionamiento del sistema de MCD depende en forma cr tica de su interaccin o con el hardware de administracin de memoria virtual del computador. El subsistema o de paginacin es el encargado de llevar a cabo esta interaccin. o o El subsistema tiene control absoluto sobre las pginas de memoria virtual que a forman el espacio de direcciones global. Puede habilitar o deshabilitar pginas e ina terceptar las excepciones que se produzcan. Su interaccin con el subsistema de MCD o asegura el respeto por los modelos de consistencia que se estn aplicando. e

4.2.3.

Subsistema de MCD

El subsistema de MCD es el encargado de implementar la semntica de memoa ria compartida sobre el conjunto de memorias dbilmente acopladas. Lleva el registro e de las pginas que se encuentran almacenadas o replicadas localmente y, en general, a cualquier informacin que los protocolos de consistencia requieran para garantizar el o cumplimiento del modelo en cuestin. o Cuando se produce una excepcin por una pgina que no se encuentra almacenada o a localmente, este mdulo interacta con sus equivalentes en otros nodos con el objetivo o u de obtener la pgina. Adems, recibe la informacin del mdulo de sincronizacin que a a o o o pueda serle util a los protocolos.

4.2.4.

Subsistema de Sincronizacin o

La sincronizacin es un aspecto fundamental en la programacin paralela. Este o o mdulo implementa las primitivas de sincronizacin que permitirn a los programas o o a distribuidos su correcta ejecucin. Actualmente se dispone de barreras globales y de o 64

locks [3]. La implementacin de ambas primitivas de sincronizacin se hace en forma o o centralizada, aunque se planea reimplementar los locks en forma distribuida para evitar cuellos de botella.

4.3.

Multithreading
DSM-PEPE fue diseado para ser un sistema completamente multithreaded, tanto n

a nivel del sistema en s como de los procesos del usuario. En la actualidad slo se ha o implementado a nivel del sistema pero, a corto plazo, se permitir que los programadores a separen sus procesos en mltiples threads de control, empleando para ello una interfaz u basada en el estndar POSIX threads [49]. a La estructuracin del sistema de MCD como varios threads hace que su diseo sea o n ms limpio y que no se pierda tiempo empleando tcnicas de polling para el acceso a a e la red. Si el sistema fuera monol tico, deber gastarse una cantidad considerable de a tiempo vericando el estado de los buers para entrada de mensajes. Si se dedica un thread a atender la llegada de mensajes, ste podr bloquearse hasta que ocurra algn e a u evento que requiera de su atencin. El tiempo restante puede ser aprovechado para o otras tareas del sistema. En DSM-PEPE, adems del thread que ejecuta el cdigo del usuario, existe un thread a o que est encargado de la recepcin de mensajes desde los otros nodos del sistema y un a o thread que se encarga de garantizar la consistencia de cada pgina de memoria. Este a ultimo tambin es responsable de atender las peticiones concernientes a consistencia e que hagan los otros nodos para la pgina que administra. Adicionalmente existe un a thread que maneja en forma independiente las operaciones de sincronizacin. o El objetivo de separar en mltiples threads cada proceso del sistema es poder aprou vechar el tiempo de retardo que ocasionan los requerimientos remotos de consistencia. Cuando un thread debe bloquearse a causa de uno de estos requerimientos, otro thread podr ejecutarse mientras se satisface la peticin. Adems, de esta forma es posible a o a aprovechar nodos que cuenten con mltiples procesadores bajo una arquitectura SMP, o u 65

Synch Thread

DSMprocess

User Thread

PostOffice PO

Memory Manager MM

MsgMgr Thread

PostOffice synchPO

DSMregion

...

DSMregion

pTable

...
Req Req

Page

Page

...

Page

PageMgr Thread

PageMgr Thread

PageMgr Thread

Figura 4.3: Objetos Dentro de un Proceso en un Nodo de multiprocesamiento simtrico. e

4.4.

Objetos
La estructura interna de DSM-PEPE es orientada a objetos. Tanto las estructuras

de datos que utiliza el sistema para su administracin, como los elementos activos o o threads que lo componen, son instancias de clases de objetos. La Figura 4.3 muestra los objetos participantes en un proceso en ejecucin en uno de los nodos del sistema. o El administrador de memoria, o Memory Manager tiene una instancia unica en cada procesador, MM. Su funcin es controlar el espacio global de direcciones compartidas o para el proceso que se encuentra ejecutando. Adems, es quien ofrece la interfaz de a memoria compartida para el programador de aplicaciones, a travs de funciones para la e 66

creacin de regiones de memoria compartida y para la asignacin de memoria dentro de o o una regin. La comunicacin entre los nodos se lleva a cabo en un thread de ejecucin o o o distinto, asociado al objeto Memory Manager. A su vez, este thread es una instancia de la clase de objetos MsgMgrThread. Cada una de las regiones creadas en el programa se representa como una instancia de la clase DSMregion. Para crear una regin, el programador utiliza un mtodo del o e objeto MM instanciado en el nodo. Un aspecto importante es que, dada la caracter stica distribuida del sistema y de las aplicaciones que se ejecutan sobre l, todos los procesos que componen un programa e paralelo deben crear las regiones compartidas. No hay un proceso principal que sea el encargado de crear la regin. En realidad, la semntica de la operacin no es la de o a o crear la regin, sino ms bien habilitar las estructuras distribuidas que permiten la o a administracin compartida de dicha regin. Los programas solicitan la asignacin de o o o memoria perteneciente a una regin compartida empleando una funcin de asignacin o o o y, al igual que en el caso anterior, todos los procesos deben hacer el llamado en forma distribuida. Cada regin tiene asociada un subconjunto del espacio lineal de direcciones como partidas, en la forma de un arreglo de pginas de memoria virtual. Este arreglo se a representa en cada objeto DSMregion mediante una instancia de la clase PageTable. A su vez, cada pgina es representada dentro del sistema como una instancia de la clase a Page, como se ilustra en la Figura 4.3. Cada pgina que ha sido instanciada dentro de a una regin de memoria es administrada por un thread individual. El sistema manipula o estos threads como instancias de la clase PageMgrThread. Cuando un programa paralelo va a compartir una determinada regin de meo moria debe solicitar a la instancia MM de la clase Memory Manager la creacin de un o objeto DSMregion con un protocolo de consistencia asociado. Todos los procesos distribuidos que forman el programa deben llevar a cabo este procedimiento. Dependiendo del tamao de la regin solicitada, se crea una tabla de pginas, o instancia de la n o a clase PageTable, con la cantidad de entradas apropiada. Cada una de estas entradas 67

corresponde a un objeto de la clase Page y se crean durante esta inicializacin. o Un objeto Page contiene informacin sobre una de las pginas compartidas. Por o a ejemplo, si la pgina tiene una copia vlida en el nodo, si su proteccin permite escria a o tura o slo lectura, as como una cola de requerimientos pendientes, locales o remotos, o concernientes a la pgina en cuestin. De acuerdo al modelo de consistencia implemena o tado puede ser necesario mantener alguna otra informacin adicional respecto a las o pginas. Por ejemplo, para el caso del protocolo de consistencia secuencial que se ha a implementado, es necesario conocer la identidad de algn nodo que se supone pueda u tener una copia vlida de la pgina. Esta informacin, conocida como probable propiea a o tario o ProbOwner, es almacenada en un objeto derivado de la clase Page para el caso espec co del protocolo secuencial: SeqPage. El procedimiento para implementar los protocolos espec cos dentro del sistema se detalla a continuacin o

4.5.

Protocolos de Consistencia
Uno de los objetivos primordiales de DSM-PEPE es facilitar la experimentacin con o

protocolos de consistencia de memoria. Adicionalmente se desea tener la capacidad de asignar protocolos distintos a distintas variables compartidas, de modo que se pueda especializar el tratamiento de consistencia de acuerdo a los distintos patrones de acceso a datos que tengan los programas. Estos objetivos se incorporan en el diseo del sistema, el cual manipula los pron tocolos de consistencia a nivel de regiones de memoria. La consistencia de todas las variables que se almacenen en una misma regin ser garantizada por un mismo protoo a colo. Sin embargo, variables almacenadas en distintas regiones podrn ser administradas a con distintos protocolos de consistencia. La clase de objetos Page implementa la funcionalidad bsica asociada con las a pginas de memoria. El comportamiento particular que se quiere dar a la migracin a o de pginas es un aspecto denido por el protocolo de consistencia y, por lo tanto, se a implementa en forma separada. 68

Para implementar un protocolo de consistencia es necesario derivar una clase de objetos a partir de la clase Page. Existe un conjunto de eventos ante los cuales el protocolo debe actuar [64]. Puede citarse, la ocurrencia de una falta de pgina o page a fault, ya sea de lectura o de escritura, la llegada de un requerimiento remoto desde otro de los nodos del sistema que involucre manejo de consistencia, y la ocurrencia de una accin de sincronizacin. o o Precisamente el programador debe escribir el cdigo concerniente al tratamiento o de estos posibles eventos relacionados con consistencia. Esto se hace creando una nueva clase y escribiendo una serie de funciones, hasta ahora virtuales, de la nueva clase derivada. De esta forma la inclusin de un nuevo protocolo es una tarea sencilla y o el resultado es un cdigo extremadamente organizado. En la actualidad, modicar la o lista de eventos manejados por el sistema es una tarea simple, aunque debe llevarse a cabo dentro del cdigo del sistema mismo. En un futuro, esta lista se manejar dentro o a de un archivo de conguracin para permitir un procedimiento de modicacin ms o o a transparente.

69

Cap tulo 5 Implementacin o

Un programa paralelo en ejecucin es un conjunto de procesos distribuidos entre o los nodos del sistema. La semntica de memoria compartida se implementa sobre la a nocin de regin, un conjunto de pginas consecutivas de memoria, cuya consistencia o o a ser garantizada por un mismo protocolo. a Las regiones utilizan tablas de pginas para llevar el control del espacio que ada ministran. Las tablas de pginas apuntan a objetos de alguna clase derivada del tipo a Page, especializando de esta forma la implementacin del protocolo de consistencia o Cuando una regin de MCD es creada, se construye la tabla de pginas asociada y o a se reserva la cantidad de pginas necesarias de acuerdo al tamao de la regin. Todas a n o las regiones deben ubicarse en la misma direccin virtual en todos los nodos del sisteo ma. Para lograr esto se utilizan Memory Mapped Files, una caracter stica del sistema operativo que permite reservar memoria virtual en una direccin particular del espacio. o Las pginas son inicializadas unicamente en el Nodo 0 del sistema e inicialmente a residirn slo en ese nodo. Los dems nodos reservarn el espacio pero marcarn las a o a a a pginas como invlidas, de modo que cualquier acceso que se haga a ellas genere una a a excepcin de acceso ilegal a memoria. o El sistema intercepta todas las excepciones referentes a memoria, empleando el Manejo Estructurado de Excepciones provisto por el sistema operativo. Si una excepcin o 70

involucra la administracin de la MCD, entonces ser atendida, de lo contrario se dejar al o a a sistema operativo para su tratamiento. Una vez que se ha completado el manejo de una excepcin, la instruccin que la provoc es reiniciada para que el programa del usuario o o o contine su ejecucin normal. u o Las excepciones pueden provocarse por una operacin de lectura o de escritura. o Esto da lugar a dos tipos de excepcin: ReadFault o WriteFault, respectivamente. El o manejador de excepciones que protege el programa del usuario determina el tipo de excepcin y la direccin involucrada. A continuacin, genera un objeto de tipo Request o o o que es insertado en la cola de requerimientos de la pgina asociada. El proceso del a usuario es suspendido en una variable almacenada en el mismo requerimiento y el thread encargado de manejar los requerimientos para la pgina es sealizado. a n El PageMgrThread asociado con una pgina es responsable de atender los rea querimientos locales, como el descrito anteriormente, pero tambin los requerimientos e remotos, generados por otros nodos dentro del sistema. Dichas peticiones remotas son colocadas en la cola de requerimientos por el MsgMgrThread que se est ejecutando en a el nodo y que recibe los mensajes de los dems nodos del sistema. a Cuando el PageMgrThread atiende uno de los requerimientos de su cola, identica el tipo de excepcin que est tratando. Dependiendo de esto, llama a la funcin o a o apropiada dentro de la clase Page que tenga asociada. De esta forma, el protocolo de consistencia acta en forma independiente del manejo normal de las excepciones y se u permite la coexistencia de varios protocolos en regiones diferentes de memoria compartida.

5.1.

Aspectos Espec cos de Windows NT

Para poder adentrarse en los detalles de implementacin de DSM-PEPE, primero o

es necesario destacar algunas caracter sticas propias del sistema operativo Windows NT que son explotadas en esta implementacin. o 71

_try { Bloque de Instrucciones Protegidas } _except ( Filtro ) { Bloque de Instrucciones del Manejador } Figura 5.1: Manejador de Excepciones

5.1.1.

Manejo Estructurado de Excepciones

La interfaz de programacin Win32 incluye soporte para un robusto manejo de las o excepciones [29], [66]. En este contexto, una excepcin es un evento inesperado o que o impide que un proceso contine su ejecucin normalmente. Al igual que en la mayor de u o a los sistemas operativos modernos, se distingue dos tipos de excepcin: Las de hardware o y las de software. El enfoque tradicional para implementar el manejo de excepciones involucra pasar cdigos desde una funcin que detecta el error hasta una que nalmente lo atiende, o o pasando por toda la jerarqu de llamados que se haya producido. El manejo estruca turado evita la propagacin de los errores. Una vez que un manejador de excepciones o ha sido instalado, manejar la excepcin sin importar cuntas otros funciones se hayan a o a llamado. De esta forma una funcin puede tratar las excepciones de cualquier funcin o o que llame. La estructura de un manejador de excepciones dentro de un programa escrito en C o C++ se muestra en la Figura 5.1. Las instrucciones en el bloque de instrucciones protegidas se ejecutan en forma incondicional. Durante su ejecucin, el manejador de o excepciones denido por el ltro y por el bloque de instrucciones se convierte en el manejador activo. Si ocurre una excepcin durante la ejecucin del bloque protegido, incluyendo o o cualquier funcin que haya sido llamada directa o indirectamente, el sistema le dar el o a 72

Espacio de Direcciones Lineal de 32 bits 4GB FFFF FFFF Reservado para uso del sistema
16

2GB 8000 0000 Disponible para uso del programa 0 0000 0000

16

16

Figura 5.2: Espacio de Direcciones en un Proceso de Win32 control al manejador activo, a no ser que exista un manejador con mayor precedencia y que tome el control. El ltro sirve como un preprocesador de las excepciones y tiene acceso a las variables locales dentro del ambito de ejecucin. Dependiendo del valor que retorne el ltro o se determina la siguiente accin que se tomar: Pasar el control al manejador con el o a siguiente nivel de precedencia, descartar la excepcin continuando la ejecucin donde o o se interrumpi, o manejar la excepcin ejecutando las instrucciones que se ubican a o o continuacin. o

5.1.2.

Memoria Virtual

El sistema operativo pone a disposicin de los programadores una API, o interfaz o de programacin, para acceder a las primitivas de manejo de memoria virtual. Para o implementar el subsistema de MCD es necesario utilizar esta API para manipular las pginas de memoria y poder reservarlas, invalidarlas, activarlas, liberarlas y copiarlas. a Asimismo, ser necesario reservar memoria en direcciones espec a cas de memoria y cambiar la proteccin de pginas espec o a cas. Cada proceso en Windows NT cuenta con un espacio de direcciones virtuales de 73

Programa Win32

Usuario

API para Heaps API Memoria Virtual

API para MemoryMapped Files

Subsistema Win32

Administrador de Memoria Virtual de NT

Kernel NT

Hardware Memoria Fisica

Disco

Figura 5.3: Arquitectura de Manejo de Memoria de Win32

232 = 4GB por cuanto se utiliza direcciones de 32 bits. Sin embargo, slo la mitad de o este espacio est disponible para el proceso y el resto se reserva para datos y cdigo a o compartido, para cargar bibliotecas de enlace dinmico, o DLLs, cdigo del sistema, a o drivers y otros por el estilo. La Figura 5.2 ilustra este hecho. Mediante un estudio emp rico se comprob que, en procesos t o picos y que no hacen uso de bibliotecas de enlace dinmico, la direccin de memoria virtual 0x20000000 siema o pre estar disponible, y por un rango superior a 1GB. Aprovechando esta caracter a stica, la memoria compartida distribuida de los procesos de DSM-PEPE utilizar direcciones a virtuales que se encuentran en este rango. La Figura 5.3 [29] muestra la arquitectura de manejo de memoria que utilizan los sistemas operativos basados en Win32 y, en particular, Windows NT. Puede observarse que los programas del usuario tienen acceso a tres interfaces de programacin o distintas: Una para el manejo de heaps, una para el manejo de la memoria virtual, y nalmente una para el manejo de memory-mapped les. Para la implementacin de o DSM-PEPE fue necesario utilizar las dos ultimas interfaces. 74

La intefaz de manejo de memoria virtual, propiamente dicha, se utiliza para reservar y liberar memoria, as como para consultar por su estado o cambiar sus atributos de proteccin. o Cada direccin en un proceso puede estar en uno de tres estados: Libre, reservao da o comprometida. Los procesos inician su ejecucin con todas las direcciones libres. o Antes de poder utilizar una direccin, debe ser asignada, ya sea reservndola o comproo a metindola. Cualquier acceso que se haga a una direccin libre o slamente reservada, e o o generar una excepcin de proteccin de memoria. Vindolo desde el otro punto de a o o e vista, para poder acceder a una direccin de memoria, sta debe estar comprometida. o e Cuando se reserva una direccin no se compromenten pginas de la memoria f o a sica ni se reserva memoria en el dispositivo de paginacin. La reserva se utiliza unicamente o para proteger un rango particular de direcciones para su uso posterior. Por el contrario, cuando se compromete una direccin se asignan pginas de memoria y se reserva espao a cio en el dispositivo de paginacin. La memoria puede ser reservada o comprometida o utilizando la funcin VirtualAlloc con distintos parmetros. La liberacin del espacio o a o reservado o comprometido se lleva a cabo a travs de la funcin VirtualFree. e o Para cambiar la proteccin de las pginas comprometidas, Win32 ofrece la funcin o a o VirtualProtect. Con esta funcin es posible cambiar los atributos de una pgina entre o a a los valores PAGE READONLY, PAGE READWRITE y PAGE NOACCESS, indicando que la pgina puede accederse slo para lectura, para lectura y escritura, o no accederse del todo, o respectivamente. La violacin de los atributos de proteccin de una pgina origina una o o a excepcin de proteccin de memoria. o o Finalmente, la interfaz provee una funcin para consultar por el estado de las o pginas de memoria: VirtualQuery. Con esta funcin se puede conocer el estado de a o asignacin de la pgina y, si est comprometida, sus atributos de proteccin. o a a o Una funcin adicional, GetSystemInfo, no pertenece a la interfaz de memoria o virtual, sin embargo resulta de utilidad para obtener detalles sobre caracter sticas del sistema como el tamao de las pginas. n a 75

5.1.3.

Memory-Mapped Files

Los archivos proyectados a memoria, o memory-mapped les son una de las tres interfaces que posee Win32 para que los programadores manipulen la memoria virtual. Bsicamente, permiten acceder a archivos de disco a travs de punteros de memoria. El a e archivo podr ser el dispositivo de paginacin del sistema, por lo que se convierte en a o una herramienta de manipulacin de memoria virtual. o En la implementacin de DSM-PEPE se utiliza esta interfaz para garantizar la dio reccin en que se asignar las regiones de memoria compartida en cada nodo. De no ser o a as los procesos tendr que reubicar sus accesos a memoria dependiendo del nodo en , an que se estuvieran ejecutando. Para poder utilizar una proyeccin a memoria de un archivo, es necesario crear un o objeto que representar la proyeccin, utilizando la funcin CreateFileMapping, a la a o o que se debe indicar el tamao de la regin a proyectar. Posteriormente, con la funcin n o o MapViewOfFile se asigna la direccin virtual a la que se quiere proyectar el archivo. o Esta direccin no debe estar comprometida. o

5.1.4.

Multithreading

En Win32 un thread es bsicamente un camino de ejecucin a travs de un prograa o e ma [9]. Tambin es la m e nima unidad de ejecucin que administra el sistema operativo. o Consiste de un stack, el estado de los registros de la CPU, y una entrada en la lista de ejecucin del scheduler. Un proceso consiste de uno o ms threads y el cdigo, datos y o a o otros recursos de un programa en memoria. Los threads se crean a partir de funciones en el cdigo del programa, utilizando o la funcin CreateThread, a la cual se le puede pasar los parmetros que debe recibir el o a thread recin creado. e Una vez en ejecucin, el nuevo thread tiene la misma prioridad que su creador, y o ambos se ejecutan en forma concurrente. La prioridad de un thread en ejecucin puede o manipularse con las funciones GetThreadPriority y SetThreadPriority, para obtener 76

y modicar la prioridad, respectivamente.

5.1.5.

Sincronizacin o

Cuando mltiples threads interactan en forma concurrente en un programa es u u necesario utilizar sincronizacin para garantizar su correcto funcionamiento y evitar las o condiciones de competencia [3]. Win32 cuenta con una serie de mecanismo de sincronizacin para la coordinacin de threads. Puede citarse, secciones cr o o ticas (CriticalSection), exclusores mutuos (Mutex), semforos (Semaphore), y un mecanismo genrico para el a e manejo de eventos (Event). Aqu no se hace una discusin profunda de estas primitivias. Se recomienda con o sultar el libro de Beveridge y Wiener [9] para mayor detalle.

5.1.6.

Comunicacin o

Windows tiene acceso a comunicacin sobre los protocolos TCP/UDP a travs de o e una biblioteca de funciones llamada Windows Sockets, o simplemente WinSock. El funcionamiento de los sockets es muy similar al que se tendr en ambientes a Unix. Por esta razn no se entra en detalles al respecto. Para mayor referencia puede o consultarse el libro de Quinn y Shute [63], o el de Davis [17].

5.2.

Execution Manager
Para que sea prctico ejecutar aplicaciones paralelas en un ambiente distribuido a

debe contarse con algn mecanismo para la ejecucin remota de programas. En el caso u o de DSM-PEPE se construy un subsistema de ejecucin remota compuesto por el Exeo o cution Manager en un computador, y una serie de servicios o daemons, ejecutndonse a permanentemente en todos los nodos del sistema. En realidad este subsistema no se considera como parte del ncleo de DSM-PEPE, u pues su tarea es slo facilitar la iniciacin de los procesos distribuidos. De hecho, podr o o a utilizarse en forma general para la ejecucin remota de programas. o 77

RegionID CreateDSMregion(int size, Protocol protocol); char *DSMalloc(RegionID region, int size); Figura 5.4: Interfaz de la Clase de Objetos MemoryManager

Un programa basado en ventanas interacta con el usuario y recoge la informacin u o pertinente a la ejecucin. Posteriormente genera los parmetros apropiados que deben o a ser pasados a los programas en cada mquina y hace uso del Execution Manager para a iniciar los procesos. Cada proceso distribuido consulta un archivo de hosts, construido por el Execution Manager, para saber a qu puertos debe dirigir su comuncacin de e o consistencia y sincronizacin en cada uno de los nodos participantes o En cada nodo remoto se hace uso de la funcin CreateProcess del API Win32 o para ejecutar los programas, los cuales deben estar almacenados en la misma ruta absoluta en todos los nodos. La forma ms prctica de conseguir esto es utilizando un a a directorio compartido al que todos los nodos tenga acceso para lectura y ejecucin. o La comunicacin, al igual que en el resto de los componentes del sistema, se lleva o a cabo utilizando sockets.

5.3.

Objeto MemoryManager
El objeto MM es la unica instancia de la clase MemoryManager que existe en

cada proceso del usuario. Se encarga de la administracin de las regiones de memoria o compartida y es la unica interfaz que tiene el programador con el sistema de MCD. La inicializacin del objeto MM se hace en forma transparente al programa del o usuario. Actualmente, dentro de la funcin main del programa, inaccesible al prograo mador y, en el futuro cuando el sistema se enlace como una biblioteca, mediante una rutina de inicializacin general. o Las unicas dos funciones que son visibles al programador son CreateDSMregion 78

int MaxNRegions; int SystemPageSize; int NRegions; DSMregion **regions; DWORD NextBaseAddress; HANDLE hMsgMgrThread; DWORD MsgMgrThreadId; Figura 5.5: Atributos de Estado del Objeto MemoryManager

y DSMalloc cuyos prototipos se muestran en la Figura 5.4. La primera de ellas permite crear una regin de MCD, a partir de un tamao y un protocolo de consistencia que se o n aplicar a la regin. La funcin retorna un identicador de regin, de tipo RegionID, a o o o que deber usarse en lo sucesivo para solicitar memoria sobre la regin creada. a o Las regiones de MCD se administran como heaps. La funcin DSMalloc asigna una o cantidad determinada de bytes de una regin previamente creada mediante CreateDSMregion. o La funcin retorna un puntero que funcionar como mecanismo para que el programao a dor pueda acceder a la memoria compartida recin asignada. La funcin DSMfree, para e o liberar espacio previamente asignado, an no se ha implementado. A corto plazo esu tar disponible como parte de la interfaz de programacin. a o La Figura 5.5 muestra los atributos que mantienen el estado de un objeto MemoryManager. El atributo MaxNRegions indica la mxima cantidad de regiones que soporta el objeto. a Su valor se toma de un parmetro del constructor que, a su vez, es tomado de una a constante del sistema. A partir de esta cantidad mxima se dene un arreglo de puntea ros a objetos DSMregion, cada uno representando una de las regiones de MCD que se ha creado en el programa. La cantidad real de estas regiones se almacena en el atributo NRegions. El objeto tambin mantiene registro del tamao f e n sico de las pginas del a sistema (atributo SystemPageSize), y de la siguiente direccin virtual disponible para o asignacin de regiones (atributo NextBaseAddress). Puesto que hay un thread asociado o con el objeto MM, encargado de la administracin de los mensajes de comunicacin, otros o o 79

MemoryManager MaxNRegions SystemPageSize NRegions NextBaseAddress hMsgMgrThread regions MsgMgr Thread

...

Figura 5.6: Visin Grca del Objeto MemoryManager o a dos atributos: hMsgMgrThread y MsgMgrThreadId se usan para crear y mantener este MsgMgrThread, el cual es iniciado por el constructor del objeto. La Figura 5.6 ilustra en forma grca la composicin del objeto MM. a o Cuando se llama a la funcin CreateDSMregion para crear una nueva regin de o o DSM, el objeto MM busca la primera regin libre en el arreglo regions y asigna ah la nueo va regin, utilizando como direccin base el valor almacenado en NextBaseAddress. El o o protocolo de consistencia es pasado como parmetro al constructor del objeto DSMregion a y las variables de estado son actualizadas apropiadamente.

5.4.

Objeto DSMregion
Los objetos de tipo DSMregion representan las distintas regiones de MCD que pue-

den coexistir dentro de un programa. La consistencia de cada una de ellas puede manejarse en forma independiente, con protocolos de consistencia distintos. El estado de una regin se mantiene en los atributos descritos en la Figura 5.7. o El atributo id identica de manera unica la regin. Corresponde con el o ndice de la posicin en el arreglo regions del objeto MM. La direccin virtual en la que comienza la o o regin se almacena en BaseAddress, y su tamao es registrado por los atributos size o n 80

...
MaxNRegions 1

NRegions 1

RegionID id; DWORD BaseAddress; int size; int nPages; DWORD pFree; Protocol regionProtocol; PageTable *pTable; HANDLE hMMFile; char *lpMMFile; Figura 5.7: Atributos de Estado del Objeto DSMregion

y nPages, en bytes y cantidad de pginas, respectivamente. El puntero pFree se utiliza a para manejar el heap y corresponde con la primera direccin libre dentro de la regin. o o El protocolo asociado con la regin se guarda en regionProtocol. o Una regin es administrada como una proyeccin a memoria de un archivo, lo o o que en Windows NT se conoce como un memory-mapped le. Esto permite controlar la direccin virtual en la que se asigna la memoria y garantizar que es la misma en o todos los nodos que ejecutan un programa. El estado de esta estructura se mantiene en los atributos hMMFile y lpMMFile, siendo el primero de ellos un handler del sistema operativo, y el segundo un puntero con el que se tiene acceso real a la memoria de la regin. o La regin est compuesta por una serie de pginas que se concentran en una o a a tabla de pginas (atributo pTable). Esta tabla es en realidad una instancia de la clase a PageTable, la cual no es ms que un arreglo con punteros a objetos de un tipo derivado a de la clase Page. El tipo exacto de los objetos depender del protocolo de consistencia a con que se cre la regin. La Figura 5.8 muestra en forma grca la estructura de un o o a objeto de tipo DSMregion. La interfaz de la clase incluye un constructor que recibe como parmetro la direca cin base donde se debe crear la regin, el tamao solicitado y el protocolo que debe o o n 81

Region

DSMregion id BaseAddress size nPages pFree regionProtocol pTable hMMFile lpMMFile Tamao

Figura 5.8: Visin Grca del Objeto DSMregion o a

aplicarse para mantener la consistencia de la regin. La constante MIN REGION SIZE, o normalmente inicializada en 64 Kbytes, determina el menor tamao que puede tener n una regin. La razn de su existencia es que el sistema operativo no permite manipular o o proyecciones a memoria de archivos con tamaos ms pequeos. n a n

Tambin en la interfaz se dene la funcin RegionAlloc, para reservar una cane o tidad determinada de bytes en una regin. Esta funcin es utilizada por DSMalloc del o o objeto MM para asignar memoria en las regiones creadas por un programa. La funcin o GetPage entrega un puntero a un objeto de tipo Page, a partir del nmero de pgina u a dentro de la regin. Se incluye, adems, otras funciones utilitarias como GetRegionSize o a para obtener el tamao de una regin, AddressInRegion para vericar la pertenencia n o de una direccin virtual a una regin, y GetBaseAddress para recuperar la direccin o o o virtual que sirve de base para la regin. La Figura 5.9 detalla los prototipos de las o funciones que conforman la interfaz de la clase de objetos DSMregion. 82

Espacio Virtual de Direcciones

DSMregion(DWORD address, int requiredSize, Protocol protocol); char *RegionAlloc(int nBytesRequested); Page *GetPage(int pageNumber); int GetRegionSize(); bool AddressInRegion(void *address); DWORD GetBaseAddress(); Figura 5.9: Interfaz de la Clase de Objetos DSMregion

5.5.

Objeto Page
Las pginas de memoria son el objeto alrededor del cual se construye la funcioa

nalidad del sistema de MCD. Puesto que el sistema tiene una granularidad a nivel de pgina, son precisamente las rplicas de las pginas las que deben mantenerse cona e a sistentes a lo largo del sistema distribuido. Por esta razn, el comportamiento de las o pginas depender del modelo de consistencia que se est implementando. Para poder a a e cumplir con esto, las pginas se representan mediante clases derivadas de una clase a comn llamada Page. Dependiendo del protocolo de consistencia asociado con una reu gin de memoria compartida, el constructor de la clase PageTable crear pginas de o a a la clase derivada asociada con el protocolo, empleando el concepto de object factory o fbrica de objetos [72]. a La clase Page mantiene un estado comn a todos los tipos de pginas y sirve de u a enlace con el objeto PageTable. La Figura 5.10 resume los atributos de la clase. El identicador de la pgina dentro de la regin se almacena en pageNumber. El atributo a o status indica si la pgina es vlida o invlida en el nodo. En caso de ser vlida, sus a a a a atributos de proteccin se encuentran en protection, con posibles valores READONLY y o READWRITE. Cada pgina tiene asociado un PageMgrThread, encargado de atender los requea rimientos que vayan surgiendo y que se almacenan en la cola Requests. Para procesar un requerimiento se extrae de la cola y se almacena en el atributo currentRequest. El 83

int pageNumber; PageStatus status; Request *currentRequest; Semaphore *idlePageMgr; Semaphore *blockedPageMgr; Semaphore *mutexInvalidate; Semaphore *initBlock; Queue *Requests; HANDLE hPageMgrThread; DWORD PageMgrThreadId; DWORD address; AccessMode protection; Message *Reply; Figura 5.10: Atributos de Estado del Objeto Page

semforo idlePageMgr le permite al PageMgrThread bloquearse cuando no tiene trabaa jo pendiente. Por su parte, el semforo blockedPageMgr le permite bloquearse cuando a espera por un requerimiento remoto que hizo a otro nodo. En este caso, la respuesta que sea recibida le ser dejada al thread bloqueado en el campo Reply. a Puesto que las invalidaciones pueden ocurrir en forma asincrnica por parte del o MsgMgrThread asociado al objeto MM, el semforo de exclusin mutua mutexInvalidate a o se emplea para garantizar que no se aplicar una invalidacin a una pgina que est siena o a a do habilitada, dejando as el sistema en un estado inconsistente. La invalidacin no o podr proceder hasta que la habilitacin se haya completado. Finalmente, el semforo a o a initBlock se emplea para sincronizar el constructor del objeto Page con el PageMgrThread. El thread no podr proceder hasta que el constructor haya terminado su trabajo. a En la interfaz de la clase Page cabe destacar las funciones que manipulan el estado de la pgina en el nodo: InitPage, DisablePage, EnablePage y ChangeProtection. La a primera inicializa la pgina en el nodo. Las dos siguientes invalidan y habilitan la pgina a a y, nalmente, la ultima cambia sus atributos de proteccin. La proteccin se implementa o o cambiando directamente los atributos sobre las pginas de memoria, utilizando la API a 84

Page(int pageN, DWORD addr); void InitPage(); void DisablePage(); void EnablePage(char *buffer, AccessMode mode); void ChangeProtection(AccessMode mode); virtual void ReadFault(LocalRequest *req); virtual void WriteFault(LocalRequest *req); virtual void RemoteReadFault(RemoteRequest *req); virtual void RemoteWriteFault(RemoteRequest *req); Figura 5.11: Interfaz de la Clase de Objetos Page

para el manejo de memoria virtual de Win32. De esta forma, cualquier acceso anmalo o sobre una pgina ser interceptado por el hardware y manejado por el manejador de a a excepciones del sistema. En la Figura 5.11 puede verse el prototipo de las funcionen que componen la interfaz de la clase Page. Las funciones que dan la funcionalidad al protocolo de consistencia sobre las pginas se encuentran denidas como virtuales [72] en la clase Page. a De este modo podrn ser implementadas en las clases derivadas para cada protocoa lo de consistencia. Estas funciones son ReadFault, WriteFault, RemoteReadFault, y RemoteWriteFault.

5.6.

Threads
Uno de los aspectos relevantes en el diseo de DSM-PEPE es la coexistencia con n

el thread del usuario, de mltiples threads concentrados en tareas espec u cas de la administracin del sistema. Dos de los ms importantes son el MsgMgrThread, asociado o a al objeto MemoryManager para el cual hay una unica instancia, y el PageMgrThread, asociado a cada objeto Page y que, por lo tanto, cuenta con mltiples instancias en u cada programa. 85

5.6.1.

MsgMgrThread

El MsgMgrThread es el responsable de la recepcin de mensajes por la red y su o correcto encausamiento. Permanece bloqueado en espera de mensajes en el buzn PO, o utilizado para la comunicacin relacionada con consistencia. o

Ante la llegada de un mensaje, el thread extrae el identicador de regin y de pgio a na asociados y su siguiente accin depender del tipo de mensaje que se haya recibido. o a Si el mensaje es un requerimiento provocado por un fault remoto, ya sea de lectura o de escritura, generar un objeto de tipo RemoteRequest, y lo insertar en la cola de a a requerimientos de la pgina involucrada. Posteriormente sealizar al PageMgrThread a n a de la pgina para que atienda el requerimiento. Si el mensaje llega como respuesta a una a peticin que se gener previamente para otro nodo, se colocar en el campo Reply de o o a la pgina relacionada y se sealizar al PageMgrThread que espera por dicha respuesta. a n a

Un caso especial es cuando el mensaje recibido es una seal de invalidacin para n o una pgina en particular, provocada por el protocolo de consistencia en un nodo remoa to. En este caso, se est pidiendo a todos los nodos que tengan una rplica de la pgina a e a que la invaliden, es decir, que la descarten. Este tipo de peticin se hace normalmente o empleando un broadcast a todos los nodos del sistema y requiere de una respuesta de reconocimiento o ACK. El thread invalidar la pgina localmente, en exclusin mutua a a o con cualquier accin de habilitacin que pudiera estar pendiente, y generar el ACK o o a correspondiente. Precisamente, tambin es tarea del MsgMgrThread manejar los recoe nocimientos que lleguen ante la emisin de un broadcast. Este tipo de primitiva de o comunicacin involucra un contador para saber el nmero de respuestas que se han o u recibido. Cuando el thread recibe una de estas respuestas, decrementa este contador y verica si se ha completado la cuenta. En tal caso, es su responsabilidad desbloquear al PageMgrThread que emiti el broadcast. o 86

5.6.2.

PageMgrThread

Un PageMgrThread est encargado de la atencin de la cola de requerimientos de a o la pgina que tiene asociada. Mientras la cola se encuentre vac el thread permanece a a, bloqueado en un semforo del objeto Page. Los requerimientos son colocados en la a cola por el manejador de excepciones, para el caso de requerimientos locales, y por el MsgMgrThread, para el caso de requerimientos remotos. En cualquiera de los casos, el PageMgrThread es sealizado indicando la llegada del requerimiento y ste es extraido n e y manejado en el campo currentRequest del objeto Page. Puesto que el requerimiento pudo haber pasado un tiempo en la cola antes de ser atendido, el thread debe vericar que las condiciones que dieron lugar a la peticin o todav persisten. a Luego, como la funcionalidad del protocolo de consistencia no est implementada a en el objeto Page sino en una clase derivada de l, el PageMgrThread llama a la funcin e o asociada con el tipo de requerimiento que se est tratando. Dicha funcin ser ejecutada a o a por la instancia de la clase derivada de Page.

5.7.

Sincronizacin o
DSM-PEPE suministra dos mecanismos de sincronizacin distribuida a los que los o

programas pueden tener acceso: Barreras y locks. Ambos mecanismos se implementan en forma centralizada, aunque los locks se cambiarn a una implementacin distribuida a o a corto plazo. Las tareas de coordinacin centralizada se dejan al Nodo 0 del sistema. o

5.7.1.

Barreras

El Nodo 0 es el encargado de administrar las barreras, a travs de su SynchThread. e Un objeto de la clase BarrierCoordinator es creado en ese nodo y se encarga de contar la llegada de los mensajes que env los distintos nodos avisando de su llegada a una an barrera. Cuando este contador llega a ser igual al nmero de nodos en el sistema, se u 87

env mensajes de desbloqueo a todos los nodos, cuyos procesos estarn bloqueados an a esperando la llegada de estos avisos. El acceso a las barreras se hace a travs de la clase de objetos Barrier, cuya e unica funcin de interfaz disponible a los programas es WaitInBarrier. Esta es una o primitiva bloqueante, que dormir al proceso que la llame hasta que todos los nodos a hayan llegado a la barrera y el coordinador del Nodo 0 haya noticado de este evento.

5.7.2.

Locks

Un lock es un mecanismo de exclusin mutua distribuida implementado en forma o centralizada. La clase de objetos Lock implementa su funcionalidad. Al igual que en el caso de las barreras, en el Nodo 0 existe un objeto de la clase LockManager, encargado de administrar cada instancia de la clase Lock. Cada lock puede estar en uno de dos posibles estados: Libre u Ocupado. El estado inicial ser siempre libre. a Cuando un proceso desea tomar un lock, debe utilizar la funcin de interfaz o Acquire. Si se encuentra libre, la funcin retorna de inmediato y el nuevo estado o ser ocupado. En caso de estar ocupado, el proceso que hizo el llamado se bloquea a en una cola de espera hasta que el lock se encuentre libre y hayan pasado por l todos e los procesos que lo solicitaron previamente. Para liberar un lock se utiliza la funcin o de interfaz Release. Ambas funciones se comunican con el SynchThread en el Nodo 0, quien es el encargado de entregar el lock o dejar en espera al proceso emisor hasta que pueda hacerlo. El enfoque centralizado, implementando una pol tica FIFO, garantiza justicia en la implementacin. o

5.8.

Objeto PostOffice
La comunicacin entre nodos de todos los componentes del sistema recae en la clase o

de objetos PostOffice. Esta clase implementa la abstraccin de una ocina de correos o en donde se puede recibir mensajes de distintos tipos y para distintos destinatarios. La comunicacin se lleva a cabo utilizando sockets. Cada nodo del sistema eso 88

SOCKET hSockIn; int listenPort; int NumHosts; int NodeID; struct { char hostname[HOSTNAME_SIZE]; int port; } Hosts[MAX_NHOSTS]; Figura 5.12: Atributos de Estado del Objeto PostOce

cuchaen dos puertos TCP distintos, uno para mensajes relacionados con consistencia y otro para mensajes relacionados con sincronizacin. La recepcin de los mensajes la o o llevan a cabo los threads MsgMgrThread y SynchThread, respectivamente, utilizando dos instancias de esta clase: PO y SynchPO, conguradas en puertos distintos. Adems, a cada nodo debe conocer los puertos a travs de los cuales debe comunicarse con los e dems nodos. Esto se logra a travs de archivos de hosts que se encuentran en el mismo a e directorio que el programa ejecutable y que fueron creados por el ExecutionManager centralizado al momento de iniciar el programa distribuido. La Figura 5.12 muestra los atributos de estado de la clase de objetos PostOffice. Puede verse que cada instancia almacena en un arreglo de estructuras los datos concernientes a los puertos que debe usar para comunicarse con los otros nodos. Adems, a cada objeto registra su identicador de nodo, en el atributo NodeID, y la cantidad de nodos que participan en la ejecucin, en el campo NumHosts. Asimismo, el atributo o listenPort se reere al puerto en el que deber recibir conexiones, y su valor es pasaa do al constructor del objeto. Finalmente, el campo hSockIn se utiliza para manipular los sockets. En la Figura 5.13 se muestra los prototipos que forman la interfaz del objeto PostOffice. Puede verse que el constructor de la clase recibe como parmetro el puerto a TCP a travs del cual debe recibir conexiones, as como su identicador de nodo y el e 89

PostOffice(int TCPlistenPort, int node, char fname[]); int msgSend(short int node, void *msg, int nBytes); int msgRecv(void *msg, int nBytes); int msgBroadcast(void *msg, int nBytes, int *counter); int msgBroadcastEx(int nodeEx, void *msg, int nBytes, int *counter); int getNodeId(); int getHostsNumber(); Figura 5.13: Interfaz de la Clase de Objetos PostOce

nombre del archivo de hosts que debe emplear para obtener la informacin del resto de o los nodos en el sistema. El env y recepcin de mensajes a travs del PostOffice se lleva a cabo utilizando o o e las funciones msgSend y msgRecv, respectivamente. Para enviar un mensaje es necesario indicar el identicador de destino y la longitud del mensaje, que puede ser de cualquier tipo aunque por lo general ser encapsulado en una instancia de la clase de objetos a Message para poder as especicar un tipo que utilizar el receptor para direccionar el a mensaje. La recepcin de mensajes es una operacin bloqueante. El thread que haga el o o llamado ser bloqueado hasta que se reciba un mensaje en el PostOffice en cuestin. a o Las operaciones msgBroadcast y msgBroadcastEx permitan enviar un mismo mensaje a varios nodos en forma simultnea. Actualmente se implementan en forma a secuencial pero, en un futuro, podr aprovechar las caracter an sticas de multicast de la red. La diferencia entre estas dos funciones es que, la primera enviar el mensaje a a todos los nodos distintos al emisor, mientras que la segunda permite adems especicar a otro nodo que ser excluido de la operacin. Ambas operaciones requieren del uso de a o un contador cuya ubicacin es pasada como parmetro para garantizar la reentrancia, o a es decir, que puedan existir dos ocurrencias de broadcast simultneamente. a Las funciones getNodeId y getHostsNumber son accesorias y permiten obtener el identicador del nodo y la cantidad de nodos actualmente en el sistema, respectivamente. 90

5.9.

Protocolo de Consistencia Secuencial

En esta seccin se detalla la implementacin del protocolo de consistencia secueno o

cial que se incorpora en DSM-PEPE. En la actualidad ste es el unico protocolo existente, e sin embargo, se trabaja en la implementacin de un protocolo PRAM y uno LRC, los que o estar disponibles a corto plazo. an Para que la MCD se comporte acorde con un modelo secuencial es necesario garantizar que todos los nodos vean las actualizaciones a la memoria en el mismo orden. Para esto se aprovecha una caracter stica de las redes Ethernet: Los mensajes llegan en el orden en que son enviados, dado que hay un unico medio de comunicacin y no o hay enrutamiento ni buering de por medio. Esto quiere decir que si un nodo env dos a mensajes a otro nodo, stos se recibirn en el destino en el mismo orden que fueron e a despachados en el origen. No hay posibilidad de que el segundo se reciba primero. Los protocolos de consistencia se implementan derivando clases a partir de la clase Page. Bsicamente lo que debe hacerse es implementar la funcionalidad de las a funciones asociadas con los distintos eventos de consistencia que pueden ocurrir. Para el caso de la consistencia secuencial los eventos de inters son la ocurrencia de faltas de e pgina locales y la llegada de mensajes remotos provocados por faltas en otros nodos a del sistema. Otros protocolos consideran tambin los eventos de consistencia que se e producen local y remotamente. Los requerimientos remotos son recibidos por el MsgMgrThread y colocados en la cola de la pgina. A su vez, el manejador de excepciones que protege el cdigo del a o usuario coloca en la misma cola los requerimientos generados localmente. En ambos casos, el PageMgrThread es noticado y procede a llamar a la funcin virtual asociada o con el tipo de requerimiento. En la actualidad la cantidad de tipos de requerimiento que se manejan es ja. Se pretende emplear un archivo de cdigos y un arreglo de punteros o a funciones para que pueda agregarse nuevos tipos en forma sencilla. Para implementar el protocolo de consistencia secuencial es necesario agregar dos nuevos atributos, a los ya existentes en la clase Page. La nueva clase derivada, 91

int broadcastCount; int probOwner; Figura 5.14: Atributos de Estado del Objeto SeqPage

llamada SeqPage, y sus nuevos atributos se detallan en la Figura 5.14. El atributo broadcastCount se emplea como contador de broadcast a la hora de emitir ordenes de invalidacin. Por otra parte, el atributo probOwner sirve para llevar registro de cul fue o a el ultimo dueo conocido para la pgina, es decir, a qu nodo se deber pedir la pgina n a e a a en caso de ser requerida. Mayor detalle al respecto, a continuacin. o Inicialmente las pginas se inicializan y se mantienen unicamente en el Nodo 0. a El proceso en ese nodo tiene permiso para leer y escribir las pginas pues no existen a rplicas en otros nodos, donde las pginas se encuentran reservadas pero marcadas como e a invlidas. En todas las instancias distribuidas del objeto SeqPage asociadas con una a misma pgina se registra al Nodo 0 como el probable propietario de la pgina. Esto se a a hace guardando un 0 en el campo probOwner del objeto. En general, el propietario de una pgina ser el nodo que tuvo por ultima vez el a a permiso de escritura sobre la pgina. El unico nodo que puede entregar rplicas de una a e pgina a otros nodos es su propietario. De igual forma, para poder escribir una pgina es a a necesario primero convertirse en su propietario. Cuando la propiedad de una pgina se a entrega a otro nodo, que requiere escribir sobre ella, el antiguo propietario registra en el campo probOwner el identicador del nodo al que se la entreg. De esta forma se forma o una cadena de punteros y siempre es posible ubicar al actual propietario de la pgina, a no importa qu tan desactualizada sea la informacin que se tiene localmente. En el e o peor de los casos, una solicitud ir saltando de un nodo a otro, hasta llegar al verdadero a propietario de la pgina. Un nodo siempre puede saber si es el verdadero propietario a de una pgina comparando su identicador de nodo con el probable propietario de la a pgina. Estos valores coinciden slo en el caso del propietario. a o 92

void SeqPage::ReadFault(LocalRequest *req) { Message *msg; status = VALID; msg = new Message(msgREADFAULT, PO->getNodeId(), pageNumber, req->regionId, NULL, 0); PO->msgSend(probOwner, msg, msg->MsgSize()); blockedPageMgr->P(); // Node that actually answered becomes probOwner probOwner = Reply->RequestingNode; mutexInvalidate->P(); if (status == VALID) EnablePage(Reply->buffer, READONLY); mutexInvalidate->V(); delete(msg); // Signals user thread ((LocalRequest *)currentRequest)->block->V(); } Figura 5.15: Funcin ReadFault del Protocolo de Consistencia Secuencial o

5.9.1.

ReadFault

Cuando en un nodo ocurre un acceso a una pgina marcada como invlida se a a genera una excepcin y un requerimiento de tipo ReadFault para el PageMgrThread. o En este caso es necesario solicitar al propietario de la pgina el env de una rplica para a o e poder satisfacer la lectura. El nodo mantiene informacin unicamente sobre el probable o propietario de la pgina, por lo que debe enviar su requerimiento a l, con la certeza a e de que si ya no es el propietario, al menos redireccionar la peticin al nodo al que le a o entreg la propiedad. o En la Figura 5.15 puede verse el cdigo que implementa la funcin ReadFault para o o el protocolo de consistencia secuencial. Se env un mensaje al probable propietario, con a la informacin que resume la falla, incluyendo el nodo que hace el requerimiento, cul o a es la pgina involucrada y a qu regin pertenece. Esta informacin ser aprovechada a e o o a por el MsgMgrThread en el nodo de destino para saber dnde colocar el requerimiento o 93

remoto que se construir. Una vez que se env el mensaje, el PageMgrThread se bloquea a a a esperar la respuesta. Durante este tiempo no atender ninguna peticin, ni local ni a o remota, hasta que tenga una versin actualizada de la pgina. o a Una vez recibida la respuesta, debe copiarse y habilitarse la pgina que se ena cuentra en Reply. Para hacer esto es necesario entrar a una seccin cr o tica que evite la interferencia de las invalidaciones asincrnicas que puede provocar el MsgMgrThread. o Una vez habilitada la pgina se desbloquea al thread del usuario que estaba esperando a en un semforo asociado con el requerimiento. El cdigo del manejador de excepciones a o podr continuar sobre este thread y reiniciar la instruccin que provoc la excepcin. a a o o o Es necesario observar que la respuesta que se recibi no necesariamente provino o del nodo al cual se le hizo la peticin. Es probable que haya existido una secuencia o de redireccionamientos, o forwards. En cualquier caso, al recibir la respuesta, el nodo registra desde cul nodo se envi, actualizando de esta forma la informacin sobre el a o o probable propietario de la pgina. En futuros requerimientos la longitud de la cadena a de redireccionamientos se podr ver reducida. a

5.9.2.

RemoteReadFault

Cuando el PageMgrThread atiende un requerimiento provocado por un ReadFault remoto, debe vericar primero si todav posee la propiedad de la pgina involucrada. a a De no ser as debe redireccionar la peticin hacia el nodo que tiene registrado como , o probable propietario. Se restringi la entrega de rplicas al propietario de la pgina para o e a garantizar la consistencia secuencial. Otro nodo, distinto del propietario podr entregar a una copia cuando se ha iniciado un procedimiento de invalidacin. Puesto que slo el o o propietario puede iniciar uno de estos procedimientos, en la implementacin actual se o desestima este tipo de problemas. En caso de tener la propiedad de la pgina, debe asegurarse de cambiar sus atria butos de proteccin para que no pueda escribirse de ahora en adelante. De no ser as o , una escritura podr dejar la rplica que est por enviarse en un estado secuencialmena e a 94

void SeqPage::RemoteReadFault(RemoteRequest *req) { Message *msg; int ME = PO->getNodeId(); if (probOwner != ME) { // Not owner => Forward to probable owner msg = new Message(msgREADFAULT, req->remoteNode, pageNumber, req->regionId, NULL, 0); PO->msgSend(probOwner, msg, msg->MsgSize()); } else { // Owner => Reply to request this->ChangeProtection(READONLY); msg = new Message(msgREPLY, PO->getNodeId(), pageNumber, req->regionId, (char *)this->address, GetSystemPageSize()); PO->msgSend(req->remoteNode, msg, msg->MsgSize()); } delete(msg); } Figura 5.16: Funcin RemoteReadFault del Protocolo de Consistencia Secuencial o

te inconsistente. Posteriormente se env en un mensaje el contenido de la pgina al a a nodo que emiti el requerimiento. Esta informacin se mantiene invariante, aunque la o o peticin haya pasado por mltiples nodos hasta llegar al verdadero propietario. o u En la Figura 5.16 se muestra el cdigo que implementa la funcin RemoteReadFault o o para el caso del protocolo de consistencia secuencial.

5.9.3.

WriteFault

Una excepcin de WriteFault puede producirse por dos motivos. En primer lugar, o no existe una rplica de la pgina almacenada localmente. En este caso el proceder es e a muy similar al del caso del ReadFault. La otra posibilidad es que exista una rplica e pero que est protegida contra escritura. Esto protege la consistencia de las mltiples e u rplicas que existen de la pgina. e a 95

void SeqPage::WriteFault(LocalRequest *req) { Message *msg; int ME = PO->getNodeId(); if (probOwner == ME) { // Owner => Invalidate on all others msg = new Message(msgINVALIDATE, ME, pageNumber, req->regionId, NULL, 0); PO->msgBroadcast(msg, msg->MsgSize(), &broadcastCount); blockedPageMgr->P(); this->ChangeProtection(READWRITE); } else { // Not owner => Request to probable owner msg = new Message(msgWRITEFAULT, ME, pageNumber, req->regionId, NULL, 0); PO->msgSend(probOwner, msg, msg->MsgSize()); blockedPageMgr->P(); probOwner = ME; EnablePage(Reply->buffer, READWRITE); } delete(msg); // Signals user thread ((LocalRequest *)currentRequest)->block->V(); } Figura 5.17: Funcin WriteFault del Protocolo de Consistencia Secuencial o

96

La Figura 5.17 muestra la forma en que se implement la funcin WriteFault o o dentro del protocolo de consistencia secuencial. Cuando la falta se genera en el nodo que es propietario de la pgina, quiere decir que hay rplicas en otros nodos que deben a e ser invalidadas. Esto se logra enviando un mensaje en broadcast que ser atendido en a forma asincrnica. Es necesario esperar a que todos los nodos conrmen la invalidacin o o antes de proceder a escribir. De otro modo la consistencia podr verse comprometida. a Cuando la excepcin se produjo en un nodo que no es el propietario se trata de la o misma forma que si no existiera rplica local. Es decir, se procede a pedir al probable e propietario la pgina junto con su propiedad. Puesto que slo el propietario verdadero a o puede entregar la copia y la propiedad de la pgina, y por ser el propietario el unico que a puede escribir la pgina, la consistencia se garantiza al no poder haber invalidaciones a pendientes al momento de recibir la pgina y la propiedad. a

5.9.4.

RemoteWriteFault

Cuando un nodo procesa un requerimiento remoto de WriteFault, procede de manera similar al caso del requerimiento remoto de ReadFault. Verica si es el verdadero propietario de la pgina y, de no ser as redirecciona la peticin al nodo que registra a , o como probable propietario. La Figura 5.18 muestra el cdigo que implementa la funcin RemoteWriteFault o o en el protocolo de consistencia secuencial. Cuando el verdadero propietario recibe el requerimiento, debe invalidar primero todas las rplicas que existan en otros nodos e as como su copia local. Para no interferir con el requerimiento pendiente que existe en el nodo que emiti la peticin, dicho nodo es excluido del broadcast. Cuando se ha o o conrmado la invalidacin global, se procede a enviar la pgina, no sin antes actualizar o a el valor del probable propietario. 97

void SeqPage::RemoteWriteFault(RemoteRequest *req) { Message *msg; int ME = PO->getNodeId(); char *buffer; if (probOwner != ME) { // Not owner => Forward to probable owner msg = new Message(msgWRITEFAULT, req->remoteNode, pageNumber, req->regionId, NULL, 0); PO->msgSend(probOwner, msg, msg->MsgSize()); return; } // Only the owner replies to the request probOwner = req->remoteNode; buffer = new char[GetSystemPageSize()]; memcpy(buffer, (void *)(this->address), GetSystemPageSize()); this->DisablePage(); msg = new Message(msgINVALIDATE, ME, pageNumber, req->regionId, NULL, 0); if (PO->msgBroadcastEx(req->remoteNode, msg, msg->MsgSize(), &broadcastCount)) { blockedPageMgr->P(); } delete(msg); msg = new Message(msgREPLY, ME, pageNumber, req->regionId, buffer, GetSystemPageSize()); PO->msgSend(req->remoteNode, msg, msg->MsgSize()); delete(msg); delete(buffer); } Figura 5.18: Funcin RemoteWriteFault del Protocolo de Consistencia Secuencial o

98

5.10.

Otras Clases de Objetos

Las secciones anteriores describen las principales clases de objetos que intervienen en la implementacin de DSM-PEPE y del protocolo de consistencia secuencial que o incorpora el sistema. Se ha dejado de lado algunas clases accesorias para no complicar la descripcin. Estas clases se enumeran en la Tabla 5.1. o

Clase Request LocalRequest RemoteRequest PageTable Semaphore Message Queue Timer

Descripcin o Requerimiento de consistencia Derivado de Request para el caso de excepciones locales Derivado de Request para el caso de peticiones remotas Arreglo de punteros a objetos de tipo Page o clases derivadas Interfaz estndar para el uso de semforos: P() y V() a a Encapsula un mensaje que ser transmitido a traves de un PostOffice a Tipo de datos cola, con comportamiento FIFO Reloj para llevar registro de estad sticas de tiempo de ejecucin o

Cuadro 5.1: Otras Clases de Objetos Empleadas en la Implementacin o

5.11.

Funciones main y DSMmain

A pesar de que DSM-PEPE fue diseado para enlazarse como una biblioteca a los n programas del usuario, en la actualidad su funcionamiento es monol tico, es decir, el programa del usuario se mezcla con las funciones que incorporan el sistema de MCD. Sin embargo, dada la interfaz limpia diseada, la interaccin es m n o nima. La funcin main del programa se encarga de hacer las inicializaciones pertinentes o y construir los objetos globales que son necesarios para la ejecucin del programa. Este o es el caso del administrador de memoria, MM, y las ocinas de correo, PO y synchPO. De igual manera, al nalizar el cdigo del usuario se lleva a cabo la limpieza de las o estructuras de datos y objetos globales. El programador no debe escribir su cdigo dentro de la funcin main. Se ha dio o seado una funcin especial para este propsito, llamada DSMmain, que se ejecuta desde n o o 99

_try { DSMmain(atoi(argv[1])); } _except (ExceptionHandler(GetExceptionInformation())) {} Figura 5.19: Llamado a DSMmain() desde la Funcin main() del Sistema o

main y protegida por un manejador de excepciones. La Figura 5.19 muestra la porcin o de la funcin main que hace el llamado a la funcin DSMmain. El parmetro argv[1] o o a transmite el identicador del nodo, entregado por el Execution Manager como parmea tro de entrada al programa en ejecucin. o

100

Cap tulo 6 Programacin o

Uno de los objetivos de diseo del sistema DSM-PEPE es que permita la ejecucin n o de programas escritos previamente para multiprocesadores fuertemente acoplados. Para que esto sea factible, las modicaciones que requieran los programas deben ser m nimas. Para cumplir con este objetivo se opt por manejar la memoria compartida distribuida a o manera de heap de memoria dinmica. Los programas solicitan la asignacin de memoria a o a partir de regiones de MCD, las que permiten la coexistencia de mltiples protocolos u de consistencia en un mismo programa. Los programas tienen una estructura simtrica. Las regiones deben crearse en e todas las instancias de proceso y las asignaciones de memoria tambin deben replicarse e en forma distribuida. Puesto que toda la inicializacin se lleva a cabo en la funcin o o main del programa, slo es necesario escribir el cdigo efectivo del programa dentro de o o la funcin DSMmain. o Para que cada proceso pueda conocer su identidad y trabajar en forma asimtrica, e la funcin DSMmain recibe un parmetro entero, llamado nodeID. Este identicador o a permite diferenciar los distintos procesos que forman el programa paralelo y se asigna desde 0 en adelante. 101

RegionID CreateDSMregion(int size, Protocol protocol); char *DSMalloc(RegionID region, int size); Figura 6.1: Interfaz de Programacin o

6.1.

Interfaz de Programacin o
En la actualidad el programador dispone unicamente de dos funciones provistas

por la biblioteca de DSM-PEPE para el manejo de la MCD y cuyos prototipos se muestran en la Figura 6.1. El tipo de datos RegionID se utiliza para representar los identicadores de regin de MCD. En la implementacin actual el unico protocolo de consistencia o o disponible es el secuencial. Por lo tanto, de la enumeracin Protocol el unico valor o vlido que puede utilizarse es SEQi. En un futuro cercano se dispondr de, al menos, a a un protocolo PRAM y uno Lazy Release, o LRC. La funcin CreateDSMregion dene una regin de memoria compartida cuya cono o sistencia ser garantizada por el protocolo especicado. El unico valor posible para el a protocolo es SEQi. Cualquier otro valor har que la funcin falle. El tamao deseado a o n para la regin debe incluirse como primer parmetro de la funcin. Este valor debe o a o indicarse en bytes. El tamao m n nimo para una regin est denido por la constante o a global MIN REGION SIZE, cuyo valor es 65536. Esto quiere decir que no puede utilizarse regiones de menos de 64Kbytes de longitud. En caso de solicitarse una regin ms o a pequea, el sistema ajustar el tamao al m n a n nimo denido. Si la regin se pudo denir o con xito, la funcin devolver un identicador de tipo RegionID. Si se produce algn e o a u error y la regin no puede asignarse, la funcin retorna la constante INVALID REGION. o o La funcin DSMalloc asigna memoria dentro de una regin previamente creada o o con CreateDSMregion. El parmetro region debe ser el valor retornado por el llamado a previo a CreateDSMregion. El parmetro size se reere a la cantidad de bytes que se a est solicitando asignar. La funcin retorna un puntero al area asignada, o la constante a o NULL en caso de error. Por el momento no existe una funcin DSMfree que libere espacio o 102

Barrier::Barrier(); Barrier::~Barrier(); void Barrier::WaitInBarrier(); Lock::Lock(); Lock::~Lock(); void Lock::Acquire(); void Lock::Release(); Figura 6.2: Primitivas de Sincronizacin Distribuida o

asignado para una posterior reutilizacin. o La sincronizacin distribuida se implementa a travs de dos clases de objetos: o e Barrier y Lock, para barreras y locks, respectivamente. Los prototipos de las funciones que forman la interfaz de estas dos clases se muestran en la Figura 6.2. Las barreras permiten sincronizar a todas los procesos distribuidos en un punto determinado del programa. Cuando un proceso llama a la funcin WaitInBarrier pero manecer bloqueado hasta que todos los procesos hayan arribado a la barrera y llamado a a la funcin. El ultimo proceso en llamar a la funcin desencadena una serie de seales o o n que despiertan a los procesos bloqueados. Las barreras se conguran para la cantidad de nodos participantes en el sistema y pueden reciclarse indenidamente. Los locks implementan exclusin mutua para el acceso a variables compartidas. o Inicialmente un lock se encuentra disponible, y es adquirido por un proceso a travs e de la funcin Acquire. El proceso que posee un lock puede liberarlo empleando la o funcin Release. Cuando un proceso llama a la funcin Acquire y el lock se encuentra o o tomado, se bloquear hasta que sea liberado. La implementacin garantiza justicia a a o travs de una pol e tica FIFO, es decir, los procesos esperan en el orden de llegada. No existe implementado mecanismo alguno para la deteccin de los deadlocks que pudieran o producirse al utilizar varios locks en un programa. Es responsabilidad del programador evitar las condiciones de riesgo. 103

void DSMmain(int nodeID) { RegionID Rid1, Rid2, ... ; int A*, B*, ... ; Rid1 = MM->CreateDSMregion(size1, protocolo1); Rid2 = MM->CreateDSMregion(size2, protocolo2); ... A = (int *)MM->DSMalloc(Rid1, sizeA); B = (int *)MM->DSMalloc(Rid2, sizeB); ... if (nodeID == 0) { // Cdigo para el proceso 0 o } else { // Cdigo que ejecutan los procesos que no son 0 o } // Codigo comun a todos los procesos } Figura 6.3: Estructura de un Programa de Aplicacin o

6.2.

Programa Ejemplo
Las variables compartidas dentro de un programa distribuido deben denirse den-

tro de una regin de MCD. La cantidad de regiones distintas dentro de un programa o depender, principalmente, de la cantidad de protocolos de consistencia diferentes que el a programador quiera aplicar a sus datos compartidos. Si slo se va a utilizar un protocolo, o basta con denir una unica regin. La cantidad mxima de regiones que puede denirse o a en un programa del usuario est denida en la constante del sistema MAX NUM REGIONS, a a la cual el programa del usuario tiene acceso. Para denir una regin de MCD, el programador debe declarar una variable de tipo o RegionID y almacenar en ella el resultado del llamado a la funcin CreateDSMregion o sobre el objeto MM que es global a todos los procesos. Una vez que se ha creado la regin, o es posible solicitar memoria utilizando DSMalloc sobre el mismo objeto MM. La funcin o DSMalloc retorna un puntero a char, que puede ser convertido a cualquier otro tipo de 104

puntero utilizando type casting. As la estructura de un programa de DSM-PEPE viene , a ser algo como lo que se muestra en la Figura 6.3 El ejemplo de la Figura 6.4 es uno de los programas que se utiliz para probar o el sistema en su primera versin. Corresponde a una multiplicacin de matrices en o o paralelo, diseada para que fuera llevada a cabo por cuatro procesadores. Se dene una n unica regin de MCD, cuyo tamao se estima para que permita almacenar tres matrices o n de dimensin Dim Dim de nmeros enteros. Se asigna memoria para cada una de las o u matrices, las cuales sern referenciadas utilizando punteros a int con los nombres: A, B a y C. El Nodo 0 inicializa con valores aleatorios las matrices A y B, y todos los procesos esperan en una barrera la llegada de sus colaboradores. Cuando esto ocurre, cada nodo se dedica a obtener el resultado de uno de los cuatro cuadrantes que componen la matriz resultado C. Estos procedimientos son independientes, pues no existen condiciones de competencia por datos compartidos. Una vez que han nalizado, esperan de nuevo en la barrera, y el Nodo 0 despliega el resultado en la pantalla.

105

void DSMmain(int nodeID) { RegionID Rid; char *pA, *pB, *pC; int *A, *B, *C; int i, j, Dim = N*2; Rid = MM->CreateDSMregion(12*N*N*sizeof(int), SEQi); if (Rid == INVALID_REGION) ERRORMSG("DSMmain", "NO se pudo crear la region!!!\n"); pA = MM->DSMalloc(Rid, 4*N*N*sizeof(int)); if (pA==NULL) ERRORMSG("DSMmain", "NO se pudo obtener memoria para A"); A = (int *)pA; pB = MM->DSMalloc(Rid, 4*N*N*sizeof(int)); if (pB==NULL) ERRORMSG("DSMmain", "NO se pudo obtener memoria para B"); B = (int *)pB; pC = MM->DSMalloc(Rid, 4*N*N*sizeof(int)); if (pC==NULL) ERRORMSG("DSMmain", "NO se pudo obtener memoria para C"); C = (int *)pC; if (nodeID == 0) { RandomInitMatrix(A,Dim); RandomInitMatrix(B,Dim); } BB->WaitInBarrier(); mult(nodeID, Dim, A, B, C); BB->WaitInBarrier(); if (nodeID == 0) PrintMatrix(C,Dim); } Figura 6.4: Programa para Multiplicacin de Matrices o

106

Cap tulo 7 Experimentacin y Resultados o

Para probar el sistema de MCD desarrollado se condujo dos series de pruebas, con dos aplicaciones diferentes, multiplicacin de matrices y un algoritmo de ordenamiento. o En el primer caso se pretende demostrar la aplicabilidad del sistema como computador paralelo. En el segundo, probar el funcionamiento del sistema y del protocolo de consistencia ante situaciones extremas de intercambio de pginas. a El multicomputador est compuesto por computadores idnticos, cuyas caraca e ter sticas se enumeran en la Tabla 7.1. La red que comunica los computadores es una Ethernet de 100Mbps para la primera aplicacin, y una Ethernet de 10Mbps para la o segunda. Los programas fueron compilados utilizando Microsoft Visual C++, versin o 6.0.

Procesador Velocidad de Reloj Memoria Cach e Memoria RAM Disco Duro Sistema Operativo Versin S.O. o

Intel Pentium III 550 MHz 256 Kbytes 128 Mbytes 10 Gbytes Windows NT 4 con Service Pack 6

Cuadro 7.1: Caracter sticas de los Computadores

107

0 1 2 3 4 5 6 7 0 2 4 6 1 3 5 7

P0 P1

P0 P2

P1 P3

P0 (a)

P1 (b) (c)

Figura 7.1: Tipos de Particionamiento de una Matriz: (a) Striped en Bloque, (b) Striped C clico, (c) Checkboard Para minimizar el impacto de eventuales errores inducidos por factores externos, las mediciones se repitieron 10 veces, en ambiente dedicado, para luego considerar valores promedio.

7.1.

Multiplicacin de Matrices o
La multiplicacin de matrices es un proceso iterativo que puede paralelizarse fcilo a

mente, pues se puede acceder a las matrices a multiplicar slo para lectura y la escritura o del resultado puede distribuirse entre los mltiples procesadores, eliminando as las conu diciones de competencia. El primer aspecto a considerar es la asignacin de los tramos o de la matriz resultado que deber calcular cada procesador. Existen dos formas de llevar a a cabo este particionamiento [43]: En rebanadas, llamado striped y en pequeos bloques n rectangulares o cuadrados, formando un tablero y llamado checkboard. La Figura 7.1 muestra las dos formas existentes para hacer un particionamiento de tipo striped: En bloque y c clico, as como un particionamiento de tipo checkboard. Para la implementacin de este algoritmo se eligi un particionamiento de tipo o o striped. La decisin se bas en el acomodamiento de los bloques en pginas individuales o o a de memoria de modo que pudiera hacerse una mejor interpretacin de las medicioo nes. Cada matriz cuadrada se divide en rebanadas del mismo tamao, una por cada n computador participante, en la forma en que se muestra en la Figura 7.2 para el caso de un multicomputador compuesto por cuatro nodos. Por simplicidad se hace refe108

0 1 2 3

Figura 7.2: Particionamiento de las Matrices rencia a estas rebanadas como bloques. Para el caso de una matriz de 64 64, el espacio requerido para almacenar cada uno de los 4 bloques del particionamiento es: 16 64 sizeof(int) = 4096 bytes. En el caso de los computadores que se utilizaron, este valor coincide con una pgina de memoria. La implementacin del programa se a o asegura de que cada uno de los bloques se almacene en forma contigua. En este ejemplo, puede verse que para calcular el bloque 1 del resultado se requieren las pginas que almacenan el bloque 1 de la matriz A, y todos los bloques de a pginas de la matriz B, as como las pginas que componen el bloque 1 de la matriz C. a a En total, 1 bloque de pginas de A, 4 bloques de pginas de B y un bloque de C. a a Para analizar el comportamiento que tendr el programa, considere el caso del a proceso encargado de obtener el resultado en el bloque 1, en la matriz de 64 64 descrita, suponiendo el uso de 4 computadores. La primera vez que intente acceder a las las de A y a las columnas de B, se producirn excepciones que harn que las pginas que a a a almacenan los bloques 1 de la matriz A, y 0, 1, 2 y 3 de la matriz B, sean replicados localmente. Estas matrices se acceden slo para lectura, por lo que no se producirn ino a validaciones posteriores sobre esas rplicas. Adems, se producir una excepcin cuando e a a o el proceso intente escribir sus resultados en el bloque 1 de la matriz C. La propiedad de la pgina que almacena este bloque le ser cedida y continuar escribiendo en ella sin a a a interrupcin. Al nalizar el programa, cuando el Nodo 0 proceda a escribir el resultado, o se producir una excepcin para la pgina que almacena el bloque 1 de la matriz C. a o a Al nalizar el clculo global, la propiedad de las pginas que almacenan la matriz C a a estar uniformemente distribuida en todos los nodos: Cada nodo poseer una pgina y a a a 109

MCD 4p 2,694 2,734 2,754 2,704 2,724 2,794 2,713 2,684 2,694 2,674 2,717

Tiempo de Ejecucin (segundos) o MCD 1p Mono ST Mono MT. 6,28 7,401 6,639 6,019 8,152 6,049 8,051 7,151 8,132 6,029 6,990 13,399 13,389 13,399 13,399 13,399 13,400 13,400 13,399 13,400 13,400 13,398 13,399 13,409 13,409 13,419 13,409 13,409 13,409 13,409 13,410 13,409 13,409

Mono Opt. 0,861 0,861 0,851 0,861 0,851 0,861 0,861 0,851 0,862 0,861 0,858

Cuadro 7.2: Multiplicacion de Matrices 256 256

tendr derecho de escritura sobre ella. a La Tabla 7.2 muestra una comparacin del tiempo de ejecucin para distintas cono o guraciones y versiones del programa de multiplicacin de matrices de tamao 256. La o n primera columna, MCD 4p, se reere al programa descrito anteriormente, ejecutndose a sobre el multicomputador con 4 procesadores. La siguiente columna, MCD 1p, se reere al mismo programa pero ejecutando en un slo computador con 4 instancias del mismo o proceso. La unica diferencia es que el Execution Manager selecciona la misma mquina a para ejecutar 4 nodos. En este caso no existe comunicacin real por la red. La terceo ra columna, Mono ST, muestra los resultados para una versin singlethreaded diseado o n para un monoprocesador. El mecanismo de acceso es el mismo que en el caso anterior, es decir, las referencias no son directas a la memoria sino que se pasa por funciones de biblioteca que obtienen la ubicacin en memoria de cada posicin de la matriz. El o o programa es una versin secuencial de los anteriores, separando la matriz pero trabao jando en cada bloque en forma secuencial. La cuarta columna, Mono MT es una versin o multithreaded del programa anterior, separando y asignando la matriz con las mismas pol ticas que en el programa diseado para el multiprocesador. Finalmente, la quinta n 110

MCD 4p 13,169 13,119 13,139 13,069 13,119 13,129 13,188 13,129 13,039 13,069 13,117

Tiempo de Ejecucin (segundos) o MCD lp Mono ST Mono MT 46,136 49,732 50,743 45,976 49,731 50,703 45,746 49,732 50,713 45,946 49,731 50,913 45,676 49,732 50,913 45,977 49,732 50,773 46,537 49,732 51,003 45,776 49,732 51,023 45,696 49,731 50,753 45,956 49,741 50,993 45,942 49,733 50,853

Mono Opt 4,336 4,327 4,326 4,326 4,326 4,326 4,336 4,336 4,336 4,336 4,331

Cuadro 7.3: Multiplicacin de Matrices 400 400 o

columna, Mono Opt es un programa totalmente diferente, optimizado en su algoritmo y forma de acceso a los datos para un monoprocesador. La ultima la presenta los valores promedio para las 10 mediciones que se realizaron. En la Tabla 7.3 se presentan los resultados obtenidos en un segundo experimento, muy similar al anterior pero utilizando matrices de tamao 400 400. En estos dos n experimentos iniciales puede observarse cmo la versin distribuida obtiene un desemo o peo pobre, comparado con la versin optimizada para monoprocesador. En el primer n o caso, la diferencia en los tiempos de ejecucin es de un 216 % en contra de la versin o o distribuida. En el segundo experimento la diferencia se reduce a un 203 %. El problema que se presenta en estos casos es que el overhead introducido por la administracin de la MCD y la comunicacin por la red en s es signicativamente alto o o , comparado con las mejoras de desempeo provocadas por el uso de 4 procesadores en n paralelo. En otras palabras, el problema no es lo sucientemente pesado en trminos e de computacin como para que se justique su ejecucin en el multicomputador. Otro o o aspecto a considerar es el retardo introducido por el acceso no secuencial a la matriz. Cuando la matriz se almacena por orden de la, el acceso a cada posicin tiene un orden o constante y m nimo. En el caso de la implementacin construida para los primeros o 111

Tiempo de Ejecucin (segundos) o DSM 4p Mono Opt 20,860 23,715 20,920 23,715 20,810 23,744 20,890 23,744 20,810 23,744 20,941 23,755 20,900 23,745 22,272 23,744 22,322 23,744 21,051 23,744 21,178 23,739 Cuadro 7.4: Multiplicacin de Matrices 512 512 o

cuatro casos, el acceso se hace a travs de funciones de biblioteca que localizan la e ubicacin de un elemento en la matriz. o La situacin cambia notoriamente conforme se complica el problema aumentando o la dimensin de las matrices. La Tabla 7.4 muestra los resultados para la versin multio o procesador y monoprocesador optimizada en el caso de matrices de tamao 512 512. n En este caso, la versin multiprocesador obtiene un mejor tiempo de ejecucin que la o o versin monoprocesador, con una diferencia del 12 %. El elevado costo computacional o que tiene este problema de mayor dimensin hace que el overhead introducido por la o MCD se vea opacado ante la incorporacin de mayor poder computacional. A partir de o este punto, el sistema de MCD ofrecer una aceleracin, o speedup mayor que 1 respeca o to a la versin monoprocesador optimizada, demostrando la aplicabilidad del enfoque o distribuido. A modo de ilustracin, la Figura 7.3 resume los datos de aceleracin alcanzados o o por el sistema de MCD para los distintos experimentos llevados a cabo. El eje horizontal representa el tamao de las matrices consideradas en el problema, y el eje vertical el n tiempo de ejecucin. Se gracan los resultados del sistema de MCD multiprocesador y o del programa monoprocesador optimizado. 112

T i e m p o d e E j e c u c i o n

21 18 15 12 9 6
3

: MCD 4p

: Mono

256

400 512

Dimensin del Problema o Figura 7.3: Comparacin del Sistema de MCD y el Monoprocesador o

113

3 8 14 4

11 1 7 13

6 5 12 9

16 10 2 15

3 10 2 15

6 8 7 13

11 5 12 9

16 1 14 4

(1) Inicial

2) Despues de fase 1 (row sort)

2 3 10 15

6 7 8 13

5 9 11 12

1 4 14 16

1 9 8 16

2 7 10 15

5 4 11 13

6 3 14 12

3) Despues de fase 2 (column sort)

4) Despues de fase 3 (row sort)

1 8 9 16

2 7 10 15

4 5 11 13

3 6 12 14

1 8 9 16

2 7 10 15

3 6 11 14

4 5 12 13

5) Despues de fase 4 (column sort)

6) Despues de fase 5 (row sort) Resultado Final

Figura 7.4: Algoritmo Shearsort para N=16 Nmeros Enteros u

7.2.

Shearsort
El algoritmo Shearsort es un algoritmo de ordenamiento que ordena N nmeros u

en log2 N + 1 fases [48]. El algoritmo ubica los datos a ordenar en una matriz cuadrada y ordena las y columnas de forma alterna. Las columnas se ordenan siempre ascendentemente. Las las impares se ordenan ascendentemente y las pares descendentemente. La Figura 7.4 ilustra el funcionamiento del algoritmo para N = 16 nmeros enteros. u El algoritmo puede especicarse de modo que el ordenamiento de las las y columnas en cada fase no presente condiciones de competencia. Entonces, es posible llevar a 114

cabo estos ordenamientos en paralelo, asignando un thread a cada la o columna, y con un m nimo de sincronizacin. Tan slo al nal de cada iteracin los threads tendr o o o an que sincronizarse para poder continuar con la siguiente etapa. El algoritmo se implement tanto para un multiprocesador como para un moo noprocesador en una versin multithreaded, utilizando en ambos casos 16 nmeros, o u aleatorios pero jos, almacenados en la matriz. Los resultados de este experimento se ilustran en la Tabla 7.5. Tiempo de Ejecucin (segundos) o DSM 4p DSM lp Mono MT 0,241 0,170 0,020 0,231 0,160 0,020 0,241 0,150 0,030 0,231 0,161 0,030 0,301 0,170 0,030 0,251 0,150 0,030 0,250 0,250 0,030 0,251 0,190 0,030 0,331 0,180 0,030 0,290 0,160 0,030 0,262 0,174 0,028 Cuadro 7.5: Shearsort 16 Nmeros (4 4) u

El objetivo de este experimento no es tratar de obtener algn nivel de aceleracin u o con la versin distribuida. De hecho, los resultados muestran la notable diferencia de o desempeo a favor de la versin monoprocesador. Sin embargo, el problema es util n o desde un punto de vista de sobrecarga del protocolo de consistencia. En este caso, a diferencia del anterior, la separacin de los problemas en una matriz tan pequea no o n da lugar al tratamiento de problemas independientes. La matriz se almacena en una unica pgina y prcticamente cualquier acceso que se haga provocar una excepcin y a a a o la pgina deber viajar por la red. En todos los casos, los resultados fueron correctos, a a a pesar del pobre desempeo alcanzado. n

115

Cap tulo 8 Conclusiones

En los cap tulos previos se describe el diseo y la implementacin de DSM-PEPE. n o Su diseo, orientado a objetos, hace posible modicar el sistema e incluir nuevos comn ponentes, por ejemplo, nuevos protocolos. La implementacin del protocolo de consiso tencia secuencial que se muestra, es un buen ejemplo del procedimiento a seguir para incorporar un protocolo al sistema. Puesto que el sistema se encarga de manejar la ocurrencia de eventos que involucran acciones de consistencia y la comunicacin misma, el o protocolo tan slo debe manejar la atencin de los eventos y el trco de las pginas o o a a compartidas. En un futuro cercano se espera poder contar con dos implementaciones ms de protocolos de consistencia, uno para el modelo PRAM y otro para el modelo Lazy a Release. Los niveles de depuracin con que cuenta el sistema, as como los mecanismos o de recoleccin de estad o sticas, son una notable ayuda a la hora de evaluar protocolos de consistencia y las distintas variantes que pudiera implementarse. A pesar de que algunos de estos factores pueden evaluarse utilizando tcnicas de simulacin, la ejecucin e o o efectiva sobre un multicomputador ofrece mayor realismo, principalmente en aspectos como retardo de comunicacin y competencia por el medio, en el caso de una Ethernet. o El desempeo es un aspecto primordial en un sistema de MCD. La principal motin vacin para la construccin de computadores paralelos es obtener mayor poder compuo o 116

tacional. En el caso de DSM-PEPE se ha demostrado que an en problemas muy simples u y con moderados requerimientos de computacin, un pequeo computador paralelo, o n compuesto por cuatro computadores personales, puede obtener mejoras en el tiempo necesario para obtener la solucin. Esto demuestra la factibilidad de los sistemas de o MCD como computadores paralelos efectivos. Los resultados de la experimentacin son o alentadores. Sin embargo, an quedan muchos aspectos que pueden mejorarse en la u implementacin, con el objetivo de reducir el overhead y acercar as el desempeo a los o n niveles conocidos para sistemas de paso de mensajes. Ser interesante tambin, efectuar un conjunto de pruebas de mayor complejidad a e y utilizando mquinas paralelas con mayores capacidades. A este respecto, se planea a utilizar un multicomputador compuesto por 20 o 25 computadores personales, y con juntos de problemas estndares como Splash [70]. De este modo podr vericarse a a a cabalidad el potencial del modelo de MCD para aplicaciones computacionales de alto desempeo. n Esta etapa de experimentacin servir tambin para validar una de las hiptesis o a e o del proyecto. En general, los programas incluidos en estos conjuntos de pruebas debern a ser portados al sistema. Si esto se logra con un m nimo de esfuerzo, quedar demosa trado a plenitud que este tipo de sistemas es un sustituto potencial para los costosos multiprocesadores para los cuales fueron escritos los programas. En el cuerpo de la tesis ya se mostr lo simple que resulta la programacin en DSM-PEPE y lo familiares que o o parecen los programas resultantes. Durante la implementacin del sistema se pudo corroborar que el sistema operao tivo Windows NT cuenta con una interfaz de programacin y con caracter o sticas que lo hacen una plataforma adecuada para el desarrollo de sistemas a bajo nivel. Aspectos como la interfaz de programacin para la memoria virtual, el manejo estructurado de exo cepciones, los archivos proyectados a memoria, los threads a nivel del kernel y la enorme diversidad de mecanismos de sincronizacin, facilitaron enormemente la construccin o o de DSM-PEPE. La eleccin de un paradigma de diseo y programacin orientado a objetos, as coo n o 117

mo la estructuracin en mltiples threads de ejecucin del sistema mismo, ayudaron a o u o que la depuracin y prueba fueran tareas sencillas. El diseo multithreaded ayud a que o n o la estructura del sistema fuera ms clara y a poder aislar las funcionalidades particulares a de cada uno de los mdulos que componen el sistema. o El sistema descrito en esta tesis es apenas una versin preliminar de lo que se o espera llegue a ser a corto plazo. El diseo presentado se construy de modo que sea n o posible la incorporacin de multithreading en los programas del usuario, unido a capacio dades de migracin de threads. El diseo futuro pretende implementar rplicas en todos o n e los nodos de cada uno de los threads del usuario, permitiendo su ejecucin en una unica o ubicacin; el resto permanecern bloqueados. Ante una migracin, el thread activo se o a o bloquear y su rplica en el nodo destino reiniciar la ejecucin en el mismo estado en a e a o que se suspendi la anterior. Estas innovaciones abrir nuevas posibilidades de inveso an tigacin en aspectos como la relacin entre el modelo de consistencia y la migracin de o o o threads, as como pol ticas de migracin y balanceo de carga. o Como un objetivo a mediano plazo se pretende portar el sistema a Linux. Este sistema operativo est demostrando un enorme potencial, y al obtenerse sin costo facilita a la construccin de nuevas mquinas paralelas. Al completarse este proceso, el sistema o a DSM-PEPE estar en capacidad de ejecutarse sobre mquinas virtuales ligeramente hea a terogneas, es decir, utilizando el mismo hardware pero distintos sistemas operativos. A e pesar de este reducido nivel de heterogeneidad, la tarea no es sencilla. Debe considerarse aspectos como los formatos de almacenamiento de los datos, manejo de excepciones y la interfaz de memoria virtual del sistema operativo. Para nalizar, el sistema DSM-PEPE cuenta con un enorme potencial para la computacin de alto desempeo, a la vez que representa una plataforma de experimentacin o n o a la que se puede tener acceso ilimitado, tanto a su diseo como a su cdigo fuente, sin n o costo alguno. El panorama se abre para la investigacin aplicada en el area y para la o explotacin de su poder computacional. o

118

BIBLIOGRAFIA
[1] S. Adve and M. Hill. Weak Ordering: A New Denition. In 17th Annual International Symposium on Computer Architecture, ACM, pages 214, May 1990. [2] Thomas E. Anderson, Edward D. Lazowska, and Henry M. Levy. The Performance Implications of Thread Management Alternatives for Shared-Memory Multiprocessors. IEEE Transactions on Computers, 38(12):16311644, December 1989. [3] Gregory R. Andrews. Concurrent Programming: Principles and Practice. Addison Wesley, Menlo Park, California, 1991. [4] Yeshayahu Artsy and Raphael Finkel. Designing a Process Migration Facility: The Charlotte Experience. IEEE Computer, 22(9):4756, September 1989. [5] G.H. Barnes. The ILLIAC IV Computer. IEEE Transactions on Computers, C17(8):746757, August 1968. [6] K.E. Batcher. Design of a Massively Parallel Processor. IEEE Transactions on Computers, 13(9):836840, September 1980. [7] Gordon Bell. Ultracomputers: A Teraop Before Its Time. Communications of the ACM, 35(8):2747, August 1992. [8] J.K. Bennett, J.K. Carter, and W. Zwaenepoel. Munin: Distributed Shared Memory Based on Type-Specic Memory Coherence. In Second ACM Symposium on Principles and Practice of Parallel Programming, pages 168176, 1990. [9] Jim Beveridge and Robert Wiener. Multithreading Applications in Win32. Addison Wesley, Reading, Massachusetts, 1997. [10] A.D. Birrell and B.J. Nelson. Implementing Remote Procedure Calls. ACM Transactions on Computer Systems, 2(1):3959, February 1984. 119

[11] N. Carriero and D. Gelernter. Linda in Context. Communications of the ACM, 32(4):444458, April 1989. [12] John B. Carter, John K. Bennett, and Willy Zwaenepoel. Techniques for Reducing Consistency-Related Communication in Distributed Shared Memory Systems. ACM Transactions on Computer Systems, 13(3):205243, August 1997. [13] John B. Carter, Dilip Khandekar, and Linus Kamb. Distributed Shared Memory: Where We Are and Where We Should Be Headed. In Fifth Workshop on Hot Topics in Operating Systems, May 1995. [14] IBM Corporation. Interconnection Technologies for High-Performance Computing (RS/6000 SP). Technical report, IBM Corporation, 2000. [15] Thinking Machines Corporation. The CM-2 Technical Summary. Technical report, Thinking Machines Corporation, Cambridge, MA, 1990. [16] David E. Culler, Andrea Arpaci-Dusseau, Remzi Arpaci-Dusseau, Brent Chun, Steven Lumetta, Alan Mainwaring, Richard Martin, Chad Yoshikawa, and Frederick Wong. Parallel Computing on the Berkeley NOW. In 9th Joint Symposium on Parallel Processing, JSPP97, 1997. [17] Ralph Davis. Win32 Network Programming. Addison Wesley, Reading, Massachusetts, 1996. [18] Bozhidar Dimitrov and Vernon Rego. Arachne: A Portable Threads System Supporting Migrant Threads on Heterogeneous Network Farms. IEEE Transactions on Parallel and Distributed Systems, 9(5):459469, May 1998. [19] Fred Douglis and John Ousterhout. Transparent Process Migration: Design Alternatives and the Sprite Implementation. Software Practice and Experience, 21(8):757785, August 1991. 120

[20] Alex Dubrovski, Roy Friedman, and Assaf Schuster. Load Balancing in Distributed Shared Memory Systems. International Journal of Applied Software Technology, 3:167202, March 1998. [21] Derek L. Eager, Edward D. Lazowska, and John Zahorjan. Adaptive Load Sharing in Homogeneous Distributed Systems. IEEE Transactions on Software Engineering, SE-12(5):662675, May 1986. [22] M.J. Flynn. Very High-Speed Computing Systems. Proceedings of the IEEE, 54:19011909, 1966. [23] M.J. Flynn. Some Computer Organizations and Their Eectiveness. IEEE Transactions on Computers, C-21:948960, September 1972. [24] Roy Friedman, Maxim Goldin, Ayal Itzkovitz, and Assaf Schuster. Millipede: Easy Parallel Programming in Available Distributed Environments. Software: Practice and Experience, 27(8):929965, August 1997. [25] Michael R. Garey and David S. Johnson. Computers and Intractability, A Guide to the Theory of NP-Completeness. W. H. Freeman and Company, New York, NY, 1979. [26] Al Geist, Adam Beguelin, Jack Dongarra, Weicheng Jiang, Robert Manchek, and Vaidy Sunderam. PVM, Parallel Virtual Machine: A Users Guide and Tutorial for Networked Parallel Computing. MIT Press, Cambridge, Massachusetts, 1994. [27] K. Gharachorloo, D. Lenoski, J. Laudon, P. Gibbons, A. Gupta, and J. L. Hennessy. Memory Consistency and Event Ordering in Scalable Shared-Memory Multiprocessors. In 17th Annual International Symposium on Computer Architecture, ACM, pages 1526, 1990. [28] M.D. Godfrey and D.F. Hendry. The Computer as von Neumann Planned It. IEEE Annals of the History of Computing, 15(1):1121, 1993. 121

[29] Johnson M. Hart. Win32 System Programming. Addison Wesley, Reading, Massachusetts, 1997. [30] P.W. Hutto and M. Ahamad. Slow Memory: Weakening Consistency to Enhance Concurrency in Distributed Shared Memories. In 10th IEEE International Conference on Distributed Computing Systems, pages 302311, 1990. [31] L. Iftode, J. P. Singh, and Kai Li. Scope Consistency: A Bridge between Release Consistency and Entry Consistency. In 8th Annual ACM Symposium on Parallel Algorithms and Architectures, pages 277287, Padua, Italy, 1996. [32] Silicon Graphics Inc. Power Challenge. Technical report, Silicon Graphics Inc., 1996. [33] Ayal Itzkovitz and Assaf Schuster. MultiView and Millipage Fine-Grain Sharing in Page-Based DSMs. In Third USENIX Symposium on Operating Systems Design and Implementation, pages 215228, February 1999. [34] Ayal Itzkovitz, Assaf Schuster, and Lea Shalev. Thread Migration and its Applications in Distributed Shared Memory Systems. Journal of Systems and Software, 42(1):7187, 1998. [35] A.K. Jones, R.J. Chansler, Jr, I. Durham, P. Feiler, and K. Schwans. Software Management of CM* - A Distributed Multiprocessor. In NCC AFIPS, pages 657 663, 1977. [36] Peter Keleher. The CVM Manual. Technical report, Department of Computer Science, University of Maryland, 1996. [37] Peter Keleher. TreadMarks: Shared Memory Computing on Networks of Workstations. IEEE Computer, 29(2):1828, February 1996. [38] Peter Keleher. CVM: The Coherent Virtual Machine. Technical report, Department of Computer Science, University of Maryland, 1997. 122

[39] Peter Keleher, Alan L. Cox, and Willy Zwaenepoel. Lazy Release Consistency for Software Distributed Shared Memory. In 19th Annual International Simposium on Computer Architecture, ACM, pages 1321, May 1992. [40] Peter J. Keleher. The Relative Importance of Concurrent Writers and Weak Consistency Models. In 16th International Conference on Distributed Computing Systems, 1996. [41] Brian W. Kernighan and Rob Pike. The Unix Programming Environment. Prentice Hall, Englewood Clis, New Jersey, 1984. [42] Dilip Khandekar. Quarks: Portable Distributed Shared Memory on Unix. Technical report, Computer Systems Laboratory, Department of Computer Science, University of Utah, 1996. [43] Vipin Kumar, Ananth Grama, Anshul Gupta, and George Karypis. Introduction to Parallel Computing: Design and Analysis of Algorithms. Benjamin/Cummings, Redwood City, California, 1994. [44] H.T. Kung. Why Systolic Architectures? IEEE Computer, 15(1):3746, January 1982. [45] Leslie Lamport. Time, clocks, and the ordering of events in a distributed system. Communications of the ACM, 21(7):558565, July 1978. [46] Leslie Lamport. How to make a multiprocessor computer that correctly executes multiprocess programs. IEEE Transactions on Computers, C-28(9):690691, September 1979. [47] D.H. Lawrie. Access and Alignment of Data in an Array Processor. IEEE Transactions on Computers, C-24(1):11451155, 1975. [48] F. Thomson Leighton. Introduction to Parallel Algorithms and Architectures. Morgan Kaufmann, San Mateo, California, 1991. 123

[49] Bil Lewis and Daniel J. Berg. Multithreaded Programming with Pthreads. Sun Microsystems Press Prentice Hall, Upper Saddle River, New Jersey, 1998. [50] Kai Li. Shared Virtual Memory on Loosely Coupled Multiprocessors. PhD thesis, Yale University, October 1986. [51] Kai Li and Paul Hudak. Memory Coherence in Shared Virtual Memory Systems. ACM Transactions on Computer Systems, 7(4):321359, November 1989. [52] D.J. Lilja. Cache Coherence in Large-Scale Shared-Memory Multiprocessors: Issues and Comparisons. ACM Computing Surveys, 25(3):303338, September 1993. [53] R.J. Lipton and J.S. Sandberg. PRAM: A Scalable Shared Memory. Technical Report CS-TR-180-88, Department of Computer Science, Princeton University, September 1988. [54] Honghui Lu, Sandhya Dwarkadas, Alan L. Cox, and Willy Zwaenepoel. Quantifying the Performance Dierences between PVM and TreadMarks. Journal of Parallel and Distributed Computing, 43:6578, 1997. [55] Edward Mascarenhas and Vernon Rego. Ariadne: Architecture of a Portable Threads System Supporting Thread Migration. Software Practice and Experience, 26(3):327356, March 1996. [56] Federico Meza and Alvaro E. Campos. Modelos de Consistencia y Migracin de o Threads en un Sistema de MCD. Technical Report RT-PUC-DCC-99-01, Departamento de Ciencia de la Computacin, Universidad Catlica de Chile, June 1999. o o [57] David Mosberger. Memory Consistency Models. Technical Report TR 93/11, Department of Computer Science, University of Arizona, 1993. [58] Frank Mueller. Distributed Shared-Memory Threads: DSM-Threads. In Workshop on Run-Time Systems for Parallel Programming, pages 3140, April 1997. 124

[59] Juan E. Navarro. Un Protocolo de Consistencia Causal para Memoria Compartida Distribuida. Masters thesis, Departamento de Ciencia de la Computacin, o Universidad Catlica de Chile, Santiago, Chile, 1996. o [60] nCube Corporation. nCUBE Users Handbook. Technical report, nCube Corporation, Beaverton, Oregon, 10 1987. [61] nCube Corporation. n4 Streaming Media Systems. Technical Report 109786, nCube Corporation, Foster City, California, 11 2000. [62] Peter S. Pacheco. Parallel Programming with MPI. Morgan Kaufmann, San Francisco, California, 1997. [63] Bob Quinn and Dave Shute. Windows Sockets Network Programming. Addison Wesley, Reading, Massachusetts, 1996. [64] Mukund Raghavachari and Anne Rogers. Ace: A Language for Parallel Programming with Customizable Protocols. ACM Transactions on Computer Systems, 17(3):202248, August 1999. [65] Siddharthan Ramachandramurthi. iPSC/860 Guide. Technical report, Joint Institute for Computational Science, University of Tennessee, Knoxville, Tennessee, 1995. [66] Jerey Richter. Advanced Windows. Microsoft Press, Redmond, Washington, 1997. [67] Assaf Schuster and Lea Shalev. Using Remote Access Histories for Thread Scheduling in Distributed Shared Memory Systems. Technical Report LPCR-9701, Computer Science Department, Technion Israel Institute of Technology, January 1997. [68] Lea Shalev. Load Sharing in Distributed Shared Memory Systems. Masters thesis, Computer Science Department, Technion Israel Institute of Technology, November 1997. 125

[69] Abraham Silberschatz and Peter B. Galvin. Operating System Concepts. John Wiley & Sons, New York, fth edition, 1997. [70] J.P. Singh, W.D. Weber, and A. Gupta. SPLASH: Stanford Parallel Applications for Shared-Memory. Technical Report CSL-TR-91-469, Stanford University, 1991. [71] Evan Speight and John K. Bennett. Brazos: A Third Generation DSM System. In Proceedings of the First USENIX Windows/NT Workshop, August 1997. [72] Bjarne Stroustrup. The C++ Programming Language. Addison Wesley, Reading, Massachusetts, third edition, 1997. [73] Andrew S. Tanenbaum. Distributed Operating Systems. Prentice Hall, Englewood Clis, New Jersey, 1995. [74] Andrew S. Tanenbaum. Operating Systems: Design And Implementation. Prentice Hall, Englewood Clis, New Jersey, 2nd edition, 1996. [75] Radhika Thekkath, Amit Pal Singh, Jaswinder Pal Singh, Susan John, and John Hennessy. An Evaluation of a Commercial CC-NUMA Architecture: The CONVEX Exemplar SPP1200. In 11th International Parallel Processing Symposium, pages 817, Geneva, Switzerland, 4 1997. [76] Kritchalach Thitikamol and Peter Keleher. Per-Node Multithreading and Remote Latency. IEEE Transactions on Computers, 47(4):414426, 1998. [77] Kritchalach Thitikamol and Peter Keleher. Thread Migration and Communication Minimization in DSM Systems (Invited Paper). Proceedings of the IEEE, March 1999. [78] Albert Y.H. Zomaya. Parallel and Distributed Computing: The Scene, the Props, the Players. In Albert Y.H. Zomaya, editor, Parallel and Distributed Computing Handbook, chapter 1. McGraw Hill, New York, 1996.

126