Na detailech urcite zalezi. A na kontextu take. I kdyz JVM implementuje
synchronizaci vzdy stejne, napr. pomoci instrukce Compare-And-Swap (CAS),
je zde prostor pro optimalizaci: JVM si napr. muze vsimnout, ze zamek je
pouzivan jen jednim vlaknem a zcela jej eliminovat. Nebo muze sdruzit vice
kritickych sekci do jedne a tim usetrit jednu instrukci CAS na ukor toho,
ze vlakno bude drzet zamek dele. Nebo v okamziku, kdy chce vlakno zamek a
zamek neni k dispozici, bude vlakno chvilku cekat aktivne (tzv. spinning),
misto toho, aby doslo k prepnuti kontextu (toto je vyhodne, protoze
prepnuti kontextu je nakladna operace).
[Takze pokud vas ve skole ucili, ze lepsi je pasivni cekani, tak tady
najdete vzacnou vyjimku.]
Tyto optimalizace umela JVM pouze pro zamky synchronized, protoze o
zamcich ReentrantLock nevi. Mozna, ze uz se to ale zmenilo a optimalizace
se delaji i pro ReentrantLock.

Nicmene i presto vsechno si myslim, ze programator by mel uprednostnovat
java.util.concurrent. Proc?
Vyborne to napsal Joshua Bloch v Effective Java na strane 277:

"In summary, using wait and notify directly is like programming in
'concurrency assembly language', as compared to the higher-level language
provided by java.util.concurrent. There is seldom, if ever, a reason to
use wait and notify in new code."

Kdyz k tomu pridame to, ze michani java.util.concurrent a synchronized
neni dobry napad, zbyva pro pouziti synchronized opravdu velmi maly
prostor.

Z.
-- 
Zdenek Tronicek
FIT CTU in Prague


Roman Pichlík napsal(a):
>> ReentrantLock je nejen intuitivni a mocnejsi nez synchronized (ma napr.
fair policy), ale je take rychlejsi.
> to neni tak uplne pravda, velky rozdil je mezi Javou 5 a Javou 6. V
sestce uz je ten rozdil mensi. Zalezi na strasne moc detailech, jestli
je ten lock fair atd. Opet je to o nejakem micro benchamrku jehoz
vysledky by se mely posuzovat prave a jenom v kontextu toho micro
benchmarku. Jinak k problematice synchornized vs. reentrantlock viz
zminovana Java Concurrency in practice kapitola 13.4. Takze bych volil
podle pripadu uziti :-).
> --
> S pozdravem Roman "Dagi" Pichlik
> /* http://dagblog.cz/ Blog pro kodery */



Odpovedet emailem