Odczyty zmiennych zmiennych nabrały semantyki . Oznacza to, że jest zagwarantowane, że pamięć odczytana ze zmiennej ulotnej wystąpi przed jakimkolwiek następnym odczytem pamięci. Blokuje kompilator przed zmianą kolejności, a jeśli sprzęt tego wymaga (słabo uporządkowany procesor), użyje specjalnej instrukcji, aby sprzęt opróżnił wszystkie odczyty, które wystąpią po odczycie ulotnym, ale zostały spekulacyjnie uruchomione wcześnie, lub procesor może przede wszystkim zapobiegać ich wczesnemu wystawianiu, zapobiegając pojawianiu się jakiegokolwiek spekulacyjnego obciążenia między wydaniem ładunku a jego wycofaniem.
Zapisy zmiennych zmiennych mają semantykę wydania . Oznacza to, że gwarantuje się, że wszelkie zapisy w pamięci do zmiennej nietrwałej będą opóźnione, dopóki wszystkie poprzednie zapisy w pamięci nie będą widoczne dla innych procesorów.
Rozważmy następujący przykład:
something.foo = new Thing()
Jeśli foojest zmienną składową w klasie, a inne procesory mają dostęp do instancji obiektu, do której odwołuje się something, mogą zobaczyć foozmianę wartości, zanim zapisy do pamięci w Thingkonstruktorze będą widoczne globalnie! To właśnie oznacza „słabo uporządkowana pamięć”. Może to nastąpić nawet wtedy, gdy kompilator ma wszystkie sklepy w konstruktorze przed sklepem foo. Jeśli footak, volatilemagazyn foobędzie miał semantykę wydania, a sprzęt gwarantuje, że wszystkie zapisy przed zapisem foosą widoczne dla innych procesorów przed zezwoleniem na foowystąpienie zapisu .
Jak to możliwe, fooże pisma są tak źle uporządkowane? Jeśli wstrzymanie linii pamięci podręcznej fooznajduje się w pamięci podręcznej, a magazyny w konstruktorze przegapiły pamięć podręczną, wówczas sklep może zakończyć się znacznie wcześniej niż zapisy do pamięci podręcznej chybiają.
(Okropna) architektura Itanium firmy Intel miała słabo uporządkowaną pamięć. Procesor użyty w oryginalnym XBox 360 miał słabo uporządkowaną pamięć. Wiele procesorów ARM, w tym bardzo popularny ARMv7-A, ma słabo uporządkowaną pamięć.
Programiści często nie widzą tych wyścigów danych, ponieważ takie rzeczy jak blokady będą tworzyć pełną barierę pamięci, zasadniczo to samo, co pozyskiwanie i zwalnianie semantyki w tym samym czasie. Żadne obciążenia wewnątrz śluzy nie mogą być spekulatywnie wykonywane przed pozyskaniem zamka, są one opóźniane do momentu nabycia zamka. Żadne zapasy nie mogą być opóźnione przez zwolnienie blokady, instrukcja zwalniająca blokadę jest opóźniona do momentu, gdy wszystkie zapisy wykonane wewnątrz zamka będą widoczne globalnie.
Bardziej kompletnym przykładem jest wzorzec „Podwójnie sprawdzone blokowanie”. Celem tego wzorca jest uniknięcie konieczności uzyskiwania blokady w celu leniwego zainicjowania obiektu.
Zaczepiony z Wikipedii:
public class MySingleton {
private static object myLock = new object();
private static volatile MySingleton mySingleton = null;
private MySingleton() {
}
public static MySingleton GetInstance() {
if (mySingleton == null) {
lock (myLock) {
if (mySingleton == null) {
mySingleton = new MySingleton();
}
}
}
return mySingleton;
}
}
W tym przykładzie sklepy w MySingletonkonstruktorze mogą nie być widoczne dla innych procesorów przed sklepem mySingleton. Jeśli tak się stanie, inne wątki, które zaglądają do mySingleton, nie otrzymają blokady i niekoniecznie przejmą zapisy do konstruktora.
volatilenigdy nie zapobiega buforowaniu. Gwarantuje porządek, w jakim „widzą” inne procesory. Zwolnienie magazynu opóźni magazyn, dopóki wszystkie oczekujące zapisy nie zostaną zakończone i zostanie wydany cykl magistrali, informujący inne procesory o odrzuceniu / zapisaniu zwrotnym linii pamięci podręcznej, jeśli zdarzy się, że mają buforowane odpowiednie linie. Pozyskiwanie obciążenia usunie spekulowane odczyty, zapewniając, że nie będą one przestarzałymi wartościami z przeszłości.