Vlákno názorů k článku Pohled pod kapotu JVM – základy optimalizace aplikací naprogramovaných v Javě (4) od mala - Druhý problém související s volatilními atributy spočívá v...

Druhý problém související s volatilními atributy spočívá v tom, že změna hodnoty těchto atributů musí být viditelná i pro další vlákna, což znamená nutnost synchronizace vyrovnávacích pamětí (cache) jednotlivých mikroprocesorů či procesorových jader.

Ve skutečnosti všechny architektury (vyjma blackfin) mají cache automaticky synchronizovanou mezi procesory i jádry. Problém zde není synchronizace cache, problém je v tom, že procesor může přehazovat pořadí vykonávaných instrukcí. Proto se do kódu vkládají bariéry, které přehazování instrukcí zabraňují. Na cache však ty bariéry nemají vliv.

Prostý zápis do paměti moc nevadí, aplikuje se write-combine a několik zápisů do cache se do paměti provede najednou.
Zabijákem výkonnosti je
1) Přetahování více vláken o jednu cache-line (32 nebo 64 byte na adrese dělitelné 32 nebo 64) a to se děje už při prostém čtení a zápisu
2) Prefix LOCK
3) Nedejbože synchronizace na úrovni OS

Jakmile je tam LOCK, tak je to pěkně na ho***.

Tohle je jasné, to je bariéra pro čtení i zápis
lock addl $0x0,(%rsp)

To je samozřejmě splněno přes cache-coherency mechanismus, zápis byť do cache je ihned viditelný všude v celém SMP systému.

Instrukce se zpracovávají out-of-order prakticky neustále. Bariéry slouží jako prevence read-ahead, kdy se přednačítají hodnoty z paměti pro instrukci v předstihu dlouho před vlastním zpracováním instrukce. Analogicky při zápisu do paměti.