Влияние на видимость памяти, если один поток запланирован на несколько ядер - PullRequest
4 голосов
/ 02 июня 2019

Этот вопрос конкретно о JVM и гарантиях видимости памяти

Предположим, что у меня есть поток t1, который обращается к переменной в куче, скажем x

Предположим, что поток запланирован для выполнения в ядре c1 и изменил x в регистрах (после выборки из ОЗУ) & x должен быть перемещен из регистров, потому что t1 необходимо выполнить еще немного инструкции, требующие загрузки дополнительных данных в регистры. Таким образом, x находится в кэше c1 вместо регистров

Теперь ОС планирует другой поток t2 в c1, поэтому регистры процессора заполнены новыми данными, но у нас все еще есть емкость в кеше для x (фактически, я имею в виду, что кэш может не были сброшены в RAM / L3. Это мое предположение, я не уверен, так ли это на самом деле)

Через некоторое время ОС запланирует исходный поток t1 на новом ядре c2. Требуется ли по-прежнему t1 видеть последнее значение x в кэше c1 при любых обстоятельствах?

Если t1 в c2 не видит последние x в c1, я считаю, что мы будем нарушать Последовательную согласованность JMM

Я не прав?

PS: я уже читал эту другую ветку, в которой говорится об одной и той же / подобной проблеме, но она не адресовала вопрос к моему удовлетворению. Так что перепост это здесь

Видимость данных на многоядерном процессоре по одному потоку

1 Ответ

1 голос
/ 03 июня 2019

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

Если вас беспокоят подробности такого низкого уровня, то в случае x86 вы можете прочитать руководство Intel Vol 3A, глава 8:

Эти многопроцессорные механизмы имеют следующие Характеристики:

[...]

• Для поддержания целостности кэша - при обращении к одному процессору данные, кэшированные на другом процессоре, не должны получить неверные данные. Если он изменяет данные, все остальные процессоры, которые доступ к этим данным должен получить измененные данные.

[...]

Это должно быть достаточно убедительно, чтобы не беспокоиться о несогласованности кэша, по крайней мере на x86:)

...