Workerthread: Der Diener im Hintergrund

[alzaimar]

Hallo,

Threads sind eine tolle Sache. Wenn man sie versteht. Wenn nicht, bringen sie einen an den Rand des Wahnsinns. Oder ein Stück weiter. Ich weiss, wovon ich rede.

Ich benötige für meine Applikationen immer mal wieder einen Thread, der ab und zu einzelne Jobs im Hintergrund ausführen muss. Wenn man z.B. auf bestimmte Ereignisse reagieren muss, diese Reaktion aber zeitaufwändig ist, dann kann die Ereignisbehandlung während der Ausführung des Eventhandlers blockiert sein.

Also habe ich einen generischen Thread implementiert, der einzelne Aufgaben (Jobs) im Hintergrund abarbeitet. Ich muss dazu nur den Job selbst definieren, alles Andere macht dieser Thread. Diese Threads nennen sich auch 'worker threads', weil sie eben ankommende Arbeiten ausführen.

So ein Job kann z.B. das Einlesen einer Tabelle von einer Datenbank sein, oder auch das Abspeichern von Daten.

Die Unit instantiiert einen Workerthread 'PendingJobs', den man sofort mit Arbeit befüllen kann. Dazu ruft man einfach die 'AddJob'-Methode auf:

Delphi-Quellcode:

...
PendingJob.AddJob (TMyJob.Create);
...

Die Anweisung schiebt den Job ans Ende der Jobliste und aktiviert ggf. den Thread (wenn der nicht sowieso schon aktiv ist). Der TMyJob wird dann 'demnächst' im Hintergrund ausgeführt.

Wenn man einen Job definiert, der mit COM-Objekten arbeitet (z.B. ADO) dann setzt man die Eigenschaft 'UsesCOMObjects' des Jobs auf True.


Der Thread verwendet eine Semaphore sowie eine Threadliste (die Liste der noch nicht ausgeführten Jobs). Auf Schnickschnack habe ich verzichtet, das kann jeder selbst einbauen.

Ich habe die Unit sowie eine kleine bescheuerte Demo bereitgestellt, die jedoch zeigt, wie einfach man Hintergrundarbeiten in seiner Anwendung implementieren kann.

Kritik, Verbesserungs- und Erweiterungsvorschläge sind ausdrücklich erwünscht.

Viel Spaß damit.

Update: Die Idee von thkerkmann wurde aufgenommen: Die Synchronize-Methode des Workerthreads ist nun public und kann innerhalb der TJob.Execute-Methode aufgrufen werden.

Update: Idee von shmia: Exception-Notification Event, und eine verbesserte Beendigung des Workerthreads. Man kann unn steuern, ob vor Beendigung alle ausstehenden Jobs noch abgearbeitet werden sollen oder nicht.

Update: Aus dem Thread wurde ein Threadpool (Idee von shmia). Er ist in einer wackeligen Version fertig. Er läuft in der Demo stabil, aber was heißt das schon. Ich würde Euch bitten, mal kräftig gegen die Klasse zu treten. Mal sehen, was sie aushält.

Der Threadpool verwaltet mehrere Threads (Anzahl einstellbar, auch zur Laufzeit), die gemeinsam die oben erwähnte Jobliste abarbeiten.

Update vom Threadpool: Schleifenvariablen als Cardinal deklariert, wenn Schleifenende = 'X-1', und X=0, bombt es.

Update vom Threadpool: Memoryleak beim Beenden beseitigt. Weiterhin stellt die Unit keine Instanz 'PendingJobs' mehr bereit. Denn das wurde im Finalisierungsabschnitt der Unit wieder freigegeben. Wenn die Classes-Unit ihren Finalisierungsabschnitt schon durchlaufen hat, gibt es Probleme.

Update vom Threadpool: Das Herabsetzen der Poolsize zur Laufzeit führte zu einem Speicherleck, ein fehlendes 'UnlockList' im der Clear-Methode der JobList und noch ein paar Kommentare.

Update vom Threadpool: x000x hat einen Bug gefunden: Die Setter-Methode des OnJobException-Events muss den Methodenzeiger natürlich an die einzelnen Threads weiterleiten. Weiterhin habe ich die Workerthread-Unit rausgenommen. Man braucht sie nicht mehr.

Update vom Threadpool: Die aktuelle Version läuft stabil, sie ist in einer Kundenanwendung im Einsatz.

Update vom Threadpool: Neue Methode, um aus einem Job heraus Nachrichten zu verschicken (siehe beiliegende Demo).

Update: Eigenschaft 'Terminated' des TWorkerThread wird publiziert, kleiner Fehler in der Clear-Methode beseitigt.

Update: Kleiner Hack, um den Threadnamen zu setzen (Debugginghilfe). Dank an Assertor.

[alzaimar]

Ich kann meinen Beitrag oben nicht mehr editieren, weil er zu alt ist. Ich hab Matze gefragt, was ich tun soll.

Aber hier ist die Version, die irgendwann im 1.Post sein wird.

[shmia]

Zitat:

Kritik, Verbesserungs- und Erweiterungsvorschläge sind ausdrücklich erwünscht.

Also ich bin soweit ganz zufrieden.
Aber das Non Plus Ultra wäre ein Thread-Pool, der die Jobs abarbeitet.
Man gibt die max. Anzahl von WorkerThreads vor, die alle auf die gleiche Jobliste zugreifen.
Angenommen man möchte 500 Webseiten downloaden und sieht max 10 parallel arbeitende Threads vor.
Jeder der 10 Threads krallt sich einen Job, arbeitet diesen ab, und wenn er fertig ist schaut er in der Jobliste, ob noch was zu tun ist.

Die Krönung wäre dann folgendes Verhalten:
Wenn ein Thread länger als 10 Sekunden nichts zu tun hat (weil Jobliste leer ist), beendet er sich automatisch.

[alzaimar]

Oho. Lustig. Soll ich?

Bis auf 'die Krönung'. Die ist eigentlich unnötig, weil WaitForSingleObject keine CPU-Zeit verbrät. Mal sehen.

Ich glaub, ich bastel das heut abend.

[kalmi01]

Zitat:

Ich glaub, ich bastel das heut abend.

Aber hier einstellen nich vergessen

[alzaimar]

Zitat von kalmi01:

Zitat:

Ich glaub, ich bastel das heut abend.

Aber hier einstellen nich vergessen

Nö. Nachher haben andere noch was davon. Nö Nö. Ich poste ein HEX-Listing zum abtippen.

[kalmi01]

Zitat von alzaimar:

Nö Nö. Ich poste ein HEX-Listing zum abtippen.

vom Source, oder von der ZIP-Datei, mit den dcu's für alle Delphi-Releases

[alzaimar]

Von der ZIP-Datei? Das ist gemein. Nee, nee, sind wir mal nicht so: Hex-Listing vom verschlüsselten Sourcecode!

[Elvis]

Zitat von alzaimar:

Von der ZIP-Datei? Das ist gemein. Nee, nee, sind wir mal nicht so: Hex-Listing vom verschlüsselten Sourcecode!

Mönsch! Gleich 3 Dinge auf einma:l Spannung, Spiel und Schoko.... source code.

[sh17]

Zitat von Elvis:

Zitat von alzaimar:

Von der ZIP-Datei? Das ist gemein. Nee, nee, sind wir mal nicht so: Hex-Listing vom verschlüsselten Sourcecode!

Mönsch! Gleich 3 Dinge auf einma:l Spannung, Spiel und Schoko.... source code.

Und der Key ist der Happy-Code in jedem 7. Thread.

[Daniel]

Zitat von alzaimar:

Ich kann meinen Beitrag oben nicht mehr editieren, weil er zu alt ist.

Kinderchen, so sagt doch was. Ich habe die Edit-Limitierung aus dieser Rubrik jetzt rausgenommen. *zupf*