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

тут мы сходимся:
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). По-моему, очевидно.

*leap

vimbaquestionerпропущено...

Где вам почудилось время то я не могу понять в первом посте?

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

questionerвремя задаёт ордеринг?

И здесь то же самое, у Вас потрясающая способность писать двусмысленные фразы, я лично не понимаю даже из контекста кто-кого задаёт.

время - подлежащее
задаёт - сказуемое
ордеринг - дополнение

vimbaquestioner,

Ну и какой порядок задает время? Happens-befor order или Synchronized-with order, или оба сразу?

время задаёт обычный человеческий порядок.

happens-before задаёт правила порядка выполнения кода и видимости. Порядок это значит до или после, то бишь одно раньше/после другого. Но это пограничное событие, которое определяет ребро, оно всё равно в какой-то момент времени происходит. То есть время это аттрибут нашего события. И в обычном мире событие, которое происходит после имеет время большее, нежели у этого события, задающее ребро.


а вот кстати про Synchronized-with order не слышал. Объясните недвусмысленно?

Сергей АрсеньевСкорее вопрос. Вы так еще по прошлому не поняли, что означает happens before.
почему не понял?
Сергей АрсеньевЭто всего лишь гарантированная точка синхронизации, говорящая, что если видно, что было на момент точки видно и то, что было до того.
Хитро закрученная фраза, несколько раз перечитал с попыткой расставить паузы по разному, не помогло.


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

Сергей Арсеньевquestionerвремя задаёт ордеринг? да,задаёт(ну кроме lip second). По-моему, очевидно.
Очевидное очень часто ложно. В данном случае определенно.
Порядок задает исходный код программы. А до или после решает jvm по ходу пьесы.
Другими словами


JMM разрешает сделать jvm и сначала инкремент, затем увеличение на два.И сначала увеличение на два, а затем инкремент. И даже сразу присвоение тройки.Но требует, чтобы к моменту работы с потоком эти операции были сделаны полностью.

Вы всё в кучу смешали. я не говорю, что всё, что очевидно это правда. В вашем примере, да, реордеринг может случиться и другой поток может увидеть нечто вгоняющее в ступор, но это особенность JMM. Я лишь говорю, что время это АТТРИБУТ события(1). любое, любое другое событие после события(1) будет иметь время, большее, чем у события(2), а меньшее, меньше, чем у события(1).

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

Что угодно. JMM это список гарантий. Не более. Все попытки придумать "как это делано"- это пустая трата времени (более того, это запутывает). Волатильность гарантирует только две вещи- атомарность и то, что чтение видит всё то, что было сделано до (в том же потоке) той записи, которую это чтение видит.
Никаких гарантий, какую запись увидит чтение нет. Вообще никаких. Сброс кэшей и т.п.- это только чьи-то фантазии. Если в JDK 1.8.101 сделано так, то в 1.8.111 может всё быть уже по-другому. Если что-то выпоняется на intel core i7, то на ARM может быть всё другое. А арендовав машину в облаке можно получить что угодно.

Нет уж давайте конкретно. что значит "дойдёт"?
Про атомарность это Вы про long и double ?
Alexey Tominчтение видит всё то, что было сделано до (в том же потоке) той записи, которую это чтение видит.
Для видимости внутри одного потока у нас и так есть гарантии(happens before) по JMM. Никакой volatile тут не при делах.

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

Откуда, ну откуда Вы это взяли? Никто и нигде такого не обещал.
А как же ж нет то? давайте посмотрим на любой код, который работает с volatile, а без него не гарантированно.


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

Такое обязательство (наличие момента времени для каждой операции) снизило бы производительность многоядерной системы на несколько порядков. Поэтому "у момента записи есть свойство - время" - неправда. Чем быстрее Вы это поймёте- тем быстрее поймёте JMM и вообще разработку в многопроцессорной среде.

Вся JMM построена на понятии частичного порядка. По сути "если мы видим вот эту запись, то мы видим и вот эти операции точно, а вот эти- может быть". Всё. Забудьте (до понимания главного) про кэши, инвалидацию, реордеригн, спекулятивное исполнение (да, оно тоже может подгадить тому, кто пытается строить код на "понимании работы процессора").

Это похоже на side effect volatile. А как по вашему мы должны определять увидели мы изменение или нет? в коде может как-то?

BlazkowiczAlexey TominВсё. Забудьте (до понимания главного) про кэши, инвалидацию, реордеригн, спекулятивное исполнение (да, оно тоже может подгадить тому, кто пытается строить код на "понимании работы процессора").
То что оно не пригодится на практике, вообще никак не значит что про это нужно забывать. Полезно понимать природу вещей, а не абстрактные аксиомы. Для понимания нужно знать как всё работает. JMM нужна совершенно для другого - она даёт доказательных механизм корректности работы кода.

Расскажите пожалуйста про то, что случается при входе в критическую секцию с кешами. Я такого не встречал пока что.

Alexey Tominquestionerпропущено...


Расскажите пожалуйста про то, что случается при входе в критическую секцию с кешами. Я такого не встречал пока что.

Зависит от процессора. Это главное, что надо знать.

я спросил, что случится, получил ответ, что главное, это надо знать. Что знать то надо?

Alexey TominquestionerНет уж давайте конкретно. что значит "дойдёт"?

Значит, что второй поток увидит значение, заданное в другом потоке.
Через сколько тактов процессора второй поток увидит изменения, сделанные первым- точно неизвестно.

questionerПро атомарность это Вы про long и double ?

Да, хотя для intel это не актуально, но может стрельнуть на каком-нибудь ARM.

questionerпропущено...

Для видимости внутри одного потока у нас и так есть гарантии(happens before) по JMM. Никакой volatile тут не при делах.

Да, я неудачно выразился.
Если в потоке 1 поменяли значения волательной переменной и в потоке 2 мы это увидели, то мы увидим (во втором потоке) так же все изменения, сделанные в 1м потоке до (внутри одного потока допустимо говорить о порядке) изменения волатильной переменной.
Но надо понимать, что можем увидеть и ЕЩЁ какие-то изменения ;)

questionerпропущено...

А как же ж нет то? давайте посмотрим на любой код, который работает с volatile, а без него не гарантированно.

Не путайте "обычно так" и "гарантировано". В этом и проблема, что код с ошибкой работает в 99.9% случаев. Т.е. у заказчика бага будет, а воспроизвести- фиг.

questionerЭто похоже на side effect volatile. А как по вашему мы должны определять увидели мы изменение или нет? в коде может как-то?

А волатильные переменные и служат флагами.
Мы просто ждём, пока увидим изменения.

так мы можем долго разбираться, давайте Вы приведете пример с volatile, где мы увидим, что изменение не гарантировано и обсудим действительно ли оно не гарантировано. И как этот флаг будет использоваться.

Зачем мне, разработчику на java, задумываться о тактах процессора? сброс кешей хоть упрощает понимание происходящего, а такты то мне зачем?

ну и значит ли Ваша фраза про флаги, что есть смысл только в boolean volatile ?
В других случаях я не очень понимаю как мы будем понимать чего нам ждать

Alexey Tominquestionerтак мы можем долго разбираться, давайте Вы приведете пример с volatile, где мы увидим, что изменение не гарантировано и обсудим действительно ли оно не гарантировано. И как этот флаг будет использоваться.

Отсутствие гарантий нельзя проверить. Ещё раз- при любом эксперементе, скорее всего, Вы проблем не увидете. Они вдруг случатся в продакшене.

questionerЗачем мне, разработчику на java, задумываться о тактах процессора? сброс кешей хоть упрощает понимание происходящего, а такты то мне зачем?

И не надо. Есть гарантии JMM - это всё, что надо знать.


questionerну и значит ли Ваша фраза про флаги, что есть смысл только в boolean volatile ?
В других случаях я не очень понимаю как мы будем понимать чего нам ждать

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

Я понимаю, что эксперимент приведет к провалу, но давайте таки посмотрим на код и умозрительно оценим с точки зрения наших знаний и HB.

Без конкретики тяжело говорить.

----------------------------------------------

Кстати по поводу DCL и входа в synchronized секцию:




внутри synchronized (Something.class) мы же всегда увидим корректное значение?

То есть то, что DCL без volatile не работает это всего лишь то, что нам придётся захватывать лишний раз монитор и выигрыша в производительности(ради чего и придумана была эта идея) мы не получим, но при этом второй экземпляр синглтона создать нам таки не получится? то есть код thread-safe, но просто тормозной. Я просто под сломанностью понимал другое до этого.

no56892В данном случае все ОК, за исключением того, что в случае с volatile некоторые потоки, могли бы увидеть ссылку уже в первой строке, а здесь вынуждены будут заходить в synchronized. Хотя я читал, что без volatile это не работает типо, я так и не увидел никаких доводов - то, что instance не синхронизирована - ну будет null во втором потоке, когда уже в памяти не null, ну зайдем в synchronized и все.

Вот и у меня такие мысли, то есть синглтон работает, но, вероятно, не эффективно, но прям в каждой статье об этом столько ненависти к этому коду и что мол это "очевидно" не будет работать)

Вот если ссылка не идиножды меняется, то да, тогда очевидно, что будет бяка.