Eigenes 3D MMORPG mit Delphi möglich?

[Zudomon]

Also mein Problem bezüglich Multithreading lässt sich eigentlich sehr einfach auf den Punkt bringen:

Man benutze den Hauptthread und lässt da drin eine Endlosschleife laufen, macht vielleicht irgendwas was, in meinem Fall eben das Rendering usw. . Wenn man nun die Framedeltas als Graph anzeigen lässt, müsste es bei gleicher Last immer ziemlich ähnliche Framedeltas geben.

Nun startet man bevor die Endlosschleife ausgeführt wird, noch einen Workerthread und legt den auf einen anderen Prozessorkern, so dass man sicher sein kann, dass da nichts dazwischenfunkt...
In dem Workerthread startet man auch eine Endlosschleife...

Resultat: Alles läuft perfekt und wie gewollt... wenn man nun in dem Workerthread rechnet usw. läuft auch alles prima.

Aber erzeugt man nun im Workerthread in dieser Endlosschleife eine einzige Instanz und gibt diese wieder frei, so beginnt der Hauptthread zu stockeln. Und dafür habe ich bisher keine Lösung. Ich könnte mir vorstellen, dass es deswegen ist, weil der ganze Heapspeicher von allen Threads geteilt wird und dann bei einer Instanz sichergestellt werden muss, dass der Speicher der zugewiesen wird, nicht gerade von anderen Threads benutzt wird.

PS: Die Threads haben untereinander keine Verbindung...

[Medium]

Wie wäre es denn dann mit einem zu Programmstart vorinitialisierten Threadpool? Das wäre ein Spontaneinfall für einen schnellen Fix.

[Zudomon]

Kannst du mir das genauer erklären?

[Medium]

Du erstellst dir einfach zu Programmstart eine Hand voll Threads, wirfst die in eine Liste, und lässt die zunächst mal alle "Leerrunden" drehen. (repeat Sleep(1) until Terminated) Diese Threads bekommen noch eine Liste von "Arbeitsaufträgen", die sie, so denn was drin steht, von dem Thread abgearbeitet werden - so ein Auftrag könnte rein theoretisch sogar ein Methodenzeiger sein, so dass du beliebige Methoden von wo her auch immer im Threadkontext laufen lassen könntest. (Nur bei OS-Resourcen aufpassen, manche lassen sich nur in dem Thread verwenden, in dem sie erzeugt wurden.) Das wäre aber schon die sehr allgemeine Variante eines Workerthreadpools. Wenn die Funktion immer gleich ist, macht es ggf. mehr Sinn, Daten in den Thread zu stopfen, die der dann mit immer dem gleichen Algo durchnudelt, z.B. Kram übers Netz jagen.

Dadrüber wäre dann eine kleine Managerroutine sinnig, die das Verteilen von Aufgaben an die Threads verwaltet (z.B. dem mit der aktuell kleinsten Arbeitsliste). Und... ich würde das ja in eine hübsche, handliche Klasse kapseln

Damit liefen die Threads an sich also schon von Anfang an, und würden nur bei Bedarf mit Daten oder Methoden gefüttert. Wie viele man davon nachher braucht, ist von der Anwendung abhängig, und je nach Auslastung dieser spielt auch noch die Anzahl CPU Kerne mit rein. Viel mehr als 2*Kernanzahl (logische) macht eher selten wirklich Sinn.

[Zudomon]

Ja, ziemlich exakt so habe ich das in meiner Engine gemacht... und es hat fürchterlich geruckelt...
Ich habs dann soweit runtergebrochen bis ich gemerkt habe, was der Sündenbock ist... sobald in den Workerthreads Instanzen erzeugt werden, kann man es vergessen.

[Klaus01]

.. aber sollte es nicht gehen, aus dem Workerthread heraus neue Aufträge auf den Auftragsstack zu legen. Der Stack wird dann wie gewohnt von den bereits bestehenden Threads abgearbeitet.
Neue Thread müssten so nicht erzeugt werden.

Grüße
Klaus

[WladiD]

Ich hab ja bisher nicht allzuviel Code gesehen, dennoch meine Vermutung:

FastMM skaliert schlecht, wenn in mehreren Threads strings oder dynamische Arrays vergrößert bzw. instanziert werden.

Hier eine ausführliche Abhandlung darüber...

Ist es bei dir der Fall?