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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

В статье "Транзакционная память программного обеспечения: почему это всего лишь исследовательская игрушка?" (Călin Caşcaval et al., Communications of ACM, ноябрь 2008 г.) не рассматривается реализация Haskell, которая является действительно большое упущение. Проблема для STM, как указывается в статье, заключается в том, что реализации должны выбирать между либо выполнением транзакционного доступа ко всем переменным, если только компилятор не может доказать их безопасность (что снижает производительность), либо позволением программисту указать, какие из них должны быть транзакционными (что убивает простоту). и надежность). Однако реализация Haskell использует чистоту Haskell, чтобы избежать необходимости использовать большинство переменных для транзакций, в то время как система типов предоставляет простую модель вместе с эффективным применением для операций транзакционной мутации. Таким образом, программа на Haskell может использовать STM для тех переменных, которые действительно разделяются между потоками, гарантируя при этом безопасное использование нетранзакционной памяти.

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 6

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

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

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

Ответ 7

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