*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 ?
В других случаях я не очень понимаю как мы будем понимать чего нам ждать