stop() vs. interrupt()

[ulr!ch]

Hi JavaGemeinde,

hier 'ne Frage an die Spezialisten, wieso kann ich einen Thread in einer externen Klasse mit stop() stoppen, wohingegen bei interrupt() eine kurze Verzögerung auftritt, aber dann der Prozess (eine JProgressBar) weiterläuft?
Eigentlich sollte es mir ja egal sein, weil es funktioniert, aber der Befehl wurde ja als verworfen eingestuft.
Why?

By<e Ulrich

 

[DP]

keine ahnung. habe mit threads nichts am hut.

jedoch ist es (lt. gedächtnis) so, dass interrupt den thread anhält (mit resume gehts dann weiter), stop diesen dagegen beendet.

wurde imho als deprecated eingestuft, weil es imho nicht threadsicher ist.

kann aber auch alles absoluter schachsinn sein, was ich erzähle

mea culpa

 

[ulr!ch]

mhm...
also ich habe jetzt gefunden, dass stop() von außen beendet und interrupt() von innen heraus.
Das würde erklären, wieso in o. a. Beispiel nur stop() funktioniert, weil es ja halt eine externe Klasse ist.
Aber wie kann ich das in einer non-deprecated-Version schreiben?

By<e Ulrich

 

[Icewind]

also so weit ich weis und wies in der api steht ist stop() deprecatet und unschön... wenn du deinen thread beenden willst machst du myThread.interrupt() und in dem thread musst du auf isInterrupted() überprüfen und wenn das gesetzt ist dann musst du deinen thread auslaufen lassen... halt er sollte sich dann selbst beenden...

 

[ulr!ch]

also so weit ich weis und wies in der api steht ist stop() deprecatet und unschön... wenn du deinen thread beenden willst machst du myThread.interrupt() und in dem thread musst du auf isInterrupted() überprüfen und wenn das gesetzt ist dann musst du deinen thread auslaufen lassen... halt er sollte sich dann selbst beenden...

Soweit die Theorie...
Wenn ich aber diese Progressleiste in einer externen Klasse habe, kann ich nicht mehr prüfen, ob der referenzierte thread der Hauptklasse isInterrupt() oder nicht, da zum Zeitpunkt der Erzeugung der Thread ja noch lief und erst später durch Eingaben des Users unterbrochen werden kann.

By<e Ulrich

 

[DP]

hmm.. da gibt es noch (deprecated) suspend...

 

[Beni]

Und zu all den deprecated-Methoden der Klasse Thread hat es seitenlange Texte, wieso sie keinesfalls mehr verwendet werden sollen... :wink:

 

[pappenpeter]

Die eingebauten Funktionen wie interupt, stop usw. sind allesamt entweder deprecated oder unschön zu handeln.

Scheib dir am einfachsten 3 Methoden start, stop und destroy wegen mir.

private volatile boolean stop = true;
private volatile boolean destroy = false;

public void stopThread() {
this.stop = true;
}

public void startThread() {
this.stop = false;
}

public void destroy() {
this.destroy = true;
}


// Hier beginnt run

public void run() {
while (!destroy) {
        while (stop) {
                 sleep(1);
        }
// Tu irgendwas tolles bis destroy = true;
}

// wenn Destroy true endet Thread

so oder so ähnlich. Ist recht einfach und du weißt was passiert.

 

[Icewind]

also interrupt() ist nicht deprecated und meiner meinung nach auch nicht unschön...

 

[pappenpeter]

Naja, da scheiden sich die Geister nun mal. Ich bin ja nicht abgeneigt Dinge aus der Api zu übernehmen und nur ein Idiot würde sich sachen wie Sortieralgorithmen selbst implementieren.. Aber in sachen Threads bin ich mir da nicht so sicher.. Bleibe lieber bei selber gemachtem. Macht ja jetzt auch nicht so den Aufwand die 10 Zeilen.. :wink:

 

[Icewind]

naja was du implementierst ist mehr oder weniger das interrupten nur kann deine methode ein sleep() nicht unterbrechen

 

[Roar]

außerdem müsstest du, damit bei dir der thread abgeschossen wird entweder in destroy() auch stop auf false setzen oder in deiner inneren while schleife noch auf !destroy prüfen, sonst ist destroy zwar true, aber dein prog führt weiter die inenre while schleife aus

 

[pappenpeter]

ja, klar. Wie gesagt, das war nur schnell hin geschieben.

 

[ulr!ch]

Also wenn ich das mal alles zusammenfassen sollte, dann würde hier stehen:
a) Es gibt keine Alternative zu stop(),
b) stop() sollte ich nicht verwenden (seitenlange Erklärung in der API @beni) und
c) für das angesprochene Problem mit einem eigenständigen Thread in einer externen Klasse gibt es keine unmittelbare Lösung.
d) Alternativen Lösungen gehen in Richtung for-Schleife, die einen Thread fortsetzen oder wiederaufrufen und nur wenn eine Bedingung auf false gesetzt wird, dann findet ein Abbruch der for/ while-Schleife statt.

Stimmt das soweit?
Wieso kann man nicht irgendwie à la Taskmanager einfach den Thread von außen terminieren?

By<e Ulrich

 

[Reality]

Hi!
In Java 2 ENT-PACKT steht folgendes:
1. Thread.stop() kann keine Threads mehr fortsetzen
2. Thread.stop() kann zu schweren Systemfehlern führen, da wenn man z.B. wichtige Datenstrukturen schreibt und erst ein Teil der Änderungen vollendet ist und man stoppt, bleibt diese unvollständige und fehlerhafte Änderungen vorhanden.

Liebe Grüße
Reality

 

[Gast]

Nochmal zum Verständnis von Stop und Interrupt:

Beide Funktionen sollen unterschiedliche Aufgaben erfüllen (nicht nur in Java, sondern allgemein in Prozessen). Wie die Namen schon sagen: Stop = Beenden, Interrupt = Unterbrechen. Und aufgrund der Allgemeingültigkeit sollte man sie auch so benutzen.

Das Deprecated-Problem:
Ich habe keine Ahnung, wie Sun seine Methoden implementiert hat. Auf jeden Fall sind sie wohl nicht sicher, da nicht genau definiert werden kann, an welchem Punkt der Thread beendet wird.
Die Methode von pappenpeter verwende ich daher auch, nur bei mir sieht die run noch minimal ander aus, um abbrechen und unterbrechen zu gewährleisten:

public void run() {
while(!isStopped) {
if (!isInterrupted) {
// Inhalt der run-Methode, inklusive Verzögerung (wenn benötigt)
}
}
}


Damit ist auf jeden Fall sichergestellt, dass der Thread an definierter Stelle beendet wird und somit sollte die Sache sicher sein.

 

[Elandriel]

hier 'ne Frage an die Spezialisten, wieso kann ich einen Thread in einer externen Klasse mit stop() stoppen, wohingegen bei interrupt() eine kurze Verzögerung auftritt, aber dann der Prozess (eine JProgressBar) weiterläuft?
Eigentlich sollte es mir ja egal sein, weil es funktioniert, aber der Befehl wurde ja als verworfen eingestuft.
Why?

Weil mit stop() unvorhersehbare sachen passieren können, es ist nicht genau definiert an welcher stelle im code dadurch abgebrochen wird.
Ein interrupt() kannst du hingegen selbst mit isInterrupted() abfragen und entsprechend reagieren:

public void run() {
      while(true) {         
        
        if( isInterrupted() || allThreadsStopp ) {                   //Thread gezielt stoppen            
            // bla

            break;  //stop();
        }        
                
              
        try {  sleep(slt);   }   
        catch( InterruptedException e ) {   }        
      }
   
    }

gruss

 

[ulr!ch]

Hi JavaGemeinde,

ich habe das jetzt mal umgesetzt, was ihr hier zusammengetragen habt. Noch einmal vielen Dank an dieser Stelle.
Das sieht nun so aus:

int u=0;
while (!this.isInterrupted()) {
  u++;
  try {
    thread.sleep(1);
    bar.setValue(bar.getMaximum()*u/10000);
  }
  catch (InterruptedException ie) { }
}

Das funktioniert auch in 98% der Fälle, aber in zwei Prozent kriege ich eine IE.
Wieso weiß der Teufel.

Wieso schreibe ich nicht einfach:

for (int u = 0; u<=10000; u++) {
  try {
    thread.sleep(1);
    bar.setValue(bar.getMaximum()*u/10000);
  }
  catch (InterruptedException ie) {
    break;
  }
}

Ist das uncool ( 8) ) über die Exception zu gehen?
Für Rat bin ich dankbar.

By<e Ulrich