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]

Hi Assertor,

Ich bau das mal ein und stelle es im 1.Post wieder rein.

Edit: Achso, äh.. Danke für das Kompliment.

[Assertor]

Hi Alzaimar,

Zitat von alzaimar:

Edit: Achso, äh.. Danke für das Kompliment.

Bitte, gerne

[Assertor]

Hi,

noch eine kleine Verbesserung, um das Debugging in neueren Delphi Versionen zu vereinfachen:

Delphi-Quellcode:

--- D:/Downloads/csWorkerThreadPool.pas   Sat Nov 29 15:30:22 2008
+++ D:/csWorkerThreadPool.pas   Sun May 17 01:38:13 2009
@@ -113,6 +113,7 @@
     fMsg: String;
     Procedure DoAction;
 {$ENDIF}
+    procedure SetName;
     Procedure Run;
     Procedure DoOnException;
     procedure DoNotify;
@@ -265,6 +266,35 @@
 
 { TWorkerThread }
 
+{$IFDEF MSWINDOWS}
+type
+  TThreadNameInfo = record
+    FType: LongWord;     // must be 0x1000
+    FName: PAnsiChar;    // pointer to name (in user address space)
+    FThreadID: LongWord; // thread ID (-1 indicates caller thread)
+    FFlags: LongWord;    // reserved for future use, must be zero
+  end;
+{$ENDIF}
+
+procedure TWorkerThread.SetName;
+{$IFDEF MSWINDOWS}
+var
+  ThreadNameInfo: TThreadNameInfo;
+{$ENDIF}
+begin
+{$IFDEF MSWINDOWS}
+  ThreadNameInfo.FType := $1000;
+  ThreadNameInfo.FName := 'csWorkerThread';
+  ThreadNameInfo.FThreadID := $FFFFFFFF;
+  ThreadNameInfo.FFlags := 0;
+  try
+    RaiseException($406D1388, 0, sizeof(ThreadNameInfo) div sizeof(LongWord),
+      @ThreadNameInfo);
+  except
+  end;
+{$ENDIF}
+end;
+
 Constructor TWorkerThread.Create(aID: Integer; aJobList: TWorkerThreadJobList);
 Begin
   Inherited Create(True);
@@ -302,6 +332,7 @@
 
 Procedure TWorkerThread.Execute;
 Begin
+  SetName;
   While Not Terminated Do Begin
     fCurrentJob := fJobList.WaitForNextJob;
     If Assigned(fCurrentJob) Then Begin

Das benennt die Threads dann ordentlich, so daß man diese im Debugger auch erkennt Ich weiß aus dem Kopf nicht, ob die Exception für benannte Threads < Delphi 2006 Probleme macht, vielleich packst Du noch ein IFDEF rein, damit es nur > Delphi 2006 verwendet wird.

Gruß Assertor

[alzaimar]

Davon von den @@ Tags habe ich noch nie etwas gehört. Kannst Du mir kurz erklären, worum es dabei geht?

[Win32.API]

Das ist nur eine Darstellungsform von Unterschieden zwischen zwei Versionen.

Zitat:

++ -> Datei 1
-- -> Datei 2
+ -> Hinzugefügt
- -> Gelöscht
@@ -> Vieleicht Zeilen angaben?

Also alles, wo ein + vorsteht, ist neu und muss ergänzt werden.

--win32

[alzaimar]

Aha. Ich habe das mal eingebaut und geprüft. Delphi 6 meckert bei der Ausführung mit einer 'external Exception', läuft ansonsten durch. Ich habe das dann aber nur für Delphi 2006 und höher aktiviert.

Zur Ermittlung der Delphi-Version habe ich 'JEDI-SDL.INC' verwendet. Wenn es eine andere/bessere Möglichkeit gibt, die Delphi-Version zu ermitteln, immer her damit.

Update wie immer im 1.Post.

[Assertor]

Hi,

@Win32.API: Danke, warst schneller mit dem Erklären

Zitat von alzaimar:

Aha. Ich habe das mal eingebaut und geprüft. Delphi 6 meckert bei der Ausführung mit einer 'external Exception', läuft ansonsten durch. Ich habe das dann aber nur für Delphi 2006 und höher aktiviert.

Zur Ermittlung der Delphi-Version habe ich 'JEDI-SDL.INC' verwendet. Wenn es eine andere/bessere Möglichkeit gibt, die Delphi-Version zu ermitteln, immer her damit.

Ich nutze immer gerne die Compilers.inc von Mike Lischke und Jim Kueneman. Das ist die Include für die VirtualTreeView. Link zum Source (steht unter der MIT Lizenz): http://new.lischke-online.de:8080/br.../Compilers.inc

Dann einfach im Source um alle Änderungen ein
{$IFDEF COMPILER_6_UP}...{$ENDIF} Das mit der Änderungsdatei war gestern einfacher, um die geänderten Stellen zu finden - war etwas faul Tools wie WinMerge (Bild) erstellen sowas und sind eine erhebliche Arbeitserleichterung.

Gruß Assertor

[alzaimar]

Gut, diese JEDI-SDL.Inc macht im Prinzip das Gleiche...

[Assertor]

Hi,

Zitat von alzaimar:

Gut, diese JEDI-SDL.Inc macht im Prinzip das Gleiche...

Ja, nur die Lizenz der Compilers.inc ist noch liberaler. Für Projekte von Entwicklern, die keine JEDIs einsetzen vielleicht besser.

Außerdem nimmt die JEDI-SDL.inc soweit ich sehen kann auch noch andere Änderungen an den Compiler Einstellungen vor (z.B. {$F+,Q-,R-,S-,I-,A+}). Das braucht der Diener im Hintegrund nicht und führt u.U. - wenn projektweit - zu Probleme oder ungewünschten Einstellungen.

Bei der Compilers.inc werden wirklich nur die Compiler festgestellt, kein Rumdrehen an Einstellungen.

Gruß Assertor

[sundance]

@alzaimar:
Erst mal vielen Dank für deine Mühe, die du in diese Unit gesteckt hast. Ich bin gerade dabei, in einem von meinen kleinen "Projekten" davon zu profitieren....

Ein paar Fragen/Anmerkungen hätte ich aber doch:

- Was bezweckst du mit der Methode TWorkerThreadPool.Notify?

- Wie würdest du es anstellen, auf die Abarbeitung aller Jobs in der List zu warten, um z.B. irgendwelche Controls zu aktualisieren oder eine Statusmeldung auszugeben? (Polling auf TWorkerThreadPool.PendingJobCount = 0 ist ja wohl nicht der beste Weg...)

- In diesem Thread war mal eine Anmerkung:

Zitat:

Eins hab ich aber nicht ganz verstanden:
Wenn man Synchronized auf true setzt, wird der ganze Job über Synchronize(Run) ausgeführt. Wird das nicht zu einer blockierenden Operation dann ? Dann kann ich doch eigentlich diese Arbeit gleich im Haupt-VCL-thread ausführen lassen.

Zitat:

stimmt auffallend...

Nun ist das aber immer noch so drin:

Delphi-Quellcode:

If fCurrentJob.Synchronized Then
  Synchronize(Run)
Else
  Run;

Läuft der synchronisierte Thread nun autark oder nicht?
(na ja, vielleicht habe ich deine Source auch noch nicht ganz verstanden...)

.sundance.