Какова область очистки кеша, требуемая ключевым словом синхронизации Java?

Сегодня я весь день исследовал модель памяти Java, чтобы подробно понять проблемы с JMM до Java 5 и изменения, внесенные JSR-133, реализованные в Java 5.

На что я не могу найти окончательный ответ, так это на объем аннулирования и очистки кеша, необходимых для конкретной синхронизации.

Должны ли все регистры и кеши ЦП быть недействительными при входе в любую синхронизированную часть кода и все сбрасываться в основную оперативную память при выходе, или JVM разрешено аннулировать только те переменные, которые фактически читаются, и сбрасывать только те, которые фактически записаны во время синхронизированного блока кода?

Если первое, то почему JMM так педантично настаивает на том, что барьер памяти возникает только между двумя потоками, которые синхронизируются с одним и тем же объектом?

Если последнее, есть ли хороший документ, объясняющий детали того, как это достигается? (Я полагаю, что базовая реализация должна будет установить флаг «обхода кешей» на уровне ЦП в начале синхронизированного блока и очистить его в конце, но я мог найти ошибку. )


java synchronization
person Lawrence Dol    schedule 06.05.2009    source источник

Ответы (3)


arrow_upward
5
arrow_downward

Есть очень хороший технический доклад о модели памяти Java. Если вам не нравится Wideos Google 'happens before' в контексте модели памяти Java.

В основном все записи видны другим потокам, если они происходят до связи. Предположим, что поток A записывает в поле X, а поток B читает из него, поэтому это происходит до установления между записью и чтением, если:

  • х изменчив
  • запись в x была защищена той же блокировкой, что и чтение из x
  • может быть, еще немного.

Так что думаю, что второй вариант верный, как они его реализовали, я не знаю.

person jb.    schedule 11.05.2009
comment
Ссылка на техническое обсуждение не работает. Это может быть вот этот. - person Lawrence Dol; 29.04.2014

arrow_upward
1
arrow_downward

Вы должны понимать, что JMM до версии 5.0 никогда не был реализован в точности, потому что на самом деле это было невозможно.

Так что до версии 5.0 технически приходилось записывать все в разделяемую память. В 1.5 (на самом деле 1.4) это смягчено. В частности, если блокировка не может обойти поток, то JVM имеет право рассматривать ее как nop. Кроме того, разблокировка, за которой следует блокировка той же блокировки, может быть объединена, что не относится к старому JMM. Для экранированной блокировки JVM часто приходится быть пессимистичной и сбрасывать больше, чем это технически необходимо.

person Tom Hawtin - tackline    schedule 06.05.2009
comment
Спасибо, Том; но на самом деле меня в первую очередь интересует объем аннулирования и очистки кешей памяти. - person Lawrence Dol; 06.05.2009

arrow_upward
1
arrow_downward

Я предлагаю вам начать с:

person Neil Coffey    schedule 06.05.2009
comment
извините, в ссылку попал бродячий символ - сейчас исправлено - person Neil Coffey; 06.05.2009
comment
p.s. список рассылки доступен для поиска! - person Neil Coffey; 06.05.2009
comment
О, и да, что бы вы ни делали, нужно много читать, потому что это довольно сложный материал. Вот почему у вас есть JVM и программа на Java, а не на ассемблере, так что в целом вам не нужно слишком беспокоиться обо всех этих мелочах (хотя, признаюсь, я достаточно занудный, чтобы также найти это интересным). - person Neil Coffey; 06.05.2009