thread pool

15/09/2014 - 08:10 von Philipp Kraus | Report spam
Hallo,

ich schreibe eine Simulation, bei dem ich einen Threadpool benötige.
Der Ablauf eines Workers sieht so aus:

while(true)
{

// bearbeite alle Collectionobjekte
thread.barrier // threads müssen alle diesen Punkt erreichen
// bearbeite alle Simulationsobjekte
thread.barrier

Thread.sleep() // damit der User die Verànderungen in der UI sehen
kann und die Geschwindigkeit der Schritte beeinflussen kann
thread.barrier
}

Ich hatte das ganze in der ersten Version mittels einem
CachedThreadPool gelöst, habe dann aber den Pool
einmal selbst von Hand implementiert, d.h. ganz normale Threadobjekte,
an die ich ein Runnable binde.

Mein subjektiver Eindruck ist, dass wenn ich den Pool selbst
implementiere das ganze deutlich schneller làuft als
mit dem CachedPool, dafür habe ich bei der eigenen Implementation das
Problem, dass ab und an ein Thread
Probleme macht.

Meine Frage wàre, wie würde man es gut lösen. In der Simulation
befinden sich bis zu 100 Collectionobjekte und
bis zu 50.000 Objekte, die verarbeitet werden müssen (ein
Collectionobjekt, kann man sich wie eine Folie
auf einem Overheadprojektor vorstellen, in der mehrere Objekte abgelegt
werden).
Alle Objekte sindunabhàngig von einander, es muss lediglich die
Reihenfolge beibehalten werden, d.h. zuerst müssen
immer die Collectionobjekte verarbeitet werden und erst wenn alle
abgearbeitet wurden, dann jedes Simulationsobjekt

Aktuell würde ich wohl wieder zu dem CachedThreadPool zurück gehen. Was
würdet Ihr empfehlen?

Vielen Dank

Phil
 

Lesen sie die antworten

#1 Patrick Roemer
15/09/2014 - 18:14 | Warnen spam
Responding to Philipp Kraus:
ich schreibe eine Simulation, bei dem ich einen Threadpool benötige.
Der Ablauf eines Workers sieht so aus:

while(true)
{

// bearbeite alle Collectionobjekte
thread.barrier // threads müssen alle diesen Punkt erreichen
// bearbeite alle Simulationsobjekte
thread.barrier

Thread.sleep() // damit der User die Verànderungen in der UI sehen
kann und die Geschwindigkeit der Schritte beeinflussen kann
thread.barrier
}



Thread.sleep()? In jedem Worker!?

Klingt eher so, als ob man das ueber einen Timer und ein separates
Latch, auf das die Worker warten, erledigen sollte. Oder ganz anders.

Ich hatte das ganze in der ersten Version mittels einem
CachedThreadPool gelöst, habe dann aber den Pool
einmal selbst von Hand implementiert, d.h. ganz normale Threadobjekte,
an die ich ein Runnable binde.

Mein subjektiver Eindruck ist, dass wenn ich den Pool selbst
implementiere das ganze deutlich schneller làuft als
mit dem CachedPool, dafür habe ich bei der eigenen Implementation das
Problem, dass ab und an ein Thread
Probleme macht.



Kaputte Threadpools sind oft schneller als funktionierende. ;)

Was genau heisst denn "Probleme"?

Ich faende es auch komisch, wenn man bei sowas zwischen zwei
funktionierenden Threadpools signifikante Laufzeitunterschiede
feststellen koennte - denn bei Deinem Ansatz (Worker, die einmalig
disponiert werden und dann "ewig" vor sich hinlaufen) sollte der
Overhead fuer die Threadverwaltung doch vernachlaessigbar sein. Oder ich
habe was falsch verstanden...?

Aktuell würde ich wohl wieder zu dem CachedThreadPool zurück gehen. Was
würdet Ihr empfehlen?



Ich wuerde gerade bei Concurrency grundsaetzlich das verwenden, was die
Standardbibliothek bietet, wenn es nicht wirklich zwingende Gruende fuer
RYO gibt.

Wenn es Probleme mit der Performance gibt, wuerde ich erst mal
ueberlegen, ob man das Design an sich nicht "asynchroner" hinbekommen
koennte, bevor ich im Maschinenraum bastele. Das Thread.sleep() riecht
z.B. nach einem guten Ansatzpunkt in der Richtung.

Ansonsten wuerde ich das Threading-Design vielleicht mal in eine
minimale Beispiel-App ohne echte Domaenenlogik und sonstiges Drumherum
giessen, um damit zu experimentieren. Wenn man dann haengenbleibt, ist
das meist auch eine gute Grundlage, um Fragen mit ein bisschen "echtem"
Code zu illustrieren.

Viele Gruesse,
Patrick

Ähnliche fragen