Hat jemand schon eine Dateisuche für Multicore geschrieben?

[Dezipaitor]

Hi,

es gibt ja eine Menge Threads zum Thema FindFirst. Also dir Datei- und Ordnerauflistung oder -Suche.
Jedoch sind die alle nur für einen Kern.

Die Frage ist daher, wer hat schonmal, oder wer kann sich ein Konzept vorstellen, FindFirst für Multicore Prozessoren zu nutzen.

Reicht es einfach stupide mehrere Threads zu erstellen und diese werden dann auf verschiedene Kerne verteilt, ohne dass man extra Sachen macht? Also verteilt Windows Threads automatisch auf verschiedene Kerne?
Dann wäre es mehr oder weniger einfach eine Multithreadsuche zu erstellen.

Irgendwelche Vorschläge?

[gsh]

jo es ist so einfach:
1 Thread (z.b. Hauptthread) = SingleCore nutzung
2 Threads = DualCore
4 Threads = QuadCore

[OregonGhost]

Grundsätzlich verteilt Windows das schon und man sollte da nicht allzuviel reinpfuschen. Aber andererseits kannst du natürlich problemlos die Prozessoraffinität jedes einzelnen Threads einstellen, so dass jeder Thread definitiv auf einem eigenen Kern/Prozessor läuft, das ist gar nicht so kompliziert, wie es sich vielleicht anhört. Vergiss dabei jedoch folgendes nicht:
Die Suche greift auf den Datenträger zu. Wenn mehrere Threads gleichzeitig an ganz verschiedenen Orten suchen, kann die Zugriffszeit sich dramatisch erhöhen. Den Flaschenhals beim Suchen stellt ohnehin nicht die Rechenzeit da (was Multithreading ja verbessern würde), sondern die Wartezeit. Insofern bezweifle ich einen übermäßigen Performance-Anstieg ohnehin, aber ich bin gespannt auf deine Testergebnisse, so sie kommen :)

[sirius]

Zitat:

Wenn mehrere Threads gleichzeitig an ganz verschiedenen Orten suchen

Und bei verschiedenen Platten?

[C.Schoch]

Bei verschiedene physikalischen Platten bist du im optimalen Fall doppelt so schnell, das Suche nicht sequentiell sondern parallel abgearbeitet wird.
Kann ich selbst bestätigen

[OregonGhost]

Klar, das ist so. Die große Frage ist halt, ob die explizite Aufteilung auf mehrere Kerne hier so viel bringt oder ob es nicht ausreicht, Windows einfach machen zu lassen, weil die Suchthreads so oder so die meiste Zeit auf die Festplatte(n) warten.

[Dezipaitor]

Also ich kann definitv sagen, das Windows Vista meinen Quadcore bei der Suche und auch bei der Änderung von Dateisicherheiten nutzt.
Alle Kerne sind da immer gut 2/3 ausgelastet. Man kann schon garnicht mehr nebenher was machen. Ich entferne daher immer 1 oder 2 Kerne vom Explorer, damit ich weitermachen kann.

Jetzt ist nur die Frage, wie man den Algorithmus erstellt.
Ich hätte folgenden Vorschlag:


1a. Hauptthread (oder eigener neuer Thread) durchsucht das Ziel nach allen Verzeichnissen auf allen Ebenen. Es sucht nur nach Ordner
und setzt diese in eine Liste. Jeder Eintrag enthält einen vollständigen Pfad. Gibt es keine Ordner mehr, wartet der Thread
auf die anderen Threads. Dieser Thread kann auch die anderen Threads beenden, wenn er beendet wird (durch Nachricht).
1b. Threads erstellen. Anzahl = Kerne
2. Hier ist das Problem:
Die anderen Threads starten nach einer gewissen Zeit oder Anzahl von Ordnern, indem sie aus der Liste Ordner entnehmen (diese Löschen)
und darin nach Dateien suchen (oder alle durchgehen, je was gewünscht wird)
Der Zugriff auf die Liste muss natürlich synchronisiert werden.
3. Jeder Thread enthält eine eigene Gefundenliste, die die Pfade zu den gesuchten Dateien enthält.
Es gibt auch die Alternative, wenn z.B. etwas mit den Dateien gemacht werden soll (zB. Attribute angepasst), dann wird das über ein Callback (MultiThreading
muss der Aufgerufene beachten).


Ich meine diese Lösung ist nur ein Ansatz. Es könnte z.B. bei sehr vielen Ordnern Probleme geben, wenn diese nur wenige Dateien haben. Dann warten die anderen Threads ständig auf, dass neue Ordner in die Liste kommen.
Wie man jedoch mehrere Threads auf die Ordnersuche schickt, kann ich mir derzeit nicht vorstellen.

Irgendwelche Vorschläge?

[Dezipaitor]

Die schnellste Suche ist immernoch die inidzierte Suche. Also ständiges indizieren im Hintergrund un speichern der Daten in einer DB.
Das funktioniert aber nicht für Situationen, in denen man Änderungen oder andere Besonderheiten (Sicherheit, Attribute) machen muss.

Ich habe mir nochmal den Vorgang überlegt:

1. (Hauptthread)
Initialisieren einer Liste für die Ordnernamen (absolut) (OL)
Initialisieren einer Critical Section CS für den Zugriff auf die OL.
Initialisieren einer Liste für die gefundenen Dateien (DL)
Initialisieren einer Critical Section CDL für den Zugriff auf die DL.
Initialisieren eines CallbackEvents (CE) für Lieferungen von gesuchten Dateien
Initialisiere eines Beenden Flag (BF) für das (vorzeitige) Beenden der Threads
Initialisieren von x ThreadState Flags (TS) für die Signalisierung, dass der Thread keine Aufgabe hat.

Einfügen der Suchordner in die OL. Hier können beliebig viele Startordner oder -laufwerke eingetragen werden.

x Threads erstellen, wobei x für die Anzahl der Kerne steht. Die Threads bekommen alle eine Suchmaske (z.B. *.*)
und ein Handle auf die CS, CDL, CE, BF und sein eigenes TS.

Der Hauptthread geht in einer Schleife mit folgender Endbedingung: Alle Threads sind arbeitslos, d.h. alle TS Flags
sind gesetzt. Wenn dies der Fall ist, wird BF gesetzt und per WaitFor Api auf die Threads gewartet und dann die Suche beendet

In der Schleife überwacht der Thread das CE. D.h. wenn das Event CE ausgelöst wird (oder es ein Timeout gibt),
dann wird CDL gesperrt und die DL wird kopiert, entleert und die CDL entsperrt. Die kopierten Dateien, werden dann als
Ereignis ausgegeben.


2. Threads
Jeder Thread wartet auf die CS. Wenn sie nicht gesperrt ist, dann sperrt er die CS, holt den ersten Ordnername und
entsperrt die CS. Der Thread läuft erst dann weiter, wenn die CS entsperrt wird. Das gilt für jedne der x Threads.
Fortgang:
Über FindFirst und Findnext werden die gesuchten Dateien in dem Unterordner aufgelistet. Zudem werden auch immer die
Ordner alle in einer Threadlokalen Liste gespeichert.
Wenn die Suche in diesem einen Unterordner beendet ist (keine weitere Suche in tieferen Unterordnern!!!), dann wird diese Ordnerliste
unter Sperrung und Entsperrung der CS in die OL eingefügt. Dies passiert einmalig nachdem es keine weiteren Dateien und Ordner gibt.
Dadurch wird verhindert, dass die CS ständig gesperrt werden muss.
Wird eine gewünschte Datei gefunden, dann wird sie auch ersteinmal in eine lokale Liste eingefügt und am Ende (genauso wie die OL)
über das CallbackEvent CE an den Hauptthread gesendet. Der Hauptthread bekommt daher eine Liste von gewünschten Dateien und kann
diese an die Anwendung über ein Ereignis übermitteln oder als Endergebnis zwischenspeichern.

Enthält die OL kein Ordner mehr, dann passiert folgendes*:
Der Thread setzt das ihm zugeordnete ArbeitslosFlag TS und überprüft weiter, ob Ordner in OL vorhanden sind (wie anfangs).
Wenn Ordner wieder enthalten sind, dann wird das Flag TS gelöscht, sonst wird überprüft, ob das Beenden Flag BF gesetzt ist.
Wenn nein, gehts zurück zu (*). Wenn ja, dann beendet sich der Thread.










So ich hoffe das war verständlich. Was haltet ihr davon? Irgendwelche Fehler?

[sakura]

Mit FindFirst/FindNext auf mehrere Cores zu springen hilft nur, wenn Du auch mehrere physisch verschiedene Datenträger abfragst, sonst wirst Du insgesamt viel langsamer, da das ewige hin- und herspringen der Schreib/Leseköpfe der Datenträger verhältnismäßig sehr, sehr lange dauert. Es stellt sich also die Frage, ob Dein Ansatz überhaupt Sinn macht ;)

Nutze lieber, wie hier schon empfohlen den Windows Suchindex, lade Dir für Beispiele mal meine aktuellen EKON 11 Papiere aus meinem Blog ;)

...:cat:...

[Dezipaitor]

Ich will diesen Ansatz nicht nur für die Suche sondern auch für die Verarbeitung von allen Dateien und UnterOrdner eines oder mehrere Ordner verwenden.
Da wird z.B. der Sicherheitsdeskriptor jedes Ordners und jeder Datei überprüft und gegebenfalls neu angepasst.