privateПро clojure говорится что она использует персистентные структуры данных и поэтому свободна от проблем с мультитредингом и синхронизацией.
Ссылку можно? Где говориться-то? Это не фишка clojure. Это свойство большинста сильно функциональных языков.

privateНо, даже иммутабельные (или персистентные) объекты нужно както создавать. И мне непонятно как это можно сделать тредсейф без синхронизации.

Персистентные структуры это не тоже самое что immutable
http://en.wikipedia.org/wiki/Persistent_data_structure
Смешивать не нужно.

privateПотому что в жава без синхронизации (или волатайл) нельзя даже создать обьект так чтобы это было потокобезопасно.
Уже много лет как можно.

privateКому интересно детали по ссылке http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
С разморозкой.

privateТак как-же они тогда делают это в кложуре без синхронизации? Или они таки ее используют?
Когда надо - используют. Просто функциональное программирование использует другие подходы. Поэтому хранить общедоступное для разных потоков состояние там приходится реже.

privateУточню вопрос, понятно что в кложуре не нужно писать синхронизацию явно и нет проблем с дедлоками.
Это тогда чиво такое?
https://clojuredocs.org/clojure.core/locking


privateВопрос в том что если она использует синхронизацию или волатайл неявно внутри - то будут потери в производительности - и получается что это какбы не совсем чистая неблокирующая многопоточность.
Блин. Суть вообще не в том. Используй immutable структуры в Java и у тебя тоже будет меньше проблем с многопоточностью, как следствие того, что все ресурсы разделены между потоками. И конкуренция сводится к минимуму.

Вот, на вскидку, статья из гугла, полностью повторяет то что я написал.
https://miles.no/blogg/why-care-about-functional-programming-part-1-immutability Unlike traditional object-oriented languages, functional programming, by its very nature, encourages us to write thread-safe code .
Это не значит, что там нет блокировок, волатильности и прочих прелестей. Просто функциональный подход минимизирует надобность в конкуренции.

YamahaR1Ссылка не открывается.
Это провайдеру надо жаловаться, а не на форум писать.

privateВы концентрируетеь на деталях, да персистентные и иммутабельные структуры данных не совсем одно и тоже и да функциональный стиль меньше требует разделения памяти и тд
И да в кложуре тоже есть и локи и атомы и тп которые тоже нужны хоть и реже.
Так задай вопрос внятно. Ты же первый каким-то образом связал иммутаблельность с отсутствеим дедлоков.

privateЗабудем на секунду все эти локи и атомы в кложуре и представил что мы ничего о них не знаем и не используем.
Вопрос - использует ли кложур синхронайз/волатайл при создании нового объекта (модификации персистентной структуры данных)?
Внутри, когда она создает новую вершину персистентного дерева, в его внутренней жавовской реализации?
То эта вершина видна одному потоку, который её создал. Когда он с ней закончит - может передать другому.
Но как только возникает конкуренция, тут же надо руками синхронизировать. Берем тот же синглтон, который ты зачем-то приплел к вопросу
http://www.clodoc.org/doc/clojure.contrib.singleton/global-singleton Warning: global singletons are often unsafe in multi-threaded code.
Consider per-thread-singleton instead.

privateКак? Только не синглтон с загрузкой класса.
Новые гарантии в JMM. Сначала для volatile, потом для final. Уже разжевано-пережовано где только можно
http://habrahabr.ru/post/27108/
http://habrahabr.ru/post/129494/

privateТе получается что без волатайл тредбезопасно создать объект (не интеджер или стринг) нельзя.
Фак мой моск. Ты всё мешаешь в кучу.
Есть многопоточный доступ к mutable ссылке? Значит создать в ней значение безопасно нельзя. Поэтому Clojure предлагает этого не делать вообще! А создавать объекты внутри потоков без volatile и не шарить эти объекты в другие потоки, пока не закончится работа в текущем. Создать объект одним потоком безопасно и без volatile. Главное не шарить этот объект в другие потоки. Нет никакой магии. Все те же мониторы\семафоры\CAS\барьеры\задвижки всё работает на одном и том же железе. Не важно на функциональном языке написано или на процедурном.

Blazkowicz https://miles.no/blogg/why-care-about-functional-programming-part-1-immutability Unlike traditional object-oriented languages, functional programming, by its very nature, encourages us to write thread-safe code .

А такие клевая статья. Там и вторая часть есть по близкой теме.
http://miles.no/blogg/why-should-we-care-about-functional-programming-part-2-transformations