Necessità di scrittura di array volatile mentre si è nel blocco sincronizzato

Question

Domanda relativa al JMM e alla semantica riguardante i campi volatili scritti in un blocco sincronizzato, ma letti non sincronizzati.

In una versione iniziale del codice seguente, non stavo sincronizzando l'accesso poiché non era necessario per i requisiti precedenti (e abusando di un'assegnazione automatica this.cache = this.cache assicurava una semantica volatile di scrittura). Alcuni requisiti sono stati modificati, rendendo necessaria la sincronizzazione per garantire che non vengano inviati aggiornamenti duplicati. La domanda che ho è che il blocco di sincronizzazione preclude di richiedere l'auto assegnazione del campo volatile?

// Cache of byte[] data by row and column. 
    private volatile byte[][][] cache; 

    public byte[] getData(int row, int col) 
    { 
    return cache[row][col]; 
    } 

    public void updateData(int row, int col, byte[] data) 
    { 
    synchronized(cache) 
    { 
     if (!Arrays.equals(data,cache[row][col])) 
     { 
     cache[row][col] = data; 

     // Volatile write. 
     // The below line is intentional to ensure a volatile write is 
     // made to the array, since access via getData is unsynchronized. 
     this.cache = this.cache; 

     // Notification code removed 
     // (mentioning it since it is the reason for synchronizing). 
     } 
    } 
    } 

Senza sincronizzazione, ritengo che sia tecnicamente necessaria la scrittura volatili assegnazione sé (anche se le bandiere IDE come avere alcun effetto). Con il blocco sincronizzato, penso che sia ancora necessario (dal momento che la lettura non è sincronizzata), ma voglio solo confermarlo poiché appare ridicolo nel codice se non è effettivamente richiesto. Non sono sicuro se ci sono garanzie che non sono a conoscenza tra la fine di un blocco sincronizzato e una lettura volatile.

Answer 1

Sì, è ancora necessario scrivere in modo volatile, secondo il modello di memoria Java. Non c'è un ordine di sincronizzazione di sbloccare cache ad una successiva lettura volatile del cache: sblocco -> volatileRead non garantisce la visibilità. È necessario sbloccare -> blocco o volatileWrite -> volatileLettura.

Tuttavia, le JVM reali hanno garanzie di memoria molto più forti. Solitamente unlock e volatileWrite hanno lo stesso effetto memoria (anche se sono su variabili diverse); uguale a blocco e volatileLettura.

Quindi abbiamo un dilemma qui.La raccomandazione tipica è che si dovrebbe seguire rigorosamente le specifiche. A meno che tu non abbia una conoscenza molto ampia della questione. Ad esempio, un codice JDK può impiegare alcuni trucchi che non sono teoricamente corretti; ma il codice ha come target una JVM specifica e l'autore è un esperto.

Il sovraccarico relativo della scrittura extra volatile non sembra essere comunque così grande.

Il codice è corretto ed efficiente; tuttavia è al di fuori di schemi tipici; Vorrei modificarlo un po 'come:

private final byte[][][] cacheF = new ...; // dimensions fixed? 
    private volatile byte[][][] cacheV = cacheF; 

    public byte[] getData(int row, int col) 
    { 
    return cacheV[row][col]; 
    } 

    public void updateData(int row, int col, byte[] data) 
    { 
    synchronized(cacheF) 
    { 
     if (!Arrays.equals(data,cacheF[row][col])) 
     { 
     cacheF[row][col] = data; 

     cacheV = cacheF; 
     } 
    } 
    } 

Answer 2

L'autoassegnazione si assicura che un altro thread leggerà il riferimento di matrice impostato e non un altro riferimento di matrice. Ma potresti avere un thread che modifica l'array mentre un altro thread lo legge.

Sia le letture che le scritture sull'array devono essere sincronizzate. Inoltre, non memorizzerei e restituirò ciecamente gli array a/da una cache. Un array è una struttura di dati mutabile, non a prova di thread e qualsiasi thread potrebbe corrompere la cache mutando la matrice. Dovresti prendere in considerazione la creazione di copie difensive e/o restituire un elenco non modificabile piuttosto che un array di byte.

Answer 3

Un indice di scrittura su un array volatile non ha effettivamente effetti di memoria. Cioè, se hai già istanziato l'array, avere il campo dichiarato come volatile non ti darà la semantica della memoria che stai cercando quando assegni ad elementi all'interno dell'array.

In altre parole

private volatile byte[][]cache = ...; 
cache[row][col] = data; 

ha la stessa semantica di memoria come

private final byte[][]cache = ...; 
cache[row][col] = data; 

A causa di questo è necessario sincronizzare su tutti lettura e scrittura alla matrice. E quando dico "semantica memoria stessa" intendo dire che non vi è alcuna garanzia che i thread leggeranno il valore più aggiornato di cache[row][col]