С коллегой разошлись мнения по сабжу.

тут мы сходимся:
volatile:
Изменения сделанные над volatile переменной видны сразу всем потокам

1 точка зрения(моя)
изменения сделанные внутри syncronized блока будут гарантированно видны только в syncronized блоке по тому же монитору
2 точка зрения
по выходу из syncronized блока все изменения сделанные внутри syncronized сразу видны всем потокам.

vimbaquestioner,

Для JMM времени не существует. Вот это неправильное рассуждение
questionerИзменения сделанные над volatile переменной видны сразу всем потокам

JMM вам такого не обещает, она всего лишь говорит, что если поток T2 видит изменение в волатольной переменной X сделанное потоком T1, то T2 также увидит и все остальные изменения сделанные T1 предшествующие записи в X. Но вот про время которое должно пройти, прежде чем T2 увидит запись в X вообщее ничего не говорится. Соответсвенно пункт 2 ошибочен по тем же причинам,

А пункт 1 не полон для случая когда внутри синхронизированного блока вы пишете в volatile переменные:


getIfCompleted монитор не захватает, однако в нем гарантированно будет видно value в ветке где completed = true.

а вы где увидели, что я про время говорю?


vimba getIfCompleted монитор не захватает, однако в нем гарантированно будет видно value в ветке где completed = true

ну много разных happens-before бывает. Что конкретно хотите этим показать?
я разве где-то писал, что этого не может быть? я всего лишь написал, что есть гарантия, что если мы вышли из блока syncronized, то потом при входе в секцию по тому же монитору мы гарантированно увидим изменения в блоке из которого вышли.

Комментарий из разряда "поумничать ради поумничать"

забыл никno56892пропущено...

Ага, особенно happens-before.


Все правильно сказали, для JVM понятие время неопредлено. А вот понятие ordering как раз и определяется посредством JMM, что очевидно не одно и то же

ну вот допустим , что поток 1 в 10:00:00 минут изменил значение в волатильной переменной(и больше не меняет)
в 10:00:01 другой поток прочитал это значение. и естественно оно для него выглядит актуально. И любой момент времени после 10:00:00 любой поток увидит актуальное значение гарантированно.
в 10:00:05 он увидит такое же значение. JMM определяет ордеринг, но при этом мы можем привязывать этот ордеринг и ко времени.

считаю фразу

авторИзменения сделанные над volatile переменной видны сразу всем потокам
корректной.

vimbaquestioner...я разве где-то писал, что этого не может быть?...


Да писал, выдиляю специально жирным фрагмент твоего первого поста:
questionerизменения сделанные внутри syncronized блока будут гарантированно видны только в syncronized блоке по тому же монитору


пфф и что тут не так?


я до сих пор в этом уверен. В общем случае это абсолютно верно и никак не противоречит использованию волатильных ссылок внутри.

vimbaquestionerJMM определяет ордеринг, но при этом мы можем привязывать этот ордеринг и ко времени.
Нет не можете.

а время как-бы ордеринг не устанавливает?

Когда на билете куда либо пишут, что посадка начинается с какого-то времени. Это ли не ордеринг?

просто время делится на фрагменты, которые нам интересны.

ну типа переменная будет видна после выполнения инструкции. Выполнения инструкции имеет свойство время.

Alexey Tominquestionerну вот допустим , что поток 1 в 10:00:00 минут изменил значение в волатильной переменной(и больше не меняет)
в 10:00:01 другой поток прочитал это значение.

Либо ЛЮБОЕ ДРУГОЕ, сделанное ранее.
гарантия в другое- если второй поток прочитает записанное в 10:00:00 значение, то он прочитает МИНИМУМ всё то, что было выполнено в этом потоке до (в порядке написанного кода) присвоения переменной.
А когда до жирафа второго потока дойдёт значение, записанного в первом- в мире многопроцессорных машин с NUMA-архитектурой неизвестно. И пытаться угадать- это прямая дорога в АДЪ.



а что значит дойдёт? что вы под этим подразумеваете?

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

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

BlazkowiczТут по-моему и бeз JMM всё очевидно.

questionerизменения сделанные внутри syncronized блока будут гарантированно видны только в syncronized блоке по тому же монитору

А почему не будут видны по "другому монитору"?

questionerпо выходу из syncronized блока все изменения сделанные внутри syncronized сразу видны всем потокам.
synchronized через ch пишеться, если что.

Нет, не будут. У каждого потока свой кэш, если один поток в synchronized блоке обновил значение в основной памяти, это ещё не значит что другой поток будет читать это значение не из своего кэша. Если к полю доступ только внутри synchronized, то volatile не обязателен. Если поле видно и в не synchronized секциях, то без volatile можно вычитать значение кэша, а не main memory.

Прошу прощения за ошибку)

а не будут видны по другому монитору ибо нет такого happens before. http://stackoverflow.com/a/23961401/2674303

а последний абзац хорош!

vimbaquestionerпфф и что тут не так?

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

jmm даёт гарантии, то есть как минимум. я не говорю, что ничего другого не будет, я говорю, что при отсутствии каких-то дополнительных условий, которые могут быть можно гарантировать как минимум это.

BlazkowiczНет, не будут. У каждого потока свой кэш, если один поток в synchronized блоке обновил значение в основной памяти, это ещё не значит что другой поток будет читать это значение не из своего кэша. Если к полю доступ только внутри synchronized, то volatile не обязателен. Если поле видно и в не synchronized секциях, то без volatile можно вычитать значение кэша, а не main memory.

Кстати если следовать этой теории, то при входе в synchronized секцию получается кеш потока обновляется из основной памяти?

vimbaquestionerпфф и что тут не так?

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

Если я на фотографии вдалеке вижу силует человека, то я могу гарантировать только то, что это человек, могу гарантировать, что он ест еду и не могу гарантировать, что он может рожать

Blazkowiczquestionerа не будут видны по другому монитору ибо нет такого happens before. http://stackoverflow.com/a/23961401/2674303

Ну, да. Верно. Кэш не единственный способ увидеть другое значение.

а можно отсюда поподробнее?

vimbaquestionerКстати если следовать этой теории, то при входе в synchronized секцию получается кеш потока обновляется из основной памяти?
Забудте о кешах и о времени, JMM специально Вам дана, чтобы Вы об этих двух понятиях программируя, многопоточный код на java никогда не думали.
Где вам почудилось время то я не могу понять в первом посте?

время задаёт ордеринг? да,задаёт(ну кроме lip second). По-моему, очевидно.