[Java] Variabili di istanza e multithead

[carosene]

Sto provando a mettere in pratica alcune nozioni di multithread studiate, ma mi trovo sempre davanti allo stesso tipo di problema.
Immaginiamo una semplice classe come la seguente:
public class Esempio {

private int a;
private int b;

public Esempio() {
}

public int getA() {
return a;
}

public void setA(int a) {
this.a = a;
}

public int getB() {
return b;
}

public void setB(int b) {
this.b = b;
}

public int somma(){
return a + b;
}
}
Come faccio a garantire a thread concorrenti che la somma sia sempre quella giusta?
Per risolvere il problema, bisogna modificare il design della classe o utilizzare l’oggetto java.util.concurrent.Semaphore?

[PGI-Bis]

Per stabilire se un programma si giusto dal punto di vista della concorrenza devi prima determinare una o più possibili esecuzione sequenziali e poi verificare se l'esecuzione parallela sia equivalente.

Desiderare la somma giusta significa quindi stabilire prima cosa sia questa somma giusta e poi verificare se l'esecuzione concorrente delle medesime istruzioni comporti o meno la stessa somma.

Ad esempio, la "somma giusta" potrebbe essere 7 con a = 7 e b = 23 se l'esecuzione sequenziale "bersaglio" fosse:

setA
somma
setB

Ipotizzando che esistano tre Thread, uno per metodo, l'esecuzione parallela di quelle istruzioni può eventualmente coincidere con la sequenza bersaglio. L'eventualità del fatto ci dice che, rispetto alla sequenza stabilita, il programma non è correttamente sincronizzato.

Per sincronizzarlo (sempre rispetto ad una possibile sequenza) introduci le diavolerie che ti sembrino più opportune: barriere, semafori, mutex... tutto quello che vuoi.

Supponendo che la somma giusta sia:

setA
setB
somma

che, a parole, sarebbe "la somma è quella degli ultimi valori A e B", la versione sincronizzata richiederebbe semplicemente l'apposizione del modificatore "volatile" ai campi A e B.

[carosene]

Mille grazie per la risposta.

Mi rimane un solo dubbio nell’ultimo esempio che hai fatto:

Supponendo che la somma giusta sia:

setA
setB
somma

che, a parole, sarebbe "la somma è quella degli ultimi valori A e B", la versione sincronizzata richiederebbe semplicemente l'apposizione del modificatore "volatile" ai campi A e B.
Nel caso in cui i metodi setA() e setB() fossero più sostanziosi, non sarebbe opportuno applicare il modificatore synchronized?
Questo per evitare lo “scavalcamento” dei thread nei metodi setA() e setB().

[PGI-Bis]

:D Non è che uno applichi synchronized o volatile o usi il resto dell'armamentario perchè oggi la concorrenza viene tre euro al kilo :D

Fuor di metafora non è la quantità di istruzioni che fonda la decisione sullo strumento da adottare. E' il risultato che vuoi ottenere.

Cosa fa synchronized? Fa due cose. La prima è garantire la visibilità inter-thread delle scritture eseguite in un blocco sincronizzato in blocchi sincronizzati sullo stesso monitor. La seconda è garantire l'ordine di esecuzione delle istruzioni contenute nel blocco sincronizzato.

Esempio:

public void metodo() {
a = 5;
b = 6;
}

public int getA() { return a; }
public int getB() { return b; }


Il thread che esegue metodo deve rispettare l'ordine apparente delle istruzioni. Non è tuttavia detto che un Thread diverso veda le scritture nell'ordine apparente.

Vale a dire che se Thread Uno esegue:

a = 5
b = 6

Thread due potrebbe benissimo vedere un b che vale sei e un a che vale qualcosa di diverso da 5.

La sincronizzazione:

private final Object LOCK = new Object();

public void metodo() {
synchronized(LOCK) {
a = 5;
b = 6;
}
}

public int getA() {
synchronized(LOCK) {
return a;
}
}

public int getB() {
synchronized(LOCK) {
return b;
}
}

Ci dice che se b vale 6 allora necessariamente un qualsiasi thread leggerà a = 5. Sincronizzazione sullo stesso monitor, mi raccomando. Blocchi sincronizzati su monitor diversi equivalgono tra loro a blocchi non sincronizzati.

La seconda cosa che fa syncronized è garantire la visibilità delle scritture. Poichè synchronized si applica ad un blocco di codice questa visibilità di propaga a tutte le scritture direttamente o indirettamente contenute nel blocco. Esempio:

private ArrayList<String> lista = new ArrayList<String>();

Sappiamo che questo campo lista non è usabile in un contesto concorrente così com'è (a meno di condizioni particolari). L'imbarazzo più notevole capita quando lista risulti "null" nonostante l'inizializzazione contestuale alla dichiarazione. Succede se il Thread che inizializza è diverso dal Thread che legge o, più in generale, se non esiste una relazione happens-before tra l'inizializzazione e la lettura.

Potremmo pensare a una cosa del genere:

private volatile ArrayList<String> lista = new ArrayList<String>();

oppure

private final ArrayList<String> LISTA = new ArrayList<String>();

final ci dice che LISTA non sarà mai null, anche in un contesto concorrente. volatile ci dice che se l'inizializzazione del campo precede la sua lettura allora necessariamente la lettura vedrà il valore diverso da null.

Tutto bene? E no. Va bene per il riferimento lista. Per il numero a 32 o 64 bit contenuto nel puntato lista. Ma non va bene rispetto ai campi dell'oggetto a cui lista punta. A meno che quei campi non siano a loro volta final o volatile, il loro valore minimo garantito, in un contesto concorrente, è sempre e solo quello iniziale (null, false, zero).

Qui entra in campo synchronized (o i Lock del nuovo package concurrent).

private ArrayList<String> lista;

//inizializzazione dell'oggetto (in un costruttore, in un metodo initialize o in un blocco di inizializzazione o in forma lazy... un po' ovunque).
syncronized(LOCK) {
lista = new ArrayList<String>();
}

Qui che succede. Succede che il blocco sincronizzato su un ipotetico monitor LOCK garantisce che la lettura dei valori là scritti in un analogo blocco sincronizzato "veda" quelle scritture. E vale per lista, per i campi di lista, per i campi dei campi dei campi di lista eccetera eccetera.

E' questo genere di considerazioni che ci guida nello scrivere un programma concorrente in Java.