Il problema del runFlag si risolve velocemente. Dal momento che runFlag è solo
scritto nel EDT e solo
letto dai due thread, allora la variabile runFlag è una buona candidata per essere marcata "volatile":
private
volatile boolean runFlag=false;
volatile fornisce una importante informazione alla JVM. Così la JVM evita qualunque tipo di ottimizzazione/caching riguardo l'uso di runFlag e garantisce che tutti i thread "vedano" in modo consistente l'ultimo valore scritto.
Ci sono però altri problemi nel tuo codice.
1) Il init() della applet NON è invocato nel contesto del EDT ma in un thread specifico del container delle applet. La cosa che generalmente si fa nel init è usare SwingUtilities.invokeAndWait per dispacciare un Runnable nel EDT.
C'è l'esempio
qui sul tutorial ufficiale.
2) Nel contesto dei tuoi thread vai ad accedere alla interfaccia utente. Sono quei:
Pow.setText(""+a);
T.setText(""+Counter);
Questo non va bene. Ci sono pochissime operazioni sulla UI che sono thread-safe e possono essere fatte da qualunque thread. Quindi tutto il resto dell'accesso alla UI va fatto esclusivamente nel contesto del EDT.
Quindi in genere si usa SwingUtilities.invokeLater per dispacciare un Runnable nel EDT che fa quelle modifiche.
3) Un altro punto è "critico". Sincronizzi sul Counter che è un Integer. Siccome fai Counter++ questo porta a fare un auto-unboxing (da Integer a int), incremento e poi auto-boxing (da int a Integer).
In sostanza ad ogni incremento hai un
nuovo oggetto Integer. E visto che Counter è condiviso tra i due thread .... qualche problema c'è sicuramente perché i due thread potenzialmente possono sincronizzare su Integer appunto diversi.
In ogni caso, evita questo come la peste .... usa un altro oggetto di lock, che sia comune e stabile.