Beh, certo. L'oggetto Lista è uno solo utilizzato da entrambi i thread e questo è ok (non è il massimo tenere il reference a Lista come campo statico, sarebbe stato più corretto passare ad entrambi i thread il reference. Ma sono questioni più di "design").Originariamente inviato da bmw
ciao, sto facendo delle prove per gestire la sincronizzazione fra due o più threads.
sto provando a lanciare due thread e fare in modo che il secondo non scriva nella lista finchè il primo non finisce...
ho provato e riprovato ma i due threads continuano a scrivere nella lista in modo alternat...
Ma il fatto che hai messo synchronized sul metodo aggiungi() vuol solo dire che solamente 1 thread per volta può eseguire il metodo e quindi fare la lista.add(). Insomma, la "esclusività" è solo nella esecuzione del metodo. Se vuoi che un thread possa chiamare per 100 volte consecutive aggiungi() in modo "atomico" (ed è qui il nocciolo della questione), allora devi acquisire il lock per tutto il ciclo di inserimento!
Visto che il lock è fatto sulla istanza dell'oggetto, allora è possibile fare il "client-side locking" e dovresti fare:
(idem nell'altro thread) In tal caso tutto il ciclo di inserimento diventa "atomico". È anche chiaro, che visto cosa fa il thread, in particolare la sleep, il lock è mantenuto per molto molto tempo. Tu stai facendo un esempio "didattico", diciamo. Ma in casi reali, una cosa del genere sarebbe "troppo".codice:synchronized(ThreadsSincronizzati.miaLista) { for(int i = 0; i < 100; i ++){ ThreadsSincronizzati.miaLista.aggiungi("THREAD01 " + i); try{ this.sleep(20); } catch(Exception err){ System.out.println("ERRORE THREAD 01"); } } } }

Rispondi quotando