memoria transaccional

En informática e ingeniería , la memoria transaccional busca simplificar la programación concurrente al permitir que un grupo de instrucciones de carga y almacenamiento se ejecuten de forma atómica . Se trata de un mecanismo de control de concurrencia análogo a las transacciones de bases de datos para controlar el acceso a la memoria compartida en la computación concurrente . Los sistemas de memoria transaccional proporcionan una abstracción de alto nivel como alternativa a la sincronización de hilos de bajo nivel. Esta abstracción permite la coordinación entre lecturas y escrituras concurrentes de datos compartidos en sistemas paralelos. ^{[ 1 ]}

En la programación concurrente, la sincronización es necesaria cuando los hilos paralelos intentan acceder a un recurso compartido. Las construcciones de sincronización de hilos de bajo nivel, como los bloqueos, son pesimistas e impiden que los hilos que se encuentran fuera de una sección crítica ejecuten el código protegido por dicha sección. El proceso de aplicar y liberar bloqueos suele funcionar como una sobrecarga adicional en cargas de trabajo con poco conflicto entre hilos. La memoria transaccional proporciona un control de concurrencia optimista al permitir que los hilos se ejecuten en paralelo con una interferencia mínima. ^{[ 2 ]} El objetivo de los sistemas de memoria transaccional es admitir de forma transparente las regiones de código marcadas como transacciones al imponer atomicidad , consistencia y aislamiento .

Una transacción es un conjunto de operaciones que pueden ejecutarse y confirmar cambios siempre que no exista un conflicto. Cuando se detecta un conflicto, la transacción vuelve a su estado inicial (antes de cualquier cambio) y se repite hasta que se eliminan todos los conflictos. Antes de una confirmación exitosa, el resultado de cualquier operación es puramente especulativo dentro de una transacción. A diferencia de la sincronización basada en bloqueos, donde las operaciones se serializan para evitar la corrupción de datos, las transacciones permiten un paralelismo adicional siempre que pocas operaciones intenten modificar un recurso compartido. Dado que el programador no es responsable de identificar explícitamente los bloqueos ni el orden en que se adquieren, los programas que utilizan memoria transaccional no pueden producir un interbloqueo . ^{[ 2 ]}

Con estas estructuras implementadas, la memoria transaccional proporciona una abstracción de programación de alto nivel al permitir a los programadores encerrar sus métodos dentro de bloques transaccionales. Las implementaciones correctas garantizan que los datos no se puedan compartir entre hilos sin pasar por una transacción y producen un resultado serializable . Por ejemplo, el código se puede escribir de la siguiente manera:

clase Cuenta : def __init __ ( self , id : int , balance : float , name : str ) - > None : self.id : int = id self.balance : float = balance self.name : str = name​​​​def transfer_money ( from_account : Account , to_account : Account , amount : float ) -> None : """  Transfiere dinero de una cuenta a otra.  """ with transaction (): from_account . balance -= amount to_account . balance += amount

En el código, el bloque definido por "transacción" tiene garantizada la atomicidad, la consistencia y el aislamiento por la implementación subyacente de la memoria transaccional, y es transparente para el programador. Las variables dentro de la transacción están protegidas de conflictos externos, lo que garantiza que se transfiera la cantidad correcta o que no se realice ninguna acción. Cabe señalar que aún pueden producirse errores relacionados con la concurrencia en programas que utilizan un gran número de transacciones, especialmente en implementaciones de software donde la biblioteca proporcionada por el lenguaje no puede garantizar un uso correcto. Los errores introducidos a través de transacciones suelen ser difíciles de depurar, ya que no se pueden colocar puntos de interrupción dentro de una transacción. ^{[ 2 ]}

La memoria transaccional tiene la limitación de requerir una abstracción de memoria compartida. Si bien los programas con memoria transaccional no pueden producir un interbloqueo, aún pueden sufrir un bloqueo permanente o escasez de recursos . Por ejemplo, las transacciones más largas pueden revertirse repetidamente en respuesta a múltiples transacciones más pequeñas, lo que supone un desperdicio de tiempo y energía. ^{[ 2 ]}

La abstracción de atomicidad en la memoria transaccional requiere un mecanismo de hardware para detectar conflictos y deshacer cualquier cambio realizado en los datos compartidos. ^{[ 3 ]} Los sistemas de memoria transaccional de hardware pueden comprender modificaciones en los procesadores, la caché y el protocolo de bus para admitir transacciones. ^{[ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ]} Los valores especulativos en una transacción deben almacenarse en búfer y permanecer ocultos para otros hilos hasta el momento de la confirmación. Se utilizan grandes búferes para almacenar valores especulativos evitando la propagación de escritura a través del protocolo de coherencia de caché subyacente . Tradicionalmente, los búferes se han implementado utilizando diferentes estructuras dentro de la jerarquía de memoria, como colas de almacenamiento o cachés. Los búferes más alejados del procesador, como la caché L2, pueden contener más valores especulativos (hasta unos pocos megabytes). El tamaño óptimo de un búfer aún está en debate debido al uso limitado de transacciones en programas comerciales. ^{[ 3 ]} En una implementación de caché, las líneas de caché generalmente se aumentan con bits de lectura y escritura. Cuando el controlador de hardware recibe una solicitud, utiliza estos bits para detectar un conflicto. Si se detecta un conflicto de serializabilidad en una transacción paralela, se descartan los valores especulativos. Al utilizar cachés, el sistema puede introducir el riesgo de falsos conflictos debido al uso de la granularidad de la línea de caché. ^{[ 3 ]} La carga-enlace/almacenamiento condicional (LL/SC) ofrecida por muchos procesadores RISC puede considerarse como el soporte de memoria transaccional más básico; sin embargo, LL/SC suele operar con datos del tamaño de una palabra de máquina nativa, por lo que solo se admiten transacciones de una sola palabra. ^{[ 4 ]} Aunque la memoria transaccional de hardware proporciona el máximo rendimiento en comparación con las alternativas de software, su uso ha sido limitado hasta el momento.

La memoria transaccional por software proporciona semántica de memoria transaccional en una biblioteca de tiempo de ejecución de software o en el lenguaje de programación ^{[ 9 ]} y requiere un soporte de hardware mínimo (normalmente una operación atómica de comparación e intercambio , o equivalente). Como desventaja, las implementaciones por software suelen presentar una penalización en el rendimiento en comparación con las soluciones de hardware. La aceleración por hardware puede reducir algunos de los gastos generales asociados con la memoria transaccional por software.

Debido a la naturaleza más limitada de la memoria transaccional de hardware (en las implementaciones actuales), el software que la utiliza puede requerir una optimización bastante extensa para aprovecharla al máximo. Por ejemplo, el asignador de memoria dinámica puede tener una influencia significativa en el rendimiento y, del mismo modo, el relleno de la estructura puede afectarlo (debido a problemas de alineación de caché y compartición falsa); en el contexto de una máquina virtual, varios subprocesos en segundo plano pueden provocar abortos de transacciones inesperados. ^{[ 10 ]}

Una de las primeras implementaciones de memoria transaccional fue el búfer de almacenamiento controlado utilizado en los procesadores Crusoe y Efficeon de Transmeta . Sin embargo, este solo se usaba para facilitar optimizaciones especulativas para la traducción binaria, en lugar de cualquier forma de multihilo especulativo o exponerlo directamente a los programadores. Azul Systems también implementó memoria transaccional por hardware para acelerar sus dispositivos Java , pero esto también se mantuvo oculto para los usuarios externos. ^{[ 11 ]}

Sun Microsystems implementó memoria transaccional por hardware y una forma limitada de multihilo especulativo en su procesador Rock de gama alta . Esta implementación demostró que podía utilizarse para la eliminación de bloqueos y sistemas de memoria transaccional híbridos más complejos, donde las transacciones se gestionan con una combinación de hardware y software. El procesador Rock se canceló en 2009, justo antes de su adquisición por Oracle ; si bien los productos finales nunca se lanzaron al mercado, varios sistemas prototipo estuvieron disponibles para los investigadores. ^{[ 11 ]}

En 2009, AMD propuso la Advanced Synchronization Facility (ASF), un conjunto de extensiones x86 que proporcionan una forma muy limitada de soporte para memoria transaccional por hardware. El objetivo era proporcionar primitivas de hardware que pudieran utilizarse para la sincronización de nivel superior, como la memoria transaccional por software o los algoritmos sin bloqueo. Sin embargo, AMD no ha anunciado si ASF se utilizará en sus productos y, de ser así, en qué plazo. ^{[ 11 ]}

Más recientemente, en 2011, IBM anunció que Blue Gene/Q contaba con soporte de hardware tanto para memoria transaccional como para multihilo especulativo. La memoria transaccional podía configurarse en dos modos: el primero, desordenado y de versión única, donde una escritura de una transacción provoca un conflicto con cualquier transacción que lea la misma dirección de memoria; y el segundo, para multihilo especulativo, que proporciona una memoria transaccional ordenada y multiversión. Los hilos especulativos pueden tener diferentes versiones de la misma dirección de memoria, y la implementación de hardware realiza un seguimiento de la antigüedad de cada hilo. Los hilos más jóvenes pueden acceder a los datos de los hilos más antiguos (pero no al revés), y las escrituras en la misma dirección se basan en el orden de los hilos. En algunos casos, las dependencias entre hilos pueden provocar la interrupción de las versiones más jóvenes. ^{[ 11 ]}

Las extensiones de sincronización transaccional (TSX) de Intel están disponibles en algunos procesadores Skylake . Anteriormente también se implementaron en los procesadores Haswell y Broadwell , pero en ambos casos las implementaciones resultaron defectuosas y se deshabilitó la compatibilidad con TSX. La especificación TSX describe la API de memoria transaccional para su uso por parte de los desarrolladores de software, pero omite detalles sobre la implementación técnica. ^{[ 11 ]} La arquitectura ARM cuenta con una extensión similar. ^{[ 12 ]}

A partir de GCC 4.7, está disponible una biblioteca experimental para memoria transaccional que utiliza una implementación híbrida. La variante PyPy de Python también introduce la memoria transaccional en el lenguaje.

C++ cuenta con una "Especificación Técnica de Memoria Transaccional" (TM TS), que es una bifurcación experimental del lenguaje que implementa la memoria transaccional como una característica central del mismo. ^{[ 13 ]} Introduce "bloques atómicos" (o se ejecutan todas las instrucciones o no se ejecuta ninguna) y "bloques sincronizados" (se ejecutan en un único orden total con todos los bloques sincronizados). Introduce las siguientes palabras clave:

• atomic_cancel: Declara un bloque atómico que se revierte en caso de excepción.
• atomic_commit: Declara un bloque atómico que se confirma en caso de excepción.
• atomic_noexcept: Declara un bloque atómico que se interrumpe en caso de excepción.
• synchronizedDeclara un bloque sincronizado que se ejecuta en un único orden total junto con todos los demás bloques sincronizados. Compárese con los bloques de Javasynchronized , que tienen un "objeto monitor" o "bloqueo intrínseco", y donde solo un hilo puede ejecutar una sección específica del código.
• transaction_safe: Declara que una función es segura para transacciones.
• transaction_safe_dynamic: Declara que una función virtual es segura para transacciones.

El progreso en el desarrollo de la memoria transaccional TS se ha estancado desde 2026, mientras que el último borrador de trabajo conocido fue una revisión realizada en 2022. ^{[ 14 ]}

• semántica de la memoria
• exclusión mutua automática

• Harris, Tim; Larus, James R.; Rajwar, Ravi (diciembre de 2010), Memoria transaccional, 2.ª edición , Synthesis Lectures on Computer Architecture, vol. 5, Morgan & Claypool, pp.  1–263 , doi : 10.2200/S00272ED1V01Y201006CAC011
• McKenney, Paul E.; Michael, Maged M.; Triplett, Josh; Walpole, Jonathan (julio de 2010). "Por qué la hierba puede no ser más verde al otro lado: una comparación entre el bloqueo y la memoria transaccional". SIGOPS Oper. Syst. Rev. 44 ( 3). Nueva York, NY, EE. UU.: ACM : 93–101 . doi : 10.1145/1842733.1842749 . ISSN  0163-5980 . S2CID  1917393 .

• Dave Dice, Yossi Lev, Mark Moir, Dan Nussbaum y Marek Olszewski. (2009) «Primeras experiencias con una implementación comercial de memoria transaccional de hardware». Informe técnico de Sun Microsystems (60 págs.) SMLI TR-2009-180. Una versión abreviada se presentó en ASPLOS'09 (doi : 10.1145/1508244.1508263).
• Amy Wang, Matthew Gaudet, Peng Wu, José Nelson Amaral, Martin Ohmacht, Christopher Barton, Raul Silvera y Maged Michael. « Evaluación del soporte de hardware de Blue Gene/Q para memorias transaccionales. Archivado el 27 de junio de 2013 en Wayback Machine ». En Actas de la 21.ª conferencia internacional sobre arquitecturas paralelas y técnicas de compilación, págs. 127-136. ACM, 2012.
• Jacobi, C., Slegel, T., & Greiner, D. (2012, diciembre). " Arquitectura e implementación de memoria transaccional para IBM System z Archivado el 4 de marzo de 2016 en Wayback Machine ". En Microarchitecture (MICRO), 45.º Simposio Internacional Anual IEEE/ACM de 2012 (págs. 25-36). IEEE.
• Harold W. Cain, Maged M. Michael, Brad Frey, Cathy May, Derek Williams y Hung Le. «Soporte arquitectónico robusto para la memoria transaccional en la arquitectura Power». En Actas del 40.º Simposio Internacional Anual sobre Arquitectura de Computadoras (ISCA '13), págs. 225-236, ACM, 2013. doi : 10.1145/2485922.2485942

• Michael Neuling (IBM), " ¿Qué pasa con la memoria transaccional de hardware? ", charla introductoria en linux.conf.au 2014.
• Memoria transaccional en línea : bibliografía categorizada sobre memoria transaccional