Condition con synchronized wait e notify

[linux_r]

Salve vorrei realizzare una Condition utilizzando però wait notify e synchornized (al posto di Condition di ReentrantLock), bisogna però considerare, che sono due thread che lavorano in due classi diverse che implementano runnable, naturalmente la prima classe ha un riferimento alla seconda. Come posso realizzare , un meccanismo di tipo wait-notify, dove il secondo thread è in wait e il primo a un certo punto gli notifica di sbloccarsi?

[andbin]

Salve vorrei realizzare una Condition utilizzando però wait notify e synchornized (al posto di Condition di ReentrantLock), bisogna però considerare, che sono due thread che lavorano in due classi diverse che implementano runnable, naturalmente la prima classe ha un riferimento alla seconda. Come posso realizzare , un meccanismo di tipo wait-notify, dove il secondo thread è in wait e il primo a un certo punto gli notifica di sbloccarsi?

Tecnicamente potresti anche mettere il codice per il meccanismo wait-notify direttamente dentro una delle due classi (quella del secondo thread) ma sarebbe un po' più elegante e pulito se facessi una classe separata es. MyCondition (chiamala come vuoi, ovviamente) che incapsula questa logica. Ovviamente poi sia il primo che il secondo thread dovranno avere il riferimento ad uno stesso oggetto MyCondition.

Ma a parte la questione di "design", non sono quanto conosci di wait-notify degli oggetti, comunque di norma non basta solo una semplice invocazione di wait() da una parte e un notify() o notifyAll() dall'altra parte. Il wait generalmente va fatto dentro un ciclo while che testa una "condizione", che può essere anche solo una semplice variabile boolean di istanza.

while (condizione_per_tenere_in_wait) {
    xyz.wait();
}

E questo while deve essere fatto in un metodo synchronized o un blocco synchronized che acquisisce il lock su xyz (spesso e tipicamente xyz è il this ovvero l'oggetto su cui è invocato il metodo).

Poi da un'altra parte, sempre dopo aver acquisito il lock su xyz, si cambia il valore di quella condizione in modo che diventi falsa e si fa un xyz.notify() o xyz.notifyAll().

Non so quanto posso essere stato chiaro, se hai altri dubbi, chiedi pure.

[linux_r]

per invocare signalAll() di un oggetto condition, devo necessariamente acquisire prima il lock, o l'acquisizione dipende dalla situazione in cui mi trovo?


Inoltre non riesco ad usare per i thread il gestore per le eccezioni . sapresti aiutarmi?

[andbin]

per invocare signalAll() di un oggetto condition, devo necessariamente acquisire prima il lock

Sì, per il Condition fornito da ReentrantLock, il lock deve essere "tenuto" (acquisito) per poter invocare i vari await/signal.

Inoltre non riesco ad usare per i thread il gestore per le eccezioni . sapresti aiutarmi?

Cosa intendi di preciso? Il Thread.UncaughtExceptionHandler?

[linux_r]

Sì, per il Condition fornito da ReentrantLock, il lock deve essere "tenuto" (acquisito) per poter invocare i vari await/signal.


Cosa intendi di preciso? Il Thread.UncaughtExceptionHandler?

si

[andbin]

si

Implementi Thread.UncaughtExceptionHandler (è una interfaccia) e lo assegni ad un Thread specifico con setUncaughtExceptionHandler.
Sicuro che ti serve questo?

[linux_r]

Implementi Thread.UncaughtExceptionHandler (è una interfaccia) e lo assegni ad un Thread specifico con setUncaughtExceptionHandler.
Sicuro che ti serve questo?

penso di si ! questo serve per catturare le eccezioni per cui non e prevista una catch esaatto?

[andbin]

penso di si ! questo serve per catturare le eccezioni per cui non e prevista una catch esaatto?

Dal run() del thread non possono uscire eccezioni "checked", perlomeno non con codice che fa invocazioni normali controllate dal compilatore (escludiamo quindi newInstance() di Class che permetterebbe di bypassare il check a compile-time delle eccezioni) ma solo quelle "unchecked".
Una eccezione unchecked che esce fuori dal run() generalmente è un po' il "sintomo" di un baco da qualche parte nel thread (o comunque una mancanza da parte del programmatore) e un UncaughtExceptionHandler effettivamente è di fatto "l'ultima spiaggia" in cui si può ad esempio, sempre tipicamente, fare del logging specifico per evidenziare il problema.

Se a te serve un UncaughtExceptionHandler per qualcos'altro di più specifico, es. perché ti aspetti una qualche eccezione o perché vuoi che un'altra parte del programma possa ricevere la eccezione, sappi che il tuo uso sarebbe dubbio/discutibile. Quindi precisa meglio.

[linux_r]

no a me serve perchè devo gestire le unchecked !!

[andbin]

no a me serve perchè devo gestire le unchecked !!

Ok ma se si tratta di un UncaughtExceptionHandler per fare es. logging al fine di tracciare il problema o di fare cleanup di qualche risorsa, è un conto. Se si tratta di qualcosa di più specifico .... sarebbe da valutare.