- это Clojure Refs/do-sync только эквивалент java «синхронизированного» блока?

Question

Я пытаюсь убедить себя, что clojure действительно проще, чем Java для параллельного программирования.

, но я чувствую, что Clojure Refs/do-sync почти точно совпадает с java-синхронизированным блоком. то я прочитал эту тему: Clojure STM (dosync) x Java synchronize block

--- Я перезапускаю новый поток, так как, если я прокомментирую там в старой ветке, ответ может быть не очень высоким из-за старости.

первый комментарий этой темы от Michał Marczyk утверждает, что diff заключается в том, что блок синхронизации java использует блокировки, в то время как Clojure использует транзакции. Я думаю, что это утверждение не затрагивает сути проблемы: внизу транзакции по-прежнему реализуются шлюзами. поэтому «java using locks» не является причиной того, что Clojure лучше.

Я думаю, что реальная выгода заключается в том, что транзакции Clojure управляет замками автоматически, так же, как DB транзакции. таким образом, порядок приобретения блокировок и порядок воспроизведения транзакций определяются менеджером транзакций, поэтому программисту не нужно заботиться об этом, в то время как в java-мире программист должен явно выбрать, какую блокировку использовать для блок синхронизации, что приводит к возможным взаимоблокировкам. менеджер транзакций может использовать двухфазную блокировку, например, чтобы избежать взаимоблокировок.

ли это имеет смысл?

благодаря Ян

Answer 1

работы в Clojure является другим параллелизмом абстракция, и она работает как транзакция базы данных - это имеет атомарность, согласованность и свойство изоляции. Он построен поверх механизма блокировки JVM, поэтому его можно реализовать на Java. Причина, почему мы не делаем это в том, что ссылка как механизм требует других нетривиальных механизмов, которые будут реализованы заранее:

• Persistent Data Structures
• MVCC STM
• непреложных данные и отсутствие побочных эффектов внутри транзакций (так как они авто-повторена)

Answer 2

Автор ссылочного ответ здесь - позвольте мне попытаться разработать:

на самом деле в т он ссылается на ответ, в котором я утверждаю, в первую очередь, что «dosync и synchronized предоставляют доступ к совершенно различным абстракциям параллелизма». Кроме того, я описываю synchronized не просто как «использование блокировок», а скорее как «способ получения и освобождения блокировок».

Иными словами, хотя STM, безусловно, использует блокировки под капотом, он предоставляет транзакционную семантику, о которой можно рассуждать как таковая; например, он свободен от тупиков по конструкции (возможно, возможен листок, возможно). Напротив, synchronized явно не более или менее, чем способ для программиста заявить, что монитор такого и того же объекта должен быть получен и выпущен в точках, отмеченных фигурными скобками. Важное различие здесь заключается в семантике, а не в реализации.

Кроме того, для STM существует больше, чем управление порядком блокировки; есть MVCC, как упоминалось Grzegorz, происходит автоматический перезапуск транзакций, есть ensure и commute (контроль согласованности против.параллелизм, если вы это сделаете), существует сотрудничество между STM и агентами (действия агента, помещенные в очередь с send, отправляются только в момент фиксации, если вызваны из транзакции).

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