Hab jetzt das Threading in eine externe Anwendung übertragen, die jetzt nur das Partikelsystem und den Thread enthält...läuft allerdings selbst in dieser Umgebung nicht so wie ich das will...
Download: http://dl.dropbox.com/u/12342503/ParticleSystem.rar

Also, da ist einiges ziemlich schräg... *grins*

Fangen wir mal beim Thread selber an:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TWorkerthread.Execute;
begin
  while True do //<- wie schon mal gesagt: sollte while not Terminated do heissen...
  begin
  if HasJob then //<- nur als Anmerkung: mit ein paar einrückungen würde es leichter zum lesen gehen...
  begin
  Fin := False;
  //Die eigentliche Berechnung
  TParticleSystem(PSystem).Update; //<- und wo initialisierst du PSystem?
                                   //das muss ja auf ein existierendes TParticleSystem
                                   //verweisen, das auch mit .Create angelegt wurde!
                                   //außerdem ist dein ASystem ja teil des Main-Threads,
                                   //daher muss hier auf eine Synchronisation geachtet werden!
  HasJob := false;
  Fin := true;
  end
  else
  Sleep(1);
  end;
end;

gut, und dann wär da noch der Timer:

Vorneweg: So wie du das implementiert hast, wird der Timer wieder auflaufen, während du noch auf's abarbeiten des letzen wartest.

zusammenfalten · markieren

Delphi-Quellcode:

procedure TForm1.Timer1Timer(Sender: TObject);
var x: Integer;
  d: Boolean;
begin
  //Den Workerthread an seine Arbeit setzen
  AWorker.SetJob(true);

  //spätestens hier erzeugst du einen deadlock, weil der Thread und du auf das selbe ASystem zugreift.
  if (OldX <> 0) and (OldY <> 0) and (MousePos_CB.Checked) then
    ASystem.AddPartikels(OldX, OldY, Emit_SB.Position)
  else
    ASystem.AddPartikels(SizeX/2, SizeY/2, Emit_SB.Position);

  Form1.Caption := 'Partiklesystem -- © by Edlmann -- ' + IntToStr(ASystem.Parts.Count) + ' Partikel';

  //An dieser Stelle wird im Spiel dann die restliche Spiellogik geupdatet

  //Auf den Thread warten
  while AWorker.GetJob do
  begin
  sleep(1);
  Application.ProcessMessages;
  end;

  //Nachdem der Thread seine Arbeit getan hat, Render die Partikel
  Render(self, d);
end;

Ich empfehle dir den Workerthread-Thread, der weiter oben schon verlinkt ist, genau zu studieren. Hier fehlt eine sinnvolle Threading struktur (wer macht was wann und warum, was muss im vordergrund passieren, was im hintergrund und vor allem: was willst du mit deinem Thread bezwecken. Denn hier bleibt nur das Programm bedienbar, wenn du denn die Synchronisation korrigierst)
Dann solltest du genau schauen, welche Speicherbereiche aus welchem Kontext geschrieben werden - Stichwort Critical section.

So kann das auf alle Fälle nicht funktionieren!

Gruß
Luggi

@grl: Vielen Dank schonmal für dein Feedback, doch ich glaube wir reden aneinander vorbei...Das was ich da zusammengebastelt hab ist nur ein Programm, in dem mein Problem demonstriert werden soll...Das ich vergessen hab das System zu initialisieren ist ein Flüchtigkeitsfehler, der beim zusammenkopieren entstanden ist...werds mal eben überarbeiten. Hab u.a. auch eine ältere Version der Workerthreads benutzt, in der ich das True noch nicht geändert hatte...

Der Thread soll parallel zum VCL-Thread arbeiten, so dass der VCL-Thread die GameEngine übernimmt, und der Workerthread die Partikel berechnet (zumindest vorerst, vllt wenn ichs iwann mal hinbekommen hab noch mehr Threads).

Das mit dem Timer stimmt auffallend, hatte ich bisher noch nicht richtig drüber nachgedacht...was wäre denn eine bessere Möglichkeit das zu implementieren? Die Zeit, die für die Berechnungen in Anspruch genommen wird nehmen, und nur warten falls diese niedriger als 16,666ms (=> 1 Frame pro Sekunde) ist?

Lade grad eine aktualisierte Version der Demo hoch, sollten die gröbsten Dinge gefixxt sein, funktioniert aber noch immer nicht so wie ich will...Link ist der selbe wie oben.

Zitat von Edlmann:

@grl: Vielen Dank schonmal für dein Feedback,

Gern!

Zitat von Edlmann:

doch ich glaube wir reden aneinander vorbei...

Ich glaub nicht - denn egal was du auch erreichen willst - das was du da zusammengebastelt hast, kann nicht funktionieren.

Zitat von Edlmann:

Das was ich da zusammengebastelt hab ist nur ein Programm, in dem mein Problem demonstriert werden soll...Das ich vergessen hab das System zu initialisieren ist ein Flüchtigkeitsfehler, der beim zusammenkopieren entstanden ist...werds mal eben überarbeiten. Hab u.a. auch eine ältere Version der Workerthreads benutzt, in der ich das True noch nicht geändert hatte...

Der Thread soll parallel zum VCL-Thread arbeiten, so dass der VCL-Thread die GameEngine übernimmt, und der Workerthread die Partikel berechnet (zumindest vorerst, vllt wenn ichs iwann mal hinbekommen hab noch mehr Threads).

Dann hab ich dich schon richtig verstanden. Das machst du hier aber nicht - denn du wartest auf den Thread und damit läuft er nicht parallel.
Mal dir das mal auf - in einem Ablaufdiagramm oder so - dann siehst du das besser.

Zitat von Edlmann:

Das mit dem Timer stimmt auffallend, hatte ich bisher noch nicht richtig drüber nachgedacht...was wäre denn eine bessere Möglichkeit das zu implementieren? Die Zeit, die für die Berechnungen in Anspruch genommen wird nehmen, und nur warten falls diese niedriger als 16,666ms (=> 1 Frame pro Sekunde) ist?

Wenn du das mit Multithreading machen willst (was schon gescheit sein könnte) dann würde ich einen Thread bauen, der sich selbsttätig um die Berechnung kümmert und unabhängig ist vom Mainthread. Der Mainthread macht dann nur noch die Anzeige.

Dabei musst du aufpassen, daß du sauber getrennte Speicherbereiche verwendest oder die Zugriffe über eine CriticalSection schützt. Das ist jetzt auch das Problem warum du da nicht weiterkommst. Du schreibst einfach aus beiden Threads auf den selben speicher - das geht nicht.

Zitat von Edlmann:

Lade grad eine aktualisierte Version der Demo hoch, sollten die gröbsten Dinge gefixxt sein, funktioniert aber noch immer nicht so wie ich will...Link ist der selbe wie oben.

Nein, da ist vom wirklichen Problem nix gefixt.

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.

Gruß
Luggi

Zitat von grl:

Zitat von Edlmann:

@grl: Vielen Dank schonmal für dein Feedback,

Gern!

Zitat von Edlmann:

doch ich glaube wir reden aneinander vorbei...

Ich glaub nicht - denn egal was du auch erreichen willst - das was du da zusammengebastelt hast, kann nicht funktionieren.

Zitat von Edlmann:

Das was ich da zusammengebastelt hab ist nur ein Programm, in dem mein Problem demonstriert werden soll...Das ich vergessen hab das System zu initialisieren ist ein Flüchtigkeitsfehler, der beim zusammenkopieren entstanden ist...werds mal eben überarbeiten. Hab u.a. auch eine ältere Version der Workerthreads benutzt, in der ich das True noch nicht geändert hatte...

Der Thread soll parallel zum VCL-Thread arbeiten, so dass der VCL-Thread die GameEngine übernimmt, und der Workerthread die Partikel berechnet (zumindest vorerst, vllt wenn ichs iwann mal hinbekommen hab noch mehr Threads).

Dann hab ich dich schon richtig verstanden. Das machst du hier aber nicht - denn du wartest auf den Thread und damit läuft er nicht parallel.
Mal dir das mal auf - in einem Ablaufdiagramm oder so - dann siehst du das besser.

Zitat von Edlmann:

Das mit dem Timer stimmt auffallend, hatte ich bisher noch nicht richtig drüber nachgedacht...was wäre denn eine bessere Möglichkeit das zu implementieren? Die Zeit, die für die Berechnungen in Anspruch genommen wird nehmen, und nur warten falls diese niedriger als 16,666ms (=> 1 Frame pro Sekunde) ist?

Wenn du das mit Multithreading machen willst (was schon gescheit sein könnte) dann würde ich einen Thread bauen, der sich selbsttätig um die Berechnung kümmert und unabhängig ist vom Mainthread. Der Mainthread macht dann nur noch die Anzeige.

Dabei musst du aufpassen, daß du sauber getrennte Speicherbereiche verwendest oder die Zugriffe über eine CriticalSection schützt. Das ist jetzt auch das Problem warum du da nicht weiterkommst. Du schreibst einfach aus beiden Threads auf den selben speicher - das geht nicht.

Zitat von Edlmann:

Lade grad eine aktualisierte Version der Demo hoch, sollten die gröbsten Dinge gefixxt sein, funktioniert aber noch immer nicht so wie ich will...Link ist der selbe wie oben.

Nein, da ist vom wirklichen Problem nix gefixt.

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.

Gruß
Luggi

Ich verstehe nicht an welcher Stelle ich aus beiden Threads etwas zugreifen soll...Der VCL-Thread berechnet die Spiellogik, der Worker die Partikel-Engine (VCL-Thread greift nicht auf die Partikel zu), nur beim Rendern liest der VCl-Thread die Werte der Partikel aus, ändert diese aber nicht. Auf den Workerthread warten hab ich eingebaut, damit der Worker auf jeden Fall beim nächsten Frame fertig mit seinem Durchlauf ist, und wieder weiter arbeiten kann. Da der Mainthread im Spiel genug zu tun hat bis dahin, sollte diese Warteschleife im Spiel nur selten aufgerufen werden, doch das schützt (zumindest in meiner eigenen kleinen Welt, in der Threads funktionieren wie ich denke ) davor, dass Einzelschritte übersprungen werden beim Partikelsystem.

Zitat von Edlmann:

Ich verstehe nicht an welcher Stelle ich aus beiden Threads etwas zugreifen soll...Der VCL-Thread berechnet die Spiellogik, der Worker die Partikel-Engine (VCL-Thread greift nicht auf die Partikel zu), nur beim Rendern liest der VCl-Thread die Werte der Partikel aus, ändert diese aber nicht. Auf den Workerthread warten hab ich eingebaut, damit der Worker auf jeden Fall beim nächsten Frame fertig mit seinem Durchlauf ist, und wieder weiter arbeiten kann. Da der Mainthread im Spiel genug zu tun hat bis dahin, sollte diese Warteschleife im Spiel nur selten aufgerufen werden, doch das schützt (zumindest in meiner eigenen kleinen Welt, in der Threads funktionieren wie ich denke ) davor, dass Einzelschritte übersprungen werden beim Partikelsystem.

Der WorkerThread macht ein TParticleSystem(PSystem).Update; in dem z.B. ein Parts.Count und ein Parts.Items[x] vorkommt, und der MainThread macht ASystem.AddPartikels(OldX, OldY, Emit_SB.Position) das dazu führt, daß die Anzahl Parts sich ändert.

Das ist nur ein beispiel - und wegen dem Timer-Problem bist du evtl. noch im MainThread im Render (das auch ein Parts.Count verwendet) während der Timer schon den nächsten Thread angeworfen hat - dann krachts gleich wieder.

Gruß
Luggi

Zitat von grl:

Der WorkerThread macht ein TParticleSystem(PSystem).Update; in dem z.B. ein Parts.Count und ein Parts.Items[x] vorkommt, und der MainThread macht ASystem.AddPartikels(OldX, OldY, Emit_SB.Position) das dazu führt, daß die Anzahl Parts sich ändert.

Das ist nur ein beispiel - und wegen dem Timer-Problem bist du evtl. noch im MainThread im Render (das auch ein Parts.Count verwendet) während der Timer schon den nächsten Thread angeworfen hat - dann krachts gleich wieder.

Gruß
Luggi

Touche, daran habe ich gar nicht gedacht...das Partikel hinzufügen sollte also auch über den Thread laufen. Soweit so gut.
Bloß fehlt mir der Ansatz, wie ich den Timer rausnehmen kann (generell, aber noch mehr im Spiel, da es eine starke Umstrukturierung fordert). 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.

Zitat von Edlmann:

...(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.

Zitat von Edlmann:

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:

Zitat von grl:

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

Zitat von grl:

Zitat von Edlmann:

...(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.

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:

Zitat von grl:

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

1.) Hab ich mir leider schon gedacht dass das nicht einfach wird...
2.) Nur mal so dumm gefragt, wenn ich das ProcessMessages rauslass, dürfte doch der Timer nicht ein zweites Mal aufgerufen werden befor er fertig ist, oder denk ich da gerade falsch? Denn dann wird der VCL-Thread (der ja den nächsten Timer starten müsste) ja schlafen gelegt, bis das Partikelsystem einen Schritt weiter ist (und wenn das PSystem vor der Spiellogik fertig ist wird gar nicht erst gewartet) - Das war so mein Gedankengang hinter dieser Warteschleife...
3.) Trennung der Speicherbereiche - Wenn ich alle aufrufe auf das Partikelsystem über den Worker laufen lasse, ist das ja soweit getrennt und dann sind doch Criticalsections unnötig (oder bin ich da falsch?)
- Das Warten ist ja nur als Fallback da, damit eben für den Fall dass das Partikelsystem noch nicht fertig ist eben kurz gewartet wird (es ist ja nich so dass der VCL-Thread dann nichts zu tun hätte, das ist nur im Beispielprogramm so, mit der Spiellogik dürfte er länger beschäftigt sein als der Worker mit den Partikeln)
- Trennung etc: Nicht nötig wenn ich das schon vom Code her Trenne (nur ein Thread was überhaupt an meiner Partikelliste rumbastelt) oder nicht?

Zitat von Edlmann:

1.) Hab ich mir leider schon gedacht dass das nicht einfach wird...
2.) Nur mal so dumm gefragt, wenn ich das ProcessMessages rauslass, dürfte doch der Timer nicht ein zweites Mal aufgerufen werden befor er fertig ist, oder denk ich da gerade falsch? Denn dann wird der VCL-Thread (der ja den nächsten Timer starten müsste) ja schlafen gelegt, bis das Partikelsystem einen Schritt weiter ist (und wenn das PSystem vor der Spiellogik fertig ist wird gar nicht erst gewartet) - Das war so mein Gedankengang hinter dieser Warteschleife...
3.) Trennung der Speicherbereiche - Wenn ich alle aufrufe auf das Partikelsystem über den Worker laufen lasse, ist das ja soweit getrennt und dann sind doch Criticalsections unnötig (oder bin ich da falsch?)
- Das Warten ist ja nur als Fallback da, damit eben für den Fall dass das Partikelsystem noch nicht fertig ist eben kurz gewartet wird (es ist ja nich so dass der VCL-Thread dann nichts zu tun hätte, das ist nur im Beispielprogramm so, mit der Spiellogik dürfte er länger beschäftigt sein als der Worker mit den Partikeln)
- Trennung etc: Nicht nötig wenn ich das schon vom Code her Trenne (nur ein Thread was überhaupt an meiner Partikelliste rumbastelt) oder nicht?

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.