Piggyback volatile. È abbastanza per la visibilità?

Question

Questo riguarda il volatile sulle spalle. Scopo: voglio raggiungere una visibilità leggera dei vars. La coerenza di a_b_c non è importante. Ho un sacco di soldi e non voglio renderli tutti volatili.

È questo il codice threadsafe?

class A { 
    public int a, b, c; 
    volatile int sync; 

    public void setup() { 
     a = 2; 
     b = 3; 
     c = 4; 
    } 

    public void sync() { 
     sync++; 
    } 
} 

final static A aaa = new A(); 

Thread0: 
aaa.setup(); 
end 

Thread1: 
for(;;) {aaa.sync(); logic with aaa.a, aaa.b, aaa.c} 

Thread2: 
for(;;) {aaa.sync(); logic with aaa.a, aaa.b, aaa.c} 

Answer 1

Java Memory Model definisce il accade-prima relazione che ha le seguenti proprietà (tra gli altri):

• "ogni azione in un thread accade-prima di ogni azione in quel filo che viene dopo nell'ordine programma" (programma regola ordine)
• "Una scrittura un campo volatili accade-prima di ogni lettura successiva dello stesso volatile" (regola variabile volatili)

Queste due proprietà insieme con transitività della accade-prima rapporto implica garanzie di visibilità che OP cerca nel seguente modo:

1. una scrittura a in filo 1 accade-prima una scrittura sync in una chiamata a sync() in filo 1 (regola ordine programma).
2. La scrittura alla sync nella chiamata a sync() in filo 1 accade-prima una lettura ad sync in una chiamata a sync in filo 2 (regola variabile volatile).
3. La lettura dalla sync nella chiamata a sync() in filo 2 accade-prima una lettura da a in filo 2 (programma regola ordine).

Ciò implica che la risposta alla domanda è sì, cioè la chiamata a sync() in ogni iterazione in fili 1 e 2 assicura la visibilità di modifiche a, b e c all'altro filo (s). Si noti che questo garantisce solo la visibilità. Non esistono garanzie di mutua esclusione e quindi tutti gli invarianti vincolanti a, b e c possono essere violati.

Vedere anche Java theory and practice: Fixing the Java Memory Model, Part 2. In particolare la sezione "Nuove garanzie per volatili" che dice

Secondo il nuovo modello di memoria, quando il filo A scrive un volatili variabile V, e filo B legge da V, i valori delle variabili che erano visibile A al momento in cui V è stato scritto sono garantiti ora visibile a B.

Answer 2

Non hanno veramente a sincronizzare manualmente a tutti, basta usare una struttura dati sincronizzati automaticamente, come java.util.concurrent.atomic.AtomicInteger.

In alternativa, è possibile effettuare il metodosynchronized.

Answer 3

L'incremento di un valore tra i thread non è mai thread-safe con solo volatile. Questo assicura che ogni thread abbia un valore aggiornato, non che l'incremento sia atomico, perché a livello di assemblatore il tuo ++ è in realtà più istruzioni che possono essere intercalate.

È necessario utilizzare AtomicInteger per un rapido incremento atomico.

Modifica: Leggere di nuovo ciò di cui si ha bisogno è in realtà una barriera di memoria. Java non ha istruzioni di fence di memoria, ma è possibile utilizzare un blocco per l'effetto collaterale della fence di memoria. In tal caso dichiarare il metodo di sincronizzazione sincronizzato per introdurre un recinto implicito:

void synchronized sync() { 
    sync++; 
} 

Answer 4

Da javadoc:

Uno sblocco (blocco sincronizzato o metodo uscita) di un monitor accade-prima di ogni successivo blocco (blocco sincronizzato o metodo voce) di quello stesso monitor. E poiché la relazione before-before è transitiva, tutte le azioni di una discussione prima dello sblocco avvengono prima di tutte le azioni successive a qualsiasi thread che blocca il monitoraggio .

Una scrittura su un campo volatile avviene prima di ogni successiva lettura di nello stesso campo. Le scritture e le letture dei campi volatili hanno effetti di consistenza della memoria simili a come entrate e uscite dai monitor, ma lo non comporta il blocco dell'esclusione reciproca.

quindi penso che la scrittura var volatile non è un equivalente di sincronizzazione in questo caso e che non garantisce accade-prima che l'ordine e la visibilità delle variazioni del Thread1 a Thread2

Answer 5

Il motivo è solitamente simile a questo.

public void setup() { 
    a = 2; 
    b = 3; 
    c = 4; 
    sync(); 
} 

Tuttavia, mentre questo garantisce che gli altri thread vedano questa modifica, gli altri thread possono vedere una modifica incompleta. per esempio. il Thread2 potrebbe vedere a = 2, b = 3, c = 0. o anche eventualmente a = 2, b = 0, c = 4;

L'utilizzo della sincronizzazione() sul lettore non aiuta molto.