Любой Реальный Опыт Использования Программной Транзакционной Памяти? [закрытый]

статья " программная транзакционная память: почему это только исследовательская игрушка?"не удается посмотреть на реализацию Haskell, что является действительно большим упущением. Проблема для STM, как отмечается в статье, заключается в том, что реализации должны выбирать между тем, чтобы сделать все переменные доступы транзакционными, если компилятор не может доказать их безопасность (что убивает производительность) или позволить программисту указать, какие из них должны быть транзакционными (что убивает простоту и надежность). Однако Реализация Haskell использует чистоту Haskell, чтобы избежать необходимости делать большинство переменных транзакционными, в то время как система типов обеспечивает простую модель вместе с эффективным применением для операций транзакционной мутации. Таким образом, программа Haskell может использовать STM для тех переменных, которые действительно разделяются между потоками, гарантируя при этом безопасность использования нетранзакционной памяти.

мы используем его довольно регулярно для приложений с высоким параллелизмом в Galois (в Haskell). Он работает, его широко используют в мире Haskell, и он не тупик (хотя, конечно, у вас может быть слишком много разногласий). Иногда мы переписываем вещи, чтобы использовать MVars, если у нас есть правильный дизайн-так как они быстрее.

просто использовать его. Ничего страшного. Насколько я понимаю, STM в Haskell "решен". Больше ничего не надо делать. Поэтому мы используем его.

мы, factis research GmbH, используют Haskell STM с GHC в продукции. Наш сервер получает поток сообщений о новых и измененных "объектах" от clincal "Data server", он преобразует этот поток событий на лету (генерируя новые объекты, изменяя объекты, агрегируя вещи и т. д.) и вычисляет, какие из этих новых объектов должны быть синхронизированы с подключенными iPads. Он также получает входные данные формы от iPads, которые обрабатываются, объединяются с "основным потоком" и также синхронизируется с другими iPad. Мы использовали СТМ для всех каналов и изменяемых структур данных, которые должны быть разделены между потоками. Потоки очень легкие в Haskell, поэтому мы можем иметь их много, не влияя на производительность (на данный момент 5 на подключение iPad). Создание большого приложения всегда является сложной задачей, и было много уроков, которые можно извлечь, но у нас никогда не было никаких проблем с STM. Он всегда работал так, как вы наивно ожидали. Мы должны были сделать некоторые серьезные выступления настройка, но STM никогда не была проблемой. (80% времени мы пытались уменьшить кратковременные выделения и общее использование памяти.)

STM-это одна из областей, где Haskell и среда выполнения GHC действительно сияют. Это не просто эксперимент и не только для игрушечных программ.

мы строим другой компонент нашей клинковой системы в Scala и до сих пор использовали актеров, но нам действительно не хватает STM. Если у кого-то есть опыт использования одного из Scala STM реализации в производстве я хотел бы услышать от вас. : -)

мы реализовали весь наш система (база данных и среда выполнения в памяти) поверх нашей собственной реализации STM в C. До этого у нас был некоторый механизм на основе журнала и блокировки для работы с параллелизмом, но это было больно поддерживать. Мы очень довольны STM, так как мы можем относиться к каждой операции одинаково. Почти все замки можно было снять. Теперь мы используем STM практически для всего любого размера, у нас даже есть менеджер памяти сверху.

производительность хорошо, но чтобы ускорить процесс, мы теперь разработали пользовательский операционные системы в сотрудничестве с ETH Zurich. Система изначально поддерживает транзакционную память.

но есть некоторые проблемы, вызванные STM, а также. Особенно с большими транзакциями и горячими точками, которые вызывают ненужные конфликты транзакций. Если, например, две транзакции помещают элемент в связанный список, возникает ненужный конфликт, который можно было бы избежать с помощью данных без блокировки структура.

в настоящее время я использую Akka в некоторых исследованиях систем PGAS. Акка это библиотека Scala для разработки масштабируемых параллельных систем с использованием акторов, STM и встроенных возможностей отказоустойчивости, смоделированных по философии Erlang "пусть это не сработает/сбой/кратер/ROFL". Реализация STM Akka предположительно построена вокруг порта Scala реализации STM Clojure. Обзор модуля STM Akka можно найти здесь.