Здравствуйте, dshe, Вы писали:

D>http://safari.oreilly.com/0321349601/ch13lev1sec4
D>13.4. Choosing Between Synchronized and ReentrantLock
D>(Java Concurrency in Practice)
[skipped]
Да, читал все это больше года назад (может ошибаюсь, но вроде бы тогда Гетц еще не опубликовал эту книгу; кстати, когда ее переведут?), только в переводе на ibm.com: Теория и практика Java: Более гибкая, масштабируемая блокировка в JDK 5.0. Новые классы блокировки усовершенствуют synchronized — но не спешите списывать synchronized со счетов. Кроме дополнительных возможностей, ReentrantLock выигрывает у synchronized во всех остальных отношениях (об этом Гетц четко пишет), к примеру, имеет лучшую пропускную способность в условиях активных гонок.



Из минусов ReentrantLock, пожалуй, можно привести только то, что он требует большей ответственности при программировании: не забывать unlock в блоке finally — с synchronized это делает за вас виртуальная машина. Ну а основной аргумент, почему не стоит отказываться от synchronized — это преемственность (про synchronized знает любой относительно не новичок в Java, новыми возможностями платформы интересуются в основном только профессионалы), большая функциональная поддержка со стороны виртуальной машины, ну и ожидания, что в новых версиях JVM synchronized будет улучшен. Гетц четко и говорит, цитирую:

Классы блокировки в java.util.compatible.lock — это передовой инструментарий для продвинутых пользователей и сложных ситуаций.

Ну и самое главное, претензию вашу не очень понял: выше я вовсе не утверждал, что нужно железно заменить synchronized на ReentrantLock — а только привел альтернативный вариант кода, ну и упомянул, что он в общем случае более производительный. Вроде бы нигде не соврал.

Здравствуйте, dshe, Вы писали:

D>Не думаю, что это поможет. Она ведь должна быть неизменяема внутри, а не снаружи.
Быть может, видимо, не до конца понял, чего же нужно автору.

Здравствуйте, Foror, Вы писали:

F>Вот это не не понял.
Теория и практика Java: Характеристика безопасности потока. Безопасность потока не является понятием типа "все-или-ничего":

Безопасность потока

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

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

Здравствуйте, rsn81, Вы писали:

R>...Ну и самое главное, претензию вашу не очень понял: выше я вовсе не утверждал, что нужно железно заменить synchronized на ReentrantLock — а только привел альтернативный вариант кода, ну и упомянул, что он в общем случае более производительный. Вроде бы нигде не соврал.

Мне показалось спорным утверждение о том, что ReentrantLock более производительней, чем старый добрый synchronized. Это заставило меня порыться в Интернете и я кое-что для себя выяснил. За это вам отдельное спасибо. Признаюсь, я был удивлен обнаружив подтверждения тому, что противоречило моим представлениям. Я пока не вижу принципиальных причин почему synchronized должен быть медленнее ReentrantLock (ведь в крайнем случае JVM могла бы неявно использовать RL в качестве реализации synchronized). И то, что synchronized в Java 5 работает медленнее мне кажется не более чем досадным недоразумением. Еще раз спасибо за ссылки.

Здравствуйте, dshe, Вы писали:

D>Мне показалось спорным утверждение о том, что ReentrantLock более производительней, чем старый добрый synchronized.
Угу, само появление ReentrantLock и та статья Гетца, несмотря на все увещевания и предостережения, вообще полны противоречий: казалось бы, изобрели более качественный альтернативный инструмент, а тем не менее... Мне кажется, ReentrantLock только временно выигрывает у synchronized, дорихтуют. То есть, разумеется, проектировался просто как инструмент с более широким функционалом, нежели synchronized, но раз уж получился впридачу и более быстрым (временно), ну что ж тут поделать... не замедлять же!

D>Это заставило меня порыться в Интернете и я кое-что для себя выяснил. За это вам отдельное спасибо. Признаюсь, я был удивлен обнаружив подтверждения тому, что противоречило моим представлениям. Я пока не вижу принципиальных причин почему synchronized должен быть медленнее ReentrantLock (ведь в крайнем случае JVM могла бы неявно использовать RL в качестве реализации synchronized).
Да вроде не могла бы: ReentrantLock — обычный исполняемый байт-код, а synchronized реализован на уровне виртуальной машины (зашит в язык), за счет чего на основе synchronized виртуальная машина потенциально может осуществлять некоторые манипуляции с программой (что-то Гетц там про это писал, точно не помню).

D>И то, что synchronized в Java 5 работает медленнее мне кажется не более чем досадным недоразумением. Еще раз спасибо за ссылки.
Угу, согласен. Один нюанс только: вендоров и виртуальных машин много, а JDK — один.