Multithreaded File loader

Eisflamme

seekg(length / 2); ? Eine Überladung hat doch streampos als Parametertypen.

Ich frage mich nur gerade, ob das Sinn macht. Wo liegt denn bei so einem Lesevorgang der Bottleneck? Wird der mit MT behoben? Irgendwie bezweifle ich das...

Also ich seh mir das ganze gerade an und muss sagen es ist sinnlos.Wenn ich einen Datei habe ,wo ich einen streampointer habe und die Datei lese macht es kein sinn in 2 threads parallel von verschiedenen Stellen der Datei zu lesen ,weil die Threads ja nicht parallel laufen sondern nacheinander und da muss der positionspointer aufder Festplatte immer hin und her springen, was kein Sinn macht.

Ich habe mir überlegt einfach bei jedem Mesh, dass man laden will ein Thread zum Lesen von diesem zu erstellen, damit die anderen Komponenten flüssig weiter laufen können.

Jetzt hab ich meinen FilManager als Singleton deklariert, was denk ich mal das sinnvollste ist, da ich davon eben nur eine Instanz brauche und diesen quasie wie eine Funktion verwende.

Jetzt will ich ja beim Laden eines Meshes in dieser Klasse ein thread erstellen (also bei jedem Laden des Meshes wird eins erstellt ) und ich muss die HANDLE zu jedem Thread in einer STL list speichern (oder Vector).Dann müsste ich aber beim Update der liste/vector gucken, ob die threads alle laufen und wenn nicht diese Stelle der liste/vector entfernen. Gibts da eine elegantere Methode ??

Danke

hustbaer

Herr Bob Wolfskin,

was das reine Lesen angeht (Bytes rumschaufeln) gibt es nix schnelleres als lineares Lesen.
Dein Problem liegt auch wo anders, und zwar vermutlich beim Parsen. Und das meiste wirst du dabei nicht mit multithreading rausholen, sondern mit nem besseren (schnelleren) Parser.

Bzw. mit einem "schnelleren" binären File-Format.

Und was Threads angeht ... pfuh. Ich hab' nicht den Eindruck dass du das nötige Hintergrundwissen hast um korrekt mit Threads zu arbeiten.

Naja ich habe eigendlich bisher keine Probleme mit dem Parser , da ich ein bekanntes Formatdesign verwende.In der Tat habe ich nicht so viel mit Threads zu tun gehabt , jedoch muss ich nur für jedes Mesh was geladen wird eine Threadfunkton erstellen und da drinnen ganz normal parsen/ laden... das wars mit den Threads.Ich erstellte dafür eine map mit den HANDLE von jedem thread und ein DWORD für den thread zustand ( warte bis der thread fertig ist).Dann wird in der Update Funktion durch einen iterator dieser dword wert abgefragt und falls derthread fertig ist dieser aus der map mit dem handle gelöscht.

hustbaer

Also... äh.

Wenn du davon ausgehst dass das Parsen nicht der Flaschenhals ist, dann brauchst du keine Threads. Denn Threads können keine Daten von der Festplatte/SSD laden. Das macht der SATA Controller auf deinem Mainboard, und während der das macht macht der Thread heia.

Nur wird wie gesagt dort nicht der Flaschenhals sein, sondern bei der Verarbeitung der Daten - dem was ich mit "Parsen" bezeichne.

Und da kann man oft viel mehr mit anderem Code rausholen als mit mehreren Threads möglich wäre. Also vorausgesetzt du hast jetzt nicht 10 oder 100 Cores in deinem Rechner.

Natürlich kann man dann zusätzlich noch mehrere Threads parallel laufen lassen, um das ganze noch weiter zu beschleunigen. Das würde ich aber erst als zweites angehen, weil der zu erwartende Gewinn dabei eben nicht so toll ist. Mehr als Faktor 4 wirst du da mit aktuellen PCs kaum rausbekommen.

BTW: was bitte ist ein "Formatdesign"?

Ich glaube du verstehst das etwas falsch mit den Threads.

Ich arbeite schon viele Jahre mit einer 3D Engine ,wo das Laden von Dateien und Ressourcen leider nicht abstract in einem separaten Thread läuft, sondern ganz normal im Hauptthread der Anwendung, was zur Folge hat, dass beim Laden von Modelen/Texturen etc. alles angehalten wird (Renderer,physics Simulation.....)

Es ist z.B nicht möglich wie bei fast allen Spielen währen der am Anfang laufenden Splashscreens Daten für z.B das Menu und für das Spiel selbst zu laden, weil einfach nichts mehr aktualisiert wird.

Als "Format design" meine ich das Design eines Datei formates, was in vielen DirectX Büchern verwendet wird.Eigendlich ein einfaches, jedoch schnelles Konzept ,wo man mit Chuncks arbeitet.

Die Threads sind dazu gedacht, da der Filemanager nur eine Instanz hat ,wird bei jedem Aufruf zum Laden von irgendwas (Mesh,Texture....) ein neuer Thread erstellt und dort drin wird das Mesh/texture etc. geladen, ohne dass die anderen Komponenten dadurch angehalten werden müssen.Es geht mir nicht darum irgendwie alle Modele gleichzeitig laden zu können, eher darum das ganze System nicht anzuhalten

welche engine ist das denn? so ein hobby-ding? "filemanager" hört sich stark nach heimarbeit an.

wenn die intern nicht synchronisiert wird, kannst du nicht einfach so ressourcen aus einem anderen thread reinschaufeln.

Ja das ist eine Heimarbeit.

Ich habe jetzt eine Threadfunktion mit einer struktur als Parameter (MeshLoaderParam enthält GMesh* mesh und std::string path )
Der pointer zu mesh wird dann in dem Thread ausgefüllt (bzw. die Buffer)

Denkst du dass funktioniert nicht ?

das kann man so pauschal nicht beantworten. wenn multithreading in der engine nicht vorgesehen ist, wirst du schlechte karten haben. dann darfst du im prinzip keine funktionen aus anderen als dem hauptthread aufrufen. das gibt dann bestensfalls abstürze oder (wahrscheinlicher) "unerklärliches" verhalten, das kaum reproduzierbar ist.

wenn du die daten selbst im hintergrund in den speicher laden und dann später im hauptthread der engine zum parsen geben kannst, hast du bessere chancen.

hustbaer

@Bob Wolfskin
Naja, die Frage ist ob die Mesh-Ladefunktion thread-safe ist.
Und das können wir die nicht beantworten, wenn wir nicht wissen womit du arbeitest.
Wenn es eine selbst gebastelte Engine ist, und du dich mit Threads noch nicht so wirklich auskennst, dann stehen die Chancen relativ schlecht.