Une expérience du monde réel en utilisant la mémoire transactionnelle logicielle? [fermé]

Question

Il semble que l’intérêt croissant pour les frameworks STM (logiciels transactionnels) et les extensions de langage se soit manifesté récemment. Clojure a notamment une excellente implémentation qui utilise MVCC (contrôle de la simultanéité avec plusieurs versions) plutôt qu'un journal de validation évolutif. GHC Haskell dispose également de une monade extrêmement élégante de la STM qui permet également la composition de transaction . Enfin, afin de me vanter un peu, j'ai récemment mis en place un Framework STM pour Scala qui applique de manière statique les restrictions de référence.

Toutes ces expériences sont intéressantes, mais elles semblent être confinées à cette seule sphère (expérimentation). Ma question est donc la suivante: l’un d’entre vous at-il vu ou utilisé la STM dans le monde réel? Si oui, pourquoi? Quel genre d'avantages a-t-il apporté? Qu'en est-il de la performance? (Il semble y avoir beaucoup d’informations contradictoires sur ce point) Souhaitez-vous utiliser à nouveau STM ou préférez-vous utiliser une autre abstraction de concurrence telle que des acteurs?

Answer 1

J'ai participé au développement amateur du client BitTorrent à Haskell (nommé conjure). Il utilise assez fortement STM pour coordonner différents threads (1 par homologue + 1 pour la gestion du stockage + 1 pour la gestion globale).

Avantages: moins de verrous, code lisible.

La vitesse n'était pas un problème, du moins pas à cause de l'utilisation de STM.

J'espère que cela vous aidera

Answer 2

L'article "Mémoire transactionnelle logicielle: pourquoi ne s'agit-il que d'un jouet de recherche?" omet de regarder la mise en œuvre Haskell, qui est une très grande omission. Le problème pour STM, comme le souligne l'article, est que les implémentations doivent choisir entre rendre tous les accès variables transactionnels, sauf si le compilateur peut prouver qu'ils sont sûrs (ce qui tue les performances), ou laisser le programmeur indiquer ceux qui doivent être transactionnels (ce qui tue la simplicité). et fiabilité). Cependant, l'implémentation Haskell utilise la pureté de Haskell pour éviter la nécessité de rendre transactionnelles les utilisations les plus variables, tandis que le système de types fournit un modèle simple associé à une application efficace des opérations de mutation transactionnelle. Ainsi, un programme Haskell peut utiliser STM pour les variables réellement partagées entre les threads tout en garantissant la sécurité de l’utilisation de la mémoire non transactionnelle.

Answer 3

Nous l'utilisons assez couramment pour les applications à haute concurrence de Galois (en Haskell). Cela fonctionne, il est largement utilisé dans le monde Haskell et il n’est pas une impasse (même si bien sûr, vous pouvez avoir trop de conflits). Parfois, nous réécrivons des choses pour utiliser MVars, si notre conception est correcte, car elles sont plus rapides.

Utilisez-le. Ce n'est pas grand chose. En ce qui me concerne, STM à Haskell est "résolu". Il n'y a plus de travail à faire. Nous l'utilisons donc.

Answer 4

Nous, factis research GmbH , utilisons Haskell STM avec GHC en production. Notre serveur reçoit un flux de messages sur les "objets" nouveaux et modifiés. à partir d'un "serveur de données" clinique, il transforme ce flux d'événements à la volée (en générant de nouveaux objets, en modifiant des objets, en agrégeant des éléments, etc.) et en calculant lequel de ces nouveaux objets doit être synchronisé avec les iPad connectés. Il reçoit également des entrées de formulaire provenant d’iPad qui sont traitées et fusionnées avec le "flux principal". et également synchronisé avec les autres iPad. Nous utilisons STM pour tous les canaux et toutes les structures de données modifiables devant être partagées entre les threads. Les threads étant très légers en Haskell, nous pouvons en avoir beaucoup sans nuire aux performances (actuellement, 5 connexions par iPad). Construire une application volumineuse est toujours un défi et il y avait beaucoup à apprendre mais nous n'avons jamais eu de problèmes avec STM. Cela a toujours fonctionné comme vous le souhaitiez naïvement. Nous avons dû procéder à de sérieux ajustements des performances, mais la STM n’a jamais posé problème. (Dans 80% des cas, nous avons essayé de réduire les allocations temporaires et l’utilisation globale de la mémoire.)

STM est un domaine dans lequel Haskell et le runtime GHC brille vraiment. Ce n'est pas juste une expérience et pas seulement pour les programmes de jouets.

Nous construisons un composant différent de notre système clinique à Scala et utilisons Actors jusqu'à présent, mais nous manquons vraiment de STM. Si quelqu'un a une expérience concrète de l'utilisation d'une des implémentations Scala STM en production, j'aimerais beaucoup avoir de vos nouvelles. : -)

Answer 5

Nous avons implémenté l'intégralité de notre système (base de données en mémoire et exécution) en haut de notre propre implémentation STM en C. Avant cela, nous avions un mécanisme basé sur le journal et le verrouillage pour gérer la simultanéité, mais cela était difficile à maintenir. Nous sommes très satisfaits de la STM car nous pouvons traiter chaque opération de la même manière. Presque toutes les serrures pourraient être supprimées. Nous utilisons maintenant STM pour presque tout, quelle que soit sa taille. Nous avons même implémenté un gestionnaire de mémoire.

Les performances sont satisfaisantes, mais pour accélérer les choses, nous avons développé un système d'exploitation personnalisé en collaboration. avec l'ETH Zurich. Le système prend en charge de manière native la mémoire transactionnelle.

Mais la STM pose également certains problèmes. Surtout avec des transactions plus importantes et des points chauds qui provoquent des conflits de transaction inutiles. Si, par exemple, deux transactions placent un élément dans une liste chaînée, un conflit inutile risque d’être évité grâce à une structure de données sans verrouillage.

Answer 6

J'utilise actuellement Akka dans certaines recherches sur les systèmes PGAS. Akka est une bibliothèque Scala permettant de développer des systèmes concurrents évolutifs à l'aide d'acteurs, de STM et de fonctionnalités de tolérance aux pannes intégrées, conçues sur le modèle d'Erlang ". ; Let It Fail / Crash / Crater / ROFL " philosophie. L’implémentation STM d’Akka est censée être construite autour d’un implémentation STM de Clojure à Scala. Vous trouverez un aperçu du module STM d’Akka ici .