HalJordan ha scritto:
Ah diavolo giusto, è la stessa cosa, non avevo capito bene synchronized su di un metodo.
Il synchronized nella dichiarazione del metodo:
* Su un metodo "di istanza" (non static), acquisisce il lock sulla istanza su cui è invocato.
* Su un metodo "di classe" (static) acquisisce il lock sul Class relativo alla classe.
HalJordan ha scritto:
Se dovessi invece avere una sola istanza di myThread e usarla in due istanze di Thread, varrebbe lo stesso?
La tua classe è
extends Thread quindi quello che dici non ha granché senso.
Ma se tu avessi scritto una classe
implements Runnable e poi crei UNA (una sola!) istanza e la passi a DUE istanze di Thread, allora sì, un synchronized sul run() FA la mutua-esclusione, perché il lock è uno solo.
HalJordan ha scritto:
Quindi .class in questo genere di esercizio è corretto, ma in futuro con altro tipo di implementazione non va usato, perchè è brutto da vedere o c'è un motivo preciso?
E' un po' raro dover usare Xyz.class come oggetto di lock esplicito in un blocco synchronized.
HalJordan ha scritto:
Per vedere se ho capito bene, se avessi due Thread che condividono due array(a e b) in cui il metodo run sposta i positivi di a in b:
public void run(){
for (int i = 0; i < a.length; i++) {
if (a[i] > 0) {
b[i] = a[i];
a[i] = 0;
}
}
}
Sostanzialmente, stessa cosa di prima: tutto quel if e il suo corpo DEVE essere fatto in modo "atomico" dando mutua-esclusione tra i thread.
Se metti il synchronized che racchiude tutto il for, succede che UN solo thread farà tutti gli spostamenti e l'altro non farà più nulla.
Se metti il synchronized che racchiude solo il if, succede che a seconda delle tempistiche un thread farà alcuni spostamenti e l'altro thread ne farà alcuni altri.