[Java lista] A synchronized mítosz

Marai Laszlo lists at atleta.hu
2008. Júl. 31., Cs, 16:34:19 CEST


On Thu, 31 Jul 2008 15:38:07 +0200
Auth Gábor <auth.gabor at javaforum.hu> wrote:

  Hali!

> > Egyebkent kivancsisagbol megneztem a generalt byte code-ot, es abbol
> > latszik, hogy az inkrementalas nem atomi (betolt, hozzaad egyet,
> > visszair), meg az is, hogy az int-re es a long-ra ugyanugy nez ki,
> > raadasul akkor is, ha volatile-ok meg akkor is, ha nem. Ettol persze
> > meg lehetne, hogy a vm maskepp hajtja vegre a vilatile long-ra az
> > ladd-ot.
>   A probléma az, hogy nincs byte code-ot futtató processzor... és nem
> mindegy, hogy RISC-en vagy CISC-en fut a Java kód. Mert CISC-en
> általában egy atomi művelet lesz az inkementálás, RISC-en pedig
> három. :) -- 

Igen, ez az, amivel a VM iroinak kell foglalkoznia. Most mar csak
megneztem a JLS-t, es ott szepen le van irva, hogy a volatile-lal
felcimkezett long-ot es double-t atomikent kell kezelni a load, store,
read es write muveletekre. A tobbi esetben viszont az van, hogy a szalak
nem ugyanazt a memoria teruletet hasznaljak, hanem a thread sajat
cache-et, ezert ott nem fordulhat elo, hogy szemet kerul a
valtozoba. Ebbol viszont az kovetkezik, hogy maga az inkrementalas
muvelet a VM-en futo programok szamara - abban az ertelemben ahogy lsp
irta - mindig atomi, sosem fordulhat elo, hogy egy long egyik fele a ++
kovetkezteben a ++ elotti allapotot mutatja, mig a masik az utana levot.

http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html

  atleta


További információk a(z) Javalist levelezőlistáról