Java/Interblocco ricontrollato: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m +link |
wikificata, cambio E -> trasf |
||
Riga 1:
{{trasferimento|b}}
▲Il '''Double Checked Locking Idiom''' è uno dei più subdoli Antipattern della programmazione concorrente in Java. A prima vista sembra un utile strumento per migliorare le performance, tuttavia sotto le regole dell'attuale JavaMemoryModel questo schema non funziona. Vediamone un esempio.
==Esempio==
public class DoubleCheckedLocking {
private static Resource _instance
Line 19 ⟶ 17:
}
Inizializzare un [[oggetto (informatica)|oggetto]] comporta la scrittura di alcune [[variabile (informatica)|variabili]] (stato dell'oggetto), pubblicare un oggetto riguarda la scrittura di altre variabili (il [[reference]]). Se non si assicura che pubblicare l'oggetto accada prima che un [[Thread (informatica)|thread]] possa leggerne il reference, la scrittura del reference può essere riordinata con le scritture dello stato dell'oggetto.▼
▲Inizializzare un oggetto comporta la scrittura di alcune variabili (stato dell'oggetto), pubblicare un oggetto riguarda la scrittura di altre variabili (il reference). Se non si assicura che pubblicare l'oggetto accada prima che un [[Thread (informatica)|thread]] possa leggerne il reference la scrittura del reference può essere riordinata con le scritture dello stato dell'oggetto.
In tale caso un Thread può vedere un valore aggiornato per il reference, ma un valore non aggiornato per alcune delle variabili che compongono lo stato dell'oggetto. Si ottiene quindi il reference ad un oggetto parzialmente costruito.
Senza utilizzare tecniche troppo elaborate e spesso inutili è possibile risolvere il problema con il seguente codice:
public class EagerInstantiation {
Line 33 ⟶ 30:
}
Un'alternativa è l'utilizzo di una [[variabile booleana]] che mantenga lo stato dell'inizializzazione dell'istanza del [[singleton]]. Questo impedisce che thread concorrenti possano ottenere un riferimento all'istanza prima che il costruttore dell'oggetto abbia terminato e reso l'oggetto consistente:▼
▲Un'alternativa è l'utilizzo di una variabile booleana che mantenga lo stato dell'inizializzazione dell'istanza del singleton. Questo impedisce che thread concorrenti possano ottenere un riferimento all'istanza prima che il costruttore dell'oggetto abbia terminato e reso l'oggetto consistente:
public class DoubleCheckedLocking {
Line 53 ⟶ 48:
}
Il momento in cui avviene l'istruzione di assegnazione alla variabile booleana garantisce che il [[costruttore (programmazione)|costruttore]] abbia terminato l'inizializzazione dell'oggetto.
Anche nello scenario in cui il thread che ha avviato la costruzione dell'oggetto non sia ancora uscito dalla sezione critica, qualsiasi altro thread concorrente che ottenga un esito negativo dal primo test fuori dalla sezione critica, restituirà direttamente (senza attendere sul [[mutex]]) l'oggetto correttamente inizializzato.
Questa soluzione al problema, quindi, si basa sull'idea di non testare direttamente il riferimento all'oggetto, ma una variabile distinta che sia stata settata successivamente alla costruzione dell'oggetto.
==Bibliografia==
* ''Reality Check'', Douglas C. Schmidt, C++ Report, SIGS, Vol. 8, No. 3, March 1996.
* ''Double-Checked Locking: An Optimization Pattern for Efficiently Initializing and Accessing Thread-safe Objects'', Douglas Schmidt e Tim Harrison. 3rd annual Pattern Languages of Program Design conference, 1996
* ''Lazy instantiation'', Philip Bishop e Nigel Warren, JavaWorld Magazine
* ''Programming Java threads in the real world'', Part 7, Allen Holub, Javaworld Magazine, April 1999.
* ''Java 2 Performance and Idiom Guide'', Craig Larman e Rhett Guthrie, p100.
* ''Java in Practice: Design Styles and Idioms for Effective Java'', Nigel Warren and Philip Bishop, p142.
* Rule 99, ''The Elements of Java Style'', Allan Vermeulen, Scott Ambler, Greg Bumgardner, Eldon Metz, Trvor Misfeldt, Jim Shur, Patrick Thompson, SIGS Reference library
==Collegamenti esterni==▼
* {{en}}[http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html Declaration: Double Checked Locking Idiom is broken
* {{en}}http://www.javaworld.com/jw-02-2001/jw-0209-double.html▼
* {{en}}http://www-128.ibm.com/developerworks/java/library/j-dcl.html▼
[[Categoria:Antipattern]]
[[Categoria:Controllo della concorrenza]]
[[en:Double-checked locking]]
▲==Collegamenti esterni==
[[lt:Tikrintas rakinimas]]
▲* [http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html Declaration: Double Checked Locking Idiom is broken ]
[[ru:Double checked locking]]
▲* http://www.javaworld.com/jw-02-2001/jw-0209-double.html
▲* http://www-128.ibm.com/developerworks/java/library/j-dcl.html
| |||