Чтения изменчивых полей имеют семантику приобретения . Это означает, что гарантируется, что чтение памяти из изменчивой переменной произойдет до любого следующего чтения из памяти. Он блокирует компилятор от выполнения переупорядочения, и, если аппаратное обеспечение этого требует (слабо упорядоченный ЦП), он будет использовать специальную инструкцию, чтобы заставить оборудование сбрасывать все чтения, которые происходят после изменчивого чтения, но были предположительно запущены раньше, или ЦП мог предотвратить их раннюю выдачу, во-первых, предотвращая возникновение любой спекулятивной нагрузки между выпуском загрузки и ее списанием.
Записи изменчивых полей имеют семантику выпуска . Это означает, что гарантируется, что любая запись в память в изменчивую переменную будет отложена до тех пор, пока все предыдущие записи в память не станут видимыми для других процессоров.
Рассмотрим следующий пример:
something.foo = new Thing();
Если fooэто переменная-член в классе, а другие процессоры имеют доступ к экземпляру объекта, на который ссылается something, они могут увидеть fooизменение значения до того, как записи в память в Thingконструкторе станут глобально видимыми! Вот что означает «слабоупорядоченная память». Это может произойти, даже если у компилятора есть все хранилища в конструкторе перед сохранением в foo. Если fooесть, volatileто хранилище fooбудет иметь семантику выпуска, и оборудование гарантирует, что все записи перед записью fooбудут видны другим процессорам, прежде чем разрешить запись foo.
Как это возможно, чтобы записи fooбыли так плохо переупорядочены? Если кеш-строка fooхранится в кэше, а хранилища в конструкторе пропустили кеш, то возможно, что хранилище завершится гораздо раньше, чем записи в кеш не пройдут.
(Ужасная) архитектура Itanium от Intel имела слабо упорядоченную память. Процессор, использованный в оригинальном XBox 360, имел слабо упорядоченную память. Многие процессоры ARM, включая очень популярный ARMv7-A, имеют слабо упорядоченную память.
Разработчики часто не видят этих гонок данных, потому что такие вещи, как блокировки, создают полный барьер памяти, по сути то же самое, что и семантика получения и освобождения одновременно. Никакие нагрузки внутри блокировки не могут быть выполнены предположительно до получения блокировки, они откладываются до получения блокировки. Сохранение не может быть отложено при снятии блокировки, инструкция, которая снимает блокировку, откладывается до тех пор, пока все записи, выполненные внутри блокировки, не станут глобально видимыми.
Более полный пример - шаблон «Двойная проверка блокировки». Цель этого шаблона - избежать необходимости всегда получать блокировку для ленивой инициализации объекта.
Позаимствовано из Википедии:
public class MySingleton {
private static object myLock = new object();
private static volatile MySingleton mySingleton = null;
private MySingleton() {
}
public static MySingleton GetInstance() {
if (mySingleton == null) { // 1st check
lock (myLock) {
if (mySingleton == null) { // 2nd (double) check
mySingleton = new MySingleton();
// Write-release semantics are implicitly handled by marking
// mySingleton with 'volatile', which inserts the necessary memory
// barriers between the constructor call and the write to mySingleton.
// The barriers created by the lock are not sufficient because
// the object is made visible before the lock is released.
}
}
}
// The barriers created by the lock are not sufficient because not all threads
// will acquire the lock. A fence for read-acquire semantics is needed between
// the test of mySingleton (above) and the use of its contents. This fence
// is automatically inserted because mySingleton is marked as 'volatile'.
return mySingleton;
}
}
В этом примере хранилища в MySingletonконструкторе могут быть не видны другим процессорам до сохранения в mySingleton. Если это произойдет, другие потоки, которые смотрят на mySingleton, не получат блокировку и не обязательно будут получать записи в конструктор.
volatileникогда не мешает кешированию. Что он делает, так это гарантирует порядок, в котором другие процессоры «видят» записи. Освобождение хранилища будет задерживать сохранение до тех пор, пока все ожидающие записи не будут завершены и не будет запущен цикл шины, сообщающий другим процессорам, что они должны сбросить / записать свою строку кэша, если у них есть кэшированные соответствующие строки. Приобретение нагрузки сбрасывает все предполагаемые чтения, гарантируя, что они не будут устаревшими значениями из прошлого.