15 Jan 2014
Implementando Reducciones en TinySTM (II) - Estructura
Cambios en el Makefile
En el Makefile principal de TinySTM se han añadido dos definiciones nuevas:
DEFINES += -DRDX_ENABLED
DEFINES += -DRDX_MULTIOP_ENABLED
DEFINES += -DDEBUG_RDX
La primera habilita o deshabilita las reducciones directamente. Si está habilitada necesitará también el orden total (ORDERING_ENABLED), las optimizaciones del ORDERING (ORDERED_OPTIMISATIONS) y las lecturas visibles mediante los bloomfilters de lectura que hemos implementado anteriormente (READ_BLOOMFILTER_ENABLED).
La segunda habilita o deshabilita el soporte a múltiples operaciones de reducción, ya que en la primera iteración sólo se soportará la suma. La razón de esto es seguir un enfoque y diseño incremental, ya que diseñar y programar reducciones con operaciones no específicas desde el principio, probablemente complicaría toda la casuística. La idea es desarrollar un soporte básico de reducciones (sólo con enteros y la operación de suma), e irlo aumentando progresivamente en sucesivas iteraciones: enteros y doubles en la siguiente iteración y soporte a más operaciones de reducción en última instancia.
La tercera habilita o deshabilita los mensajes de DEBUG específicos para las reducciones, que nos servirán para comprobar que todo funciona como debe.
Creación de mod_reduction
Para modularizar las reducciones en la medida de lo posible, vamos a crear un nuevo módulo para aglutinar en él todas las estructuras, funciones y variables necesarias. Esto no quita para que haya que modificar el Conflict Manager principal para controlar qué se hace en caso de un conflicto que involucre a reducciones, así como los atributos de las transacciones para incluir un RDX_SET que nos permita almacenar los valores nuevos hasta el commit. Conviene recordar que TinySTM es Eager-Lazy, lo que significa que la detección de conflictos es en el momento en que se producen (aunque con la salvedad de que al tener originalmente lecturas invisibles, los conflictos con RAW se detectaban en el commit cuando la transacción comprobaba su intervalo de validez mediante el algoritmo LSA); pero las variables afectadas se escriben en el commit, almacenandose mientrastanto en unos conjuntos específicos que forman parte de los atributos de la transacción: Si la transacción tiene que abortar, basta con descartar estos conjuntos, ya que las variables reales no se han modificado.