Thread beenden (gnadenlos und ohne rücksicht auf Verluste) ?

[Oli]

Hallo,

ich habe einen Thread der mir Daten aus einer Datenbank schaufelt. Dieser wird vom Benutzer über einen Button gestartet. (In der Applikation gibt es mehrere Buttons, die verschiedene Tabellen auslesen und die Daten auswerten). Das ganze ist auch timergesteuert ist (also wenn Daten angezeigt werden, dann werden diese alle 10 Min. aktualisiert).
Mein Problem ist nun, dass ich erreichen möchte, dass wenn ein Button gedrückt wird und Daten geholt werden und in dieser Zeit ein zweiter Button gedrückt wird, dass der erste Thread gekillt wird. Imoment löse ich das indem ich den thread = null setze, aber ich glaube, das ist nicht die beste lösung...

Wie kann ich einen Thread beenden und eben wie oben geschrieben, gnadenlos und ohne rücksicht auf Verluste ?

Thread.stop() ist ja veraltet....

Grüße Oli

 

[Niki]

Ich bezweifle dass du den Thread killst indem du die Referenz auf null setzt...

Ist es richtig dass du den Thread einfach schlafen legst und der nach 10 Minuten weiter arbeitet? Wenn du es sauber machen willst solltest du es ca. so machen:

public class MyRunnable implements Runnable{
  private boolean running = true;

  public void run(){
    while(running){
      //tu hier was
      synchronized(this){
        //10 Minuten warten
        try{
          this.wait(10 * 60 * 1000);
        }catch(InterruptedException ex){
        }
      }
    }
  }

  public synchronized void stop(){
    running = false;
    this.notify();
  }
}

Wird vom Runnable Objekt die stop Methode aufgerufen wird sofort beendet, und das ganze ist auch noch schön sauber.

 

[GRudiD]

Du hast doch in der run()-Methode eine Schleife zu laufen. In der musst du nur abfragen, ob ein bestimmter Wert (boolean abbrechen) true ist (sollte man per Klick auf deinen Abbrechen-Button setzen können). Dann verlässt du die Schleife, die Methode wird korrekt beendet und der Thread anschließend auch.

Bsp:

public boolean abbrechen = false;
public void run() {
 // hole Daten aus DB
 while (resultSet.next()) {
  if (abbrechen)
   break;
  // tue was
 }
}

 

[GRudiD]

@Niki: Ok, warst wohl schneller :applaus:

 

[Oli]

Hi,

ja so hab ich das ja auch. Allerdings ist das Problem das die Daten nicht nur aus der DB geholt werden, sondern verschiedene Prozeduren aufgerufen werden, die Berechnungen durchführen. Naja und dann wird auch noch das UI gebaut und upgedatet...
Dann müsste ich nach jeder Rückkehr aus einer Prozedur abfragen ob running == true, wenn nicht, dann break?

Grüße Oli

 

[Niki]

Richtig, aber nicht break, sondern return
So programmiert man multithreaded. Der Thread muss selber wissen ob er weiter laufen darf oder nicht, und das macht man halt am besten über Flags. Bei jeder Schleife sollte dieses Flag abgefragt werden und nach jeder atomaren (heißt das so) Funktion/Transaktion.

 

[Gast]

bei aktionen, die sehr lange dauern können, sollte man sich zusätzlich überlegen, die neue aktion sofort in einem weiteren thread zu starten und dem bereits laufenden schlicht mitzuteilen, dass er bei nächster gelegenheit die arbeit einstellen und die ergebnisse verwerfen kann.

wenn man sowas nicht macht, kann es recht schnell passieren, dass z.b. lange datenbankabfragen, die schon gar nicht mehr benötigt werden, die abarbeitung neuer aufgaben verzögern,

 

[Beni]

Der übliche Weg Threads anzuhalten ist der "interrupt"-Mechanismus.

Von dem kommt auch die ominöse "InterruptException", denn wenn auf einem Thread interrupt aufgerufen wird, werden alle Pausen und auch IO-Operationen automatisch abgebrochen.

 

[FArt]

Der übliche Weg Threads anzuhalten ist der "interrupt"-Mechanismus.

Von dem kommt auch die ominöse "InterruptException", denn wenn auf einem Thread interrupt aufgerufen wird, werden alle Pausen und auch IO-Operationen automatisch abgebrochen.

Die InterruptedException wird aber nur geworfen, wenn ein Thread gerade blockiert (wait, sleep, blockierender Socket...). Ein laufender Thread muss regelmäßig abfragen, ob er unterbrochen werden soll, z.B. mit Thread.currentThread().isInterrupted().

Nikis Variante ist übrigens auch nicht konsistent. Das Flag (running) muss mit dem Schlüsselwort volatile deklariert werden, weil sonst der Thread u.U. das setzen des Flags nicht mitbekommt (siehe JSR-133 oder die Java-Spec oder als Tipp an den Ursprungsposter: schau doch mal selber bei SUN bevor du postest, einfach über Google zu finden: http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html)

 

[Niki]

Das mit dem volatile überreiß ich nicht ganz. Warum sollte das der Thread nicht mitbekommen? Könntest du das etwas näher erläutern?

 

[FArt]

Die VM darf hier eine Optimierung vornehmen: in der Schleife kann (muss aber nicht) der Wert aus der Variable aus Gründen der besseren Performance im Prozessorchache oder einem Register vorgehalten werden. Mit dem Identifier "volatile" wird dies verhindert.

Diese Optimierung macht nur bei konkurrierenden Zugriffen Probleme, deswegen muss der Entwickler um eine korrekte Synchronisation kümmern. Wer mit Nebenläufigkeiten arbeitet, muss m.E. die JSR-133 einmal gelesen haben... viele werden überrascht sein...

 

[Niki]

Bei dieser Schleife gibts ja gar nichts zu optimieren, da wird ja nichts im Körper gemacht sondern nur abgefragt.
Bei so einer Schleife hätte es ja Sinn:

for(int i = 0; i < 1000000; i++){
  count += i;
}

Aber bei meiner Schleife finde ich nicht

 

[FArt]

Schau dir doch einfach das von mir verlinkte Beispiel von SUN an und lies dir die JSR durch...

Volatile benötigt man nicht nur bei 64bittigen Werten und lokalen Zählern.

Deine Lösung ist inkonsistent, weil du zwar die stop-Methode synchronisiert hast, aber das Flag auch außerhalb der Synchronisation gelesen wird. Das kann vom Compiler derart optimiert werden, dass die while-Schleife immer einen Wert auswertet, der nicht frisch aus dem Heap stammt.

Volatile verhindert das. Außerdem spart man sich dann notify() und wait() und den relativ langsamen Monitor über den synchronized-Block... und nicht zuletzt das, macht den Code unkomplizierter und lesbarer...

 

[Niki]

Wie kann man sich wait und notify sparen? Ohne denen werd ich den Thread kaum für 10 Minuten warten lassen können bzw. früher aufwecken, falls notwendig.

 

[FArt]

Thread#sleep und wie schon erwähnt Thread#interrupt behandeln. Damit kann man sich übrigens auch das Flag sparen. Beni hat schon gesagt wie man das macht.

Deine Technik wird von SUN vorgeschlagen um suspend und resume zu realsieren. Allerdings steckt der Teufel (der in deren Fall die Konsistenz schafft) im Detail: das Flag um das es geht wird nur in kritischen Bereichen (mit synchronized abgesichert) verwendet... im Unterschied zu deinem Vorschlag, wo das auch außerhalb passiert. Nur dann ist die Konsistenz gegeben!!

Aber wie gesagt: einfach dem Link folgen, da steht das alles...

 

[Niki]

Ich weiß dass das Flag auch außerhalb von synchronized abgefragt wird. Was wäre wenn man es so löst:

while(true){
  synchronized(this){
    if(!running){
      return;
    }
  }
  //tu was
  synchronized(this){
    try{   
      this.wait(10 * 60 * 1000);
    }catch(InterrupedException ex){
   }
  }
}

 

[FArt]

Yepp, bzgl. dem Flag "running" wäre das ok, denn jetzt wird die Variable konsistent gelesen/geschrieben, und zwar immer aus dem Heap.

Der einzige "kleine" Nachteil gegenüber "volatile": die Synchronisation über volatile ist schneller ...

 

[Niki]

Passt, wieder was dazugelernt. Besten Dank!