Estoy confundido porque al leer la página de la wiki parece que solo tiene un sistema CheckValidate y commit para cargas y tiendas. ¿El propósito es resolver problemas de sincronización? ¿Es una cosa de programación de software sobre la base del hardware actual, o es una implementación de hardware a través de un ISA? ¿Cuál es la diferencia entre cada implementación (HW/SW)?¿Qué es la memoria transaccional?
Gracias.
En el nivel de implementación, la memoria transaccional es parte de la capa de caché. Permite al software "probar" algunas operaciones en la memoria, y luego "comprometerlas" más tarde solo si ningún otro multiprocesador en el sistema modificó la memoria que fue leída o escrita. En entornos SMP muy paralelos donde la mayoría de los accesos no colisionan, esto puede ser más rápido que tener todos los subprocesos bloqueando las mismas primitivas de sincronización (altamente disputadas).
Hace la tarea del programador de aplicaciones más difícil, sin embargo, porque el software tiene que ser capaz de recuperar ("retrotraer") la transacción si falla la confirmación.
Desde el gcc Wiki:
In general, implementations come in two forms: a Software Transactional Memory (STM) system uses locks or other standard atomic instructions to do its job. A Hardware Transactional Memory (HTM) system uses multi-word synchronization operations of the CPU to implement the requirements of the transaction directly (e.g., see the Rock processor). Because most HTM systems are likely to be best effort facilities (i.e., not all transactions can be executed using HTM), practical TM implementations that incorporate HTM also have a STM component and are thus termed Hybrid Transactional Memory systems.
memoria transaccional es el concepto de la utilización de transacciones en lugar de cerraduras para sincronizar los procesos que se ejecutan en paralelo y compartir la memoria.
En un nivel muy simplificado, para sincronizar con bloqueos identifica secciones de código (llamadas secciones críticas) que no deben ejecutarse simultáneamente por diferentes subprocesos y adquirir y liberar bloqueos alrededor de las secciones críticas. Dado que cada bloqueo solo puede mantenerse en un hilo a la vez, esto garantiza que una vez que un hilo ingresa a una sección crítica, todas las operaciones de la sección se completarán antes de que otro hilo ingrese en una sección crítica protegida por el mismo bloqueo.
La memoria transaccional le permite designar secciones de código como transacciones. El sistema de memoria transaccional (que puede implementarse en hardware, software o ambos) intenta brindarle la garantía de que cualquier ejecución de un programa en el que múltiples hilos ejecutan transacciones en paralelo será equivalente a una ejecución diferente del programa en la cual todas las transacciones se ejecutaron una tras otra, nunca al mismo tiempo.
El sistema de memoria transaccional hace esto permitiendo que las transacciones se ejecuten en paralelo y controlando su acceso a variables de transacción. Si el sistema detecta un conflicto entre el acceso de dos transacciones a la misma variable, hará que uno de ellos se anule y se "retrotraiga" al comienzo de la transacción que se estaba ejecutando; luego reiniciará automáticamente la transacción, y el estado general del sistema será como si nunca hubiera comenzado la ejecución anterior.
Uno de los objetivos de la memoria transaccional es la facilidad de programación y seguridad; un sistema TM correctamente implementado que sea capaz de hacer cumplir que las transacciones se usan correctamente da garantías que no hay errores de paralelismo (interbloqueos, condiciones de carrera, etc.) en el programa, y solo requiere que el programador designe las transacciones (y algunas veces variables de transacción, si el sistema no solo considera que todas las memorias son implícitamente variables de transacción), sin necesidad de identificar exactamente qué bloqueos se necesitan, adquieralos en el orden correcto para evitar interbloqueos, etc., etc."Las transacciones se usan correctamente" implica que no hay datos compartidos entre hilos sin pasar por variables de transacción, no hay acceso a datos transaccionales excepto en transacciones, y no hay operaciones "no reversibles" dentro de transacciones); Los sistemas de memoria transaccional de software basados en bibliotecas para lenguajes imperativos como C, Java, etc. generalmente no pueden hacer cumplir todo esto, lo que puede volver a introducir la posibilidad de algunos de los errores de paralelismo.
Otro objetivo de la memoria transaccional es aumentar el paralelismo; Si tiene un montón de operaciones paralelas que acceden a alguna estructura de datos, todas las cuales pueden escribir, pero pocas de ellas realmente funcionan, entonces la sincronización basada en el bloqueo generalmente requiere que todas las operaciones se ejecuten en serie para evitar la posibilidad de corrupción de datos. La memoria transaccional permitiría que casi todas las operaciones se ejecuten en paralelo, perdiendo solo el paralelismo cuando algún proceso realmente escriba en la estructura de datos.
En la práctica (a partir de cuando investigué mi proyecto de honores hace unos años), la memoria transaccional basada en hardware realmente no ha despegado, y los sistemas de memoria transaccionales de software actuales tienen gastos indirectos significativos. Por lo tanto, la memoria transaccional del software está más orientada a "un rendimiento razonable que se adapte moderadamente bien con los procesadores disponibles y sea bastante fácil de codificar", en lugar de ofrecerle un rendimiento máximo absoluto.
Sin embargo, existe una gran variabilidad entre los diferentes sistemas de memoria transaccional; Estoy hablando a un nivel bastante abstracto y simplificado aquí.
Creo que está vendiendo en exceso aquí. Los algoritmos TM son sutiles, al igual que las técnicas de sincronización tradicionales. Y los errores resultantes pueden ser igualmente inescrutables. En cualquier caso, generalmente necesita una variante tradicional de trabajo como una alternativa para las colisiones de transacciones, por lo que no hay almuerzo gratis. STM ha fracasado en gran medida por estos motivos. HTM en Haswell parece prometedor, pero más desde una perspectiva de rendimiento que una facilidad de programación. –
** Si ** el sistema STM pretende proporcionar fuertes garantías de seguridad ** y ** existe un mecanismo para hacer cumplir que (a) los datos transaccionalmente compartidos solo se acceden desde dentro de las transacciones (b) las transacciones nunca tienen efectos secundarios, luego Los programas STM están garantizados para estar libres de condiciones de carrera y puntos muertos. Habiendo trabajado en implementaciones de STM, esto es cierto. El uso deficiente de un sistema STM de este tipo puede darte un rendimiento abismal debido a la disputa, pero no puede darte problemas ni condiciones de carrera que solo causen problemas en condiciones de tiempo extremadamente precisas. – Ben
Esas condiciones previas no son ciertas para las implementaciones STM basadas en bibliotecas para C, porque sin la integración del lenguaje no hay forma de aplicar (a) y (b), y con C es bastante difícil hacer cumplir cualquier cosa de todos modos. No sé mucho sobre HTM, pero tengo entendido que necesita una vez más la integración del lenguaje para ofrecer garantías de seguridad, por lo que utilizar HTM de C o ensamblador no incluye el almuerzo gratis, no. – Ben