Barrapunto

Ahora, pongamos todos cara de eruditos y finjamos que sabemos perfectamente qué es la memoria transaccional y estamos al día de la investigación...

El enlace correcto a la primera página del artículo es Software Transactional Memory: Why is it Only a Research Toy? [acmqueue.com] (se me ha colado el enlace a la última parte) Si alguien lo quiere leer en pdf también está disponible (Software Transactional Memory: Why is it Only a Research Toy? (pdf) [acm.org])

Por otro lado la he envíado a reddit [reddit.com] y hay quien, con buen critero, echa de menos a clojure [clojure.org] en el benckmark.

de http://buscon.rae.es/ [buscon.rae.es]

transaccional.

1. adj. Perteneciente o relativo a la transacción.

Saludos.

La memoria transaccional requiere de un nuevo paradigma de programación que los desarrolladores estancados niegan asimilar. Pero la fuerza del mercado apunta a que esta memoria junto con el cloud computing dará a las empresas un nuevo abanico de servicios Web 2.0 que potenciará el B2B y el B2C.


Nota: No tengo ni pajolera idea que es memoria transaccional, clud computing, web 2.0 y solo se que son las siglas B2B y B2C pero nada mas.... pero como suena de bonito el parrafo anterior.

Estoy haciendo mi tesis doctoral en este tema y he tenido relación con muchos de los autores que se citan en el artículo, os pongo mi opinión por si fuera de interés para alguien.

Para quien no lo sepa, la idea de la memoria transaccional es aplicar los fundamentos de las transacciones de bases de datos a la programación ordinaria. De esta forma, todas las modificaciones que se hagan a objetos compartidos dentro de una "transacción" de nuestro código se mantienen atómicas, consistentes y aisladas entre sí. Así, podemos quitarnos el problema del manejo de locks.

El artículo es muy bueno, ya que expone las propuestas que se han realizado, y critica los fallos que pueda tener cada una de ellas, aunque puede resultar algo complejo para público profano.

En general, el principal problema que se puede alegar es el tema del rendimiento. Básicamente, si tenemos un código basado en locks para proteger datos compartidos, cuando un procesador toma un lock puede modificar los datos a su antojo. En cambio, si lo hacemos mediante una transacción, es necesario guardar las dos versiones (la vieja y la nueva) por si eso falla. Esto hace que las operaciones a memoria se dupliquen, el tamaño necesario para bufferes de escritura (o undo-logs) se dispare en caso de tener transacciones grandes. De esta forma, si tenemos un código con poca "contención" en el acceso a los datos compartidos (y generalmente está optimizado para que así sea, ya que eso es el cuello de botella en programas paralelos) entonces la versión basada en locks proporcionará un rendimiento mejor. Además, tendremos numerosas llamadas al runtime que se encarga de proporcionar esas características (atomicidad, consistencia...) que enlentecen la ejecución.

También hay propuestas hardware o híbridas, de Universidades (TCC [stanford.edu] de Stanford, LogTM [wisc.edu] de Wisconsin, y muchas otras) o de fabricantes (como el sistema híbrido de Intel [ieee.org] o el Rock [wikipedia.org] de Sun, que también es híbrido. En estas propuestas, se pasa a algún mecanismo HW las tareas de mantenimiento de versiones, detección de colisiones, inicialización y commit de las transacciones, etc. Sin embargo, en conversaciones con un ingeniero de Intel Haifa (Israel, el laboratorio donde se desarrolló el Core 2) me aseguraba que tardaría mucho en estar disponible en silicio, y alegaba un problema bien claro: Si sale mal, y la gente no lo acepta, habrá que mantenerlo de cualquier forma en versiones subsiguientes de la arquitectura x86, con el alto coste que puede acarrear (ya que no solo implica cambios en la ISA del procesador, puede que también en las caches L1, primitivas de comunicación entre cores, etc).

A mi parecer, uno de los principales problemas, que creo que no se comenta en el artículo, es la falta de aplicaciones "serias" que utilicen memoria transaccional. Sí, tenemos micro-benchmarks (todos los artículos implementan de alguna manera red-black trees y linked lists), tenemos kernels de aplicaciones (como STAMP [stanford.edu]), pero en cualquier caso son aplicaciones generadas a base de "cambiar locks por transacciones". Una de las ventajas de las transacciones es que se pueden componer, es decir, se puede anidar una transacción dentro de otra sin ningún problema, y en cualquier orden. Esto no se puede hacer con locks, ya que puede llevar a deadlock (si dos threads pretenden tomar dos locks dados en orden inverso), lo que obliga al programador a ser consciente de todos los posibles caminos que puedan tomar los threads en el sistema. De esta forma, el diseño de una aplicación paralelo (e

el titulo de la noticia es completamente incorrecto y presta a la desinformacion. El articulo es referente a la "Software Transactional Memory" especifica y no a la "Transactional Memory" en general.

Mi intención era ponerlo en el título, pero Slashcode no me dejaba (demasiado largo) Así que he decidido quitar "Software" porque estaba explícito en el título del artículo y en el enlace a STM...