Есть ли реальный опыт использования программной транзакционной памяти?

scala haskell clojure language-agnostic stm

4978 просмотра

6 ответа

Похоже, что в последнее время растет интерес к платформам STM (программная транзакционная память) и языковым расширениям. В частности, Clojure имеет отличную реализацию, в которой используется MVCC (управление несколькими версиями параллелизма), а не обновляемый журнал фиксации. GHC Haskell также имеет чрезвычайно элегантную монаду STM, которая также позволяет составлять транзакции. Наконец, для того, чтобы немного поразмыслить над своим собственным звуком, я недавно внедрил платформу STM для Scala, которая статически обеспечивает ограничения ссылок.

Все это интересные эксперименты, но, похоже, они ограничены только этой сферой (эксперименты). Итак, мой вопрос: кто-нибудь из вас видел или использовал STM в реальном мире? Если так, то почему? Какие выгоды это принесло? Как насчет производительности? (кажется, есть много противоречивой информации по этому вопросу). Вы бы снова использовали STM или предпочли бы использовать какую-то другую абстракцию параллелизма, такую ​​как актеры?

Автор: Daniel Spiewak Источник Размещён: 25.08.2019 06:16

Ответы (6)


31 плюса

Решение

Я принимал участие в разработке хобби для клиента BitTorrent в Haskell (названного в фокусе). Он довольно интенсивно использует STM для координации различных потоков (1 на одноранговый узел + 1 для управления хранилищем + 1 для общего управления).

Преимущества: меньше блокировок, читаемый код.

Скорость не была проблемой, по крайней мере, не из-за использования STM.

Надеюсь это поможет

Автор: ADEpt Размещён: 16.10.2008 10:10

27 плюса

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

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

Автор: Don Stewart Размещён: 26.06.2010 05:09

27 плюса

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

Автор: Paul Johnson Размещён: 26.12.2008 09:28

12 плюса

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

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

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

Автор: David Leuschner Размещён: 06.12.2011 05:49

4 плюса

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

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

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

Автор: gtroxler Размещён: 09.12.2011 05:19

1 плюс

В настоящее время я использую Akka в некоторых исследованиях систем PGAS. Akka - это библиотека Scala для разработки масштабируемых параллельных систем с использованием Actors, STM и встроенных возможностей отказоустойчивости, созданных по образцу философии Эрланга «Let It Fail / Crash / Crater / ROFL». Реализация Akka STM предположительно построена вокруг Scala-порта реализации Clomure STM. Обзор модуля Akka STM можно найти здесь .

Автор: Marc Размещён: 17.04.2011 05:56
Вопросы из категории :
32x32