powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Java [игнор отключен] [закрыт для гостей] / syncronized vs volatile с точки зрения visibility
25 сообщений из 135, страница 5 из 6
syncronized vs volatile с точки зрения visibility
    #39395721
no56892
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey Tomin,
Они никуда не утрачены, ссылка на объект в памяти не изменится.
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39395726
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
no56892Alexey Tominпропущено...
"Я не могу придумать, как процессор это сделает"- никак не аргумент.
В таком случае покажите как когерентность кэшэй не допустит случая, который я описал.

Тут вопрос о чём мы говорим.
"Засыпание и просыпание" не ломает hb - тут есть некоторые гарантии OS (я тоже этот вариант придумал, но на joker'е сказали, что "да без этого и single-thread работать не будет ия согласен).
Другое дело, что искать как сломается работа- это неправильный путь. Гарантий нет- значит может быть что угодна. А как оно может быть- вопрос забавный- очень подходит для разговора под пивко , но к JMM отношения не имеющий.
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39395730
no56892
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey Tominno56892пропущено...

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

Тут вопрос о чём мы говорим.
"Засыпание и просыпание" не ломает hb - тут есть некоторые гарантии OS (я тоже этот вариант придумал, но на joker'е сказали, что "да без этого и single-thread работать не будет ия согласен).
Другое дело, что искать как сломается работа- это неправильный путь. Гарантий нет- значит может быть что угодна. А как оно может быть- вопрос забавный- очень подходит для разговора под пивко , но к JMM отношения не имеющий.
Так я же говорю про случай где как раз таки нет happens before. То, что не ломает hb это ясно, вопрос в том, когда его нету. Вполне логично было бы предположить, что чтение происходит из разных кэшэй, а разные кэши - разные ядра. Ну да ладно, меня такой вариант развития событий устраивает для обоснования такого чуда)))
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39395735
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
no56892В таком случае покажите как когерентность кэшэй не допустит случая, который я описал.Первоначально линии логических схем могли находится только в двух состояниях и, типично, объединялись по схеме монтажного или.
Затем добавилось третье (высокимпедансное) состояние, в котором отключенная линия не влияла на сигналы, выдаваемые другими линиями.
Затем добавилась возможность чтения уровней шины линией, находящейся в третьем состоянии.

У кэша есть два основных режима работы - сквозная запись (write-through) и отложенная запись (write-back). Режим по умолчанию - сквозная запись, при которой на шину выдаются адреса, по которым идут обращения.
Процессоры (ядра) умеют считывать (snooping) эти адреса и, если режим обращения указывает на запись - процессор (ядро) пометит соответствующую строку в своём кэше как невалидную. Если найдёт, конечно.
Дальше, вроде бы, всё очевидно.
И это я ещё не упомянул ни явные команды инвалидации кэша (i486+) ни всяческих "барьеров памяти" (просто знаю, что есть).
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39395736
Фотография Usman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Usmanno56892
Код: java
1.
atomicInteger

cheat
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39395743
no56892
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Usman,
Дак это же наиобычнейший happens-before, там много как его можно заиметь помимо volatile и synchronized. Java SE API -> java.util.concurrent вниз прокрутить справа там все очень емко расписано.
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39395748
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey TominЕсть. Она гарантирует hb.Это гарантирует JMM. И это - дополнительная гарантия сверх базовой.Как оно будет обеспечено- вопрос другой.Другой. И неважный.Надо понимать, что до второго процессора записанное значение всё одно дойдёт нескоро.Скоро или нескоро влияет только на цену happens-before.
Собственно, процессору совершенно необязательно записать значение в основную память - более чем достаточно начать специальный цикл на шине, "увидев" который "потенциально заинтересованные" "замрут в ожидании".
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39395768
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovСобственно, процессору совершенно необязательно записать значение в основную память - более чем достаточно начать специальный цикл на шине, "увидев" который "потенциально заинтересованные" "замрут в ожидании".

Всё одно- блокировка не может дойти сразу. Вопрос только в размере задержки.
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39395772
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey TominВсё одно- блокировка не может дойти сразу.Не согласен - если блокировка критична, то сначала делаются подготовительные приседания и только потом подаётся основное блюдо.
Т.е. процессор должен сначала оповестить "я меняю этот адрес" и только потом начать записывать новое значение.

P.S. Нет, я, конечно, не знаю как оно в реальности работает ...
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39395781
Фотография Usman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
no56892Дак это же наиобычнейший happens-beforeопять же, который достигается за счет volatile
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39395811
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Usmanno56892Дак это же наиобычнейший happens-beforeопять же, который достигается за счет volatile

но без пары с synchronized
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39395827
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovAlexey TominВсё одно- блокировка не может дойти сразу.Не согласен - если блокировка критична, то сначала делаются подготовительные приседания и только потом подаётся основное блюдо.
Т.е. процессор должен сначала оповестить "я меняю этот адрес" и только потом начать записывать новое значение.

P.S. Нет, я, конечно, не знаю как оно в реальности работает ...

Наверное.
Т.е. возможно, что "сразу после" присвоения volatile-переменной в другом потоке прочитается новое значние.
И я ошибся- оно не может прочитать более старое значение.

Но суть-то не в этом. Не надо сравнивать моменты времени. Это лишнее.
Просто операции с volatile объектами всегда можно выстроить в порядок, причём он одинаковый для всех читателей. Введения понятия времени только запутывает дело. Есть "раньше-позже" для конкретных операций, а время тут лишнее. Я вот запутался в них :)
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39395901
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Alexey TominПошла работа- ждём очередь записи, обновляем сквозь все три уровня кэша строчку- это сотни тактов. Сотни!
Кто сказал, что соседний процессор замер в предвкушении? Нет, конечно. Он жуёт свои кэши (инвалиадировать кэшлайн пока данные не в ОЗУ нельзя, а то опять фигня прочитается). Когда запись из первого пройдёт- ему прилетит инвализация строки кэша. Да, тут он остановится и начнёт перечитывать строку кэша. Но "сразу" уже давно прошло

Ну так говорится же, что сразу после окончания записи данные будут видны всем потокам. После, видимо, всех этих сотен тактов.

Запись длительная операция, возможно даже синхронная (ну как вариант). Противоречий не вижу.
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39395918
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
questioner
Ну так говорится же, что сразу после окончания записи данные будут видны всем потокам. После, видимо, всех этих сотен тактов.

Запись длительная операция, возможно даже синхронная (ну как вариант). Противоречий не вижу.

Вот тут очень долго это все обсуждали, в итоге пришли к тому, что ситуация когда поток так и не увидит запись волатильной переменной другого потока НЕ ПРОТИВОРЕЧИТ JMM. С оговоркой что в реальности такой кейс представить сложно.
http://cs.oswego.edu/pipermail/concurrency-interest/2012-August/009816.html
http://stackoverflow.com/questions/11761552/detailed-semantics-of-volatile-regarding-timeliness-of-visibility
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39395961
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
questionerНу так говорится же, что сразу после окончания записи данные будут видны всем потокам. После, видимо, всех этих сотен тактов.
Запись длительная операция, возможно даже синхронная (ну как вариант). Противоречий не вижу.

По сути, вопрос времени только запутывает.
Просто для другого потока "сразу" наступает в какой-то отложенный момент. В какой- вопрос интересный, НО не описанный никак в JMM (я вчера много чего там прочитал).
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39396012
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
questionerВ вашем примере, да, реордеринг может случиться и другой поток может увидеть нечто вгоняющее в ступор, но это особенность JMM. Я лишь говорю, что время это АТТРИБУТ события(1). любое, любое другое событие после события(1) будет иметь время, большее, чем у события(2), а меньшее, меньше, чем у события(1).
Скорее шкала.
Но дело в том, что если в потоке А произошли события 1 и 2, то в другом потоке они не произошли, а соответственно нет возможности понять какое было раньше какое позже.
Поэтому придумали способ - синхронизацию. В какой-то момент времени поток Б гарантированно узнает, что события 1 и 2 произошли. Поскольку он так же може подглядывать в память доступную потоку А, то и до этого по результатам подглядывания он может догадаться о том какое из событий произошло. Но смотрит он через произвольную нарезку кадров (что-то из того что он считал из памяти актуально, а что-то как лежало в его кеше от начала времен, так и лежит). Поэтому у него инет гарантий до точки синхронизации в его шкале времени в что произошло в соседнем потоке, а что нет.
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39396030
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
questionerвнутри synchronized (Something.class) мы же всегда увидим корректное значение?

Вопрос не в том, что ты увидишь внутри .
Положим туда попал поток А. То (1) захватываем монитор (делаем грань h-b) (2)проверяем на null если да (3)создаем один экземпляр класса, (4)ссылку на него записываем по адресу instance (5) выходим из монитора и создаем (h-b грань).

Вопрос в том, что ты увидишь снаружи. Если поток B прочел память в которую попал объект Somthing() где-то между моментами 1 и 5, а потом прочел этот адрес, то для него действует грань h-b момента 1 - а там before ничего не было, т.е. может пользоваться состоянием кеша на этот момент (не совсем так, частично в ходе инициализации new Somthing() будет еще одна грань, но она до конструктора). Необходимо, чтобы момент окончания конструктора попал за грань, после которой будет чтение адреса.
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39396036
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovВот чтобы были (хотя бы) два реальных процессора, которые не связаны ничем, кроме общей памяти шины адресов и данных которой разделяются между внешними железками.
И не на TSO архитектуре.
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39396038
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сергей Арсеньевquestionerвнутри synchronized (Something.class) мы же всегда увидим корректное значение?

Вопрос не в том, что ты увидишь внутри .
Положим туда попал поток А. То (1) захватываем монитор (делаем грань h-b) (2)проверяем на null если да (3)создаем один экземпляр класса, (4)ссылку на него записываем по адресу instance (5) выходим из монитора и создаем (h-b грань).

Вопрос в том, что ты увидишь снаружи. Если поток B прочел память в которую попал объект Somthing() где-то между моментами 1 и 5, а потом прочел этот адрес, то для него действует грань h-b момента 1 - а там before ничего не было, т.е. может пользоваться состоянием кеша на этот момент (не совсем так, частично в ходе инициализации new Somthing() будет еще одна грань, но она до конструктора). Необходимо, чтобы момент окончания конструктора попал за грань, после которой будет чтение адреса.

Как я понял всё это сводится к тому, что если даже мы увидили не в synchronized секции новое значение, то нет гарантии, что при повторном чтении без acquire мы вновь увидим его же. Просто это кажется интуитивно понятным, но вот, к сожалению, не работает.
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39396050
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
questionerКак я понял всё это сводится к тому, что если даже мы увидили не в synchronized секции новое значение,
Не в повторном чтении, а в другом чтении. Там нет гарантии, что если ты увидел адрес объекта, то он полностью создан. Другими словами, если в нем есть некоторое поле, которое программа гарантированно считает не null, ибо конструктор его таким делает, то ты можешь увидеть его null или поле x будет установлено, а поле y еще нет и т.п.
Потому что нужна гарантия на то, что конструктор до чтения ссылки. А для этого нужна гарантия конструктор до записи ссылки.
На x86 все более менее просто. На других архитектурах jvm приходится плясать ужом и операция получается не такой простой.
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39396058
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сергей АрсеньевНе в повторном чтении, а в другом чтении.
А в чем разница между терминами?

Сергей АрсеньевТам нет гарантии, что если ты увидел адрес объекта, то он полностью создан. Другими словами, если в нем есть некоторое поле, которое программа гарантированно считает не null, ибо конструктор его таким делает, то ты можешь увидеть его null или поле x будет установлено, а поле y еще нет и т.п.
Потому что нужна гарантия на то, что конструктор до чтения ссылки. А для этого нужна гарантия конструктор до записи ссылки.
На x86 все более менее просто. На других архитектурах jvm приходится плясать ужом и операция получается не такой простой.

Тут по-момему глаголов не хватает. я не понял, что Вы имеете виду.

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
public class Something {
    private static Something instance = null;
    public static Something getInstance() {      
        if (this.instance == null) {//  AAA
            synchronized (Something.class) {
                if (this.instance == null)
                    this.instance = new Something();               
            }
        }        
        return this.instance ;// BBB
    }
}


Если конкретно, то если в AAA увидели не null, то при повторном чтении в BBB ссылки из this.instance может быть даже null
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39396240
Common Lisp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Common LispAlexey TominЯ хочу сказать, что НИГДЕ нет гарантий, что в точке 2 будет снова прочитан не null.Что-то мне кажется, что у вас паранойя.

JMM подробно пока не читал, знаком с C++11 memory model, которая выглядит более мозговывернутой, чем JMM. Так вот, если значение в одном потоке может смениться с null на не-null и другой поток увидел не-null, то старое значение — null — он уже никогда не увидит.Ладно, я, видимо, не прав. Это гарантируется только для атомиков.
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39397069
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
questionerСергей АрсеньевНе в повторном чтении, а в другом чтении.
А в чем разница между терминами?

повторное чтение это чтение того же самого еще раз.
А другое это чтение чего-то другого.
Грубо говоря чтение ссылки в цикле и чтение того на что указывает ссылка.
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39397075
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
questionerЕсли конкретно, то если в AAA увидели не null, то при повторном чтении в BBB ссылки из this.instance может быть даже null
Ну типа ААА выполнялось на процессоре 1, потом бац перелетели на процессор 2, кеш никто не сбросил и опана мы в BBB с null в кеше?
...
Рейтинг: 0 / 0
syncronized vs volatile с точки зрения visibility
    #39397078
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А вот то, что BBB вернет ссылку на объект все конструкторы которого не отработали до конца это вполне.
...
Рейтинг: 0 / 0
25 сообщений из 135, страница 5 из 6
Форумы / Java [игнор отключен] [закрыт для гостей] / syncronized vs volatile с точки зрения visibility
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]