Threads automatisch erzeugen

Theo112

Warum? Mit wenigen Partikel geht es so wunderbar. Wäre schade, wenn ich das anders machen muss!

Grüße

The-Kenny

Ich glaube es wär schlauer, einen einzelnen Thread für die Berechnung der Partikel zu nehmen, und einen für das Hauptprogramm.

CStoll

Worin unterscheiden sich denn die einzelnen Threads/Partikel tatsächlich voneinander? Wenn sich nur einige Startbedingungen ändern, kannst du eine einzelne Thread-Funktion verwenden und dieser die Randbedingungen per Parameter übergeben.

Theo112

Bisher unterscheiden sie sich nur in ihren momentanen Geschwindigkeiten in X und Y Richtung. Das heißt in 2 doubles. Später sollen noch weitere Werte wie Dichte etc hinzukommen.

Der Grund, warum ich Threads gewählt habe ist, dass so jeder Partikel unabhängig von allen anderen berechnet wird. Brauchen später mal einzelne PArtikel längere Rechenzeiten, werden die anderen in der Zwischenzeit weiter simuliert.

natürlich kannst du mehrere Thread automatisch starten und jeweils andere parameter übergeben, z.B. in ner schleife, aber machen würde ich es nicht. wenn die steuerung eines partikels nicht sehr sehr sher aufwendig ist, dann braucht das umschalten zwischen den Threads viel länge als die eigentliche berechung. mach einfach ein array von Partikeln und arbeite das ab.

Theo112

Wie würde das denn gehen? Wie sieht die Routine dafür aus?

Würde es gerne mal ausprobieren und schauen wie es dann läuft.

Vielen Dank.

CStoll

Theo112 schrieb:

Bisher unterscheiden sie sich nur in ihren momentanen Geschwindigkeiten in X und Y Richtung. Das heißt in 2 doubles. Später sollen noch weitere Werte wie Dichte etc hinzukommen.

Das ist doch die ideale anwendung eines Konzepts, das sich "Parameter" nennt

//die meisten MT-Bibliotheken übergeben der Threadfunktion einen void*, den sie selber interpretieren darf
//wir packen alle nötigen Daten in einen struct, den wir dafür anlegen:
struct th_data
{
  double vx,vy;
};

int thread_fkt(void* param)
{
  th_data* data = (th_data*)param;
  ...
}

...
th_data data[100];//wir brauchen für jeden Thread einen eigenen Struct
for(int i=0;i<100;++i)
{
  data[i].vx=random();data[i].vy=random();//Thread-Parameter zusammenstellen
  begintread(thread_fkt,data+i);
}

Theo112 schrieb:

Wie würde das denn gehen? Wie sieht die Routine dafür aus?

kommt drauf an. zeig code.

vlt. wäre es noch sinnvoll das ein thread z.B. 50 oder 100 Partikel berechnet und es davon 10 threads gibt. aber wieso meist du eigentlich, dass eine berechnung so aufwendig werden könnte?
welche api verwendest du für die threads?
vom prinzip her könnte es so ähnlich aussehen

for(int i = 0;i<100;i++) {
    Parameter* param = createParams(i);
    CreateThread(ThreadFunc, param);
}

Die Parameter kannst du auch in der Thread Funktion erzeugen lassen. Du darfst in der Threadfunktion nur keine globalen/statischen variablen verwenden.

Theo112

Vielen Dank an CStoll!

Werde es so probieren!

Danke an alle!

.filmor

Ich glaube es wäre besser, wenn du dir sowas wie einen „Partikelmanager“ baust, der Partikel erzeugt und verwaltet. Für den kannst du dann verschiedene Arten der Berechnung implementieren. Mit dem „Jeder-Partikel-ein-Thread-Ansatz“ wirst du IMHO nicht viel Freude haben, da Betriebsystemthreads ganz schön fett sind. Sinnvoller wäre es, immer einen Haufen Partikel (1/4 z.B.) zusammenzufassen und in einem Thread zu berechnen. Damit ersparst du dem Betriebsystem viel unnötigen und langsamen Verwaltungsaufwand. Du könntest sogar das ganze noch mit SIMD-Instruktionen (MMX, SSE, was auch immer) beschleunigen, du musst es halt nur erstmal abstrahieren.

CStoll schrieb:

//die meisten MT-Bibliotheken übergeben der Threadfunktion einen void*, den sie selber interpretieren darf
//wir packen alle nötigen Daten in einen struct, den wir dafür anlegen:
struct th_data
{
  double vx,vy;
};

int thread_fkt(void* param)
{
  th_data* data = (th_data*)param;
  ...
}

...
th_data data[100];//wir brauchen für jeden Thread einen eigenen Struct
for(int i=0;i<100;++i)
{
  data[i].vx=random();data[i].vy=random();//Thread-Parameter zusammenstellen
  begintread(thread_fkt,data+i);
}

vorsicht!
th_data data[100];//wir brauchen für jeden Thread einen eigenen Struct
dieses array darf nicht in einer funktion erzeugt werden, sonst zeigt der zeiger im thread auf müll, wenn die funktion beendet wurde.

BorisDieKlinge

ich habe da einen Ähnlichen ansatz, und kann "Theo112" schon verstehen! Ich Simuliere eine Maschine, welche aus einem Hauptthread, und Modulthreadsbesteht!

Der Hautpthread vergibt afugaben an die Module der Anlage, so wird für jedes Modul (bisher max. 32) ein thread verwendet!
Oder findet ihr den Ansatz nicht gut?

Allerdings erzeuge ich diese Threads am anfang, und lege sie solange schlafen bis sie vom Hautpthread ne Aufgabe zugewiesen bekommen!!!

BorisDieKlinge schrieb:

ich habe da einen Ähnlichen ansatz, und kann "Theo112" schon verstehen! Ich Simuliere eine Maschine, welche aus einem Hauptthread, und Modulthreadsbesteht!

Der Hautpthread vergibt afugaben an die Module der Anlage, so wird für jedes Modul (bisher max. 32) ein thread verwendet!
Oder findet ihr den Ansatz nicht gut?

zu wenig info um sowas zu sagen.

BorisDieKlinge

naja stellt dir die Maschine als Fertigungsstrasse vor.Die Module sind Stationen oder Roboter... welche aufgaben bekommen (bewegungabläufe etc.)

Der hautpthread verwaltet den ablauf in der fertigungsstrasse, und die modulthread steuern/simulieren stationen bzw. Roboter...

mehr als könnte ok sein kann man nicht sagen, weil es die details und anforderungen immer noch vollkommen unklar sind.

1000 Threads erzeugen zu wollen ist aber überhaupt nicht sinnvoll, die legen sich gegenseitig lahm (scheduling!).

thordk

für simulation threading zu verwenden ist gefährlich, da threading keine definierte abarbeitungsfolge garantiert. für simulation ist aber genau das wichtig. es kommt nicht darauf an, dass alles möglichst schnell durch die gegend fliegt, es kommt darauf an, dass die simulation innerhalb definierter parameter bleibt. selbst wenn man "unabhängige" system simulieren möchte, ist es wichtig, genau diese unabhängigkeit (verzögerungen, ausfall, etc.) wohl definiert simulieren zu können.

wenn die partikel miteinander interagieren sollen, scheiden threads also sofort aus.