AGB  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Projekte Workerthread: Der Diener im Hintergrund

Workerthread: Der Diener im Hintergrund

Ein Thema von alzaimar · begonnen am 12. Jun 2007 · letzter Beitrag vom 23. Jun 2011
Antwort Antwort
Seite 3 von 8     123 45     Letzte » 
alzaimar
Registriert seit: 6. Mai 2005
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.
Angehängte Dateien
Dateityp: rar workerthreadpool_198.rar (181,1 KB, 1098x aufgerufen)
"Wenn ist das Nunstruck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput!"
(Monty Python "Joke Warefare")
 
alzaimar

 
Delphi 2007 Enterprise
 
#21
  Alt 14. Jun 2007, 14:12
Zitat von 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*
Papi, hab ich, aber ich hab Onkel Matze Bescheid gesagt, oder pennt der noch?

Jut, dann werdick mal, gelle?

[edit]lethargische Unterstellungen hinzugefügt[/edit]
  Mit Zitat antworten Zitat
alzaimar

 
Delphi 2007 Enterprise
 
#22
  Alt 14. Jun 2007, 23:28
Threadpool Version 0.1 fertig zum Testen und im 1.Post verfügbar.
  Mit Zitat antworten Zitat
kalmi01
 
#23
  Alt 15. Jun 2007, 13:30
Zitat von alzaimar:
Threadpool Version 0.1 fertig zum Testen und im 1.Post verfügbar.
Jau,
und da dab ich auch gleich auf einen Fehler, Prog einfach über Close-Button schliessen:
Delphi-Quellcode:
Destructor TWorkerThreadJobList.Destroy;
Begin
  Clear;
  fJobs.Free; <<< EListError: Listenindex überschreitet Maximum(0)
  CloseHandle(fSemaphore);
End;
Memory-Leak in Zeile 154 der csWorkerThreadPool.pas:
Delphi-Quellcode:
    For i := 0 To L.Count - 1 Do
      TWorkerThreadJob(L[i]).Free; <<<< hier
    L.Clear;
Memory-Leak in der finalization
  Mit Zitat antworten Zitat
kalmi01
 
#24
  Alt 15. Jun 2007, 13:32
Zitat von alzaimar:
Die beiden Units (csWorkerThread und csWorkerThreadpool) verwenden teilweise die gleichen Bezeichner, sollten also nicht gemeinsam in einem Projekt verwendet werden.
Hab mir den Code noch nicht näher angesehen, aber lässt sich das nicht sinnvoller Weis zusammenführen ?
  Mit Zitat antworten Zitat
alzaimar

 
Delphi 2007 Enterprise
 
#25
  Alt 15. Jun 2007, 13:42
Zitat von kalmi01:
Zitat von alzaimar:
Die beiden Units (csWorkerThread und csWorkerThreadpool) verwenden teilweise die gleichen Bezeichner, sollten also nicht gemeinsam in einem Projekt verwendet werden.
Hab mir den Code noch nicht näher angesehen, aber lässt sich das nicht sinnvoller Weis zusammenführen ?
Na ja, vielleicht. Ich wüsste aber nicht, wieso. Denn Du kannst auch einfach einen ThreadPool mit einem Thread instantiieren und dann hast Du das gleiche Ergebnis.
  Mit Zitat antworten Zitat
alzaimar

 
Delphi 2007 Enterprise
 
#26
  Alt 15. Jun 2007, 13:49
Zitat von kalmi01:
Delphi-Quellcode:
    For i := 0 To L.Count - 1 Do
      TWorkerThreadJob(L[i]).Free; <<<< hier
    L.Clear;
Memory-Leak in der finalization
Schleifenvariable ist Cardinal, L.Count (=0) - 1 als Cardinal gecastet ist dann doch etwas zu groß.. Daher der Müll..

Neue Version im 1.Post
  Mit Zitat antworten Zitat
kalmi01
 
#27
  Alt 15. Jun 2007, 14:14
Zitat von alzaimar:
Neue Version im 1.Post
Demoprog starten und sofort wieder schliessen ==> Memory-Leak weil fThreadPool nicht wieder freigegeben wird.
  Mit Zitat antworten Zitat
alzaimar

 
Delphi 2007 Enterprise
 
#28
  Alt 15. Jun 2007, 15:33
Zitat von kalmi01:
Zitat von alzaimar:
Neue Version im 1.Post
Demoprog starten und sofort wieder schliessen ==> Memory-Leak weil fThreadPool nicht wieder freigegeben wird.
Fertig. Das war kniffeliger, als gedacht. Leider gibt es keine fertige Instanz 'PendingJobs' mehr, denn die Freigabe im Finalisierungsabschnitt kann nach der Classes-Finalisierung passieren, was bedingt durch die Verwendung von TThreads schmerzhaft und peinlich wird (wegen RTE 216).

Neue Version im 1.Post

Los, weitere Probleme ?
  Mit Zitat antworten Zitat
kalmi01
 
#29
  Alt 15. Jun 2007, 15:44
Zitat von alzaimar:
Los, weitere Probleme ?
Demoprog starten und (versuchen) wieder zu schliessen ==> Geht nicht, Fenster bleibt stehen.
  Mit Zitat antworten Zitat
alzaimar

 
Delphi 2007 Enterprise
 
#30
  Alt 15. Jun 2007, 16:33
Komisch, bei mir nicht... 100 Versuche, 100 mal korrekt geschlossen. Vermutlich hast du einen langsameren Rechner ...

Das Beenden von Threads beim Programmende ist nicht Ohne, aber wenn es hier funktioniert, kann ich leider keine 'Abhilfe' schaffen. Dummerweise sind auch Versuche, eine Multithreadinganwendung zu debuggen, sehr komplex, da sich die IDE sehr oft aufhängt.

klick mal auf 'Terminate', das ruft Destroy auf und erstellt den Pool anschließend wieder.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:21 Uhr.
Powered by vBulletin® Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2017 by Daniel R. Wolf