Zdravím,

to co tady popisujete bude nastávat jen v případě, že máte více
procesorů a ty mají oddělené cache.
"Problém" synchronizace Javy nastává tak, že obsah cache se
flushuje/obnovuje do/z hlavní paměti 
jen u proměnných volatile a při volání synchronized.

Ale toto vlastně není problém - stejný problém má i C/C++ - zde totiž v
rámci definice jazyka vlastně 
vůbec není definováno kdy se cache flushují - je to závislé na OS 
(tento význam slova volatile zavádí i Visual Studio C++ 2005).

Jinak z těchto důvodu by neměla v Jave fungovat ani double checking
optimalizace 
http://blog.softeu.cz/prednasky/2006/vm-nebo-nativni-kod/architektury-soucasnych-pocitacu-2.html

Ale myslím, že nasimulovat tento problém nebude tak snadné :-)
Jediné na co můžete na jednoprocesorovém stroji narazit je to, že to
překladač vyoptimalizuje tak, 
že kód úplně změní.

S pozdravem

Petr Ferschmann

Peter Stibrany píše v St 24. 01. 2007 v 21:20 +0100:

> Ahojte,
> 
> v poslednom case studujem problematiku Java Memory Model-u, a chcel by
> som nasimulovat problemy, ktore vzniknu z nekorektnej synchronizacie.
> 
> Skusal som nasimulovat problem, o ktorom sa zmienuje Brian Goetz v
> jeho prezentacii z Javapolisu 2005. Tam spomina, ze hotspot kompilator
> (-server) je schopny pretransformovat slucku
> 
> while (running) {
>    ... // tu sa running nemeni
> }
> 
> na
> 
> if (running) {
>   while (true) {
>      ... // tu sa running nemeni
>   }
> }
> 
> pokial pristup k premennej running nie je volatile a vo vnutri while
> cyklu sa running nemeni.
> 
> Vytvoril som si program, ktory spusta thready, ktore v obdobnej "while
> (running)" slucke spustaju sleep. Hlavny thread obcas niektoremu
> threadu nastavi running na false (bez akejkolvek synchronizacie,
> running nie je ani volatile). Ked pocet threadov klesne pod 50,
> vytvori dalsie. Dufal som, ze sa casom prejavi uvedeny efekt tym, ze
> pocet threadov prestane klesat. Zial, nedari sa mi nasimulovat ani len
> tento problem.
> 
> Nemate nejake priklady programov, ktore vdaka chybnej synchronizacii
> nebudu fungovat? Najlepsie spustitelny Javovsky kod, ktory sa sprava
> necakane. (Na windows/x86).
> 
> Vdaka,
> -peter

-- 
Petr Ferschmann

SoftEU s.r.o.
-----------------------------------
Sady Petatricatniku 31
301 00 Plzen
Czech Republic
-----------------------------------
Phone: +420 373 729 300
Fax:   +420 373 729 301
Cell:  +420 775 638 008
E-mail: [EMAIL PROTECTED] 

Odpovedet emailem