...(generell, aber noch mehr im Spiel, da es eine starke Umstrukturierung fordert)
*grins* Also ich kenn kein Projekt, bei dem die Einführung von Multithreading KEINE starke Umstrukturierung erfordert.
Allerdings startet der Timer ja keinen Thread, sondern sagt nur dem schon laufendem Thread "Starte den nächsten Schritt" - an der Stelle sollte es also nicht krachen.
Naja - du stellst aber nicht sicher, daß während der Thread läuft nicht schon der nächste Timer daher kommt (was auch tatsächlich der Fall ist) - und das "kracht".
Außerdem - ich glaub da wiederhol ich mich - macht deine Implementation so generell keinen Sinn - denn ob du das in einen Thread auslagerst und dann drauf wartest oder es gleich im Hauptthread machst, macht (fast) keinen Unterschied - ganz sicher keinen in der Geschwindigkeit.
Jetzt wiederhol ich mich ganz sicher, aber:
Folgendes solltest du jetzt tun:
- überlege dir eine klare Trennung der Speicherbereiche. Daß du auf ASystem aus dem MainThread und aus dem WorkerThread zugreifst ohne das zu Synchronisieren (CriticalSection!) ist ein absolutes NoGo und wird nie funktionieren!!!
- Trenne klar, was welcher Thread machen muss und vermeide, daß einer auf den anderen warten muss - damit führst du das Konzept des Multithreading ad absurdum.
- Überlege dir klare Schnittstelle zwischen den beiden Teilen. z.B eine Liste der Partikel, aus der jeder Thread eines entnimmt, es bearbeitet (also berechnet/anzeigt) und es wieder zurückgibt. Das entnehmen und zurückgeben schützt zu mit einer CriticalSection. Damit ist sichergestellt, daß du nie zugleich auf eines zugreifst.
Alles andere ist (zumindest meiner Erfahrung nach) Murks - und da hast du nix davon.
Gruß
Luggi