TThread gibt beim Beenden Speicherleck

[Zacherl]

.Terminate() solltest du grundlegend immer vermeiden. Das erzeugt nämlich seinerseits Memory Leaks, wenn der Thread noch Speicher reserviert hat, den er nicht mehr freigeben kann. Ist beim Programmende allerdings im Grunde so oder so egal. Deine Bedingung trifft nicht zu, da .FreeOnTerminate := true zwar den Thread freigibt, nicht aber die Referenz (deine Variable) auf nil setzt.

Ich persönlich würde auf .FreeOnTerminate := true verzichten und beim Programmende (z.B im OnClose des MainForms) die .WaitFor() Methode nutzen und danach den Thread selbstständig mit .Free() freigeben. Du kannst zusätzlich auch noch Thread.Terminated() überschreiben und dort eine private Statusvariable setzen. Für den Fall, dass der Thread Aufgaben in einer Schleife bearbeitet, kannst du dann dieses interne Feld als zusätzliche Schleifenbedingung nutzen.

[DieDolly]

Zitat:

Deine Bedingung trifft nicht zu,

Wenn ich in die Bedingung ein showmessage('X') schreibe, wird mir das bei Programmende angezeigt, obwohl der Thread schon komplett durch ist.

[Zacherl]

Zitat von DieDolly:

Zitat:

Deine Bedingung trifft nicht zu,

Wenn ich in die Bedingung ein showmessage('X') schreibe, wird mir das bei Programmende angezeigt, obwohl der Thread schon komplett durch ist.

Ja, genauer gesagt trifft die Bedingung immer zu. Gründe siehe einen Post weiter oben.

[DieDolly]

Idee zu WaitFor:
ich setze von Extern ein Flag das sagt, dass das Sleep unterbrochen werden kann. Das werte ich dann hier aus

Delphi-Quellcode:

 i := 0;

   while i < 5000 do
    begin
     Inc(i);
     Sleep(1);

     if FlagXYZ then
      Break;
    end;

Dann WaitFor und Free. Wäre das eine Möglichkeit?

[Zacherl]

Ja genau, so in der Art. Mit dem Überschreiben von .Terminated geht es noch ein wenig eleganter. Dann musst du beim Programmende .Terminate(); .WaitFor(); .Free(); aufrufen. Das FreeOnTerminate darfst du dann aber auf keinen Fall verwenden, weil es sonst wieder sein kann, dass der Thread bereits automatisch zerstört wurde.

[DieDolly]

Muss bei überschriebenen Terminate das inherited dann raus? Weil sonst gibt es ja wieder die Probleme die du erwähntest.

Delphi-Quellcode:

 public
  procedure Terminate; // nicht virtuell
 end;

procedure TTestThread.Terminate;
begin
 inherited;

 BreakSleep := True;
end;

Edit
klappt bis jetzt wunderbar. Das Problem im Großen und Ganzen war tatsächlich FreeOnTerminate.

[HolgerX]

Hmm..

Zitat von Zacherl:

.Terminate() solltest du grundlegend immer vermeiden. Das erzeugt nämlich seinerseits Memory Leaks, wenn der Thread noch Speicher reserviert hat, den er nicht mehr freigeben kann. Ist beim Programmende allerdings im Grunde so oder so egal. Deine Bedingung trifft nicht zu, da .FreeOnTerminate := true zwar den Thread freigibt, nicht aber die Referenz (deine Variable) auf nil setzt.

Ich persönlich würde auf .FreeOnTerminate := true verzichten und beim Programmende (z.B im OnClose des MainForms) die .WaitFor() Methode nutzen und danach den Thread selbstständig mit .Free() freigeben. Du kannst zusätzlich auch noch Thread.Terminated() überschreiben und dort eine private Statusvariable setzen. Für den Fall, dass der Thread Aufgaben in einer Schleife bearbeitet, kannst du dann dieses interne Feld als zusätzliche Schleifenbedingung nutzen.

Aus meiner Sicht ist das Blödsinn!!!

Zitat aus der Delphi Hilfe (hier D6):

Zitat:

TThread.Terminate

Die Methode Terminate signalisiert die Beendigung eines Threads. Dazu wird die Eigenschaft Terminated auf True gesetzt.

procedure Terminate;

Beschreibung

Terminate setzt die Eigenschaft Terminated des Thread auf True und signalisiert, daß der Thread so bald wie möglich beendet werden sollte. Im Gegensatz zu der Windows-API-Methode TerminateThread, die den Thread sofort beendet, fordert die Methode Terminate den Abbruch des Thread nur an. Dadurch kann der Thread vor seiner Beendigung noch erforderliche Aufräumarbeiten durchführen.

Die Methode Execute eines Threads sowie alle von Execute aufgerufenen Methoden sollten die Eigenschaft Terminated regelmäßig abfragen und die Ausführung gegebenenfalls beenden.



TThread.Terminated

Die Eigenschaft Terminated zeigt an, ob der Thread eine Aufforderung zum Beenden erhalten hat.

property Terminated: Boolean;

Beschreibung

Die Methode Execute des Threads sollte ebenso wie alle Methoden, die von Execute aufgerufen werden, die Eigenschaft Terminated abfragen und gegebenenfalls die Ausführung beenden. Die Methode Terminate setzt die Eigenschaft Terminated auf True.

Die Methode Terminate bietet ein Verfahren, einen Thread kontrolliert abzubrechen, wobei allerdings die Kooperation des Execute-Codes Voraussetzung ist.

Somit braucht hier nichts 'Überschrieben' werden, weil TThread.Terminate mit der Abfrage nach 'Terminated' in der Execute Methode genau das macht was notwendig ist!

Somit statt 'FreeOnTerminate := True;' einzubauen, einfach das 'Terminated' abfragen...

Zum Beenden eines Threads im Destroy (ohne FreeOnTerminate := True) somit das

Delphi-Quellcode:

Thread.Terminate;  // Dem Thread 'signalisieren' dass er sich beenden soll (Sprich alles in Execute beenden und raus)
Thread.WaitFor;    // Warten, bis Execute abgeschlossen
Thread.Free;       // Thread freigeben..

[Schokohase]

Dafür gibt es schon eine extra Methode

Delphi-Quellcode:

Thread.Terminate; // Dem Thread 'signalisieren' dass er sich beenden soll (Sprich alles in Execute beenden und raus)
Thread.WaitFor; // Warten, bis Execute abgeschlossen
Thread.Free; // Thread freigeben..

nämlich
Thread.Free; - ja, so einfach

[Zacherl]

Zitat von Schokohase:

Dafür gibt es schon eine extra Methode [..] - ja, so einfach

Oh, ist das schon immer so gewesen?

@HolgerX:
Du hast recht, es war auch nicht die .Terminated() Methode, sondern .TerminatedSet() oder sowas in der Art. Kann leider grade nicht nachschauen. Hintergrund des Überschreibens war, dass meine Threads oft auf Events reagieren und die entsprechende Wait Methode blockiert ja. Im .TerminatedSet() habe ich dann noch das Event signaled. Da vorher dann auch Terminated gesetzt wurde, kann ich meine Schleife dann direkt beenden und muss nicht erst warten, bis das Event "zufällig" wieder auslöst.

[mjustin]

Zitat von Schokohase:

Dafür gibt es schon eine extra Methode
nämlich
Thread.Free; - ja, so einfach

Seit ich diesen Hinweis gelesen habe bin ich kein Freund von TThread.Free mehr:

Zitat:

NEVER call Free() on a thread that has not been signaled to terminate yet. DO NOT rely on the thread destructor calling Terminate() and WaitFor() for you. ALWAYS call them explicitally in your own code instead. Plenty of people have run into problems over the years by freeing a running thread and letting the destructor do the termination. It just does not work correctly, and is not the right place to handle this anyway. – Remy Lebeau