Thread Programmierung

[Athris]

Hallo,

ich beschäftige mich erst seit ein paar Tagen mit dem Thema Threads in Delphi und konnte durch ein paar Tutorials bereits Informationen erlangen und funktionstüchtigen Code programmieren. Dieser Code funktioniert auch bereits reibungslos doch bin ich mir nicht sicher ob das so auch sauber programmiert ist.

Kurz zu der Situation. Ich programmiere zurzeit ein Programm was Dateien aktualisiert. Den Überprüfungs- und Downloadprozess habe ich nun in einem Thread ausgelagert um den Hauptthread (also die Form) während der Aktualisierung weiter benutzen zu können. Dafür habe ich eine neue Unit namens UpdateThread.pas erstellt und in mein Projekt eingebunden.
Die UpdateThread.pas sieht so aus:

Delphi-Quellcode:

unit UpdateThread;

interface

uses
  SysUtils, Classes, Dialogs, IdHTTP, IdComponent, IdTCPConnection, IdTCPClient, main;

type
  TUpdateThread = class(TThread)
    private
    { Private-Deklarationen }
    fpntMain: TfrmMain;
    protected
      procedure Execute; override;
    public
    { Public-Deklarationen }
    procedure VersionenLaden;
    procedure AktualisiereDaten;
    procedure DateiDownload(strUrl, strLocalFile:String;
    WorkBegin:TWorkBeginEvent;Work:TWorkEvent;WorkEnd:TWorkEndEvent);
  end;

implementation

procedure TUpdateThread.Execute;
begin
  fpntMain := main.frmMain;
  VersionenLaden;
  AktualisiereDaten;
end;
[...]
end.

In meiner main.pas sieht der Aufruf dann so aus:

Delphi-Quellcode:

procedure TfrmMain.FormActivate(Sender: TObject);
var
  pntUpdateThread: TUpdateThread;
begin
  pntUpdateThread := TUpdateThread.Create(true);
  pntUpdateThread.FreeOnTerminate := True;
  pntUpdateThread.Resume;
end;

Der Quellcode funktioniert soweit und die Aktualisierung läuft parallel zum Hauptthread. Wie bereits ersichtlich starte ich durch das FormActivate nur einen einzigen Thread. Diese arbeitet dann Schritt für Schritt die Dateien ab.
Meine Frage ist nun: Habe ich das soweit korrekt umgesetzt, insbesondere in Hinblick auf Speicherfreigabe usw.? Mir ist es sehr wichtig dass mein Programm so sauber wie möglich läuft und bei Threads bin ich mir unsicher wie ich diese korrekt nach kompletter Ausführung freigebe.

[Sir Rufo]

Da wir hier nur sehr wenig von der Thread-Klasse sehen, kann man nur sehr wenig darüber sagen, ob diese Implementierung auch sauber und sicher ist.

Wenn du dir Gedanken über MemLeaks machst, dann setze einfach

Delphi-Quellcode:

ReportMemoryLeaksOnShutdown := True;

und am Ende bekommst du die Leaks um die Ohren gehauen.

[Uwe Raabe]

Zitat:

Zitat von Athris (Beitrag 1314053)

Meine Frage ist nun: Habe ich das soweit korrekt umgesetzt,

Keine Ahnung, aber dieses Konstrukt "[...]" ist in meinen Delphi zumindest nicht bekannt.

[Athris]

Entschuldigung das [...] sollte nur verdeutlichen dass dann der Quellcode von den drei Methoden VersionenLaden, AktualisiereDaten und DateiDownload kommt und im Anschluss das end. der Unit. Die Unit ist ja letztendlich nur von der Klasse TThread abgeleitet die bereits in der Classes Unit vorhanden ist.

[TiGü]

Ansonsten kannst du Resume noch mit Start ersetzen (siehe zweiter Satz: http://docwiki.embarcadero.com/Libra...TThread.Resume).
Oder gleich den Thread losrennen lassen, also ohne True im Create.
FreeOnTerminate passt schon, aber anhand des kurzen Codeschnipsels sieht man nicht wirklich, was passiert.
Wie greifst du denn in auf pntUpdateThread zu? Es ist nur eine lokale Variable im OnActivate?!?

So erstellst du einen Thread und wenn er nicht in VersionenLaden; oder AktualisiereDaten; in einer Dauerschleife läuft oder auf ein Windows-Event wartet, dann ist der auch schnell wieder vorbei, beendet und freigeben.

[frankyboy1974]

Hallo,

warum gibt es bei deinem Thread die Programmierzeile

Delphi-Quellcode:

fpntMain := main.frmMain;

. Wenn der Thread also das Hauptformular kennt, müssten wir davon ausgehen, dass dieser auch darauf zurück greift!? Wenn du aber aus einem Thread auf einem gemeinsamen Speicherbereich zurückgreifst, kann dies Fehler vorursachen. Da du keinen Quellcode veröffentlichen möchtest, was die Methoden 'VersionenLaden', 'AktualisiereDaten' und 'DateiDownload' genau machen, können wir also nur raten, ob dein Thread auch wirklich threadsafe ist. Ich nehm daher meine :glaskugel: und sag nee.

mfg

[Athris]

Stimmt von der Problematik hatte ich bereits gehört. Der Pointer auf die Mainklasse ruft eine AddProtocol Funktion auf die einen Text für ein Label setzt. Ansonsten wird über diese Verbindung nur auf Variablen der Mainklasse zugegriffen.

[BUG]

Zitat:

Zitat von Athris (Beitrag 1314066)

Der Pointer auf die Mainklasse ruft eine AddProtocol Funktion auf die einen Text für ein Label setzt. Ansonsten wird über diese Verbindung nur auf Variablen der Mainklasse zugegriffen.

Und jetzt die Gretchenfrage: Wie hältst du's mit der Synchronisation?
Das geht entweder mit

Delphi-Quellcode:

TThread.synchronize(...)

oder Synchronisationsmitteln wie zB. Critical-Sections.

[frankyboy1974]

hallo,

Du greiftst also auf Variablen bzw. auf ein Label deines MainFormular zurück, wie soll hier jetzt irgendwer beurteilen, ob du dies auch threadsafe programmiert hast. Der eine läuft nach Afrika und der andere nach Amerika, jo das funktioniert, wenn aber beide (bzw. alle) gleichzeitig in die gleiche Richtung laufen, wirds etwas komplizierter. Vielleicht schreiben die Threads auch gleichzeitig in eine Datei und was passsiert, wenn die sich da treffen? Noch mal ohne Quellcode, lautet die Antwort :glaskugel:.

mfg

[Athris]

Ich bedanke mich für alle Antworten und die damit verbundenen Tipps und Hinweise.
Bezüglich der Mehrfachzugriffproblematik muss ich mich definitiv noch einmal ran setzen, da die Funktionen auch zwischenzeitlich von der Main aufgerufen werden können. Da muss ich natürlich steuern dass die sich nicht in die Quere kommen. :)

[nuclearping]

Kleiner Tipp: Arbeite mit Messages (PostMessage), statt Synchronize, um deine Hauptform zu aktualisieren.

[Mavarik]

Zitat:

Zitat von nuclearping (Beitrag 1314091)

Kleiner Tipp: Arbeite mit Messages (PostMessage), statt Synchronize, um deine Hauptform zu aktualisieren.

Oder nimm nicht PostMessage und Programmiere so, dass es auch auf anderen Plattformen läuft.

[Luckie]

Zitat:

Zitat von nuclearping (Beitrag 1314091)

Kleiner Tipp: Arbeite mit Messages (PostMessage), statt Synchronize, um deine Hauptform zu aktualisieren.

Und warum sollte er mit Nachrichten synchronisieren, wenn er die Thread Klasse benutzt?

[BUG]

Zitat:

Zitat von Luckie (Beitrag 1314115)

Und warum sollte er mit Nachrichten synchronisieren, wenn er die Thread Klasse benutzt?

Ich könnte mir noch vorstellen, das man seine Nachrichten asynchron schicken möchte.
Wenn man synchronen Nachrichtenversand und die Auswertung ordentlich wegkapselt hat man ...

Delphi-Quellcode:

synchronize

nachimplementiert! :stupid:

[Dejan Vu]

So vom Gefühl her würde ich niemals einen Thread einfach so erzeugen und in die freie Wildbahn entlassen. Ich weiß doch gar nicht, wann der zurückkommt. Da er zudem auf das Formular zugreifen will und ich ihm das u.U. irgendwann vor der Nase wegschließe, habe ich hier doch einfach zu viele Unsicherheiten.

Ich mache es immer so:
1. Ich kenne meine Threads. Ich speichere Sie irgendwo, z.B. in einem Feld oder in einer Liste etc.
2. Ich schreibe im Thread den Code so, das der Thread bei ein 'Terminate' relativ schnell beendet wird.
3. Wenn ich die Anwendung beende, rufe ich für jede Thread die Methode Terminate auf.

[Athris]

Das ist auch ein guter Ansatz Dejan Vu. Da ich sicher bin dass der Thread nur einmal in der gesamten Laufzeit aufgerufen wird könnte ich mich auch explizit darum kümmern diesen korrekt zu beenden. Ist halt die Frage ob das Notwendig ist oder FreeOnTerminate ausreicht.

Ich habe mich auch etwas mit dem Zugriff mehrerer Threads auf gemeinsame Methoden auseinandergesetzt und bin dabei über Synchronize und über CriticalSections gestolpert. Auf den ersten Blick wirken die CriticalSections einfacher umzusetzen, als diese Synchronize Methode.

[nuclearping]

Zitat:

Zitat von Mavarik (Beitrag 1314106)

Oder nimm nicht PostMessage und Programmiere so, dass es auch auf anderen Plattformen läuft.

Jein. PostMessage funktioniert auch mit FMX: http://francois-piette.blogspot.de/2...ndows-and.html

Zitat:

Zitat von Luckie (Beitrag 1314115)

Und warum sollte er mit Nachrichten synchronisieren, wenn er die Thread Klasse benutzt?

Die Alternative wäre

Delphi-Quellcode:

Synchronize

oder

Delphi-Quellcode:

Queue

und dort entweder direkt auf die Form zugreifen oder per Events.

Delphi-Quellcode:

Synchronize

ist aber zB blockierend. Dh wenn es sein Ziel war, die Hauptform weiterhin nutzen zu können, wird wohl der ständige Aufruf von Synchronize zum Aktualisieren der Form trotzdem zu "rucklern" führen.

Delphi-Quellcode:

Queue

ist zwar nicht blockierend, aber ich habe die Erfahrung gemacht, dass es mit PostMessage die wenigsten "komischen" Probleme gibt und vermeide seither die Verwendung von

Delphi-Quellcode:

Synchronize

oder

Delphi-Quellcode:

Queue

, seit ich schon mehrfach mehrere Stunden mit dem Debuggen von unerklärlichen Zugriffsverletzungsmeldungen verbracht habe. Obwohl vom Code her alles in Ordnung war und ich keinen Fehler feststellen konnte, hat es trotzdem nach einiger Zeit geknallt. Und nach Umstellung auf Nachrichten lief alles wie am Schnürchen.

Ich finde auch, dass der Versand von Nachrichten "flexibler" ist, da zum einen der Thread nicht zwangsläufig den Empfänger kennen muss. Sprich man nutzt entweder Application.MainForm.Handle oder übergibt dem Thread das Handle des zu aktualisierenden Formulars. Und zum anderen ist es auch flexibler in der Datenübergabe. Man kann einen Pointer auf einen Record oder ein Objekt übergeben, statt Felder des Formulars direkt anzusprechen oder den ganzen Overhead zur Deklaration der jeweiligen Event-Methoden mit ihren jeweiligen Parametern anzulegen.

Ist wohl auch eine Geschmacks- und Erfahrungssache. Die PostMessage-Methode ist nach dem Motto "Fire & Forget" und ich persönlich finde deren Handhabung am einfachsten und flexibelsten.

[Dejan Vu]

Zitat:

Zitat von Athris (Beitrag 1314184)

Das ist auch ein guter Ansatz Dejan Vu. Da ich sicher bin dass der Thread nur einmal in der gesamten Laufzeit aufgerufen wird könnte ich mich auch explizit darum kümmern diesen korrekt zu beenden. Ist halt die Frage ob das Notwendig ist oder FreeOnTerminate ausreicht.

Selbst wenn ein Thread mehrmals gestartet wird, würde ich die Kontrolle über das Beenden nicht aus der Hand geben.

Du kannst auch einen Threadpool verwenden. Davon gibt es hier einige im Forum. Such mal danach...

[Mavarik]

Zitat:

Zitat von nuclearping (Beitrag 1314338)

Jein. PostMessage funktioniert auch mit FMX: http://francois-piette.blogspot.de/2...ndows-and.html

Und warum soll ich sowas nachprogrammiertes nehmen.. FMX kann das von Hause aus...

[nuclearping]

Zitat:

Zitat von Mavarik (Beitrag 1314350)

Und warum soll ich sowas nachprogrammiertes nehmen..

Sollst du doch garnicht? :D

Zitat:

Zitat von Mavarik (Beitrag 1314350)

FMX kann das von Hause aus...

Wenn FMX das von Haus aus kann, warum dann dein Post oben ...?

Zitat:

Zitat von Mavarik (Beitrag 1314106)

Oder nimm nicht PostMessage und Programmiere so, dass es auch auf anderen Plattformen läuft.

[Mavarik]

Zitat:

Zitat von nuclearping (Beitrag 1314436)

Wenn FMX das von Haus aus kann, warum dann dein Post oben ...?

Weil:

Delphi-Quellcode:

TMessageManager.DefaultManager.SendMessage(NIL,TFooMyMessage.Create(Whatever));

Der "richtige" Aufruf wäre...

[nuclearping]

Zitat:

Zitat von Mavarik (Beitrag 1314438)

Weil:

Delphi-Quellcode:

TMessageManager.DefaultManager.SendMessage(NIL,TFooMyMessage.Create(Whatever));

Der "richtige" Aufruf wäre...

Interessant. Danke. Sag das doch gleich. :mrgreen:

Habe mich noch nicht so viel mit FMX beschäftigt. Ist SendMessage blockierend, so wie Windows' SendMessage? Oder verhält er sich da wie PostMessage?

[Mavarik]

Zitat:

Zitat von nuclearping (Beitrag 1314457)

Zitat:

Zitat von Mavarik (Beitrag 1314438)

Weil:

Delphi-Quellcode:

TMessageManager.DefaultManager.SendMessage(NIL,TFooMyMessage.Create(Whatever));

Der "richtige" Aufruf wäre...

Interessant. Danke. Sag das doch gleich. :mrgreen:

Habe mich noch nicht so viel mit FMX beschäftigt. Ist SendMessage blockierend, so wie Windows' SendMessage? Oder verhält er sich da wie PostMessage?

Non Blocking...

Delphi-Quellcode:

TTask.Run(Procedure
  begin
    TMessageManager.DefaultManager.SendMessage(NIL,TFooMyMessage.Create(Whatever)); // Thread-Scope beim Ziel 
  end;

oder

Delphi-Quellcode:

TIdleworker.default.Execute(
  Procedure
    begin
      TMessageManager.DefaultManager.SendMessage(NIL,TFooMyMessage.Create(Whatever));
    end;

:-D

[Sir Rufo]

Nur so zur Klarstellung, der

Delphi-Quellcode:

TMessageManager

hat nichts mit FMX zu schaffen -> es gibt keine Abhängigkeit von FMX.

Es ist genau anders herum, FMX ist abhängig vom

Delphi-Quellcode:

TMessageManager

, weil dieser von FMX verwendet wird.

Darum gehört für mich

Delphi-Quellcode:

TMessageManager

zur RTL, was auch schon durch den Namespace ausgedrückt wird

Delphi-Quellcode:

System.Messaging

.

[Mavarik]

Zitat:

Zitat von Sir Rufo (Beitrag 1314468)

Nur so zur Klarstellung, der

Delphi-Quellcode:

TMessageManager

hat nichts mit FMX zu schaffen -> es gibt keine Abhängigkeit von FMX.

Es ist genau anders herum, FMX ist abhängig vom

Delphi-Quellcode:

TMessageManager

, weil dieser von FMX verwendet wird.

Darum gehört für mich

Delphi-Quellcode:

TMessageManager

zur RTL, was auch schon durch den Namespace ausgedrückt wird

Delphi-Quellcode:

System.Messaging

.

Stimmt der "Namespace" hat sich ja geändert...