Thread stoppen ohne stop()?

[sunny01]

Hallo nochmal,

es gibt noch ein kleines Problem mit meiner GUI. Sie enthält mehrere Buttons, unter anderem einen Start- und Stop-Button.

Wenn der Startbutton gedrückt wurde, sollen gewisse Elemente und Actionlistener der GUI deaktiviert werden und das Programm gestartet werden.

Wenn der Stopbutton gedrückt wurde, sollen die Elemente wieder aktiviert werden. Weiters wird ein Parameter gesetzt der an andereren Stellen des Programms geprüft wird und gegebenfalls werden keine weiteren Schritte mehr durchgeführt. Dieses Prüfen wird allerdings über eine Variable gemacht und nicht per Überprüfung ob der Thread noch läuft (denn ursprünglich hatte ich diesen gar nicht).

So, nun habe ich aber einen Thread starten müssen, da sonst die GUI-Elemente nicht direkt nach Klick aktualisiert werden. Das Ganze sieht jetzt so aus:

    private void startActionPerformed(java.awt.event.ActionEvent evt) {                                      
        t = new Thread(new Runnable() {
            public void run() {
                    start.setEnabled(false);
                    stop.setEnabled(true);
                    par.setStopSimulation(false);
                    activateInput(false);
                    sim.startSim();
                }
            }
        });
        t.start();
}                                     

    private void stopActionPerformed(java.awt.event.ActionEvent evt) {                                     
        t.stop();
        start.setEnabled(true);
        activateInput(true);
        par.setStopSimulation(true);
    }

Das funktioniert so genau so wie ich das möchte. Allerdings ist stop() ja deprecated. Führe ich nur ein interrupt() aus, so wird das deaktivieren der GUI-Elemente und Actionlistener nicht in allen Fällen korrekt durchgeführt und es existieren dann noch Actionlistener, die eigentlich nach dem Stop weg sein sollten.

Wahrscheinlich kann hier mit dem stop nicht viel "passieren", da außer an diesen zwei Stellen nicht mit dem Thread gearbeitet wird (in weiteren Schleifen und Programmteilen wird ja immer der Parameter stopSimulation überprüft, und nicht der Thread selbst).

Aber da ich damit nicht sonderlich viel Erfahrung habe, bin ich trotzdem nicht wirklich sicher, ob ich das so lassen kann, mit dem stop(). Gibt es da eine bessere Möglichkeit?
Sollte ich vielleicht auch überhaupt "alles" umbauen, sodass der Parameter nicht mehr verwendet wird und an anderen Programmstellen immer der Thread überprüft wird? Ich finde es ja so herum einfacher und ursprünglich gab es wie gesagt keinen Thread ... aber jetzt ist die Information wohl irgendwie "doppelt" ... von daher bin ich unsicher ob das nicht eher "doof" ist, so wie es im Moment ist. Und dann ist ja da eben noch das stop-Problem ...

Sorry, von threads habe ich einfach gar keine Ahnung!
Aber hoffentlich kommt von Euch noch jemand mit, was ich da überhaupt mache ...

Liebe Grüße
sunny

 

[Marco13]

Aber hoffentlich kommt von Euch noch jemand mit, was ich da überhaupt mache ...

So halb...
Ich nehme an, dass bei "sim.startSim()" irgendwas gemacht wird, was lange dauert, z.B. sowas wie

class Sim
{
    void startSim()
    {
        while (!par.isSimulationStopped()) 
        {  
            simulateSomething();
        }
    }
}

Das heißt: Der Thread, der diese Methode aufruft, ist so lange mit simulieren beschäftigt, bis dieses Stop-Flag in den "par(ametern?)" auf "true" gesetzt wird. Wenn man das jetzt direkt in die ActionPerformed-Methode reinschreiben würde...

    private void startActionPerformed(java.awt.event.ActionEvent evt) 
    {                                      
        ...
        sim.startSim();
    }

dann würde da der "Event-Dispatch-Thread" die Simulation durchführen. Der EDT ist aber dafür verantwortlich, das GUI zu akutualisieren und Benutzereingaben zu verarbeiten, und wenn er mit simulieren beschäftigt ist, kann er das nicht (er kann also auch die Buttons nicht dekativieren...)

Das in einen eigenen Thread auslagern ist so weit schon richtig, aber der sollte dann NUR die simulation machen, der Rest kann noch im EDT gemacht werden.

Um das ganze zu stoppen müßte man wissen, wie die Simulation abläuft. Angenommen, dort ist irgendwo eine Schleife, wie oben angedeutet, dann sollte es eigentlich reichen, sowas zu machen wie

    private void startActionPerformed(java.awt.event.ActionEvent evt) {                                      
        start.setEnabled(false);
        stop.setEnabled(true);
        par.setStopSimulation(false);
        activateInput(false);

        t = new Thread(new Runnable() {
            public void run() {
                    sim.startSim();
                }
            }
        });
        t.start();
}                                     

    private void stopActionPerformed(java.awt.event.ActionEvent evt) {                                     
        start.setEnabled(true);
        activateInput(true);
        par.setStopSimulation(true);
    }

Sobald man dann auf "stop" drückt, wird mit
[c]par.setStopSimulation(true);[/c]
das Flag gesetzt, das bewirkt, dass die Haupt-Simulations-Schleife hier

        while (!par.isSimulationStopped()) 
        {  
...

beendet wird.

Um Threads zu beenden, muss man sie "ins leere laufen lassen".

 

[sunny01]

Ja, schon, aber mein Problem ist ja, dass das so nicht funktioniert ... es sieht im Moment folgendermaßen aus:

    private void startActionPerformed(java.awt.event.ActionEvent evt) {                                      
        start.setEnabled(false);
        stop.setEnabled(true);
        par.setStopSimulation(false);
        activateInput(false);
        t = new Thread(new Runnable() {
            public void run() {
                if (getInputValues() && checkStartingPoint()) {
                    sim.startSim();
                }
            }
        });
        t.start();
}                                     

    private void stopActionPerformed(java.awt.event.ActionEvent evt) {                                     
        start.setEnabled(true);
        activateInput(true);
        par.setStopSimulation(true);
    }

Wenn man jetzt start drückt, dann stop, dann stoppt alles, soweit so gut. Drückt man aber wieder auf start, dann funktioniert das deaktivierten eines Actionlisteners (welches in activateInput() passiert) nicht mehr, und der Actionlistener ist dann auch aktiv, während die Simulation läuft.

Füge ich das t.stop() ein, dann passiert das nicht mehr ... dafür wird aber auch gleich der ganze Thread gekillt, was ohnehin nicht so wünschenswert ist.

Also um es nochmal zu verdeutlichen: Das Problem ist, dass die activateInput()-Funktion irgendwie nicht so klappt, wie sie soll, sobald man das zweite Mal auf start drückt ... also start - stop - start -> dann tritt das Problem auf.

Die Funktion die den Actionlistener deaktivieren sollte, sieht so aus:

    public void activateInput(boolean a) {
        //Deactivate or activate input fields
        birthRate.setEnabled(a);
        [... usw. ... das funktioniert alles]
        //Deactivate or activate MouseListener of map
        if (!a) {
            map.removeMouseListener(map.getMouseListeners()[0]);
        }
        else {
            map.addMouseListener(new java.awt.event.MouseAdapter() {

                @Override
                public void mouseClicked(java.awt.event.MouseEvent evt) {
                    mapMouseClicked(evt);
                }
            });
        }
    }

Eventuell liegt der Fehler am Entfernen des Mouselisteners?

 

[Java-Freak]

Fehlermeldung kommt aber keine?

 

[sunny01]

Nein es kommt keine Exception ... aber der Actionlistener wird ab dem zweiten Mal dann nicht mehr entfernt, wenn man wieder auf "start" drückt ...

 

[Java-Freak]

den boolean a hast du dir auch schon mal ausgeben lassen?

 

[Marco13]

Sieht frickelig aus. Mach' dir Log-Ausgaben
System.out.println("Füge Mouse(nicht Action)Listener hinzu");
...
System.out.println("Nehme Mouse(nicht Action)Listener weg");
und schau' wann die ausgegeben werden.

Notfalls ein KSKB basteln.

 

[sunny01]

Ja klar, der boolean stimmt, alle anderen Felder der GUI werden ja wirklich deaktiviert (Inputs usw. - die sind ja dann auch ausgegraut dargestellt), nur das mit dem Listener (stimmt, ist ein MouseListener), das mag nicht.

Ich versuche dann noch ein Beispiel zu basteln!

 

[sunny01]

Also so:

            MouseListener[] ml = map.getListeners(MouseListener.class);
            for(int i = 0; i < ml.length; i++) {
                map.removeMouseListener(ml[i]);
            }

Funktioniert es jetzt. Anscheinend bekommen spätere MouseListener nicht mehr den Index 0 sondern da wird hochgezählt, auch wenn der Listener wieder entfernt wurde.

Allerdings ist das wohl ziemlich hässlich so, da eigentlich immer nur ein MouseListener da sein sollte, und keine Liste.

Kann man das irgendwie besser machen?
Der ursprüngliche MouseListener wurde eigentlich von einem von Netbeans generierten Code hinzugefügt:

        map.addMouseListener(new java.awt.event.MouseAdapter() {
            public void mouseClicked(java.awt.event.MouseEvent evt) {
                mapMouseClicked(evt);
            }
        });

Ich hätte dann versucht, das zu Löschen, und den MouseListener manuell anzulegen, und ihn zu instanziieren damit er eine Referenz hat, die ich dann direkt wieder löschen kann, aber das hat nicht funktioniert (da es sich hier wohl um abstrakte Klassen handelt).

Lg
sunny

 

[Marco13]

class Foo
{
    private MouseListener currentMouseListener = null;


    public void activateInput(boolean a) 
    {
        if (!a) 
        {
            map.removeMouseListener(currentMouseListener);
            currentMouseListener = null;
        }
        else {
            currentMouseListener = new java.awt.event.MouseAdapter() {
 
                @Override
                public void mouseClicked(java.awt.event.MouseEvent evt) {
                    mapMouseClicked(evt);
                }
            };
            map.addMouseListener(currentMouseListener );
        }
    }

:bahnhof:

 

[sunny01]

    private MouseListener currentMouseListener;

[...]

        if (!a) {
            map.removeMouseListener(currentMouseListener);
            currentMouseListener = null;

            /*MouseListener[] ml = map.getListeners(MouseListener.class);
            for(int i = 0; i < ml.length; i++) {
                map.removeMouseListener(ml[i]);
            }*/
        }
        else {
            currentMouseListener = new java.awt.event.MouseAdapter() {
                @Override
                public void mouseClicked(java.awt.event.MouseEvent evt) {
                    mapMouseClicked(evt);
                }
            };
            map.addMouseListener(currentMouseListener );
        }

Stimmt, da kommt kein Fehler. Aber der Listener verschwindet wieder nicht.
Ändere ich in der Klasse absolut gar nichts, außer dass ich die auskommentierten Zeilen wieder einkommentiere, dann funktionierts. Versteh' gar nichts mehr :noe:

EDIT: Da sind dann immer 2 MouseListener ... hab's mir grad mal in der Entfernen-Schleife ausgeben lassen ... das gibt's doch nicht ... da können doch nicht auf einmal 2 draus werden.

 

[FArt]

Nur mal um zur Überschrift zurück zu kommen: [JavaSpecialists 056] - Shutting down threads cleanly.

Wenn du von Threads wenig oder keine Ahnung hast, dann solltest du evtl. die komfortablen Kapselungen verwenden. Für die Ausführung asynchroner Aufgaben gibt es da sehr viel Hilfe im Package java.util.concurrent, z.B. den ExecutorService.

 

[Marco13]

EDIT: Da sind dann immer 2 MouseListener ... hab's mir grad mal in der Entfernen-Schleife ausgeben lassen ... das gibt's doch nicht ... da können doch nicht auf einmal 2 draus werden.

Wenn du ein KSKB posten würdest, wäre das Problem mit an Sicherheit grenzender Wahrscheinlichkeit längst erledigt...

 

[sunny01]

Also der Fehler war der, dass an anderer Stelle in einer anderen Klasse die Funktion activateInput() ebenfalls aufgerufen wurde ... und somit waren da dann logischerweise zwei MouseListener ... einmal von der anderen Klasse "ausgelöst" und einmal in der GUI selbst ...

Liebe Grüße
sunny

PS: Und der Thread hatte, wie schon festgestellt, damit eigentlich gar nichts zu tun, nur war mir das ganz am Anfang nicht klar, da das Löschen des Threads (per stop()) natürlich alles beendet hatte und dann sah es "richtig" aus, obwohl das ganz ein anderer Effekt war. Das stoppen des Threads brauche ich so in Wirklichkeit gar nicht (sondern habe es so gemacht wie Marco gepostet hat).
Sorry für den falschen Thementitel.