HalJordan ha scritto:
Avevo pensato ad un oggetto di tipo AtomicBoolean come flag, però poi potrei ritrovarmi nel caso in cui t1 smette, t2 stampa ed esce, e non è un caso accettabile.
AtomicBoolean va anche bene (dal momento che t2 opera in "polling" per sapere se terminare oppure continuare il while).
Però, scenario (AtomicBoolean false=continua ; true=termina):
t1 sta per terminare e prima di concludere setta il AtomicBoolean a true.
Se t2 ha "appena" fatto il test sul AtomicBoolean e lo ha visto false ... ovviamente esegue il corpo del while e fa la stampa. Il true lo vedrà solo al "giro" dopo. Questo sì, PUÒ capitare e se è questo che non ti va bene, bisogna fare diversamente.
HalJordan ha scritto:
Il problema non conosco bene la differenza tra interrupted e isInterrupted, o meglio ho difficoltà nel capirla. Ci provo
interrupted() riporta lo stato di interruzione del Thread che lo chiama quindi t1.interrupted ritorna lo stato di t1, ma non capisco perchè cancella lo stato o meglio la flag e perchè la seconda chiamata set a false.
isInterrupted() riporta lo stato di interruzione del Thread su cui viene chiamato. Quindi se faccio t1.isInterrupted in t2 mi dici false perchè t2 non è interrotto.
La documentazione javadoc lo dice chiaramente: interrupted() "pulisce" lo status di interrupted mentre isInterrupted() non lo "pulisce". La differenza sta lì.
Ma lo ripeto ancora, se vuoi che il meccanismo di interruption "funzioni", allora:
- in t1 devi fare t2.interrupt()
- in t2 lo testi con Thread.interrupted()