multithreading-noob braucht hilfe

heyhey

vorab: ich kenne mich mit multithreading nicht wirklich aus, habe kaum erfahrung und bin auch praktisch nicht geübt. mit beispielen wie diesen bastle ich an bisherigen programmen rum der übung wegen.

die situation sieht so aus, dass ich eine kleine partikelsimulation habe mit ein paar tausend partikeln die auf der cpu berechnet werden. bei der partikelsimulation werden dinge berechnet die unabhängig von den anderen partikeln sind, so kann ich die ganze menge der partikel wunderbar in kleinere teile aufspalten und einzeln berechnen. das ganze soll dann mittels opengl dargestellt werden.

ich habe nun daran gedacht, die einzelnen partikel mit meinen zusätzlichen 2/4/8 threads zu berechnen. dazu gibt es schon die erste frage:
wie soll man das mit der arbeitsaufteilung am besten realisieren?
mir fallen aktuell zwei möglichkeiten ein:
1. man hat shared eine map<particle, bool>, wo sich jeder thread selbstständig bedient (und dann den bool auf false setzt) und dann berechnet.
2. die gesamtmenge der partikel wird durch die anzahl der threads geteilt, dann bekommt jeder thread seinen eigenen zuständigkeitsbereich zugeteilt (klingt für mich ein wenig effektiver als 1. da man weniger cache-misses haben wird) wo er drin rumrechnen kann (das sind dann natürlich nur proxyobjekte).

gibt es hier noch andere / bessere methoden? wie macht ihr das?

die zweite frage lässt sich gerade anschliessen:
angenommen ich mache die zweite variante von der frage 1., ist es dann sinnvoll wenn ich die threads mit einer endlosschleife beschäftige wo sie immer und immer wieder über ihren zuständigen bereich drüberiterieren? (die zeitmessung für die physikalischen formeln passiert dann natürlich für jeden thread separat innerhalb jedes endlosschleifendurchgangs) dann würde ich während die threads am arbeiten sind mit dem main-prozess (nennt man den auch thread?) auf die daten zugreifen um sie auszulesen.

der gegenvorschlag wäre, die threads mit jedem frame zu joinen (da habe ich angst, wenn von den 8 threads einer aufgehalten worden ist durch eine rechenintensive singlethread-anwendung auf einem core. ist diese angst realistisch?)

mir ist dazu eingefallen, dass der erste vorschlag von frage 2. zu problemen führen kann wenn ein partikel gleichzeitig berechnet und gezeichnet wird. für jedes partikel einen mutex zu machen sieht für mich so aus als würde die performance wieder sinken. dann habe ich mir gedacht, jeder thread hat eine kopie von seinem zuständigkeitsbereich, rechnet in die kopie rein und wenn er fertig ist swappt er lediglich die pointer. wie sieht das aus bzgl. speicherverbrauch / caching? ist die idee umsetzenswert?

danke im voraus und gruss

Werner Salomon

.. suche mal (nicht im Forum - wegen geht nicht) bei Google "site:c-plusplus.net Active Object" - dann findest Du z.B. http://www.c-plusplus.net/forum/p1234889#1234889 - das Active-Object-Pattern ist IMHO der Schlüssel zur Lösung Deines Problems.

Mehr dazu, vielleicht heute Abend.

otze

Din Problem klingt nach einem Fall für OpenMP.

Zuerst einmal würde ich das Zeichnen und die Berechnung trennen. Die for-schleife der Berechnung würde ich dann knallhart parallelisieren mit Methode2, danach alle Objekte gleichzeitig zeichnen.

danke für die antworten.

das active object pattern will irgendwie nicht in meinen kopf rein, ich hab versucht den englischen wikipedia artikel dazu zu verstehen aber ich bin zu dumm dafür.

also habe ich das gestern mal nach otzes vorschlag gemacht (zwar kein openmp...) und ich bin mit 4 threads auf 42 fps statt 13 fps gekommen, richtig geil.