language agnostic - ¿Alguna experiencia real usando la memoria transaccional de software?
language-agnostic scala (6)
Actualmente estoy usando Akka en algunos estudios de sistemas PGAS. Akka es una biblioteca de Scala para desarrollar sistemas concurrentes escalables usando Actores, STM y capacidades de tolerancia a fallas incorporadas, modeladas según la filosofía "Let It Fail / Crash / Crater / ROFL" de Erlang. La implementación de STM de Akka supuestamente se basa en un puerto Scala de la implementación STM de Clojure. here puede encontrar una descripción general del módulo STM de Akka.
Parece que ha habido un interés creciente reciente en los marcos de STM (memoria transaccional de software) y las extensiones de lenguaje. Clojure, en particular, tiene una implementación excelente que utiliza MVCC (control de concurrencia de múltiples versiones) en lugar de un registro de compromiso continuo. GHC Haskell también tiene una mónada STM extremadamente elegante que también permite la composición de las transacciones. Finalmente, para activar mi propio cuerno un poco, recientemente implementé un marco STM para Scala que aplica restricciones de referencia de forma estática.
Todos estos son experimentos interesantes, pero parecen estar limitados solo a esa esfera (experimentación). Entonces mi pregunta es: ¿alguno de ustedes ha visto o usado STM en el mundo real? Si es así, ¿por qué? ¿Qué tipo de beneficios trajo? ¿Qué hay del rendimiento? (parece haber una gran cantidad de información contradictoria sobre este punto) ¿Volvería a utilizar STM o preferiría usar alguna otra abstracción de concurrencia como actores?
El artículo "Software Transactional Memory: ¿por qué es solo un juguete de investigación?" no ve la implementación de Haskell, que es una gran omisión. El problema para STM, como señala el artículo, es que las implementaciones deben elegir entre hacer que todos los accesos variables sean transaccionales a menos que el compilador pueda probarlos como seguros (lo que mata el rendimiento) o dejar que el programador indique cuáles serán transaccionales (lo que mata la simplicidad y confiabilidad). Sin embargo, la implementación de Haskell utiliza la pureza de Haskell para evitar la necesidad de que la mayoría de los usos transaccionales sean variables, mientras que el sistema de tipo proporciona un modelo simple junto con la aplicación efectiva para las operaciones de mutación transaccional. Por lo tanto, un programa Haskell puede usar STM para aquellas variables que realmente se comparten entre hilos, a la vez que garantiza que el uso de la memoria no transaccional se mantenga a salvo.
Hemos implementado todo nuestro system (base de datos en memoria y tiempo de ejecución) además de nuestra propia implementación de STM en C. Antes de esto, teníamos algún mecanismo basado en logs y bloqueos para manejar la simultaneidad, pero esto era algo difícil de mantener. Estamos muy contentos con STM ya que podemos tratar cada operación de la misma manera. Casi todos los bloqueos podrían ser eliminados. Ahora usamos STM para casi cualquier tamaño, incluso tenemos un administrador de memoria implementado en la parte superior.
El rendimiento está bien, pero para acelerar las cosas, ahora desarrollamos un sistema operativo personalizado en colaboración con ETH Zurich. El sistema admite nativamente la memoria transaccional.
Pero también hay algunos desafíos causados por STM. Especialmente con transacciones más grandes y puntos de acceso que causan conflictos de transacción innecesarios. Si, por ejemplo, dos transacciones ponen un elemento en una lista vinculada, se producirá un conflicto innecesario que podría haberse evitado utilizando una estructura de datos sin bloqueo.
Lo usamos bastante rutinariamente para aplicaciones de alta concurrencia en Galois (en Haskell). Funciona, se usa ampliamente en el mundo de Haskell, y no se bloquea (aunque, por supuesto, puede tener demasiada controversia). A veces reescribimos cosas para usar MVars, si tenemos el diseño correcto, ya que son más rápidos.
Solo úsalo. No es la gran cosa. En lo que a mí respecta, STM en Haskell está "resuelto". No hay más trabajo por hacer. Entonces lo usamos
Nosotros, factis research GmbH , estamos utilizando Haskell STM con GHC en producción. Nuestro servidor recibe un flujo de mensajes sobre "objetos" nuevos y modificados de un "servidor de datos" clínico, transforma este flujo de eventos sobre la marcha (generando nuevos objetos, modificando objetos, agregando cosas, etc.) y calcula cuál de estos nuevos los objetos deben estar sincronizados con iPads conectados. También recibe entradas de formulario de iPads que se procesan, se fusionan con la "transmisión principal" y también se sincronizan con las otras iPads. Estamos utilizando STM para todos los canales y estructuras de datos mutables que deben compartirse entre hilos. Los hilos son muy livianos en Haskell por lo que podemos tener muchos de ellos sin afectar el rendimiento (en este momento 5 por conexión de iPad). Crear una aplicación grande siempre es un desafío y había muchas lecciones que aprender, pero nunca tuvimos ningún problema con STM. Siempre funcionó como lo esperarías ingenuamente. Tuvimos que hacer algunos ajustes de rendimiento serio, pero STM nunca fue un problema. (80% de las veces intentamos reducir las asignaciones de corta duración y el uso general de la memoria).
STM es un área donde realmente brilla Haskell y el tiempo de ejecución de GHC. No es solo un experimento y no solo para programas de juguete.
Estamos construyendo un componente diferente de nuestro sistema clínico en Scala y hemos estado usando Actores hasta el momento, pero realmente nos falta STM. Si alguien tiene experiencia de lo que es usar una de las implementaciones de Scala STM en producción, me gustaría saber de usted. :-)
Participé en el desarrollo de aficionado del cliente BitTorrent en Haskell (llamado conjure). Utiliza bastante STM para coordinar diferentes subprocesos (1 por igual + 1 para la gestión de almacenamiento + 1 para la gestión general).
Beneficios: menos bloqueos, código legible.
La velocidad no era un problema, al menos no debido al uso de STM.
Espero que esto ayude