Synchronized Java

[linux_r]

< Si può osservare che l'utilizzo della parola chiave synchronized produce codice che risulta molto più conciso.Ovviamente per comprendere questo codice si deve sapere che ogni oggetto ha un lock implicito e che il lock ha una condizione implicita .Il lock gestisce i thread che tentando di entrare in un metodo synchronized . La condizione gestisce i thread che hanno chiamato wait.
Tuttavia i blocchi e le condizioni implicite hanno certi limiti ,tra cui i seguenti:
-Può essere inefficiente avere una sola condizione per lock(Che significa?)
-Le primitive di lock della macchina virtuale non si accoppiano fedelmente con i meccanismi di lock disponibili nell'hardware. (ma che lingua è??)

>>

Grazie a chiunque , mi possa aiutare. Questo testo è tratto dal libro core java 2 di cay horstman.

[luca200]

Se quello che hai postato è copiaincollato con fedeltà dal libro, puoi procurarti una frusta e metterti in caccia di chi ha fatto la traduzione

[linux_r]

magari!! A qesto punto lo compravo inglese tanto sempre devo tradurre

[valia]

magari!! A qesto punto lo compravo inglese tanto sempre devo tradurre

questo è il motivo per cui io leggo solo risorse in inglese

diciamo che è tradotto male, non voglio dirti cavolate (visto che non so a cosa si riferisce), cosa non ti è chiaro? o meglio, se leggi da altre fonti hai ancora problemi?

[kuarl]

-Può essere inefficiente avere una sola condizione per lock(Che significa?)
-Le primitive di lock della macchina virtuale non si accoppiano fedelmente con i meccanismi di lock disponibili nell'hardware. (ma che lingua è??)

cercando di intuire cosa avrebbe voluto dire, nel primo punto suggerisce che ci sono molti modi per gestire l'accesso concorrente ad una risorsa, e la parola chiave synchronized ne mette a disposizione solo uno (il pessimistic lock dei db, semplificando molto)

personalmente non sono a conoscenza di un eventuale supporto hw per queste funzioni, quello che so' e` che ogni sistema operativo ha un suo modo di gestire processi/thread/accesso concorrente. Quindi per essere al di sopra dei SO sei costretto ad usare un api semplificata e non puoi fare troppo affidamento sulla temporizzazione dei thread su uno specifico sistema operativo, ma anzi devi usare punti di sincronizzazione espliciti nel codice. Questo e` cio` che dice la teoria, ma io francamente non mi sono mai posto il problema perche` anche sullo stesso SO potresti avere comportamenti bizzarri che dipendono da mille fattori, compreso il carico attuale della macchina.
L`esperienza mi insegna quindi, che per raggiungere la pace dei sensi, e` necessario prevedere tutti i punti di accesso concorrente all'interno del tuo codice e regolarli a manina. Anche perche` trovare un bug di questo tipo puo` essere parecchio frustrante perche` e` roba difficilmente riproducibile.

[franksisca]

scommettiamo che per hardware il traduttore intendeva qualcosa tipo semafori??