Threads automatisch erzeugen

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.