Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Java [игнор отключен] [закрыт для гостей] / syncronized vs volatile с точки зрения visibility / 25 сообщений из 135, страница 1 из 6
30.01.2017, 13:18
    #39394576
questioner
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
С коллегой разошлись мнения по сабжу.

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

1 точка зрения(моя)
изменения сделанные внутри syncronized блока будут гарантированно видны только в syncronized блоке по тому же монитору
2 точка зрения
по выходу из syncronized блока все изменения сделанные внутри syncronized сразу видны всем потокам.
...
Рейтинг: 0 / 0
30.01.2017, 14:25
    #39394681
no56892
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
первое
...
Рейтинг: 0 / 0
30.01.2017, 14:31
    #39394688
vimba
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
questioner,

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

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

А пункт 1 не полон для случая когда внутри синхронизированного блока вы пишете в volatile переменные:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
public class Future {

    private volatile boolean completed;
    private Object value;

    public synchronized void complete(Object value) {
         if (completed) {
              return;
         }
         this.value = value;
         this.completed = true;
    }

    public Optional<Object> getIfCompleted() {
         if (completed) {
             return Optional.of(value);
         }
         return Optional.empty();
    }

}


getIfCompleted монитор не захватает, однако в нем гарантированно будет видно value в ветке где completed = true.
...
Рейтинг: 0 / 0
30.01.2017, 14:55
    #39394727
no56892
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
авторДля JMM времени не существует
Ага, особенно happens-before.
автор А пункт 1 не полон для случая когда внутри синхронизированного блока вы пишете в volatile переменные
В данном случае synchronized/не synchronized роли не играет.
...
Рейтинг: 0 / 0
30.01.2017, 15:47
    #39394797
забыл ник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
no56892авторДля JMM времени не существует
Ага, особенно happens-before.


Все правильно сказали, для JVM понятие время неопредлено. А вот понятие ordering как раз и определяется посредством JMM, что очевидно не одно и то же
...
Рейтинг: 0 / 0
30.01.2017, 17:22
    #39394903
questioner
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
vimbaquestioner,

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

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

А пункт 1 не полон для случая когда внутри синхронизированного блока вы пишете в volatile переменные:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
public class Future {

    private volatile boolean completed;
    private Object value;

    public synchronized void complete(Object value) {
         if (completed) {
              return;
         }
         this.value = value;
         this.completed = true;
    }

    public Optional<Object> getIfCompleted() {
         if (completed) {
             return Optional.of(value);
         }
         return Optional.empty();
    }

}


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

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


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

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

Комментарий из разряда "поумничать ради поумничать"
...
Рейтинг: 0 / 0
30.01.2017, 17:32
    #39394913
questioner
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
забыл никno56892пропущено...

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


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

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

считаю фразу

авторИзменения сделанные над volatile переменной видны сразу всем потокам
корректной.
...
Рейтинг: 0 / 0
30.01.2017, 17:38
    #39394919
vimba
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
questioner...я разве где-то писал, что этого не может быть?...


Да писал, выдиляю специально жирным фрагмент твоего первого поста:
questionerизменения сделанные внутри syncronized блока будут гарантированно видны только в syncronized блоке по тому же монитору
...
Рейтинг: 0 / 0
30.01.2017, 17:39
    #39394921
vimba
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
questionerJMM определяет ордеринг, но при этом мы можем привязывать этот ордеринг и ко времени.
Нет не можете.
...
Рейтинг: 0 / 0
30.01.2017, 17:55
    #39394928
Alexey Tomin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
questionerну вот допустим , что поток 1 в 10:00:00 минут изменил значение в волатильной переменной(и больше не меняет)
в 10:00:01 другой поток прочитал это значение.

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

[quote questioner]JMM определяет ордеринг, но при этом мы можем привязывать этот ордеринг и ко времени.[quote questioner]

Нет.

questionerсчитаю фразу
авторИзменения сделанные над volatile переменной видны сразу всем потокам
корректной.
Очень зря.
...
Рейтинг: 0 / 0
30.01.2017, 18:05
    #39394937
no56892
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
забыл никno56892пропущено...

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


Все правильно сказали, для JVM понятие время неопредлено. А вот понятие ordering как раз и определяется посредством JMM, что очевидно не одно и то же
Оно там подразумевается неявно. A happens-before B означает, что (1) A физически выполняется __до__ B и (2) результаты (актуальное состояние памяти), произошедшие до A включительно видны на момент физического выполнения B. Разве __до__ это не временной термин?
...
Рейтинг: 0 / 0
30.01.2017, 18:17
    #39394944
questioner
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
vimbaquestioner...я разве где-то писал, что этого не может быть?...


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


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


я до сих пор в этом уверен. В общем случае это абсолютно верно и никак не противоречит использованию волатильных ссылок внутри.
...
Рейтинг: 0 / 0
30.01.2017, 18:20
    #39394946
questioner
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
vimbaquestionerJMM определяет ордеринг, но при этом мы можем привязывать этот ордеринг и ко времени.
Нет не можете.

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

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

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

ну типа переменная будет видна после выполнения инструкции. Выполнения инструкции имеет свойство время.
...
Рейтинг: 0 / 0
30.01.2017, 18:25
    #39394949
questioner
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
Alexey Tominquestionerну вот допустим , что поток 1 в 10:00:00 минут изменил значение в волатильной переменной(и больше не меняет)
в 10:00:01 другой поток прочитал это значение.

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



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

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

опять же у момента записи есть свойство - время, соответственно, транзитивно верно сказать, что после времени записи волатильной переменной любые потоки увидят это обновление.
...
Рейтинг: 0 / 0
30.01.2017, 18:29
    #39394951
Blazkowicz
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
Тут по-моему и бeз JMM всё очевидно.

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

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

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

Нет, не будут. У каждого потока свой кэш, если один поток в synchronized блоке обновил значение в основной памяти, это ещё не значит что другой поток будет читать это значение не из своего кэша. Если к полю доступ только внутри synchronized, то volatile не обязателен. Если поле видно и в не synchronized секциях, то без volatile можно вычитать значение кэша, а не main memory.
...
Рейтинг: 0 / 0
30.01.2017, 18:29
    #39394952
vimba
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
questionerпфф и что тут не так?

Я же уже показал пример, который опровергает обязательность захвата монитора для определенных краегульных случаев. Вы или мой пример опровергните, либо согласитесь что категоричность заявлений только в вашем первом посте была неуместной.
...
Рейтинг: 0 / 0
30.01.2017, 18:33
    #39394955
questioner
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
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

а последний абзац хорош!
...
Рейтинг: 0 / 0
30.01.2017, 18:38
    #39394958
questioner
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
vimbaquestionerпфф и что тут не так?

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

jmm даёт гарантии, то есть как минимум. я не говорю, что ничего другого не будет, я говорю, что при отсутствии каких-то дополнительных условий, которые могут быть можно гарантировать как минимум это.
...
Рейтинг: 0 / 0
30.01.2017, 18:39
    #39394960
questioner
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
BlazkowiczНет, не будут. У каждого потока свой кэш, если один поток в synchronized блоке обновил значение в основной памяти, это ещё не значит что другой поток будет читать это значение не из своего кэша. Если к полю доступ только внутри synchronized, то volatile не обязателен. Если поле видно и в не synchronized секциях, то без volatile можно вычитать значение кэша, а не main memory.

Кстати если следовать этой теории, то при входе в synchronized секцию получается кеш потока обновляется из основной памяти?
...
Рейтинг: 0 / 0
30.01.2017, 18:41
    #39394961
vimba
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
questioner,

Имеете в виду Вы может быть и что-то своё, но уже несколько человек в этом топике поняло Вас именно так как Вы написали.
...
Рейтинг: 0 / 0
30.01.2017, 18:42
    #39394962
questioner
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
vimbaquestionerпфф и что тут не так?

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

Если я на фотографии вдалеке вижу силует человека, то я могу гарантировать только то, что это человек, могу гарантировать, что он ест еду и не могу гарантировать, что он может рожать
...
Рейтинг: 0 / 0
30.01.2017, 18:45
    #39394964
vimba
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
questionerКстати если следовать этой теории, то при входе в synchronized секцию получается кеш потока обновляется из основной памяти?
Забудте о кешах и о времени, JMM специально Вам дана, чтобы Вы об этих двух понятиях программируя, многопоточный код на java никогда не думали.
...
Рейтинг: 0 / 0
30.01.2017, 18:51
    #39394967
Blazkowicz
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
questionerа не будут видны по другому монитору ибо нет такого happens before. http://stackoverflow.com/a/23961401/2674303

Ну, да. Верно. Кэш не единственный способ увидеть другое значение.
...
Рейтинг: 0 / 0
30.01.2017, 18:53
    #39394968
questioner
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
Blazkowiczquestionerа не будут видны по другому монитору ибо нет такого happens before. http://stackoverflow.com/a/23961401/2674303

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

а можно отсюда поподробнее?
...
Рейтинг: 0 / 0
30.01.2017, 18:55
    #39394969
questioner
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
syncronized vs volatile с точки зрения visibility
vimbaquestionerКстати если следовать этой теории, то при входе в synchronized секцию получается кеш потока обновляется из основной памяти?
Забудте о кешах и о времени, JMM специально Вам дана, чтобы Вы об этих двух понятиях программируя, многопоточный код на java никогда не думали.
Где вам почудилось время то я не могу понять в первом посте?

время задаёт ордеринг? да,задаёт(ну кроме lip second). По-моему, очевидно.
...
Рейтинг: 0 / 0
Форумы / Java [игнор отключен] [закрыт для гостей] / syncronized vs volatile с точки зрения visibility / 25 сообщений из 135, страница 1 из 6
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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