Executor fragen ob fertig

[xZise]

Moin,
ich habe aktuell das Problem, dass ich darauf warten muss, dass mehrere Threads fertig werden.

Ich versuche das zu beschreiben: Und zwar mache ich sowas ähnliches wie QuickSort, wobei ich die beiden Teile die nachher übrig bleiben in einen einzelnen Thread ablaufen lasse. Allerdings sollen maximal 4 Threads laufen. Also nehme ich mir ein Executor mit maximal 4 Threads und erstelle eine Aufgabe, alle Elemente zu sortieren. Diese Aufgabe selber jetzt stellt dann die Aufgabe die Teile zu sortieren und so weiter.

Irgendwann ist er aber fertig, und wie kriege ich das mit um dann die sortierte Folge nutzen zu können? Ich dachte zuerst ich gucke solange im Hauptthread bis die Aufgaben leerlaufen, aber der Executor ist da nicht sehr informativ.

MfG
Fabian

PS: Ich selber mache etwas anderes, aber das mit QuickSort beschreibt es wohl am besten.

 

[SlaterB]

was für einen Executor verwendest du denn?
wenn ich mir das SubInterface
ExecutorService (Java 2 Platform SE 5.0)
anschaue, dann liefert jedes submit() ein Future-Objekt zurück, welches du abfragen könntest,

ansonsten ganz allgemein müsstest du deinen vier Threads irgendwas mitgeben, bei dem sie sich alle am Ende ihrer Aufgabe selber melden können

 

[xZise]

was für einen Executor verwendest du denn?[...]

ExecutorService executor = Executors.newFixedThreadPool(4);

wenn ich mir das SubInterface
ExecutorService (Java 2 Platform SE 5.0)
anschaue, dann liefert jedes submit() ein Future-Objekt zurück, welches du abfragen könntest,[...]

Aber das submit nimmt doch eine Aufgabe und gibt ein Objekt zurück und das wartet dann, bis es zuende ist. Aber ich selber kenne doch nicht die letzte Aufgabe auf die ich dann warten könnte.

[...]ansonsten ganz allgemein müsstest du deinen vier Threads irgendwas mitgeben, bei dem sie sich alle am Ende ihrer Aufgabe selber melden können

Okay da müsste ich mir was überlegen.

MfG
Fabian

 

[SlaterB]

> Aber ich selber kenne doch nicht die letzte Aufgabe auf die ich dann warten könnte.

du musst auf alle 4 Rückgaben warten, Reihenfolge egal,
wenn alle 4 ok zurückgegeben, dann ist genau der Endzeitpunkt erreicht

 

[ice-breaker]

du musst auf alle 4 Rückgaben warten, Reihenfolge egal,
wenn alle 4 ok zurückgegeben, dann ist genau der Endzeitpunkt erreicht

neija das Problem ist einfach, wenn er einen Task submitted, wird dieser weitere erstellen (Quicksort-Konzept gilt ja auch hier).
Der Task dürfte für die Futures also nicht fertig sein, solange nicht die Sub-Tasks fertig sind, aber diese können erst von dem ThreadPool ausgeführt werden, wenn der aktuelle Task fertig ist.


Ich würde es folgendermaßen machen:
einen ThreadPool mit Größe 4 nutzen und den Ursprungstask submitten, dabei wird ein Semaphor auf 0 gestellt.
Nun haben wir eine ConcurrentLinkedList-Warteschlange in der die Tasks gespeichert werden, ist ein Task fertig und gibt es weitere Tasks, werden diese in die Warteschlange eingefügt, bevor der Task zu Ende ist. Wenn irgendwann die Warteschlange leer ist und alle Threads fertig sind, wird der Semaphor auf 1 gesetzt, womit die Berechnung als fertig gilt.
Nicht leicht zu lösen.

 

[xZise]

Moin,
wie wäre es, wenn ich einfach bei jeden erstellen eines Tasks einen Zähler erhöhe und wenn dieser fertig ist, denn entsprechend verringere?

Und dann muss ich nur gucken ob der Null ist, und kann aufhören? Das einzige Problem (wo ich auch nicht fit in Java bin) ist der Threadkontext. Das heißt am besten wäre es irgendwie, wenn das Zählerverändern vom Thread angestoßen aber vom Mainthread ausgeführt wird irgendwie.

MfG
Fabian

 

[ice-breaker]

weisst du denn vorher schon wieviele Operationen (Tasks) du machen musst?
das wäre nämlich optimal.

 

[xZise]

Moin,
ich fürchte aktuell nicht mehr, da der aktuelle Algorithmus so nicht funktioniert. Das heißt da muss ich mir was überlegen, und komme dann eventuell wieder auf die Frage zurück.

MfG
Fabian

 

[ice-breaker]

also ich würde zwar jetzt eine funktionierende Lösung hinbekommen (im Gegensatz zu dem oberen), aber ich muss ehrlich gesagt sagen, dass sie sehr heftig ist, wenn man alle Synchronisierungs- und Deadlock-Probleme beseitigt und wirklich doch einige Stunden zum Implementieren benötigen würde.

Deswegen mein Tipp, mach es dir einfach und erzeuge 4 Threads die je 1/4 des Arrays bearbeiten, sollte einer mal früher sein als der andere ignoriere, dass du noch eine Optimierung hättest rausholen können.

 

[Jay_030]

So wie ich dich verstanden habe, hast du eine fixe Anzahl Threads, die eine Datenstruktur beackern und brauchst, wenn alle fertig sind, noch einen "Ergebnisthread". Hört sich nach einem Fall für die CyclicBarrier an.

Schau es dir mal, vielleicht hilft es ja. Ich habe damit schon sehr gute Erfahrungen gemacht bei solchen Berechnungsgeschichten. Zumal man seinen sequentiellen Algortihmus dadurch schnell und sicher auf mehrere Threads aufteilen kann.

Edit: Oder du nutzt eine CountDownLatch.

 

[xZise]

Moin,
okay also aktuell steht wieder Multithreading im Haus.

So sieht es aktuell aus: Ich habe n Dateien die ich in k Threads mit einem ThreadPoolExecutor abackern möchte und wenn alle n Dateien fertig sind, soll sich ein Button aktivieren.

Das beackern werde ich wohl noch schaffen, aber dann ist die Frage, wie ich den Button aktiviere. Mit so einem CountDownLatch wäre das natürlich perfekt, aber ich möchte im Dialog auch anzeigen, wie weit ich bin, d.h. der Latch blockiert das sich das erneuert.

MfG
Fabian

 

[Jay_030]

Das Aktualisieren der Oberfläche während der Bearbeitung würde ich mittels Listenern lösen.

Deine n Workerthreads (besser nur Runnables) bekommen alle eine Referenz auf die Latch, welche mit der Anzahl n initialisiert wurde. Am Ende eines Workerthreads wird die countDown()-Methode der Latch ausgeführt. In der Oberfläche - von der aus du sicherlich die Berechnung startest - wartest du auf die Berechnung mittels der await()-Methode der Latch. Für eine Aktualisierung der Oberfläche mit Fortschrittanzeige kannst du zwei Möglichkeiten nutzen:

• Jeder Worker führt Buch über seinen Fortschritt (eine einfaches Attribut) und informiert mittels PropertyChangeListener die GUI über Änderungen des Fortschritt-Attributes, die sich daraufhin aktualisiert.
• Du arbeitest mit SwingWorker. Diese Klasse bietet dir die Möglichkeit Teilergebnisse weiterzugeben.

Was für dich besser geeignet ist, weiß ich nicht. Ich denke, die Lösung mittels PropertyChangeListener lässt sich schneller in deine bereits bestehenden Worker implementieren. Wichtig ist, dass du die die PropertyChangeListener auch im EventDispatch-Thread aufrufst (z.B. mittels SwingUtilities.invokeLater(...)).

 

[xZise]

Moin,
naja aktuell geht es nur darum, dass ich n Bilder rendern muss, und das wollte ich parallelisieren in dem ich halt einen Threadpool nehme mit maximal k Threads. Soweit ist das kein Problem. Eher die Frage ist halt, wie ich den Fenster sage: Ein mehr von den n Bildern ist fertig. Ich dachte schon sowas wie an ein Listener, aber ich weiß nicht ob das Probleme macht wenn das aus den Threadkontext aufgerufen wird.

MfG
Fabian

 

[Jay_030]

Ich dachte schon sowas wie an ein Listener, aber ich weiß nicht ob das Probleme macht wenn das aus den Threadkontext aufgerufen wird.

Wie gesagt:

Wichtig ist, dass du die die PropertyChangeListener auch im EventDispatch-Thread aufrufst (z.B. mittels SwingUtilities.invokeLater(...)).

Das könnte dann in etwa so aussehen in deiner Worker-Klasse (ungetestet):

for (final PropertyChangeListener listener : allListeners)
    SwingUtilities.invokeLater(new Runnable() {

        public void run() {
            listener.propertyChange(...);
        }
    });

Mit dem PropertyChangeEvent schickst du der GUI den aktuellen Fertigstellungsstatus und die Threads kommen sich nirgends ins Gehege.