Parallel Programming Library: Reihenfolge von Tasks (Priorisierung)

[karlkoch]

Hallo,

ich verarbeite Vorschaubilder eines Verzeichnisses mit vielen Bildern. Für jede Datei im Verzeichnis starte ich einen Task und lasse ihn von der Delphi Parallel Programming Library verarbeiten. Soweit nichts besonders.

Während der Nutzer durch die Liste der Bilder scrollt, möchte ich gern, dass die Tasks der aktuell sichtbaren Bilder priorisiert werden. Soll heißen, gibt es mit der PPL von Delphi die Möglichkeit, die Reihenfolge einmal gestarteter Tasks zu manipulieren, solange sie in der Queue auf einen Workerthread warten und noch nicht verarbeitet wurden?

Viele Grüße,

karlkoch

[Delphi-Laie]

Man kann die Priorität von Prozessen und Threads verändern, evtl. auch schon bei ihrem Start festlegen.

Ansonsten läßt sich, soweit ich weiß, Windows aber grundsätzlich nicht in seine Entscheidungen, wann was behandelt bzw. abgearbeitet wird, hineinreden.

[karlkoch]

Hallo,

es geht nicht um Thread- oder Prozessprioritäten, sondern um die Abarbeitungsreihenfolge der Delphi PPL (die nichts mit Windows zu tun hat).

Viele Grüße,

karlkoch

[Der schöne Günther]

Du kannst einen Task/Future höchstens explizit in einem bestimmten TThreadPool stecken, und die können unterschiedliche Limits (Min & Max) für Worker-Threads haben. Allerdings ist auch nicht vorgesehen einen Task wieder aus einem Threadpool herauszunehmen und dann in einen anderen zu stecken.

Ich würde einfach zwei Listen anlegen (sichtbare und unsichtbare Einträge) und ein Task ist so gebaut dass er eine sichtbare Datei bearbeitet. Wenn keine da ist, eine unsichtbare.

[karlkoch]

Zitat:

Zitat von Der schöne Günther (Beitrag 1476115)

Ich würde einfach zwei Listen anlegen (sichtbare und unsichtbare Einträge) und ein Task ist so gebaut dass er eine sichtbare Datei bearbeitet. Wenn keine da ist, eine unsichtbare.

Ja, ich denke die Tasks dürfen erst den eigentlichen "Job" bekommen, wenn sie an der Reihe sind. Dann muss ich keine Tasks umsortieren, sondern brauch einfach nur meine interne Job-Liste anpassen.

Ein Problem sehe ich dabei noch. Wenn mehrere Bereiche einer Anwendung den gleichen ThreadPool verwenden, wie verhindere ich, dass ein Bereich mit einer Fülle an Tasks den Pool eine längere Zeit für sich beansprucht? Um das zu lösen, müsste ich das Konzept global einsetzen, d.h. alle Tasks aller Anwendungsbereiche dürfen erst bei der tatsächlichen Ausführung ihren Job bekommen. Gibt es von der PPL eine vorgefertigte Lösung, um so ein grundsätzliches Problem zu lösen?

Viele Grüße,

karlkoch

[himitsu]

Joar, leibt wohl nur selbermachen.

* eine TThreadList bzw. TStack+ThreadLock mit den Bildern
* ein ThreadPool (mehrere Threads) die sich nacheinander dort ein Bild rausholen
* und dann in ThreadList die Bilder hochschieben, welche drade angezeigt werden sollen, damit sie aös nächstes dran kommen
* * wenn ganz schnell, eventuell manuell einen neuen Thread starten (oder den Pool kurz vergrößern) und notfalls einen anderen Thread pausieren (bzw. dessen ThreadPriorität runtersetzten oder die Priorität des neuen Threads erhöhen), damit es schneller geht

Zitat:

Ein Problem sehe ich dabei noch

Die Aufgaben priorisieren, damit das Wichtige zuerst kommt, egal von wo es kommt.
Oder mehrere Threadpools, wo du dann aber die Poolgrößen eventuell anpassen müsstest/könntest, jenachdem vieviele (arbeitende) Pools es gibt.

[Mavarik]

Zitat:

Zitat von karlkoch (Beitrag 1476119)

Gibt es von der PPL eine vorgefertigte Lösung, um so ein grundsätzliches Problem zu lösen?

Ich würde bei dieser Problemstellung ganz auf die PPL verzichten. Da Du die Bilder - wenn ich es richtig verstanden habe - von der Platte liest,
würde ich sowieso nicht mehr als 8 Threads nehmen, ggf. sogar weniger.
In so einen Fall nehme ich 6 Worker Thread und 2 Prio-Threads. Oder (4/1).

Von da aus gibt es zwei Möglichkeiten. Entweder eine direkte Trennung 2 (Threadsafe)-Listen oder ggf. einen Thread-Listen-Thread die die Aufgaben verteilt und ggf.
die Liste umsortiert oder Aufgaben nach Priorität rauspickt und dann verteilt.

Mavarik

[karlkoch]

Ok, bisher bin ich mit eigenen Entwicklungen gut gefahren, war jedoch der Hoffnung, meine Implementierungen schrittweise durch "native" Unterstützungen zu ersetzen. Schade, dann ist die PPL immer noch nicht für meine Zwecke geeignet.

Viele Grüße,

karlkoch

[Mavarik]

Zitat:

Zitat von karlkoch (Beitrag 1476129)

Ok, bisher bin ich mit eigenen Entwicklungen gut gefahren, war jedoch der Hoffnung, meine Implementierungen schrittweise durch "native" Unterstützungen zu ersetzen. Schade, dann ist die PPL immer noch nicht für meine Zwecke geeignet.

Wenn man als Werkzeug nur einen Hammer hat, sehen alle Ziele wie ein Nagel aus...

Sicherlich kann man viele Hintergrundverarbeitung mit der PPL lösen, aber wie immer bei Lösungen nach dem Motto "One fits all", gibt es in der Regel eine
spezielle Lösung für ein Problem, dass der Anforderung besser gerecht wird.

Die PPL ist sehr gut für "shot and forget" geeignet. Spätestens, wenn es sich nicht um "Schön-Wetter-Code" handelt und ggf. Fehlermeldung/Exceptions zu erwarten sind,
muss man sich auch mit der PPL schon Gedanken machen.

Also bei Hintergrundverarbeitungen z.b. in Apps für iOS & Android, bei denen möglichst alles was nicht auf die UI zugreift, im Hintergrund ausgeführt werden sollte, ist die
PPL sehr hilfreich bis zu - ohne geht es kaum.

Daher - immer das richtige Werkzeug für das zu lösende Problem verwenden!

Mavarik

[karlkoch]

Hallo,

an sich bin ich mit der PPL zufrieden, es fehlen nur Kleinigkeiten, um mein Vorhaben mit der Library umzusetzen.

Eigentlich ist das Problem gar nicht mehr die fehlende Priorisierung, sondern die Möglichkeit, die maximale Anzahl gleichzeitig abzuarbeitender Tasks zu beschränken. Meine Idee ist, durch einen eigenen "Scheduler" die vielen Tasks zunächst in einer eigener Queue zu sammeln und immer nur dann an die PPL zu übergeben (ITask.Start), wenn aktuell nicht mehr als X Tasks ausgeführt werden. Gerade bei Festplatten- oder Datenbankzugriffen darf es nicht zu viele gleichzeitige Tasks geben, wobei TThreadPool.SetMaximumWorkerThreads keine Abhilfe schafft, weil dieser Wert an die CPU-Kerne gebunden ist.

Leider scheitert mein Vorhaben aktuell daran, dass ich es nicht schaffe, auf saubere Art und Weise extern über die Fertigstellung eines Tasks informiert zu werden, damit ich die nächsten Tasks rausschicken kann (egal ob ein Task ausgeführt, abgebrochen oder durch einen Fehler beendet wurde). Interessant sieht für mich TTask.ProcessCompleteEvents aus, weil das immer am Ende eines Tasks aufgerufen wird, allerdings verhindert TTask eine Ableitung, sodass ich diese Methode überschreiben könnte.

Oder hat jemand einen anderen Ansatz für mich?

Viele Grüße,

karlkoch