En informática , la memoria transaccional de software ( STM ) es 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 . Es una alternativa a la sincronización basada en bloqueos.. STM es una estrategia implementada en software, más que como un componente de hardware. Una transacción en este contexto ocurre cuando un fragmento de código ejecuta una serie de lecturas y escrituras en la memoria compartida. Estas lecturas y escrituras ocurren lógicamente en un solo instante en el tiempo; los estados intermedios no son visibles para otras transacciones (exitosas). La idea de proporcionar soporte de hardware para transacciones se originó en un artículo de 1986 de Tom Knight . [1] La idea fue popularizada por Maurice Herlihy y J. Eliot B. Moss . [2] En 1995, Nir Shavit y Dan Touitou ampliaron esta idea a la memoria transaccional de solo software (STM). [3] Desde 2005, STM ha sido objeto de una intensa investigación.[4] y el soporte para implementaciones prácticas está creciendo.
Actuación
A diferencia de las técnicas de bloqueo utilizadas en la mayoría de las aplicaciones modernas de subprocesos múltiples, STM suele ser muy optimista : un subproceso completa modificaciones en la memoria compartida sin tener en cuenta lo que podrían estar haciendo otros subprocesos, registrando cada lectura y escritura que realiza en un registro. En lugar de poner la responsabilidad en el escritor para asegurarse de que no afecte negativamente a otras operaciones en curso, se le asigna al lector, quien después de completar una transacción completa verifica que otros subprocesos no hayan realizado simultáneamente cambios en la memoria a la que accedió en el pasado. Esta operación final, en la que los cambios de una transacción se validan y, si la validación es exitosa, se hace permanente, se llama confirmación . Una transacción también puede anularse en cualquier momento, lo que hace que todos sus cambios anteriores se deshagan o deshagan. Si una transacción no se puede confirmar debido a cambios conflictivos, normalmente se cancela y se vuelve a ejecutar desde el principio hasta que se realiza correctamente.
El beneficio de este enfoque optimista es una mayor concurrencia: ningún subproceso necesita esperar el acceso a un recurso, y diferentes subprocesos pueden modificar de manera segura y simultánea partes disjuntas de una estructura de datos que normalmente estarían protegidas bajo el mismo bloqueo.
Sin embargo, en la práctica, los sistemas STM también sufren un impacto en el rendimiento en comparación con los sistemas basados en bloqueos de grano fino en una pequeña cantidad de procesadores (1 a 4 según la aplicación). Esto se debe principalmente a la sobrecarga asociada con el mantenimiento del registro y al tiempo dedicado a realizar transacciones. Incluso en este caso, el rendimiento no suele ser peor que el doble de lento. [5] Los defensores de STM creen que esta penalización está justificada por los beneficios conceptuales de STM [ cita requerida ] .
En teoría, el peor caso de complejidad espacial y temporal de n transacciones concurrentes es O ( n ). Las necesidades reales dependen de los detalles de implementación (se puede hacer que las transacciones fallen lo suficientemente temprano para evitar gastos generales), pero también habrá casos, aunque raros, en los que los algoritmos basados en bloqueos tengan una mayor complejidad de tiempo que la memoria transaccional de software.
Ventajas y desventajas conceptuales
Además de sus beneficios de rendimiento [ cita requerida ] , STM simplifica enormemente la comprensión conceptual de los programas multiproceso y ayuda a que los programas sean más fáciles de mantener al trabajar en armonía con abstracciones de alto nivel existentes, como objetos y módulos. La programación basada en bloqueos tiene una serie de problemas bien conocidos que surgen con frecuencia en la práctica:
- El bloqueo requiere pensar en operaciones superpuestas y operaciones parciales en secciones de código distantes y aparentemente no relacionadas, una tarea que es muy difícil y propensa a errores.
- El bloqueo requiere que los programadores adopten una política de bloqueo para evitar interbloqueo , bloqueo activo y otras fallas para progresar. Estas políticas a menudo se aplican de manera informal y son falibles, y cuando surgen estos problemas, son insidiosamente difíciles de reproducir y depurar.
- El bloqueo puede conducir a la inversión de prioridad , un fenómeno en el que un subproceso de alta prioridad se ve obligado a esperar a que un subproceso de baja prioridad tenga acceso exclusivo a un recurso que necesita.
Por el contrario, el concepto de transacción de memoria es mucho más simple, porque cada transacción puede verse aisladamente como un cálculo de un solo subproceso. El interbloqueo y el bloqueo activo se evitan por completo o se manejan mediante un administrador de transacciones externo; el programador apenas necesita preocuparse por ello. La inversión de prioridad aún puede ser un problema, pero las transacciones de alta prioridad pueden abortar transacciones conflictivas de menor prioridad que aún no se han comprometido.
Por otro lado, la necesidad de abortar transacciones fallidas también impone limitaciones al comportamiento de las transacciones: no pueden realizar ninguna operación que no se pueda deshacer, incluida la mayoría de las E / S. Estas limitaciones suelen superarse en la práctica mediante la creación de búferes que ponen en cola las operaciones irreversibles y las realizan en un momento posterior fuera de cualquier transacción. En Haskell , el sistema de tipos aplica esta limitación en tiempo de compilación.
Operaciones componibles
En 2005, Tim Harris , Simon Marlow , Simon Peyton Jones y Maurice Herlihy describieron un sistema STM construido sobre Concurrent Haskell que permite componer operaciones atómicas arbitrarias en operaciones atómicas más grandes, un concepto útil imposible con la programación basada en bloqueos. Para citar a los autores:
Quizás la objeción más fundamental es que los [...] programas basados en bloqueos no componen : los fragmentos correctos pueden fallar cuando se combinan. Por ejemplo, considere una tabla hash con operaciones de inserción y eliminación seguras para subprocesos. Ahora suponga que queremos eliminar un elemento A de la tabla t1 e insertarlo en la tabla t2; pero el estado intermedio (en el que ninguna tabla contiene el elemento) no debe ser visible para otros hilos. A menos que el implementador de la tabla hash anticipe esta necesidad, simplemente no hay forma de satisfacer este requisito. [...] En resumen, las operaciones que son individualmente correctas (insertar, eliminar) no se pueden componer en operaciones correctas más grandes.
—Tim Harris et al., "Transacciones de memoria componibles", Sección 2: Antecedentes, pág.2 [6]
Con STM, este problema es simple de resolver: simplemente envolver dos operaciones en una transacción hace que la operación combinada sea atómica. El único problema es que la persona que llama, que desconoce los detalles de implementación de los métodos del componente, no tiene claro cuándo debe intentar volver a ejecutar la transacción si falla. En respuesta, los autores propusieron un comando de reintento que utiliza el registro de transacciones generado por la transacción fallida para determinar qué celdas de memoria leyó, y reintenta automáticamente la transacción cuando se modifica una de estas celdas, basándose en la lógica de que la transacción no se comportará. de forma diferente hasta que se cambie al menos uno de esos valores.
Los autores también propusieron un mecanismo para la composición de alternativas , la función orElse . Ejecuta una transacción y, si esa transacción se reintenta , ejecuta una segunda. Si ambos vuelven a intentarlo, vuelve a intentarlo con ambos tan pronto como se realiza un cambio relevante. [ aclaración necesaria ] Esta función, comparable a funciones como la llamada select () de la red POSIX , permite a la persona que llama esperar en cualquiera de varios eventos simultáneamente. También simplifica las interfaces de programación, por ejemplo, al proporcionar un mecanismo simple para convertir entre operaciones de bloqueo y no bloqueo.
Este esquema se ha implementado en el compilador de Glasgow Haskell .
Apoyo lingüístico propuesto
La simplicidad conceptual de los STM les permite ser expuestos al programador utilizando una sintaxis de lenguaje relativamente simple. El "Soporte de lenguaje para transacciones ligeras" de Tim Harris y Keir Fraser propuso la idea de utilizar la región crítica condicional clásica (CCR) para representar transacciones. En su forma más simple, esto es solo un "bloque atómico", un bloque de código que lógicamente ocurre en un solo instante:
// Insertar un nodo en una lista doblemente enlazada atómicamente atómica { newNode-> prev = nodo; newNode-> siguiente = nodo-> siguiente; nodo-> siguiente-> prev = newNode; nodo-> siguiente = newNode; }
Cuando se alcanza el final del bloque, la transacción se confirma si es posible, o bien se aborta y se reintenta. (Este es simplemente un ejemplo conceptual, no un código correcto. Por ejemplo, se comporta incorrectamente si el nodo se elimina de la lista durante la transacción).
Los CCR también permiten una condición de protección , que permite que una transacción espere hasta que tenga trabajo por hacer:
atomic (queueSize> 0) { eliminar el elemento de la cola y usarlo }
Si no se cumple la condición, el administrador de transacciones esperará hasta que otra transacción haya realizado una confirmación que afecte la condición antes de volver a intentarlo. Este acoplamiento flexible entre productores y consumidores mejora la modularidad en comparación con la señalización explícita entre hilos. "Composable Memory Transactions" [6] llevó esto un paso más allá con su comando de reintento (discutido anteriormente), que puede, en cualquier momento, abortar la transacción y esperar hasta que algún valor leído previamente por la transacción sea modificado antes de reintentar. Por ejemplo:
atómico { if (queueSize> 0) { eliminar el elemento de la cola y usarlo } demás { rever } }
Esta capacidad de reintentar dinámicamente al final de la transacción simplifica el modelo de programación y abre nuevas posibilidades.
Un problema es cómo se comportan las excepciones cuando se propagan fuera de las transacciones. En "Transacciones de memoria componible", [6] los autores decidieron que esto debería abortar la transacción, ya que las excepciones normalmente indican errores inesperados en Haskell concurrente, pero que la excepción podría retener información asignada y leída durante la transacción con fines de diagnóstico. Destacan que otras decisiones de diseño pueden ser razonables en otros entornos.
Bloqueo transaccional
STM se puede implementar como un algoritmo sin bloqueo o puede usar bloqueo. Hay dos tipos de esquemas de bloqueo: En el bloqueo de tiempo de encuentro (Ennals, Saha y Harris), las escrituras de memoria se realizan adquiriendo primero temporalmente un bloqueo para una ubicación determinada, escribiendo el valor directamente y registrándolo en el registro de deshacer. El bloqueo de tiempo de compromiso bloquea las ubicaciones de la memoria solo durante la fase de compromiso.
Un esquema de tiempo de compromiso llamado "Transactional Locking II" implementado por Dice, Shalev y Shavit utiliza un reloj de versión global. Cada transacción comienza leyendo el valor actual del reloj y almacenándolo como la versión de lectura. Luego, en cada lectura o escritura, la versión de la ubicación de memoria particular se compara con la versión de lectura; y, si es mayor, se anula la transacción. Esto garantiza que el código se ejecute en una instantánea coherente de la memoria. Durante la confirmación, se bloquean todas las ubicaciones de escritura y se vuelven a comprobar los números de versión de todas las ubicaciones de lectura y escritura. Por último, se incrementa el reloj de la versión global, los nuevos valores de escritura del registro se vuelven a escribir en la memoria y se sellan con la nueva versión del reloj.
Un método cada vez más utilizado para gestionar los conflictos transaccionales en la memoria transaccional , y especialmente en STM, es el pedido de compromiso (también llamado pedido de compromiso ; CO). Se utiliza para lograr la serialización [2] de manera optimista (es decir, sin bloquear en caso de conflicto y solo bloquear para confirmación) mediante "orden de confirmación" (por ejemplo, Ramadan et al. 2009, [7] y Zhang et al. 2006 [8]). ). La serializabilidad es la base para la corrección de (transacciones concurrentes y) memoria transaccional. Ya se han publicado decenas de artículos de STM sobre "orden de compromiso", y la técnica está gravada por varias patentes.
Con CO, la propiedad de serializabilidad deseada se logra comprometiendo transacciones solo en orden cronológico que sea compatible con el orden de precedencia (según lo determinado por los órdenes cronológicos de operaciones en conflicto) de las respectivas transacciones. Para hacer cumplir el CO, es necesario utilizar alguna implementación del algoritmo de CO local genérico . El resumen de patente citado anteriormente describe una implementación general del algoritmo con un orden de compromiso predeterminado (esto cae en la categoría de "algoritmo genérico de CO con restricciones en tiempo real").
Problemas de implementación
Un problema con la implementación de memoria transaccional de software con lectura optimista es que es posible que una transacción incompleta lea un estado inconsistente (es decir, lea una mezcla de valores antiguos y nuevos escritos por otra transacción). Tal transacción está condenada a abortar si alguna vez intenta comprometerse, por lo que esto no viola la condición de consistencia impuesta por el sistema transaccional, pero es posible que este estado inconsistente "temporal" haga que una transacción desencadene una condición excepcional fatal como como un error de segmentación o incluso entrar en un bucle sin fin, como en el siguiente ejemplo artificial de la Figura 4 de "Compatibilidad con idiomas para transacciones ligeras":
|
Siempre que x = y inicialmente, ninguna de las transacciones anteriores altera este invariante, pero es posible que la transacción A lea x después de que la transacción B la actualice, pero lea y antes de que la transacción B la actualice, provocando que entre en un bucle infinito. La estrategia habitual para lidiar con esto es interceptar cualquier excepción fatal y abortar cualquier transacción que no sea válida.
Una forma de abordar estos problemas es detectar transacciones que ejecutan operaciones ilegales o no terminan y abortarlas limpiamente; otro enfoque es el esquema de bloqueo transaccional .
Implementaciones
Se han lanzado varias implementaciones de STM (en diferentes escalas de calidad y estabilidad), muchas de ellas bajo licencias liberales. Éstas incluyen:
C / C ++
- TinySTM , un STM basado en palabras.
- The Lightweight Transaction Library (LibLTX), una implementación en C de Robert Ennals centrada en la eficiencia y basada en sus artículos "La memoria transaccional de software no debe estar libre de obstrucciones" y "Memoria transaccional de software sensible a la caché".
- LibCMT , una implementación de código abierto en C de Duilio Protti basada en "Transacciones de memoria componibles". [6] La implementación también incluye un enlace C # .
- TARIFA es un prototipo que trae la palabra clave "atómica" a C / C ++ instrumentando la salida del ensamblador del compilador.
- Intel STM Compiler Prototype Edition implementa STM para C / C ++ directamente en un compilador (el compilador Intel) para Linux o Windows que produce código de 32 o 64 bits para procesadores Intel o AMD. Implementa palabras clave atómicas y proporciona formas de decorar (declspec) definiciones de funciones para controlar / autorizar el uso en secciones atómicas. Una implementación sustancial en un compilador con el propósito declarado de permitir la experimentación a gran escala en cualquier tamaño de programa C / C ++. Intel ha realizado cuatro lanzamientos de investigación de esta versión experimental especial de su compilador de productos.
- stmmap Una implementación de STM en C, basada en el mapeo de memoria compartida. Es para compartir memoria entre subprocesos y / o procesos (no solo entre subprocesos dentro de un proceso) con semántica transaccional. La versión multiproceso de su asignador de memoria está en C ++.
- CTL Una implementación de STM en C, basada en TL2 pero con muchas extensiones y optimizaciones.
- El STM basado en bloqueo TL2 del grupo de investigación Scalable Synchronization de Sun Microsystems Laboratories, como se muestra en el artículo de DISC 2006 "Transactional Locking II".
- Varias implementaciones de Tim Harris y Keir Fraser , basadas en ideas de sus artículos "Language Support for Lightweight Transactions", "Practical Lock Freedom" y un próximo trabajo inédito.
- RSTM The University of Rochester STM escrito por un equipo de investigadores dirigido por Michael L. Scott .
- G ++ 4.7 ahora admite STM para C / C ++ directamente en el compilador. La función todavía aparece como "experimental", pero aún puede proporcionar la funcionalidad necesaria para la prueba.
- STM es parte del marco de transacciones picotm para C [9]
C#
- Protegido Un STM estricto y en su mayoría libre de obstrucciones para .NET, escrito en C #. Las características incluyen: transacciones condicionales, operaciones conmutables (de bajo conflicto), tipos de colección transaccional y generación automática de subclases de proxy transaccionales para objetos POCO.
- STMNet Una API de memoria transaccional de software liviana, de código abierto y puramente C #.
- SXM , una implementación de transacciones para C # de Microsoft Research . Documentación , página de descarga discontinuada.
- LibCMT , una implementación de código abierto en C de Duilio Protti basada en "Transacciones de memoria componibles". [6] La implementación también incluye un enlace C # .
- NSTM , .NET Software Transactional Memory escrita completamente en C # que ofrece transacciones verdaderamente anidadas e incluso se integra con System.Transactions.
- MikroKosmos Implementación de un modelo orientado a la verificación de un STM en C #.
- ObjectFabric cf. Implementaciones de Java.
- Sasa.TM Una implementación C # pura de memoria transaccional de software.
Clojure
- Clojure tiene soporte STM integrado en el lenguaje central
Lisp común
- CL-STM Una implementación de STM multiplataforma para Common Lisp.
- STMX Una biblioteca de simultaneidad de código abierto y mantenida activamente que proporciona transacciones de memoria híbrida, hardware y software para Common Lisp.
Erlang
- Mnesia Un DBMS distribuido, transaccional y en memoria integrado en Erlang / OTP, que desempeña la función de STM; Quizás la implementación más antigua de STM en la naturaleza.
F#
- F # los tiene a través de [1] FSharpX - muestra en [2] F #
Groovy
- GPars : el marco de Gpars contiene soporte para STM aprovechando la implementación de Java Multiverse .
Haskell
- La biblioteca STM , como se muestra en "Transacciones de memoria componibles" , es parte de la plataforma Haskell .
- La biblioteca DSTM , un STM distribuido, basado en la biblioteca anterior.
Java
- Implementación del grupo de investigación SCAT de AtomJava.
- JVSTM implementa el concepto de Versioned Boxes propuesto por João Cachopo y António Rito Silva, miembros del Grupo de Ingeniería de Software - INESC-ID . A partir de la versión 2.0, JVSTM está completamente libre de bloqueos.
- Deuce Un entorno de ejecución para la memoria transaccional de software Java que utiliza la manipulación de código de bytes.
- Multiverse es una implementación de memoria transaccional de software (STM) basada en Java 1.6+ que utiliza el control de concurrencia de múltiples versiones (MVCC) como mecanismo de control de concurrencia.
- Biblioteca de memoria transaccional de software dinámico de DSTM2 Sun Lab
- ObjectFabric es una implementación de código abierto para Java y .NET. Se puede convertir en un STM distribuido a través de un mecanismo de extensión. Otras extensiones permiten el registro, la notificación de cambios y la persistencia.
- ScalaSTM : un STM basado en bibliotecas escrito en Scala que, además, proporciona una API centrada en Java para permitir su uso con objetos ejecutables y invocables.
JavaScript
- AtomizeJS implementa la memoria transaccional de software distribuida en los navegadores web con un solo servidor NodeJS para validar los efectos de las transacciones.
OCaml
- coThreads , una biblioteca de programación concurrente de OCaml , ofrece STM (originalmente STMLib ) como módulo. Al igual que cualquier otro componente de esta biblioteca, el módulo STM se puede utilizar de manera uniforme con subprocesos a nivel de VM, subprocesos del sistema y procesos.
Perl
- STM para Perl 6 se ha implementado en Pugs a través de la biblioteca STM del compilador de Glasgow Haskell .
Pitón
- Bifurcación de CPython con bloqueos atómicos : Armin Rigo explica su parche a CPython en un correo electrónico a la lista de pypy-dev .
- Anuncio de PyPy STM con subprocesos de Armin Rigo para PyPy .
- Popovic, Miroslav; Kordic, Branislav (2014). "PSTM: memoria transaccional del software Python". 2014 22º Foro de Telecomunicaciones Telfor (TELFOR) . págs. 1106–1109. doi : 10.1109 / TELFOR.2014.7034600 . ISBN 978-1-4799-6191-7.
- Kordic, Branislav; Popovic, Miroslav; Basicevic, Ilija (2015). "DPM-PSTM: memoria transaccional de software Python basada en memoria de doble puerto". 2015 Conferencia Regional de Europa del Este cuarto en la ingeniería de sistemas basados en ordenador . págs. 126-129. doi : 10.1109 / ECBS-EERC.2015.28 . ISBN 978-1-4673-7967-0.
Rubí
- MagLev es una implementación del intérprete Ruby construido sobre la máquina virtual GemStone / S
- Concurrent Ruby es una biblioteca que proporciona funciones simultáneas para Ruby, incluido STM
- Ractor :: TVar es una implementación para Ractor y Thread en Ruby 3.0. Libras
Scala
- ScalaSTM : una propuesta preliminar junto con la implementación de referencia CCSTM [10] que se incluirá en la biblioteca estándar de Scala
- Akka STM : el marco de Akka contiene soporte para STM tanto en Scala como en Java
- MUTS - Transacciones de la Universidad de Manchester para Scala [11]
- ZIO : implementación en ZIO inspirada en la API de STM en Haskell.
- Cats STM : una extensión de Cats Effect con una implementación de memoria transaccional de software similar a la del paquete stm de Haskell .
Charla
- GemStone / S [3] Un servidor de objetos de memoria transaccional para Smalltalk.
- STM para Smalltalk de código abierto (licencia MIT) Pharo
Otros idiomas
- Fortress es un lenguaje desarrollado por Sun que usa DSTM2
- STM.NET
Referencias
- ^ Tom Knight. Una arquitectura para lenguajes mayoritariamente funcionales. Actas de la conferencia ACM de 1986 sobre LISP y programación funcional.
- ^ a b Maurice Herlihy y J. Eliot B. Moss. Memoria transaccional: soporte arquitectónico para estructuras de datos sin bloqueo. Actas del 20º simposio internacional anual sobre arquitectura informática (ISCA '93). Volumen 21, Número 2, mayo de 1993.
- ^ Nir Shavit y Dan Touitou. Memoria transaccional de software. Computación distribuída. Volumen 10, Número 2. Febrero de 1997.
- ^ " " memoria transaccional de software "- Google Scholar" . Consultado el 10 de noviembre de 2013 .
- ^ Simon Peyton-Jones. "Programación en la era de la concurrencia: software de memoria transaccional" . Canal 9 . Consultado el 9 de junio de 2007 .
- ^ a b c d e Harris, T .; Marlow, S .; Peyton-Jones, S .; Herlihy, M. (2005). "Transacciones de memoria componible" (PDF) . Actas del décimo simposio ACM SIGPLAN sobre Principios y práctica de la programación paralela - PPoPP '05 . pag. 48. doi : 10.1145 / 1065944.1065952 . ISBN 1595930809.
- ^ Hany E. Ramadan, Indrajit Roy, Maurice Herlihy, Emmett Witchel (2009): Actas de "Compromiso de transacciones en conflicto en un STM" del 14 ° simposio ACM SIGPLAN sobre principios y práctica de la programación paralela (PPoPP '09), ISBN 978-1-60558-397-6
- ^ Lingli Zhang, Vinod K. Grover, Michael M. Magruder, David Detlefs, John Joseph Duffy, Goetz Graefe (2006): Orden de confirmación de transacción de software y gestión de conflictos Patente de Estados Unidos 7711678, concedida el 04/05/2010.
- ^ "picotm - Administrador de transacciones abierto, personalizable e integrado portátil" .
- ^ NG Bronson, H. Chafi y K. Olukotun, CCSTM: Un STM basado en biblioteca para Scala . Actas del Taller de Scala Days 2010 (Lausana).
- ^ D. Goodman, B. Khan, S. Khan, C. Kirkham, M. Luján e Ian Watson, MUTS: Construcciones nativas de Scala para memoria transaccional de software . Actas del Taller de Scala Days 2011 (Stanford).
enlaces externos
- Morry Katz, PARATRAN: Un mecanismo de ejecución transparente basado en transacciones para la ejecución paralela de Scheme , MIT LCS, 1989
- Nir Shavit y Dan Touitou. Memoria transaccional de software . Actas del 14º Simposio de ACM sobre Principios de Computación Distribuida , págs. 204–213. Agosto de 1995. El papel originario de STM.
- Maurice Herlihy, Victor Luchangco, Mark Moir y William N. Scherer III. Memoria transaccional de software para estructuras de datos de tamaño dinámico . Actas del Vigésimo Segundo Simposio Anual ACM SIGACT-SIGOPS sobre Principios de Computación Distribuida (PODC) , 92–101. Julio de 2003.
- Tim Harris y Keir Fraser. Soporte de idiomas para transacciones ligeras . Programación, sistemas, lenguajes y aplicaciones orientadas a objetos , págs. 388–402. Octubre de 2003.
- Robert Ennals. La memoria transaccional de software no debe estar libre de obstrucciones .
- Michael L. Scott y col. Reducir la sobrecarga de la memoria transaccional de software sin bloqueo brinda una buena introducción no solo al RSTM sino también a los enfoques STM existentes.
- Torvald Riegel y Pascal Felber y Christof Fetzer, A Lazy Snapshot Algorithm with Eager Validation presenta el primer STM basado en el tiempo.
- Dave Dice, Ori Shalev y Nir Shavit. Bloqueo transaccional II .
- Knight, TF, Una arquitectura para lenguajes principalmente funcionales , ACM Lisp and Functional Programming Conference, agosto de 1986.
- Knight, TF, Sistema y método para procesamiento paralelo con lenguajes principalmente funcionales, Patente de EE.UU. 4.825.360, abril de 1989.
- Ali-Reza Adl-Tabatabai, Christos Kozyrakis, Bratin Saha, Unlocking concurrency , ACM Queue 4, 10 (diciembre de 2006), págs. 24–33. Vincula procesadores multinúcleo y la investigación / interés en STM.
- James R Larus , Ravi Rajwar, Transactional Memory , Morgan y Claypool Publishers, 2006.
- Grupo sin candados Cambridge
- Memoria transaccional de software Descripción; Derrick Coetzee
- Bibliografía de memoria transaccional
- Discusión crítica de STM junto con lenguajes imperativos
- JVSTM: memoria transaccional de software con versión de Java
- Deuce - Memoria transaccional de software Java
- Blog sobre STM y el algoritmo TLII
- Flexviews: las vistas materializadas actúan como una memoria transaccional de software para las relaciones de la base de datos