Мы просим слишком много транзакционной памяти?

Question

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

• Вы не можете сделать I/O
• Вы должны написать свои атомные секции, чтобы они могли работать в несколько раз (будьте осторожны с вашим локальным переменными!)
• программного обеспечения транзакционной памяти предлагает низкую производительность
• [Вставьте огорчает здесь]

Я понимаю эти проблемы: чаще всего вы найдете статьи о STM, которые работают только на определенном оборудовании, поддерживающем некоторую действительно отличную атомную операцию (например, LL/SC) или ее нужно поддерживать каким-то мнимым компилятором, или она требует, чтобы все Доступ к памяти должен быть транзакционным, он вводит ограничения типа monad-стиля и т. Д. И прежде всего: это настоящие проблемы.

Это заставило меня спросить себя: Что говорит о локальном использовании транзакционной памяти в качестве замены замков? Будет ли это уже приносить достаточное значение или должна быть использована транзакционная память по всему месту, если она используется вообще?

Answer 1

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

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

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

I/O также возможен, но ваша транзакция становится безотзывной, то есть не может быть прервана. Это означает, что только одна транзакция может использовать ввод-вывод одновременно. Вы также можете использовать операции ввода-вывода, как только транзакция верхнего уровня будет успешной, в мире без транзакций, как сейчас.

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

Answer 2

В последнее время я много читаю о транзакционной памяти.

Вы также можете быть заинтересованы в этом podcast on software transactional memory, который также вводит STM, используя аналогию на основе сбора мусора:

paper о аналогии между сбором мусора и транзакционной памятью. В дополнение к тому, чтобы увидеть красоту аналогии, обсуждение также служит хорошим введением в транзакционную память (что упоминалось в эпизоде ​​Goetz/Holmes) и - в некоторой степени - для сбора мусора.

Answer 3

Если вы используете транзакционную память в качестве замены для блокировок, весь код, который выполняется с сохраненной блокировкой, может быть откат после завершения. Таким образом, код, который ранее использовал блокировки, должен быть транзакционным и иметь все те же недостатки (и преимущества).

Итак, вы можете ограничить влияние TM только на те части кода, которые содержат блокировки, верно? Каждый фрагмент кода, который может быть вызван во время удерживаемой блокировки, должен поддерживать TM в этом сценарии. Сколько из вашей программы не хранит блокировки и никогда не вызывается кодом, содержащим блокировки?