Sistema de memoria compartida distribuida (DSM)

Se trata de una práctica que se puede desarrollar en grupos de 2 personas, con un peso de 4 sobre 10 en la nota final de la asignatura. El plazo de entrega de la práctica tanto en la convocatoria de junio como en la de septiembre coincide con el día del examen de la asignatura.

La práctica está organizada en dos partes: una básica, que permite obtener una nota de hasta 8 puntos y una avanzada, que puede proporcionar 2 puntos adicionales.

Objetivo de la práctica

La práctica consiste en desarrollar un sistema de memoria compartida distribuida (Distributed Shared Memory) que permita que el alumno llegue a conocer de forma práctica el tipo de técnicas que se usan en este tipo de sistemas, tal como se estudió en la parte teórica de la asignatura.

Con respecto al sistema que se va a desarrollar, se trata de un entorno con las siguientes características (se recomienda revisar la teoría de la asignatura para repasar todos los conceptos que se nombran a continuación):

Para evitar que se dispare la complejidad de la práctica, se han tomado una serie de decisiones de diseño que, aunque no generan una solución muy eficiente, mantienen su nivel de complejidad en unos límites razonables. Por un lado, se ha intentado simplificar la arquitectura de comunicaciones, tratando de evitar patrones de comunicación complejos, donde puedan intervenir más de 2 procesos, las comunicaciones asíncronas, como ocurre con los mensajes de invalidación, y las solicitudes que van desde el servidor al emisor, que complican el protocolo. Por otro lado, se ha optado por eliminar los problemas de false-sharing asignando a cada objeto un número entero de páginas, aunque esto cause fragmentación interna.

En cuanto al mecanismo de comunicación usado en la práctica, dadas las características de la misma, se han elegido los sockets.

Por último, en lo que se refiere a los servicios del sistema operativo requeridos, básicamente tienen que ver con la gestión de memoria. Se usan, concretamente, los servicios mmap y mprotect.

Arquitectura del software del sistema

En la arquitectura del sistema que se pretende desarrollar se diferencian dos módulos: la biblioteca de servicio y el gestor: Como se comentó previamente, la comunicación se llevará a cabo usando sockets. El servidor recibirá como argumento el número de puerto por el que recibirá las peticiones. En cuanto al cliente, la biblioteca de servicio (fichero dsm.c) debe encargarse de obtener de las variables de entorno SERVIDOR y PUERTO el nombre de la máquina donde ejecuta el gestor y el puerto por el que está escuchando, respectivamente.

Asignación de direcciones

Para evitar colisiones en el uso de los puertos, cada alumno deberá utilizar para el servidor números de puerto cuyos cuatro últimos dígitos coincidan con los cuatro últimos del número de su matrícula (así, por ejemplo, si el número de matrícula fuera 90123, se deberían usar números de puerto tales como 10123, 20123, 30123, ...). Asimismo, se recomienda el uso de la opción SO_REUSEADDR para facilitar la reutilización de los puertos.

Interfaz a las aplicaciones

A las aplicaciones de usuario se les ofrece la siguiente interfaz:
/* inicia el entorno de DSM */
void init_DSM(void);

/* macro de conveniencia que permite vincular un objeto usando su tipo */
#define vincular(nombre, tipo, nelems) _vincular(nombre, sizeof(tipo)*nelems)

/* función de vincular real que usa el tamaño en bytes */
void * _vincular(char *nombre, int tam);

/* desvincula el objeto del mapa del proceso */
int desvincular(void *dir);

/* entra en la sección crítica con respecto al acceso al objeto especificado */
void entrar_SC(void *dir, int modo);

/* sale de la sección crítica con respecto al acceso al objeto especificado */
void salir_SC(void *dir);

A continuación, se comenta el comportamiento que deben de tener estas funciones:

Nótese que, como ocurre en los sistemas que proporcionan este tipo de coherencia, las lecturas y actualizaciones que se realicen sobre un objeto compartido fuera de una sección crítica para dicho objeto tienen un comportamiento impredecible.

Protocolo

Como se comentó previamente, se ha intentado definir una arquitectura de comunicaciones que simplifique el modo de operación del sistema dando como resultado un esquema que presenta las siguientes características específicas:

Hay 5 eventos significativos en el protocolo:

Parte avanzada

La realización correcta de esta parte adicional, una vez que se ha completado correctamente la parte básica, permite obtener un incremento de hasta 2 puntos en la nota total de la práctica.

La modificación planteada en esta parte permite que se especifique a la hora de entrar en la sección crítica, usando el parámetro modo que no se utilizaba en la versión básica de la práctica, si el acceso que se va a realizar es de solo lectura (acceso COMPARTIDO) o de lectura/escritura (acceso EXCLUSIVO). Esta extensión de la funcionalidad va a aumentar el grado de paralelismo en el sistema al permitir el acceso simultáneo a una región siempre que sea de tipo compartido siguiendo el modelo de múltiples lectores pero un único escritor. Nótese que la versión básica de la práctica se corresponde con una situación en la que todos los clientes especificaran un acceso exclusivo.

A continuación, se describe cómo afecta esta nueva funcionalidad a la versión previa de la práctica, mostrando, por tanto, qué modificaciones hay que hacer sobre la misma:

Por otro lado, se plantea una segunda modificación: permitir que el sistema sea configurable en tiempo de compilación de manera que se pueda utilizar una política de acceso a la sección crítica que no sea de tipo FIFO. Concretamente, se plantea usar una política que dé prioridad a los lectores (hay que fomentar la lectura), lo que implicará:

Esta configuración se establecerá con la macro LECTORES_PRIMERO, usándose una política FIFO si no está definida. Para las pruebas, se especificará esta macro en el mandato de compilación (mediante la opción -D). El Makefile de la práctica permite especificar esta macro en la compilación con solo quitar el comentario de una línea.

Material de apoyo de la práctica

Al descomprimir el material de apoyo se crea el entorno de desarrollo de la práctica, que reside en el directorio: $HOME/DATSI/SOD/DSM.2013/.

Como parte del material de apoyo, sólo se proporciona el código para capturar la señal SEGV y obtener la dirección del acceso que produjo dicha señal. Además, se proporcionan algunos ejemplos de aplicaciones que usan este servicio.

Entrega de la práctica

Se realizará en la máquina triqui, usando el mandato:
entrega.sod dsm.2013

Este mandato recogerá los siguientes ficheros: