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

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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