Threads asynchrone Tätigkeit mit Ergebnis Auswertung

[redbomber]

Hallo zusammen,
ich stehe gerade vor folgendem Problem:

Über die GUI kann der Anwender verschiedene Aktionen durchführen. Diese dauern etwas länger und laufen in einem extra Thread asynchron ab.

Jetzt möchte ich aber an Ergebnisse in diesem Thread dran kommen.
Wie ich gelesen habe gibt es hierfür zwei Möglichkeiten:
Über Callback oder das Future-Pattern.

Ich möchte das Future-Pattern anwenden, wo ich mit der methode get() and das Ergebnis komme:

FutureTask<Integer> t = new FutureTask<Integer>(new HelloWorldCount()); // 1
new Thread(t).start(); // 2
int result = t.get());

Schön und gut, aber wenn ich über FutureTask.get() an das Ergebnis will, warte ich doch automatisch bis das Ergebnis da ist. Dann blockiere ich wieder meinen aufrufenden Thread. In meinem Fall die GUI, was ich ja gerade nicht will.

Also ich habe Beispiele dazu angeschaut, aber kein einziges Beispiel gefunden, wo mein Problem beschrieben ist. Oder verstehe ich hier einfach nur etwas falsch?

 

[kaetzacoatl]

Ruft doch eine Methode
immer wieder auf,
bis sie was zurückgibt.

 

[Marco13]

Nichts falsch verstanden. Auf so ein Feature könnte dann in einem anderen Thread gewartet werden. Für GUI-Sachen würde sich eher ein Callback anbieten. Kannst dir mal den SwingWorker ansehen: Der ist für sowas gedacht, und hat z.B. so eine Callback-Methode "done()", die automatisch im EDT aufgerufen wird, wenn er fertig ist. Der SwingWorker könnte auch so gestaltet werden, dass seine einzige Arbeit daraus besteht, auf eine Future zu warten...

 

[Bernd Hohmann]

.isDone() von FutureTask könnte helfen - was letztendlich auf die Variante von kaetzacoatl hinausläuft (mit dem Vorteil, dass man im eigenen Code sieht was passiert). Die Java-Runtime ist mittlerweile mit soviel "eleganten" Krücken-Routinen behaftet dass ich kotzen könnte.

Beispiel für FutureTask was Deinem Problem nahekommt: FutureTask - Programming Examples

Bernd

 

[redbomber]

super vielen Dank schonmal euch allen!

Dann will ich nochmal (hoffentlich richtig) zusammenfassen:

Future-Pattern:
Ich muss also in jedem Fall mit einer Schleife auf das Ergebnis des ausführenden Threads
warten, so wie in dem Beispiel von Bernd Hohmann
Bsp.:

	 FutureTask<String> future = new FutureTask<String>(...);
	 executor.execute(future);

	 while (!future.isDone()){
		try{
			//wait
			Thread.sleep(500);
		} catch (InterruptedException ie){
		}
	}

@kaetzacoatl
Dein Beispiel ist ja im Grunde gleich wie beim Future Pattern

Wenn also mein ausführender Thread von der GUI aus aufgerufen wird, dann ist das Future- Pattern
nicht sinnvoll, da dies zum einfrieren der GUI führt.

Callable-Pattern:
Dieses funktioniert im wesentlichen über Listener. D.h. der arbeitenden Thread informiert den aufrufenden
über ein entsprechendes Event. Dies Variante wollte ich gerade wählen, da dies eben meine GUI nicht einfriert.
Aber @Marco13, dein Beispiel mit dem SwingWorker, ist sehr gut, da die Methode done() vom SwingWorker nach beenden der Aufgabe
ausgeführt wird. Also dann muss ich den aufrufenden GUI-Thread nich mal als Listenern registrieren. Das macht alles der SwingWorker für mich und die Änderungen bei mir sind minimal.


Also ich habe es noch nicht probiert, aber ich sehe mit dem SwingWorker gerade kein Problem und denke es wird einfach den bei mir einzubinden.