Vlákno názorů k článku Pohled pod kapotu JVM – základy optimalizace aplikací naprogramovaných v Javě (4) od kert - Děkuji za pěkný článek. Přemýšlím, zda tedy volatile vůbec...

  • Článek je starý, nové názory již nelze přidávat.
  • 3. 10. 2013 21:27

    kert (neregistrovaný)

    Děkuji za pěkný článek.
    Přemýšlím, zda tedy volatile vůbec k něčemu je.
    Skutečně mám jako programátor někde použít volatile field? Co se místo toho radši synchronizovat na obalující instanci? Je to rychlejší (volatile místo synchronizace)?
    K čemu dnes potřebuji volatile long, když mám AtomicLong (dtto pro int)?
    A má nějaké užití volatile field neprimitivního typu (private volatile String)? V životě jsem to neviděl...

    Volatile mělo vždycky tak nějak špatnou pověst. Přijde mi, že autoři JLS měli nějakou ideu, jak by to mělo fungovat, jenže se buď ukázalo, že to tak udělat úplně nejde, nebo vývoj procesorů nabral jiný směr... Pak trvalo několik verzí Javy (deset let?), než to alespoň začalo dělat co má, do toho vzniklo sun.misc.Unsafe, které umožnilo pár fíglů navíc (viz implementace AtomicLong, kde si jenom s volatile nevystačí) a z volatile je definitivně mrtvě narozené dítě...

  • 3. 10. 2013 21:42

    Vít Šesták (v6ak)

    Tak třeba kompilátor Scaly to používá pro lazy fields na double checked locking. Podívá se do volatile bitfieldu, jestli hodnota je již spočítaná. Pokud zjistí, že ano, nepotřebuje zamykat a může ji vrátit. Pokud ne, pokusí se zamknout a vyřešit to v rámci zámku. (Do té doby tam teoreticky může někdo zapsat.)

    Vtip je v tom, že je to optimistický přístup - většinou to projde, takže to udělám tak, abych zamykat musel ideálně jen jednou. (Samozřejmě, když bude velký nával okolo prvního přístupu, tak to zpočátku nevyjde.)

    A myslím, že se najde i mnoho dalších využití. Ale asi vždy spíše low-level.

  • 3. 10. 2013 21:57

    Pavel Tišnovský
    Zlatý podporovatel

    Použití volatile atributů sice vede k určitým problémům - viz článek - ovšem pořád se pro ně najde použití. U volatile totiž požadujeme jen několik vlastností, především atomicitu čtení a zápisu (avšak ne dalších operací!) + "průpis" nové hodnoty do všech vláken + zákaz reorderingu.

    AtomicLong a podobné třídy k tomu přidávají další podmínky navíc (atomicita inkrementace, ...), tudíž bude i implementace o něco složitější a JIT méně efektivní.

    volatile String? no to je trošku podivné, protože se to vztahuje k referenčnímu typu, teď mě taky nenapadá nějaké použití.