Zitat von Sir Rufo:

Gerade das Arbeiten mit Threads nötigt einem erheblich mehr Sorgfalt ab als mit nur einem (dem MainThread).

Umsetzungen die auf der Annahme basieren "mit der Spiellogik dürfte er länger beschäftigt sein als der Worker mit den Partikeln" führen zwangsweise ins Aus (wenn nicht sofort, dann auf jeden Fall später).

Das was du machen möchtest solltest du komplett in Threads auslagern (Spiellogik, Partikel, etc.).
Der MainThread sollte nur die Anzeige regeln und die Benutzereingaben entgegennehmen.

EDIT:
BTW macht es keinen Sinn etwas in mehrere Threads auszulagern, wenn die Threads gleiche Ressourcen verwenden.

Beispiel:
Du benötigst (eine große Menge) Daten von mehreren Systemen, die über eine Leitung kommen.
Mehrere Threads werden das nicht beschleunigen können, eher wird der Thread-Overhead dieses verlangsamen

oder

Du willst umfangreiche Berechnungen durchführen. Hast du aber mehr Berechnungs-Threads als CPU-Kerne laufen, dann wird auch das langsamer anstatt schneller

aber

Du willst:
- eine Liste aller Dateien von der Festplatte sammeln (1 Thread)
- Daten von einem externen Server holen (1 Thread) - Zwischenspeicherung im RAM! sonst stören wir den Datei-Suchen-Thread
- umfangreiche Berechnungen durchführen (1 Thread pro CPU)

das wird dann mit Threads schneller, als wenn du das in einem Thread (z.B. MainThread) nacheinander abarbeiten würdest.

Soweit hab ich das Prinzip hinter den Threads schon verstanden - In der Anwendung in der ich die Threads zum laufen bekommen möchte handelt es sich wie schon gesagt um ein Spiel, was die Festplatte nur am Anfang zum Laden der Texturen beansprucht und (noch ) auf keine Downloads aus dem Internet oder so warten muss. Dadurch ist der einzige Bottleneck die CPU, da das Spiel im Moment noch als Single-Thread-Anwendung läuft beansprucht es nur einen Kern, diesen aber zu 100% - meines Verständnis nach ein typisches Szenario in dem Multi-Threading aushelfen würde

Und nur das Partikelsystem auszulagern ist auch nicht der Plan auf Dauer, das war mehr so als Versuch gedacht überhaupt mal etwas mit Threads zu machen - Mein Hauptproblem ist jedoch die vernünftige Synchronisation der Threads. Nicht die Implementierung der Threads selbst, sondern nur wie ich es hinbekomme dass mein Workerthread und der VCL-Thread (später vllt auch mehr Threads) im Gleichtakt laufen. Und da haperts halt ziemlich. Was ist dafür der Richtige Ansatz? Eigentlich doch einen Thread einmal zu erstellen und ihm dann immer neue Aufgaben zuzuteilen oder nicht? Und um diese zu synchronisieren lässt es sich doch nicht wirklich vermeiden dass der eine Thread auf den anderen wartet, sonst läuft der eine ja schneller als der andere...

Sorry, war grad unterwegs, daher gibts erst jetzt eine Antwort.

Erst mal: Ich denke, es gibt noch einen weiteren Grund für Threads: und zwar einfach Abläufe sauber gegeneinander abzuschotten. Das erhöht meiner Meinung nach die Stabilität und die Transparenz (wenn auch zum Preis eines höheren Implementationsaufwandes und der Gefahr, vor lauter Threads unnötig Ressourcen im Overhead zu verpulvern!)

Zitat von Edlmann:

Und nur das Partikelsystem auszulagern ist auch nicht der Plan auf Dauer, das war mehr so als Versuch gedacht überhaupt mal etwas mit Threads zu machen - Mein Hauptproblem ist jedoch die vernünftige Synchronisation der Threads. Nicht die Implementierung der Threads selbst, sondern nur wie ich es hinbekomme dass mein Workerthread und der VCL-Thread (später vllt auch mehr Threads) im Gleichtakt laufen. Und da haperts halt ziemlich. Was ist dafür der Richtige Ansatz? Eigentlich doch einen Thread einmal zu erstellen und ihm dann immer neue Aufgaben zuzuteilen oder nicht? Und um diese zu synchronisieren lässt es sich doch nicht wirklich vermeiden dass der eine Thread auf den anderen wartet, sonst läuft der eine ja schneller als der andere...

Ich denke, da liegt der Wurm in deinem Konzept: Zu wollen, daß die im Gleichtakt laufen und Multithreading ist ein Widerspruch in sich.

Ich versuchs mal an einem Projekt von mir zu erklären:

Ich hab eine Applikation, die Daten von einem Messgerät aufzeichnet, über die Aufzeichnung einige Filter drüberrechnet und das ganze dann als Kurve auf den Schirm malt.
Da hab ich mehrere Threads:
1.) die Kommunikation: Dieser Thread holt die Daten vom Messgerät, kontrolliert ob die Übertragung korrekt war, kümmert sich sonst darum daß die Wertereihe neu angefordert wird und legt dann die übertragenen Werte in einen Puffer. Außerdem hat der Thread einen Puffer, in dem an das Gerät zu übergebende Befehle drinstehen. Die werden dann vom Thread je nach freier Zeit, Zustand des Geräts und noch ein paar anderen Einflüssen versandt.

2.) Den Filter und Speicher Thread: der schaut regelmässig, ob im Puffer vom Kommunikationsthread was drin ist. Wenn ja, übernimmt er diese Wertereihe, macht die für die Filter notwendigen Berechungen und noch ein paar andere Sachen und schreibt sie in eine Datenbank.

3.) Den Anzeige-Berechnungs-Thread: Der weiß, welcher Bereich gerade auf dem Schirm angezeigt wird, holt sich die entsprechenden Basiswerte aus der Datenbank, rechnet da die für die Anzeige notwendigen Dinge und legt das Ergebnis als Werte-Paar (X und Y Wert) wieder in einen Puffer.

und 4.) der Mainthread, der die Daten aus dem Anzeige-Berechnungs-Thread-Puffer holt und anzeigt - was aber, da es fertig gerechnete X/Y-Paare sind, extrem schnell geht.

Untereinander kommunizieren diese Threads über Messages und über die Puffer. Die Puffer sind alle über Critical sections geschützt.
Dabei ist wichtig, daß die Threads nie auf die anderen Warten. Der Kommunikations-Thread muss nur seine Puffer lesen und schreiben und wenn da nix ist, was zu tun ist, dann wartet er ein bischen und versuchts wieder. Damit ist aber jederzeit sichergestellt, daß das Messgerät seine Daten loswird, wenn es welche zu senden hat.
Der Anzeige-Berechnungs-Thread z.B. bekommt vom Mainthread nur mitgeteilt, welcher Bereich gerade angezeigt werden soll und rechnet dann so lang ein Paar nach dem anderen, bis er alle Berechnet hat - unabhängig vom Mainthread und der Anzeige - außer es kommt vom Mainthread eine Änderung des Anzeigebereichs - dann fängt er von vorne an und vergisst die alte Aufgabe.
Der Mainthread wiederum schaut im Puffer des Anzeige-Berechnungs-Threads nach, ob da was ist, was er anzeigen kann und tut das dann. Dazu wird dem Mainthread vom Anzeige-Berechnungs-Thread eine Message geschickt, wenn einige Punkte gerechnet sind, damit er sie anzeigt. Wenn der Mainthread auf diese Message nicht gleich reagiert (weil er z.B. grad ein Einstellungsfenster darstellt) dann ist das für den Anzeige-Berechnungs-Thread eigentlich komplett egal - er rechnet einfach fröhlich weiter und füllt den Puffer weiter. Wenn der Mainthread dann wieder Zeit zur Anzeige hat, dann hat er eben mehrere Punkte zum anzeigen.

War das jetzt zu kompliziert? Ich hoffe nicht.

Gruß
Luggi