Когерентность кэша и Java Memory Model

#многопоточность #java

Может ли когерентность кэша повлиять на работу многопоточного Java-приложения? Или
все проблемы решает виртуальная машина? 
В каких случаях один и тот же многопоточный код будет работать по-разному в зависимости
от кэш-памяти?    

Ответы

Ответ 1

По идее для объектов, отмеченных volatile когерентность должна обеспечиваться независимо
от аппаратной поддержки когерентности кэшей.
У большинства современных (SMP) компьютеров обеспечение когерентности кэша встроено
в конструкцию. Этого нет (насколько мне известно) у HPC (high performance computing)
кластеров. Знаю, что в реализации JVM для них обещают Truly portable threads and synchronization
model.
Вообще же, проблемы с параллельными потоками всегда на совести программиста.


Ответ 2

В общем случае, JVM и проблема cache coherence - это 2 совершенно разных уровня взаимодействия
с железом компьютера. Проблема cache coherence всегда решается на уровне процессора,
в 99% случаев это происходит аппаратно (в архитектуре Intel, насколько мне известно,
для этого используются протоколоы MESIF и MOESI.).

Единственное, на что реально может влиять cache coherence - это на производительность
приложения (например, как влияют промахи кэша).
Теория подсказывает, что ситуация, которой стоит избегать - это помещение нескольких
переменных в строку кэша и постоянные чтения-записи между ними. Очевидно, что это плохо,
т.к накладные затраты на синхронизацию кэшей будут немаленькими (разумеется, в случае,
если это как-либо не соптимизится).
Практика же подсказывает, что в Java выиграть на этом вряд ли удастся.
Три уровня  JVM (код - байт-код - оптимизирующий в native код runtime) слабо подразумевают
оптимизации такого рода. Если бы речь шла о C++, то еще можно было бы что-нибудь придумать,
а здесь, предполагаю, что это практически невозможно, если, разумеется, не использовать JNI.