[Java lista] A synchronized mítosz

[Marai Laszlo]

On Thu, 31 Jul 2008 13:34:15 +0100
biziclop <biziclop at gmail.com> wrote:

  Hali!

> Lokalis valtozon meg mit szamit? :)

Hat ezaz :)

> A muvelet atomi abban az ertelemben, hogy vagy latod az eredmenyet
> vagy nem. Mig long-nal lathatsz valami katyvaszt is.

Hat de ez igy nem atomi szerintem :), legalabbis eleg felrevezeto igy
hivni, meg ha ertem is, hog mire gondolsz. A valami++ muvelet az
egyebkent sem csak inkrementalas, hanem 'vedd az erteket es inkrementald'
es az esetek tobbsegeben igy hasznaljuk (lasd pl. mindjart a for ciklust).

Masreszt maga az inkrementalas szerintem long-on is atomi, mivel az
primitiv tipus. Ez ugye abbol is kovetkezik, hogy a JMM szerint ha tobb
szalad van, es nem szinkronizalsz akkor ugyis kulonbozo peldanyokat
modositgat minden thread a memoriaban, tehat abbol nem lehet katyvasz. Ha
a VM implementaciojanal nem figyelnek arra, hogy a long++ -hoz tobb, mint
egy nativ muvelet tartozik, akkor pontosan a volatile eseteben lehetne
ebbol problema, amikor minden szal valoban kozvetlenul ugyanazt a
memoriateruletet piszkalja. De nyilvan figyeltek, kulonben nem sok
ertelme lenne a volatile-nak :). (Egy sima ertekadas is fejreallithatna.)

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.

  atleta