Thread | Schleifenlose run-Methode unterbrechen.

[Dit_]

Hallo,
in meiner run-Methode werden folgende Schritte abgearbeitet.

Ganz grob.

1. Connecten, max. 5 Sek
2. Daten laden, x Sek.
3. Daten parsen
4. Daten anzeigen.

Es gibt noch eine Liste in der man eine Quelle anklicken kann, wurde neue Quelle angeklickt dann soll (falls die Bearbeitung der alten Quelle noch nicht abgeschlossen ist) die laufende Bearbeitung abgebrochen und eine neue gestartet werden.

Wie mache ich das am besten?
Nach jedem Schritt

if(stopped){
return;
}

einfügen ?

Danke schon mal!

 

[nrg]

von aussen interrupten und die interrupted exception catchen

 

[SlaterB]

ohne eine Zeile Code zwischen jeder Aktion geht das genauswenig,
zu catchen ist gar nur etwas während sleep()/ evtl. wait(), das macht ein arbeitender Thread ja nicht gerade..

die kürzeste Variante ist meiner Ansicht nach ein Methodenaufruf: c();
darin im Abbruchfall eine Exception werfen, die weit oben abgefangen wird

 

[Volvagia]

Ich würde es durchrennen lassen und nur vorm Anzeigen abfragen, ob der Thread noch aktuell ist. Bei kleineren Datenbeständen merkt man da sicher keinen Unterschied. Bei größeren empfiehlt es sich vermutlich sowieso, Sleeps oder Yields (die durch kurze Sleeps ersetzbar wären) einzubauen, damit der Computer noch weiter verwendbar bleibt.
Ich würde mich nicht darauf verlassen, dass jeder min. einen Dual Core besitzt.

 

[nrg]

achso hatte ich falsch gelesen. naja trotz deprecated kann man doch hier stop() verwenden.

 

[muckelzwerg]

Du kannst

if (Thread.interrupted()) {
        return;
}

verwenden, um auch außerhalb von sleep etc. den Interrupt zu finden. Ist aber auch nicht unbedingt so toll, wenn Du das überall reinwurschtelst.

 

[SlaterB]

achso hatte ich falsch gelesen. naja trotz deprecated kann man doch hier stop() verwenden.

auch das geht nicht oder hast du das schonmal erfolgreich eingesetzt?

 

[Dit_]

schade dass es keine direkte möglichkeit gibt...
Ich versuche was ganz anderes, Thread wird nicht unterbrochen, arbeitet weiter und speichert daten am schluss, um beim erneuten Klick nicht mehr laden zu müssen. Über Schaltfläche oder F5 kann man dann die Daten neuladen.

 

[nrg]

auch das geht nicht oder hast du das schonmal erfolgreich eingesetzt?

nicht direkt, weil halt deprecated. aber ich dachte, das zieht dem thread einfach die keule übern kopf. bei dem process ja eigentlich unkritisch. tut es das nicht?

 

[muckelzwerg]

Dit_, ich wollte schon fragen, ob das Zeug wirklich JEDESMAL neuberechnet werden soll.
Ist es dann nicht vielleicht sinnvoller, das überhaupt erst einmal komplett zu berechnen, oder wird das zu viel?

 

[SlaterB]

tut es das nicht?

genau, einen Thread kann niemand reinreden, außer durch Beendigung des gesamten Java-Programmes,
er kann nur so gnädig sein, selber auf Informationen von außen (Flags, Interrupt) zu reagieren,
und aus eigenen Antrieb heraus zurücktreten äh aufhören,

siehe Guttenberg, Gaddafi, Merkel & Co.

 

[Murray]

Siehe auch hier:
"It should be noted that in all situations where a waiting thread doesn't respond to Thread.interrupt, it wouldn't respond to Thread.stop either."

 

[Dit_]

Dit_, ich wollte schon fragen, ob das Zeug wirklich JEDESMAL neuberechnet werden soll.
Ist es dann nicht vielleicht sinnvoller, das überhaupt erst einmal komplett zu berechnen, oder wird das zu viel?

die Daten werden ca alle 5 min erneuert... zu kurz um sie alle immer komplett zu laden :bahnhof:

Ich wollte das nach dem Proxyprinzip implementieren, sprich lade Daten nur dan wenn du sie brauchst (anklickst).

@SlaterB
Bei Merkel und Co hilft nur eins

System.exit(1);

da DeadLock...

 

[Volvagia]

auch das geht nicht oder hast du das schonmal erfolgreich eingesetzt?

Warum nicht?
Das funktioniert bei mir, auch wenn ich es niemals in einen anderen Programm machen würde.

import java.util.concurrent.TimeUnit;

public class Stop
{
	public static void main(String[] args)
	{
		final Thread t = new Thread() {
			public void run()
			{
				long startTime = System.currentTimeMillis();
				
				do
				{
					long currentTime = System.currentTimeMillis();
					long timeDiv = currentTime - startTime;
					String secSinceStart = String.valueOf(timeDiv / 1000);
					
					System.out.println((!secSinceStart.equals("0") ? secSinceStart : "<1") + " Sekunde(n) seit " +
							"dem Start vergangen");
					
					try
					{
						TimeUnit.SECONDS.sleep(1L);
					}
					catch (InterruptedException e) {}
				}
				while(true);
			}
		};
		t.start();
		
		new Thread() {
			public void run()
			{
				try
				{
					TimeUnit.SECONDS.sleep(5L);
				}
				catch (InterruptedException e) {}
				
				t.stop();
			}
		}.start();
	}
}

 

[SlaterB]

tatsächlich, stop() funktioniert, selber nicht genug getestet,

ich habe die letzen Monate wiederholt immer frecher die Behauptung geschrieben dass es von außen nicht geht, siehe etwa
http://www.java-forum.org/allgemeine-java-themen/112143-thread-beenden-2.html#post722400
und bisher hatte mir keiner widersprochen, nun kann ich auch hier also meine Ansicht korrigieren

stop() wirft doch tatsächlich von außen eine Exception rein,
man kann sie zwar fangen und ignorieren, bei jedem Befehl einzeln aber schwer und es können noch mehr kommen..,
stop() ist deprecated und fragwürdig, aber scheint tatsächlich etwas zu bewirken

 

[muckelzwerg]

Wurde doch schon geschrieben. Du kannst das "sleep()" unterbrechen. Aber nicht einfach an beliebiger stelle zwischen den Anweisungen.
Da musst Du aktiv abfragen, ob ein Interrupt gefeuert hat.

 

[SlaterB]

doch doch, stop() wird auch ohne sleep aktiv,
hier ein Programm welches mitten in einer Summierungsschleife abbricht, allerdings danach weitermacht

class Stop  {
    public static void main(String[] args)  {
        final Thread t = new Thread()  {
                public void run()  {
                    while (true) {
                        long sum = 0;
                        try    {
                            for (int i = 0; i < 100000000; i++)   {
                                sum += i;
                            }
                        }  catch (Error e)  {   System.out.println("e: " + e);   }
                        System.out.println("sum: " + sum);
                    }
                }
            };
        t.start();

        new Thread()   {
                public void run()  {
                    try   {
                        TimeUnit.SECONDS.sleep(1L);
                    }   catch (InterruptedException e)     {   }
                    t.stop();
                }
            }.start();
    }
}

edit: vielleicht von Java-Version/ System abhängig, bei mir ist eine Ausgabe

sum: 4999999950000000
sum: 4999999950000000
sum: 4999999950000000
e: java.lang.ThreadDeath
sum: 1097075638103796
sum: 4999999950000000
sum: 4999999950000000
...

 

[Volvagia]

Ist ja kein Ding. Bei längeren arbeitenden Schleifen darf imho eine Wartezeit wegen Singlecore-Benutzern sowieso nicht fehlen (auf den Rechnern ist mit einer 100 % ausgenutze CPU kaum zu arbeiten), bei kurzen ist es auch egal ob der Thread noch rennt, weil der so schnell beendet dass man davon nicht viel mitkriegt, und eine InterruptedException tritt meines Wissens nur auf, wenn man interrupt aufruft. Das man Exception/Error/Throwable selbst catchen kann, halte ich für einen Fehler und außer gerademal in Tests für eines der schlechtesten Dinge, die man tun kann. (Wenn man nicht vor hat, JEDEN Fehler wärend der Entwicklung anzuzeigen und zu fixen, was aber als unmöglich gilt.)

 

[muckelzwerg]

Hm nee, ich sehs immernoch nicht.
Wenn Du aktiv den Interrupt prüfen willst, dann brauchst Du dafür einen Bereich, wo der auch auftreten kann. Also "Thread.sleep(0)" oder sowas. Da fängst Du die InterruptedException und reagierst darauf. (So wird es auch in den Erklärungen zu den deprecated Methoden wie stop() angegeben.)
Aber dann rufst Du doch von außen nicht doch wieder "stop()" auf, sondern "t.interrupt()".

Wenn Du unbedingt stop() verwenden willst (damit Du auch "zwischen" die Anweisungen kommst), DANN brauchst Du auch nicht die IException zu fangen, da kommt gar keine.

Wenn Du mit "Thread.interupt()" zwischen die Anweisungen treffen willst, dann musst Du dort aktiv prüfen mit "if( Thread.interrupted() )".
Das macht bei der For-Schleife den Ablauf aber extrem langsam.

 

[SlaterB]

auf wessen Code beziehst du dich eigentlich?
das catch(InterruptedException) bei Volvagia und mir steht nur da, weil man das für sleep() explizit abfangen muss, sonst kompiliert es nicht,
um interrupt() gehts gar nicht sondern um stop()

 

[muckelzwerg]

Auf euer beider Code. "Thread.interrupt()" ist nunmal NICHT deprecated im Gegesatz zu stop() und Co.
Dit_ hat keine Schleife, also macht eine Schlafphase da wenig Sinn.
Wenn er den Thread mit stop() abwürgt, dann braucht er auch nirgendwo schlafen zu gehen.
Wenn er den Thread mit interrupt() sauber abschalten will (so wie es vorgeschlagen wird), dann braucht man entweder eine Anweisung, bei der man die InterruptedException fangen kann (Dafür hatte ich bei Volvagia das "sleep" gesehen, weil es sonst doch gar keinen Nutzen hat), oder man prüft mit "Thread.interrupted()". (was im Prinzip wohl das Gleiche ist. Vielleicht sogar langsamer?)

 

[SlaterB]

was für Dit_ sinnvoll ist war nicht direkt ein Thema, auch wennn nicht völlig Offtopic denn es wird durchaus eine interessante Alternative aufgezeigt,
das Sleep mit der Exception drumherum ist allein zum Schlafen in dem Beispiel gedacht, damit nur 1 Ausgabe pro Sekunde kommt statt Millionen,
in meinem Code fehlt es im zu unterbrechenden Thread gar völlig, stattdessen lasse ich diesen die ganze Zeit arbeiten,
eben um auch zu zeigen, dass es mit sleep() nichts zu tun hat

interrupt() mit allen Aspekten ist klar,
stop() bietet zusätzlich eine andere Möglichkeit zur Einflussnahme, mehr ist gar nicht gesagt,
da stop() ohne Schlafen und ohne alles funktioniert, ist es für Dit_ vielleicht sogar interessanter, um das nochmal aufzunehmen

 

[nrg]

der grund warum stop deprecated ist, ist imho folgender (kleine veranschlaulichung):

- ein arbeiter baut ein haus
- ist zu 50% fertig
- kriegt ne keule übern kopf
- wacht auf und erinnert sich an nichts mehr
- fängt wieder beim ersten stein an
- sieht nicht, dass da schon einer liegt und fällt auf die nase...

dadurch ist keine transaktionssicherheit mehr gewährleistet. deshalb sollte man den thread freundlich beenden. dann baut der arbeiter erst das haus fertig und hört dann auch. nachdem das hier ein request ist, ist es doch gerade gewünscht, dass dieser sofort abbrucht und wieder blindlings von vorne anfängt.

wenn irgendwas nicht stimmt, korrigiert mich aber so habe ich das noch in erinnerung (arbeite seltener mit threads).

 

[muckelzwerg]

Java Thread Primitive Deprecation
Es gibt schon Situationen, wo man stop() gefahrlos benutzen kann.