Asynchron Jobs abarbeiten - Best Practice?

[chaosben]

Moin!

Bitte helft mir mal auf die Sprünge: Wie macht man folgendes am richtigsten?

Das grundsätzliche Vorgehen ist dieses:

Der Hauptthread des Dienstes ermittelt die abzuarbeitenden Jobs. Die schreibt er in die Job-Liste der einzelnen Job-Threads.
Die Job-Threads erledigen die Jobs und schreiben sie dann in die JobsDone-Liste des Hauptthreads zurück.
Dann löscht der Hauptthread die Jobs, die in der JobsDone-Liste stehen.

Die Frage ist: Auf welche Weise schreibt man am besten (damit man die höchste Geschwindigkeit erzielt) in die Listen der Threads(Haupt->Job und Job->Haupt)?
Jeden Job einzeln oder mehrere Jobs in einem Rutsch?

Der Hintergrund der Frage ist: Beim Schreiben muss man die Liste ja sperren, bzw. irgendeiner andere Methode (CriticalSection, ...) nutzen um Konflikte zu vermeiden. In der Zeit werden die anderen Threads ja blockiert. Was ist also der beste Weg möglichst wenig Wartezeit zu haben?

[mkinzler]

Schau doch mal, wie Andreas das gelöst hat
http://andy.jgknet.de/blog/?page_id=100

[HeZa]

Du solltest auch noch unbedingt einen Blick auf OmniThreadLibrary werfen.

[himitsu]

Ich hab das bei meinen Programmen inzwischen oftmals so gelöst.
( über diese Klasse > http://www.delphipraxis.net/internal...096957#1096957 )

> der Hauptthread füllt eine Liste, mit den zu bearbeitenden Aufgaben
> alle Threads fragen nun in dieser Liste ab, ob es was gibt,
also der Thread, welcher grade nix zu tun hat, der nimmt sich die älteste Aufgabe raus und bearbeitet siese

Wenn man für jeden Thread eine eigene Liste verwaltet, dann müsste der Hauptthread schon genau wissen, wie lange die Aufgaben dauern und verteilt so die Aufgaben ... hier kann es aber auch mal vorkommen, daß einige Threads nichts zu tun haben, wärend andere Threads sich zu Tode rackern, weik die Aufgaben nicht "gut" verteilt wurden.

Die Liste hatte ich direkt schon mit einer Threadabsicherung ausgestatet, damit dieses beim Zugriff nicht noch zusätzlich in den Threads behandelt werden muß (wo man es schnell mal vergessen könnte).

PS: Willlst du jetzt noch eine Rückmeldung, für die erledigten Aufgaben, dann könnte man (wie du es wohl vor hast) die erledigten Aufgaben von den Threads in eine weitere Liste eintragen lassen, welche dann vom Haupthtread ausgelesen wird (praktisch alles nur andersrum) oder du schickst deinem Hauptprogramm einfach via PostMessage, SendMessage oder auch über einen synchronisierten Prozeduraufruf eine Meldung "Diese Aufgabe ist jetzt fertig" (wobei die Varianten, mit der 2. Liste, bzw. über PostMessage, aus Sicht der Arbeitssthreads vermutlich das Schnellere wären).

[chaosben]

Danke himi für das ausführliche drüber nachdenken.

Ich habe dummerweise verschwiegen, das die Jobs zu genau einem Thread gehören. (Der Job-Thread hat einen DB-Verbindung und der Job ist für genau diese DB bestimmt).

Was mir aber immer noch nicht klar ist: Was ist besser: Eine gemeinsame Liste nur kurz aber oft zu sperren oder länger und seltener zu sperren.

Btw.: Das Prinzip wie ich es oben beschrieben habe, läuft im Moment schon ... es funktioniert. Die Frage hat eher einen Tuning-Hintergrund ... so nach dem Motto: Kann ich das Ganze noch schneller machen?

[himitsu]

Zitat von chaosben:

Was mir aber immer noch nicht klar ist: Was ist besser: Eine gemeinsame Liste nur kurz aber oft zu sperren oder länger und seltener zu sperren.

Die Pausen zwischen den Sperrungen sollten auf jedenfall länger sein, als die Sperrung selber andauert.
Sonst passiert schnell mal sowas, wie in diesem Thread http://www.delphipraxis.net/internal...t.php?t=172942 , wo alles hängen bleibt.

Also es kommt darauf an, wie schnell der Thread arbeitet und wie lange er auch mal auf eine neue Aufgabe warten kann.
- Wenn der Thread zeit hat, dann kann länger+seltener sperren nicht schädlich sein.
- Wenn der Thread aber sehr schnell neue Aufgaben beginnem muß, dann eben lieber kürzer+öfters.

[mkinzler]

Du könntest aber auch die Verwaltung der Liste von einem Thread durchführen lassen

[chaosben]

Ok ... vielen Dank.