Multithreading Problem

[Zudomon]

Huhu!

Ich arbeite ja in meiner freien Zeit an dem Projekt Stone Quest und versuche nun, die Landschaftsgenerierung auf die anderen Threads zu verlagern. Die Engine ist schon etwas aufgebläht und nicht mehr so wirklich gut strukturiert, weil ich dort viel Prototyping betreibe.
Habe es nun geschafft, ein paar Workerthreads zu machen und die auch auf den anderen Kernen zu verlagern... auf einem Kern läuft also nur der Enginethread. Über Messages sagen die Workerthreads bescheid, wenn sie mit ihrer Aufgabe fertig sind, so kann ich auf sämtliche Critical Sections verzichten.
Das Problem ist nun, sobald ich auch nur Ansatzweise, also garnicht mal komplett versuche, die Landschaftsstücke zu bauen, hackt das im Hauptthread... das ruckeln ist schon wesentlich angenehmer im vergleich zu vorher, wo alles komplett in einem thread gemacht wurde, aber es ist dennoch störend und eigentlich doch garnicht möglich. :(

Sorry, die Beschreibung ist etwas wage... aber vielleicht hat trotzdem jemand eine Idee, wiso dieses seltsame Verhalten zustande kommt...

Gruß
Zudo

[Krishty]

Ins Blaue geraten: GPU-Upload der Vertex- und Index-Buffers?

Ansonsten Zeitmessung einbauen und schauen, welche Programmteile am stärksten streuen.

[Zudomon]

Ins Blaue geraten: GPU-Upload der Vertex- und Index-Buffers?

Achso, das hatte ich vergessen zu erwähnen... zum Debuggen baue ich nur das Grundmesh ohne das an die GPU zu übergeben...

[Krishty]

Okay. So lange ich nicht mehr weiß als „beim bauen hakt der Haupt-Thread“ weiß ich auch nicht weiter ;)

[Chromanoid]

vielleicht hängt's am speicher allokieren?

[Krishty]

Einzelne Allokationen bewirken kein Haken. Man müsste schon eine Menge Mikroallokationen durchführen um die Leistung des Haupt-Threads zu beeinflussen, aber dann würden die Allokationen des Haupt-Threads mehr oder weniger regelmäßig zwischen denen der anderen Threads abgearbeitet – es liefe also langsamer, würde aber nicht haken. Das ist jedenfalls meine Einschätzung aus C++; bei Delphi müsste es eigentlich ähnlich sein.

[B.G.Michi]

auch nur ins Blaue geraten, aber: vlt haben die Workerthreads zu hohe Priorität?

[Zudomon]

Ich verstehe, dass man eigentlich nur ins blaue raten kann, bei der Fehlerbeschreibung...

Die Priorität der anderen Threads hab ich schon vorsichtshalber auf niedrig gestellt.
Ob es wirklich am Speicher allokieren liegen könnte?

Mist, ich bräuchte mehr Zeit, um mich da mal tiefer durchzuwurschteln...

Oder könnte es auch sein, dass ich doch irgendwo auf den gleichen Speicherbereich zugreife? Aber bisher war es so, dass der dann entsprechende Zugriffsverletzungen aufgetaucht sind... aber das ganze läuft verdächtig stabil.

[Krishty]

Oder könnte es auch sein, dass ich doch irgendwo auf den gleichen Speicherbereich zugreife? Aber bisher war es so, dass der dann entsprechende Zugriffsverletzungen aufgetaucht sind...

Zugriffsverletzungen tauchen da sicher nicht auf. Die tauchen nachher auf, wenn du in einem kritischen Wettlauf falschen Kram (wie Größenangaben oder Zeiger) gelesen hast und weiterverarbeiten willst.

Beschreib entweder genau, wie das ganze abläuft, oder such alleine weiter. Das hier ist doch kein bekacktes Call-in-Forum … Speicherallokationen? Oooooh, leider nicht dabei. Ein doppelt initialisierter kritischer Abschnitt beim Empfangen einer Nachricht, die zwei angehängte, halb überlappende Speicherbereiche überträgt wär’s gewesen! Bleiben Sie in der Leitung bis wir sie zum Trostpreis durchstellen.

[kimmi]

Schau dir mal an, ob dein Mainthread irgendwo durch ein Mutex auf Daten wartet. Wenn du beispielsweise den Zugriff auf deine Daten geshared hast und diesen dann per Mutex / Semaphore gelockt hast, kann es zu solchen Aussetzern kommen.

Aber das ist ein Schuss ins Blaue.

Gruß Kimmi

[Zudomon]

Oder könnte es auch sein, dass ich doch irgendwo auf den gleichen Speicherbereich zugreife? Aber bisher war es so, dass der dann entsprechende Zugriffsverletzungen aufgetaucht sind...

Zugriffsverletzungen tauchen da sicher nicht auf. Die tauchen nachher auf, wenn du in einem kritischen Wettlauf falschen Kram (wie Größenangaben oder Zeiger) gelesen hast und weiterverarbeiten willst.

Also ich hatte schon den Fall, dass wenn ich Daten geändert hatte, die von einem anderen Thread benutzt wurden, dass dann irgendwo... und mir schien, völlig willkürlich und immer an anderer Stelle eine Exception aufgetreten ist.

Beschreib entweder genau, wie das ganze abläuft, oder such alleine weiter. Das hier ist doch kein bekacktes Call-in-Forum … Speicherallokationen? Oooooh, leider nicht dabei. Ein doppelt initialisierter kritischer Abschnitt beim Empfangen einer Nachricht, die zwei angehängte, halb überlappende Speicherbereiche überträgt wär’s gewesen! Bleiben Sie in der Leitung bis wir sie zum Trostpreis durchstellen.

Sorry, wollte nicht diesen Eindruck erwecken. Aber im moment hab ich ebend wenig Zeit und wollte aber auch kurz ein Feedback geben.
Was genau wäre denn Sinnvoll zu wissen? Es ist viel unübersichtlicher Code und alles ist irgendwie verstrickt... :D

Schau dir mal an, ob dein Mainthread irgendwo durch ein Mutex auf Daten wartet. Wenn du beispielsweise den Zugriff auf deine Daten geshared hast und diesen dann per Mutex / Semaphore gelockt hast, kann es zu solchen Aussetzern kommen.

Ich benutze nirgendwo mehr Mutex / Semaphore / CriticalSections... und der Hauptthread läuft auf einem seperaten CPU-Kern...

[Krishty]

Was genau wäre denn Sinnvoll zu wissen? Es ist viel unübersichtlicher Code und alles ist irgendwie verstrickt... :D

Werden die Daten kopiert, bevor der Haupt-Thread sie benutzt? Bei so großen Datenmengen, wie du verarbeitest, könnte das ein Flaschenhals sein. Generell: Wie ist der Besitz der Daten geregelt? Was macht der Haupt-Thread, sobald er sie erhält? Was machen die anderen Threads, sobald sie fertig sind?

Ich benutze nirgendwo mehr Mutex / Semaphore / CriticalSections... und der Hauptthread läuft auf einem seperaten CPU-Kern...

Stattdessen InterlockedXXX()?

[kimmi]

Der Haupt-Thread kann natürlich auf einem separaten CPU-Kern laufen, allerdings betreibst du das ja nachdem, was ich diesem Thread entnehmen konnte, auf einem Shared-Memory Modell. Wie stellst du sicher, dass die Daten sinnvoll aktualisiert und dann dem Render-Thread zur Verfügung gestellt werden? Benutzt du eine Lock-Free Strategie? Entstehen Diskrepanzen, wenn du viele oder wenige Daten befüllst bzw. auf irgendeine Weise unter den Threads synchronisierst? Vielleicht könntest du da dein Vorgehen mal näher erläutern, das macht das helfen leichter :).

Gruß Kimmi

[Zudomon]

@krishty & kimmi
Der Hautthread besitzt alle Objekte...
Es gibt EngineObjekte, die ein SubObjekt haben, von welchem dann Texturen/Modelle/Materialien usw. abgeleitet sind. Die Geometrie um die es erstmal geht, hat nun noch ein Modifier Unterobjekt, dieses stellt letztlich die Geometriedaten her und besitzt diese... das ganze äußert sich in einem Decorator-Pattern.

Für Kollision und zum Rendern wird die Geometrie "benutzt"... diese hat eine Bool-Variable, ob sie denn auch Ready ist... ist das nicht der Fall ist, wird sie "vorbereitet"... ist die Geometrie nicht für Multithreading geflaggt, passiert das sofort, ansonsten wird die Geometrie übersprungen und in ein Liste für "zu bearbeitende Geometrie" steckt. In der Hauptschleife der Engine wird nach einem freien WorkerThread gesucht, wenn es einen gibt, so bekommt dieser die Geometrie überwiesen ( als Pointer )...
Die WorkerThreads haben selbst eine Bool-Variable, ob sie Arbeiten. Diese wird aber auch nur vom Hauptthread aus angesteuert. Dieser weiß ja dann auch, ob er die Aufgabe an dem WorkerThread verteilt hat.
Der WorkerThread macht dann nichts anderes, als die Geometrie zu verarbeiten und wenn er fertig ist, eine Message an den Hauptthread zu schicken. Der wiederrum reagiert auf die Message und kann nun die Geometrie als Ready und den WorkerThread als Arbeitslos flaggen.

Also Daten werden keine kopiert.

[Krishty]

Für Kollision und zum Rendern wird die Geometrie "benutzt"... diese hat eine Bool-Variable, ob sie denn auch Ready ist... ist das nicht der Fall ist, wird sie "vorbereitet"... ist die Geometrie nicht für Multithreading geflaggt, passiert das sofort, ansonsten wird die Geometrie übersprungen und in ein Liste für "zu bearbeitende Geometrie" steckt. In der Hauptschleife der Engine wird nach einem freien WorkerThread gesucht, wenn es einen gibt, so bekommt dieser die Geometrie überwiesen ( als Pointer )...

Wie ist die bool (und auch die der Threads) denn geschützt?

[Zudomon]

Für Kollision und zum Rendern wird die Geometrie "benutzt"... diese hat eine Bool-Variable, ob sie denn auch Ready ist... ist das nicht der Fall ist, wird sie "vorbereitet"... ist die Geometrie nicht für Multithreading geflaggt, passiert das sofort, ansonsten wird die Geometrie übersprungen und in ein Liste für "zu bearbeitende Geometrie" steckt. In der Hauptschleife der Engine wird nach einem freien WorkerThread gesucht, wenn es einen gibt, so bekommt dieser die Geometrie überwiesen ( als Pointer )...

Wie ist die bool (und auch die der Threads) denn geschützt?

Überhaupt nicht... aber die Workerthreads greifen auf diese ganzen bools nicht zu (weder lesend noch schreibend)... das wird alles vom Hauptthread aus gesteuert.

[Krishty]

Ah stimmt, mein Fehler :/

Läuft denn alles rund, wenn keine Arbeit ansteht? (Die Grundsatzfragen zuerst …)

Stellt der Haupt-Thread noch sowas wie Cacheing mit der Geometrie an?

[Zudomon]

Ah stimmt, mein Fehler :/

Läuft denn alles rund, wenn keine Arbeit ansteht? (Die Grundsatzfragen zuerst …)

Stellt der Haupt-Thread noch sowas wie Cacheing mit der Geometrie an?

Also wenn die Threads gerade keine Geometrie bearbeiten, dann sind die pausiert. Allerdings hatte ich auch mal ne Endlosschleife am laufen, so das die Kerne ausgelastet sind... das wiederrum beeinflusst den Hauptthread nicht im geringsten.

Wie meinst du das mit dem Caching? Aber ich glaube, ich mache damit nichts...

[Krishty]

Also wenn die Threads gerade keine Geometrie bearbeiten, dann sind die pausiert.

Wie pausieren sie? Ist auch wieder nur geraten, aber könnte das Pausieren und Wiederaufnehmen Kernwechsel bewirken? Oder dass die Threads noch nicht aus dem Senden der Nachricht zurückgekehrt sind bevor sie pausiert werden?

Wie meinst du das mit dem Caching? Aber ich glaube, ich mache damit nichts...

Ob du die Daten für die Verwendung nochmal nachbearbeitest oder so. Aber das machst du ja nicht und wenn es auf voller Auslastung rund lief wird es das auch nicht gewesen sein.

[CodingCat]

Allerdings hatte ich auch mal ne Endlosschleife am laufen, so das die Kerne ausgelastet sind... das wiederrum beeinflusst den Hauptthread nicht im geringsten.

Genau hier solltest du ansetzen. Nimm immer mehr von der Geometrieerzeugung weg, bis es nicht mehr ruckelt. Wenn es nicht mehr ruckelt, du aber immer noch nicht schlauer bist, füge die weggenommenen Teile soweit möglich mal getrennt bzw. in verschiedenen Kombinationen hinzu, bis du den Verursacher isoliert hast. Mit dieser Information solltest du dir dann entweder selbst helfen oder zumindest detailliertere Angaben zum Problem machen können.

[Helmut]

Greifen denn beide Threads auf die Festplatte zu? Egal, wie die Prioritäten gesetzt sind, kann es dann zu Verzögerungen kommen. Bau also mal testweise alle Festplattenzugriffe aus dem Workerthread aus (durch Zufallsfunktion ersetzen oder so).
Ansonsten erklär doch mal, wie der Hauptthread auf die Daten vom Workerthread zugreift und was der Workerthread nun eigentlich macht. Und wie pausierst du? Ich hoffe doch nicht mit der SuspendThread Funktion oder?

[Zudomon]

Sorry, dass ich so lange brauche!! Wie gesagt, im moment extrem wenig Zeit...

Habe mich nun nochmal mit dem Problem auseinandergesetzt und es etwas runterbrechen können...
Der Hauptthread läuft auf dem ersten Kern, alle Workerthreads auf den anderen Kernen...
In den Workerthreads wird nun nur noch eine Endlosschleife ausgeführt -> Alle Kerne laufen auf nahezu 100%
Nun werden in dieser Endlosschleife immer verschieden große Arrays von Vektoren ( Structs ) erzeugt und befüllt werden -> Alle Kerne laufen auf nahezu 100%

ABER...
Wenn ich nun in der Endlosschleife eine Klasse instanziere und wieder frei gebe sind die kerne nur noch bei etwa 50%... also die Geschwindigkeit schwankt dann sehr stark, aber man sieht deutlich, dass da was nicht stimmen kann...

Nun wird in Delphi zwischen Structs und Klassen unterschieden, erstere landen auf dem Stack, letztere auf dem Heap...

Die Endlosschleife der Workerthreads sieht so aus:

Code: Alles auswählen

        while true do begin
          m:=TMemoryStream.Create;
          m.Free;
        end;

und sollte ziemlich Äquivalent zu einem new und delete in C++ sein...

Vielleicht habt ihr noch eine Idee??

Gruß
Zudo

[CodingCat]

Na vermutlich ist das Erzeugen von Instanzen in Delphi dann synchronisiert, d.h. die Threads warten immer, bis kein anderer Thread mehr Klassen instanziiert, um die eigene Instanz anlegen zu können. Dynamische Allokationen zu reduzieren (bzw. vollends zu entfernen) ist in C++ sowieso immer eine gute Idee in zeitkritischen Schleifen. Wenn der Ablageort in Delphi durch den Typ entschieden wird, müsstest du dann wohl entweder Instanzen wiederverwenden oder auf structs umsteigen.

Relevant wäre jetzt noch, ob das nur in diesem extremen Testfall ein Problem ist, oder ob du tatsächlich in den echten Workers ständig Objekte anlegst. In allen Fällen ist das ein typisches Synchronisationsproblem, da hilft nur Abhängigkeiten reduzieren.

[kimmi]

Ich empfehle gerade hier einen Stackallocator. Damit solltest du effizienter in dem Loop arbeiten können.

Gruß Kimmi

[Top-OR]

Mal ne ganz naive Frage: Hast mit mit Prioritäten experimentiert? (Ich hoffe, ich habs nicht überlesen -> ja, hab ich wohl . vergiss es.)

Nächste Frage: Du benutzt keine Mutexe/CritSections? Wie übergibst du die "Nachrichten" an den MainThread?
Dazu musst du doch auch was callen. Ist das per Mutex abgesichert?

[Zudomon]

Nächste Frage: Du benutzt keine Mutexe/CritSections? Wie übergibst du die "Nachrichten" an den MainThread?
Dazu musst du doch auch was callen. Ist das per Mutex abgesichert?

Ich sende, wenn der Thread fertig ist eine Message an den Hauptthread.... wenn dieser die Message bekommt, weiß er, dass der Thread seine Aufgabe erledigt hat... mal abgesehen von den CritSections, die Delphi hier wohl dreißterweise selbst einbaut beim erstellen von Klassen und übrigens, wie es scheint, auch bei Mehrdimensionalen Arrays, benutze ich selbst keine einzige...

[BeRsErKeR]

Nächste Frage: Du benutzt keine Mutexe/CritSections? Wie übergibst du die "Nachrichten" an den MainThread?
Dazu musst du doch auch was callen. Ist das per Mutex abgesichert?

Ich sende, wenn der Thread fertig ist eine Message an den Hauptthread.... wenn dieser die Message bekommt, weiß er, dass der Thread seine Aufgabe erledigt hat... mal abgesehen von den CritSections, die Delphi hier wohl dreißterweise selbst einbaut beim erstellen von Klassen und übrigens, wie es scheint, auch bei Mehrdimensionalen Arrays, benutze ich selbst keine einzige...

Ich stell mir vor, dass es unter Umständen "böse" werden kann, wenn da zwei Workerthreads gleichzeitig ihr "Ich habe fertig"-Signal an den Mainthread schicken. Es sei denn, die nutzen da wirklich verschiedene Methoden und der Mainthread macht da nicht an gleichen internen Daten rum. Ansonsten muss da schon eine Art Lock rein. Aber dafür kenn ich deinen Code usw zu wenig.

[Top-OR]

... mal abgesehen von den CritSections, die Delphi hier wohl dreißterweise selbst einbaut beim erstellen von Klassen und übrigens, wie es scheint, auch bei Mehrdimensionalen Arrays, benutze ich selbst keine einzige...

Bist du sicher, dass Delphi solche Sauereien macht? Ich weiß nicht obs so ist, aber es klingt pervers.

Dann bleibt dir scheinbar nur übrig, als rauszufinden, wann Delphi sowas macht und an welchen Stellen deines Codes du solche Dinge provozierst, mit anderen Worten, an welchen Stellen deines Codes zu doch indirekt Locks verwendest.

Ich bin mir nicht sicher - es ist nur son schwammiges Gefühl - aber ich kann mir nicht vorstellen, dass das Speicher-Allocaten solche massiven Störungen verursacht. Ich vermute, es ist was anderes... vielleicht solche Locks, die du nicht "siehst" ... wenn den Delphi überhaupt sowas macht (wie gesagt, keine Ahnung, ob es das tut).

[mär]

Ich bin mir nicht sicher - es ist nur son schwammiges Gefühl - aber ich kann mir nicht vorstellen, dass das Speicher-Allocaten solche massiven Störungen verursacht.

Ich schon... Vermutlich liegt das Problem am Speicher bzw. an der Bandbreite. Die Threads greifen vermutlich massiv auf ungecachten Speicher zu...

[Krishty]

Ich kann mir unter vagen Beschreibungen wie Ruckeln, Haken und 50 % CPU-Auslastung nichts vorstellen. Geht es um allgemeine Trägheit, also fortlaufende winzige Verzögerungen, oder um Haken, also sporadische Verzögerungen im Milisekundenbereich (das habe ich am Anfang so rausinterpretiert)? Könntest du ein Diagramm von dem Durchsatz einzelner Threads über die Zeit anfertigen, falls es das Verhalten nicht zu sehr verfälscht? Profiler in der Nähe?