Probleme beim Beenden eines Threads

[Milo]

Hallo,

ich lasse in einem Thread eine iterative Berechnung durchführen. Über einen Statuscode kann ich abfragen, ob die Berechnung noch läuft oder beendet wurde. Der entsprechende Code sieht somit wie folgt aus:

if (aaa2d != null) 
  new Thread( aaa2d ).start();

while (true) {
  status2d = (aaa2d == null)?100:aaa2d.getCurrentEstimationStatus();
				
  //System.out.println("Berechnungsstatus " + status2d);
  if (status2d != 0) {
    break;
  }
}
System.out.println("ENDE");

Solange die Berechnung läuft, ist der Status 0. Bricht die Berechnung ab - warum auch immer - ändert sich dieser Wert auf 1 oder -1.

Lasse ich den Code so, wie gezeigt, wird die while-Schleife nicht mehr verlassen. Entferne ich den Kommentar bei System.out.println innerhalb der Schleife, sehe ich, wie der Staus irgendwann von 0 auf 1 springt und die Schleife sofort beendet wird. Wie kann das sein?

In meiner run-Methode, die gestartet wird, wird der Status auch korrekt ausgegeben:

public void run() {
  this.adjust();
  System.out.println(this.getCurrentEstimationStatus()); // liefert 1
}

Kann mir einer einen Tipp geben, warum das so ist?

Gruß Micha

 

[Marco13]

Ein bißchen mehr Kontext könnte hilfreich sein. Es klingt, als sollte das eher durch ein wait/notify gelöst werden: Der eine Thread ist ja zu 100% damit ausgelatet, ständig den status abzufragen. Es KÖNNTE auch sein, dass dieser "status" innerhalb der Berechnung einfach als "volatile" deklariert werden muss. Ohne mehr Infos ist's schwer da genaueres zu sagen...

 

[Andi_CH]

Kann ich nicht nachvollziehen. Wird bei dir
System.out.println("ENDE");
ausgeführt?

Grundsätzlich funktioniert der Code nämlich.

		int status2d = 0;
		while (true) {
			System.out.println(status2d);
			//System.out.println("Berechnungsstatus " + status2d);
			if (status2d != 0) {
				break;
			}
			status2d++;
		}
		System.out.println("ENDE " + status2d);

Output:

0
1
ENDE 1

 

[Marco13]

Ich schätze, dass die Ursache in "aaa2d.getCurrentEstimationStatus()" liegt ... wie auch immer die genau aussieht...

 

[Andi_CH]

nur wenn Zeile 7 - system.out.println wirklich einen Wert != 0 liefert muss der Thread doch terminieren, egal wie die Methode aussieht ???:L

 

[ThreadPool]

nur wenn Zeile 7 - system.out.println wirklich einen Wert != 0 liefert muss der Thread doch terminieren, egal wie die Methode aussieht ???:L

Tut er doch auch..., ist nur etwas unglücklich ausgedrückt. Der TO schreibt "Entferne ich den Kommentar ...", damit meint er er kommentiert die Codezeile ein, sprich er entfernt die Slashes.

 

[Andi_CH]

Das habe ich schon so verstanden, nur schreibt er oben:

[ZITAT]
Lasse ich den Code so, wie gezeigt, wird die while-Schleife nicht mehr verlassen. Entferne ich den Kommentar bei System.out.println innerhalb der Schleife, sehe ich, wie der Staus irgendwann von 0 auf 1 springt und die Schleife sofort beendet wird. Wie kann das sein?
[/ZITAT]

Aber das würde ja heissen dass die sysout-Zeile das Verhalten des loops beeinflusst?
Wenn das aufgeklärt ist, ist es etwas für die Rätselecke ;-)

 

[ThreadPool]

Das habe ich schon so verstanden, nur schreibt er oben, dass der loop nicht verlassen wird, wenn die sysout-Zeile aktiviert ist ...

Aber das würde ja heissen dass die sysout-Zeile das Verhalten des loops beeinflusst?
Wenn das aufgeklärt ist, ist es etwas für die Rätselecke ;-)

Er schreibt das die while-Schleife nicht verlassen wird wenn die Ausgabe deaktiviert ist. Zitat: "Lasse ich den Code so, wie gezeigt...", und der Code wie gezeigt enthält die auskommentierte Ausgabe.

Ich zitiere mal Marco: "...eine Thread ist ja zu 100% damit ausgelatet, ständig den status abzufragen". Damit blockiert er IMHO auch prima den Rechenthread. Durch die Ausgabe wette ich das der Rechenthread abundzu mal ein wenig Zeit zugeteilt bekommt und es dann irgendwann mal schafft fertig zu sein. Ein derart aktives Warten ist eben nicht so der Burner...

 

[Milo]

Hallo,

ThreadPool hat es schon richtig erkannt. Es sieht so aus, als hätte das (nicht) vorhanden sein meiner Testausgabe einen Einfluß aus Ergebnis. Lasse ich keine Kontrollausgabe mitlaufen, wird die Schleife nie beendet. Grundsätzlich muss in der Schlefe nur irgendwas passieren. Es reicht hier zB auch einfache ein Thread.sleep(10) aufzurufen und schon wird irgendwann das Ende erreicht. Die Methode aaa2d.getCurrentEstimationStatus() liefert nur den Wert eines Integers zurück.

public void run() {
  this.adjust();
  System.out.println(this.getCurrentEstimationStatus()); // liefert 1
}

Die Methode wird beim Starten meines Threads aufgerufen. In der Methode adjust werden die Berechnungen ausgeführt und eine Statusvariable nach Ablauf der Berechnung geändert. Diese Statusvariable lasse ich dann mit getCurrentEstimationStatus() ausgeben.

Wie der Kommentar bereits andeutet, sehe ich auf der Konsole, hier eine 1 nach erfolgreicher Berechnung. Trotzdem wird die while-Schleife nicht verlassen als würde innerhalb dieser der Status nicht abgefragt werden. Die Ausgabe von System.out.println("ENDE"); erhalte ich also nicht.

Die Berechnung läuft auch fix durch. Ich kann mir hier Ausgaben machen auf der Konsole, die alle zeitnahe zu sehen sind. Die Schleife endet trotzdem nicht.

Zwei Sachen sind vielleicht noch wichtig(?) zu wissen. Den Berechnungsthread starte ich innerhalb eines anderen Threads. Den beschrieben Test habe ich nur in Eclipse durchgeführt - die Anwendung also nicht unabhängig mal über die Konsole gestartet.

Meine Lösung im Moment sieht so aus, dass ich der laufenden JProgressBar einfach mit setString() innerhalb der Schleife ein paar Werte übergebe zum Anzeigen.

Grundsätzlich könnte Marco aber recht haben, dass ich mich mal mit wait/notify beschäftigen sollte. Die Schleife ist ja nur da, um irgendwann das Ende zu haben und Anwender ein Ok oder Nicht-Ok zu liefern und dann die Daten zu speichern.

Gruß Micha

 

[Marco13]

Die Methode aaa2d.getCurrentEstimationStatus() liefert nur den Wert eines Integers zurück.

... der vermutich von einen anderen Thread auf einen Wert !=0 gesetzt, wird. Davon kriegt der while-Thread erstmal nicht unbedingt was mit. Mach den integer (zumindest für einen schnellen Test) mal "volatile" und schau ob's dann geht, wenn nicht, kann man ja nochmal schauen...

 

[Milo]

Hallo Marco,

ich habe folgendes gemacht:

volatile int currentEstimationStatus = BUSSY; // 0 als Startwert

die Methode, die diesen Wert zurückliefert, bleibt unverändert:

public int getCurrentEstimationStatus() {
  return this.currentEstimationStatus;
}

und wenn ich das gemacht habe, funktioniert es. Deine Vermutung ist also korrekt - nur, was heißt das jetzt?

Ein wenig mehr Code kann ich schon zeigen. Die Threads sind bei mir nur da, damit die Oberfläche nicht "steht". Die Berechnung erfolgt hier in der Methode adjust() (Zeile 76), wobei die eigentliche Rechnung in calculateApproximatedValues() (Zeile 99f) stattfindet, wo der Status ermittelt wird. Diesen Thread starte ich in einem Dialog-Fenster in der Methode startAdjustment() (Zeile 207). Wobei ich in Zeile 250 dort diese Ausgabe mache, damit in der Schleife etwas passiert. Lasse ich diese Zeile weg, lande ich bisher immer in einer Endlosschleife.

Hilft Dir bzw. Euch das weiter?

Gruß Micha

EDIT: Link korrigiert

 

[FArt]

@Andi_CH
Du musst jetzt Marco13 anmeckern, dass er schon wieder bei dem gleichen Problem auf der Synchronisation herumreitet ;-)

 

[ThreadPool]

AutomatedApproximationAdjustment wie ist da getCurrentEstimationStatus() implementiert?

 

[Milo]

Hi,

AutomatedApproximationAdjustment wie ist da getCurrentEstimationStatus() implementiert?

wie oben verlinkt und gezeigt. Es wird einfach nur der Staus übermittelt:

public int getCurrentEstimationStatus() {
  return this.currentEstimationStatus;
}

Die Variable wird nach der Berechnung in adjust() gesetzt:

public void adjust() {
  if (this.points != null && this.points.size() > 0) {
    List<PointBundle> systems = this.getBundles(this.points);
    if (this.targetSystem != null && (!this.isFreeNet || (this.isFreeNet && !this.estimateDatumPoints)))
      systems.add(this.targetSystem);
    this.currentEstimationStatus = this.calculateApproximatedValues(systems);
    systems = null;
  }
  else
    this.currentEstimationStatus = BundleTransformation.ERROR_FREE_ESTIMATION;
}

Gruß Micha

 

[Marco13]

@Andi_CH
Du musst jetzt Marco13 anmeckern, dass er schon wieder bei dem gleichen Problem auf der Synchronisation herumreitet ;-)

Muss ich daran irgendwas verstehen, oder war das ein Flame der sich auf irgendeinen anderen Thread bezog? ???:L

@Milo: Es gibt da ... "diffizile Details" des Java Memory Modells... ich versuche i.a. auf solche Dinge zu umschiffen (wie angedeutet wäre in diesem Fall ein wait/notify ohnehin besser als dieses "busy waiting" :autsch: ) aber der Grund, weswegen ich auf das "volatile" getippt hatte, geht aus diesem Video hervor: JAX TV: Java-Programmierung im Multicore-Zeitalter - ist etwas länger, lohnt sich aber IMHO wirklich, sich das anzusehen.

 

[Andi_CH]

Muss ich daran irgendwas verstehen, oder war das ein Flame der sich auf irgendeinen anderen Thread bezog? ???:L

Ich verstehs auch nicht - egal.

Ich hab den Hinweis auf die Auslastung echt übersehen - das solls geben.

Aber eine Frage zum Multithreading:
Ich habe nur einen Hinweis gefunden(hier) dass die Art des Schedulings nicht spezifiziert sei - aber gibt es Hinweise darauf?
Ist es wirklich non preemptive?

 

[ThreadPool]

Die JVM greift beim Scheduling auf das OS zurück.

 

[VfL_Freak]

Moin,

Ich verstehs auch nicht - egal.

ich verstehe es - vermutlich - schon .....

Gruß
Klaus

 

[Milo]

Hallo,

wie angedeutet wäre in diesem Fall ein wait/notify ohnehin besser als dieses "busy waiting"

Versuch 1 ;-)

synchronized(this) {
	if (aaa2d != null) {
		new Thread( aaa2d ).start();
	}
	if (aaa1d != null) {
		new Thread( aaa1d ).start();
	}
	if (aaa1d != null || aaa2d != null) {
		try {
			wait();
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
	}
					
	System.out.println("ENDE ERREICHT");
}

Ich starte in Abhängigkeit der Daten ggf. zwei Berechnungen gleichzeitig. Das Ende wird ja nun erreicht, wenn der erste fertig ist. Sollte auch eine zweite Rechnung noch laufen, wäre dies also zu früh. Welche Möglichkeit habe ich, auf den "letzten" Thread zu warten?

Gruß Micha

 

[FArt]

Ich starte in Abhängigkeit der Daten ggf. zwei Berechnungen gleichzeitig. Das Ende wird ja nun erreicht, wenn der erste fertig ist. Sollte auch eine zweite Rechnung noch laufen, wäre dies also zu früh. Welche Möglichkeit habe ich, auf den "letzten" Thread zu warten?

Gruß Micha

Ist eigentlich das Producer-Consumer Problem.

Wenn mehrere Beteiligte einen Punkt abwarten sollen, ist eine Barriere das richtige: CyclicBarrier (Java 2 Platform SE 5.0)

Überhaupt empfehle ich nicht selber mit Threads rumzuklöppeln, wenn es u.U. besser geht. Für viele Probleme gibt es Lösungen im Package java.util.concurrent (Java 2 Platform SE 5.0)

Lesson: Concurrency (The Java™ Tutorials > Essential Classes)

 

[Milo]

... ich lege es mal in den Lesezeichen ab. Ich habe mich jetzt erstmal beholfen, indem ich die Threads nacheinander synchronisiert starte. Die while-Schleife ist somit erstmal weg.

Gruß Micha

 

[Milo]

Hallo,

um nun die Threads doch parallel zu starten, habe ich meine beiden Berechnungen nun in einer Map gespeichert. Satt notify() aufzurufen am Ende der jeweiligen Berechnung, teile ich meinem Dialog nur mit, das diese Berechnung beendet ist:

public void run() {
	try {
		System.out.println("START ADJUSTMENT");
		this.adjust();
		System.out.println("FINISHED ADJUSTMENT");
	} finally {
		if (this.syncObj != null)
			synchronized (this.syncObj) {
				if (this.syncObj instanceof AutomatedApproximationAdjustmentDialog) {
					((AutomatedApproximationAdjustmentDialog)this.syncObj).finished(this);
				}
				else
					this.syncObj.notify();
			}
	}
}

In der Dialog-Klasse prüfe ich nun, ob alle Threads beendet wurden, in dem die Map durchlaufe. Ist dies der Fall, rufe ich notify() auf.

	public void finished(AutomatedApproximationAdjustment autoApprox) {
		if (!this.autoApproxObjs.containsKey(autoApprox))
			return;
		this.autoApproxObjs.put(autoApprox, true);
		boolean isComplete = true;
		for (Boolean b : this.autoApproxObjs.values() ) {
			if (!b) {
				isComplete = false;
				break;
			}
		}
		if (isComplete)
			super.notify();
	}

Kann das irgendwie zu Problemen führen oder ist das okay so?

Gruß Micha

 

[FArt]

notify macht nur mit wait Sinn...

Noch mal mein Hinweis auf das hervorragende Package java.util.concurrent

[EDIT]
und nur innerhalb von synchronized-Blöcken über den selben Monitor...

 

[Milo]

notify macht nur mit wait Sinn...

Der ist da und sieht fast unverändert aus wie hier gezeigt:

synchronized(this) {
	for (Thread t : aaaThreads) {
		t.start();
	}
	try {
		this.wait();
	} catch (InterruptedException e) {
		e.printStackTrace();
	}
}

Noch mal mein Hinweis auf das hervorragende Package java.util.concurrent

Das sieht im Moment auch nicht leichter aus als das andere. ;-)


Schöne Grüße
Micha

 

[ThreadPool]

Das sieht im Moment auch nicht leichter aus als das andere. ;-)

Nur, weil du nicht weisst wo du schauen musst. FutureTask wäre z.B. was zum Nachschauen, davon könntest du erben und die protected done() - Methode überschreiben die ein Event wirft wenn der Task fertig ist. FutureTask erlaubt dir sogar auf eine sichere Art anzufragen ob ein Task schon fertig ist oder nicht...

 

[FArt]

Nur, weil du nicht weisst wo du schauen musst. FutureTask wäre z.B. was zum Nachschauen, davon könntest du erben und die protected done() - Methode überschreiben die ein Event wirft wenn der Task fertig ist. FutureTask erlaubt dir sogar auf eine sichere Art anzufragen ob ein Task schon fertig ist oder nicht...

Ich glaube das wäre gar nicht nötig. Es kommt jetzt auf das genaue Konzept an, aber "Aufträge in eine bestimmte Reihenfolge bringen" kann ich eben z.B. mit einer Queue oder ich lasse einzelne Aufträge vom ExecutorService ausführen und prüfe den Status über das Future. Unter Umständen eben auch die schon angesprochene Barriere... ich denke das könnte man einfach out-of-the-box so hier verwenden.

Ja, es sieht anders aus als man es gewohnt ist. Aber ja, das wurde gemacht um die Komplexität aus asynchroner Verarbeitung ein wenig zu mildern, und somit die Möglichkeit, Fehler zu machen (hoffentlich) zu verkleinern.