Threads - aber wie?

[j-look]

Hallo Forum,

ich habe ein Programm mit GUI, das ein Datenbankergebnis in einer while-Schleife verarbeitet. Das ganze erfolgt auf Knopfdruck und innerhalb der while-Schleife können weitere Datenbankanfragen auftreten. Die eigentlichen Berechnungen werden also von mehreren Methoden durchgeführt und können mehrere Minuten dauern.

Nun würde ich gerne einen Abbruch-Button einführen und überhaupt dafür sorgen, dass die GUI währenddessen nicht blockiert ist. Dass das mit Threads geht, weiß ich. Und ich kenne auch Beispiele (wie hier).
Leider sehe ich keine Möglichkeit diese einfachen Fälle auf meine Anwendung zu übertragen.

Ich würde mich freuen, wenn ihr mir in ein, zwei Sätzen Tipps geben oder Lösungsansätze skizzieren könntet.

Vielen Dank.

 

[hdi]

Leider sehe ich keine Möglichkeit diese einfachen Fälle auf meine Anwendung zu übertragen.

Naja, ich kenn jetzt deine Anwendung nicht, aber so wie es klingt sollte das doch kein Problem sein?

Beim Klick auf den Button, der die Anfrage startet, wird ein neuer Thread gestartet,
so wie in diesen einfachen Beispielen.

Innerhalb dieses Threads werden die Datenbankabfragen beabeitet, und deine GUI
läuft weiter. Allerdings ist das bei GUI's oft etwas problematisch.
Schon mal was vom Event Dispatch Thread gehört? Auf diesen solltest du deine
GUI per invokeLater() legen, damit das auch alles funktioniert:


[HIGHLIGHT="Java"]
// wahrscheinlich in der main-Methode:
SwingUtilites.invokeLater(new Runnable(){
@Override
public void run(){
new meineGui().setVisible(true);
}
}[/HIGHLIGHT]

Und dann hast du noch einen Abbruch-Button. Dieser Button setzt zB ein boolean.

So á la:

click on abort -> shouldAbort = true;

dieser boolean shoudlAbort wird von deinem Anfrage-Thread genutzt.
Seine while-Schleife sieht so aus:

[HIGHLIGHT="Java"]while(!shouldAbort && deineBedingung ){...}[/HIGHLIGHT]

D.h. der Thread bricht ab und verlässt seine run-Methode wenn du auf abort drückst.
Jetzt ist natürlich die Frage inwiefern du mitten in der Anfrage das machen kannst.
Musst halt diese Abfrage an geeigneten Stellen einbauen, damit er möglichst schnell
mitbekommt, dass er aufhören soll.

Ansonsten sollte das eig. kein grosses Problem sein.

 

[faetzminator]

So á la:
click on abort -> shouldAbort = true;

Für das gibt es
someTread.interrupt();
bzw.
!this.isInterrupted()

 

[hdi]

Hm nee:

Interrupting Java threads

 

[musiKk]

Naja, kommt drauf an, das geht auch.

Das boolesche Flag nützt einem, wie im Hinweiskasten beschrieben, bei sleep() und join() nichts. Mittels interrupt() wird das dort mit einer entsprechenden Exception beendet.

 

[j-look]

Danke für eure Antworten.
Bei den einfachen Beispielen klappt das mit der Boolean-Variable und dem Button. Das ist nicht das Problem. Das Problem ist viel eher, dass der Button wie auch die gesamte GUI blockiert ist.

Wenn ich meine Methode in einen Thread packe, läuft das zwar über meinThread.start(), aber die GUI bleibt blockiert. Ich skizziere mal kurz:

public class MeinThread extends Thread {
   public void run() {
      Runnable r = new Runnable() {
         public void run() {
             ...
             Schleife mit DB-Abfragen ...
             ... und diversen static-class-Aufrufen ...
             ... ein Schleifendurchgang kann viele Sekunden dauern
             ...
         }
         while (isMeinThreadStarted()) {
            MeineGUI.getDisplay().asyncExec(r);
            try {
               sleep(0);
            }catch(InterruptedException e) {}
         }
      }
   }
}

 

[SlaterB]

liegt vielleicht an seltsamen Dingen wie
> meineGUI.getDisplay().asyncExec(r);

was soll dazu ein Unwissender sagen?
wenn r vom AWT-Thread ausgeführt wird, dann ist nix gewonnen,

wie der Thread meinThread (Klassen groß schreiben!) vom ActionListener aufgerufen wird, ist auch nicht zu sehen

 

[j-look]

liegt vielleicht an seltsamen Dingen wie
> meineGUI.getDisplay().asyncExec(r);

was soll dazu ein Unwissender sagen?
wenn r vom AWT-Thread ausgeführt wird, dann ist nix gewonnen,

wie der Thread meinThread (Klassen groß schreiben!) vom ActionListener aufgerufen wird, ist auch nicht zu sehen

Das kleingeschriebene werde ich oben korrigieren, im Programm hat das natürlich einen aussagekräftigeren Namen.
Zu dem Display bzw. meineGUI sollte ich noch sagen, dass ich SWT verwende, also kein AWT oder Swing.

 

[Gast2]

Du lässt deine ganze Arbeite deinen GUI Thread machen, darum ist alles blockiert...
dass asyncron ist dafür da um was in deiner GUI zu machen... z.B. ein refresh oder eine progressbar zu aktualisieren...

 

[j-look]

Du lässt deine ganze Arbeite deinen GUI Thread machen, darum ist alles blockiert...
dass asyncron ist dafür da um was in deiner GUI zu machen... z.B. ein refresh oder eine progressbar zu aktualisieren...

Danke fürs Lichteinschalten!
Jetzt läuft die Sache.

 

[j-look]

Hm, der Thread läuft jetzt und die GUI ist nicht blockiert.
Jetzt ist nur noch die Frage: Wie bekomme ich Ausgaben, die im Thread erzeugt werden, in die GUI?

 

[SlaterB]

neues Runnable,
MeineGUI.getDisplay().asyncExec(r);
wie das anscheinend unter SWT heißt

und eigenen Thread gegebenfalls warten lassen, bis das fertig ist

 

[j-look]

Ja, von der Form her wie oben.
Vielen Dank für die Hilfe.

 

[Gast2]

Aber pass auf was du verwendest ob ein async oder sync...

 

[Leroy42]

Schon mal was vom Event Dispatch Thread gehört?
Auf diesen solltest du deine GUI per invokeLater() legen, damit das auch alles funktioniert:

:noe:

Das GUI ist doch schon von Haus aus im EDT! ???:L

 

[SlaterB]

gemeint ist doch offensichtlich der Aufruf von setVisible(true),
für den das anscheinend nicht gilt

 

[hdi]

Nein nein, es geht hier nicht um setVisbile(true).

Eben weil Swing/AWT Komponenten auf dem EDT laufen (automatisch),
ist dieser Thread bei einem GUI Programm aktiv.

Wenn man nun noch einen anderen ziemlich aktiven Thread hat, kracht's.

Deshalb legt man gleich sein komplettes Programm auf den EDT. Für die GUI
macht das keinen Unterschied weil die eh dort landet, aber für den Rest der Programm-Logik
schon, weil die dann auch da drauf läuft.

 

[eliot]

Schau die dir mal folgende Klasse an: SwingWorker (Java Platform SE 6)
Oder hier: Galileo Computing :: Java ist auch eine Insel (8. Auflage) – 16.25 AWT, Swing und die Threads

Die bietet exakt das gewünschte!

regards
eliot