Можем ли мы использовать изменчивую запись исключительно для обеспечения согласованности кеша?

Я столкнулся со следующим утверждением: «Чтение или запись в изменчивую переменную накладывает барьер памяти, при котором весь кеш очищается / становится недействительным».

Теперь рассмотрим следующий сценарий выполнения:

начальный volatile boolean barrier;
начальный int b = 0;

поток 1 b = 1; // write1
поток 1 barrier = true; // write2
поток 2 barrier = true; // write3
поток 2 print(b); // r1

Вопрос: гарантированно ли поток 2 напечатает 1?

Основываясь на заявлении, я бы ответил утвердительно: поток 1 очищает свой кеш на write2 (так, чтобы b = 1 попал в основную память), а поток 2 аннулирует свой кеш на write3 (так что он будет читать b из основной памяти).

Однако в соответствующем Разделы JLS Я не могу найти гарантии для такого поведения, поскольку write3 - это запись, а не чтение. Таким образом, следующий, казалось бы, важный пункт не применяется:

Запись в изменчивую переменную v (§8.3.1.4) синхронизируется со всеми последующими чтениями v любым потоком (где «последующие» определены в соответствии с порядком синхронизации).

Есть ли какая-то другая информация, которую мне не хватает, или я что-то неправильно понимаю?

(Актуальные вопросы:


java concurrency volatile memory keyword
person Roy    schedule 13.01.2015    source источник
comment
Как вы можете гарантировать, что write3 в потоке 2 произойдет после write1 в потоке 1? Если вы можете гарантировать, что записи происходят в этом порядке, тогда, я думаю, b == 1 будет отображаться в потоке 2.   -  person jepio    schedule 14.01.2015
comment
@jepio: Я не хотел ничего гарантировать - просто описал возможный сценарий исполнения. В таком случае, не сможет ли поток 2 прочитать кэшированное / устаревшее значение для b?   -  person Roy    schedule 14.01.2015

Ответы (2)


arrow_upward
0
arrow_downward

Я думаю, вы выделили неправильное слово во фразе, которую вы процитировали (я имею в виду, тот факт, что она синхронизируется с чтениями, далеко не главная проблема здесь): «Запись в изменчивую переменную v (§8.3.1.4) синхронизирует- со всеми последующими прочтениями из v любым потоком ". Обратите внимание, что он вообще ничего не говорит о чтении других переменных. Насколько вам известно, версия b Thread-1 все еще может находиться в реестре.

person Dima    schedule 14.01.2015
comment
Насколько вам известно, версия b для Thread-1 все еще может находиться в реестре. Будет ли это противоречить утверждению, которым я начал свой вопрос, учитывая исполнение? - person Roy; 14.01.2015

arrow_upward
0
arrow_downward

Рассуждение о нестабильности с точки зрения очистки / недействительности кеша приведет к еще большей путанице и не дает полной картины.

Запись в изменчивую переменную v (§8.3.1.4) синхронизируется со всеми последующими чтениями v любым потоком (где «последующие» определены в соответствии с порядком синхронизации).

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

т.е. небольшое изменение кода операции

thread 1 b = 1; // write1
thread 1 barrier = true; // write2
thread 2 while(!barrier) // read barrier
thread 2 print(b); // r1

теперь гарантировано напечатать b как 1.

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

Если вам нужно увидеть нестабильность с точки зрения барьера, обратитесь к http://gee.cs.oswego.edu/dl/jmm/cookbook.html.

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

    as volatile read -> loadload 
       volatile wtire - > storeStore|loadStore  
before write and StoreLoad after write.

здесь loadload означает обработку недействительной очереди перед чтением следующего значения, что гарантирует чтение более поздних значений. StoreStore означает очистку буфера хранилища перед записью следующего значения.

http://gee.cs.oswego.edu/dl/jmm/cookbook.html. http://www.puppetmastertrading.com/images/hwViewForSwHackers.pdf

person veritas    schedule 19.01.2015