TTimer nicht Thread-safe

[hzzm]

In diesem SO-Thread schreiben die Antwortenden, dass man TTimer in Threads vermeiden sollte:

SO: Threaded TTimer

Meine Frage zu dieser Sachlage:
Wenn der TTimer im Thread-Objekt liegt und aktiviert wird, sind AV's nicht auszuschliessen;

Was ist, wenn das TTimer-Objekt ausserhalb des Threads in einem Objekt im Haupt-Programm liegt, erstellt wird und nur aus einem Thread angestossen wird?

[Neutral General]

Auch schlecht. Man greift aus einem Thread nicht auf Objekte außerhalb des Threads zu.
Erst Recht nicht auf VCL Komponenten.

Warum brauchst du überhaupt einen Timer in einem Thread?
Kannst du dir doch quasi im Thread selbst bauen oder nicht?
Da es ja nur ein Thread ist kannst du ja einfach ne Schleife mit sleeps machen oder?

[Stevie]

Es könnte hilfreich sein, deine Anforderung zu beschreiben, dann kann man dir eventuell besser Hinweise geben, wie du es lösen kannst.

[hzzm]

Danke fuer die Hinweise.

Ja, ich kann es auch mit Sleep loesen.

[CCRDude]

Sleep in einem Thread ist auch nicht gut. Wenn das System runter fährt, benachrichtigt es Dein Programm, das muss sich in einer kurzen Zeit beenden können, sonst wird es als eingefroren angezeigt.

Und auch wenn der Benutzer Dein Programm schließt, will er nicht erst warten, bis ein Sleep in irgend einem Thread beendet ist (mal davon ausgehend, dass Du beim Beenden des Programmes mit den Threads ordentlich aufräumst).

WaitForSingleObject eignet z.B. sich wunderbar, um auf Ablauf einer Frist aber eben auch alternativ auf ein Signal zu reagieren, damit hängt der Thread dann bei seiner Auflösung auch nicht mehr lästig.

[Der schöne Günther]

Zitat:

Zitat von CCRDude (Beitrag 1393184)

Sleep in einem Thread ist auch nicht gut. Wenn das System runter fährt, benachrichtigt es Dein Programm, das muss sich in einer kurzen Zeit beenden können, sonst wird es als eingefroren angezeigt.

Aber nur wenn sein Programm so geschrieben ist dass es beim Beenden auch sauber auf das Beenden des entsprechenden Threads wartet :stupid:

Ansonsten beendet sich das Programm direkt :wink:

[hzzm]

Zitat:

Zitat von Neutral General (Beitrag 1393176)

Auch schlecht. Man greift aus einem Thread nicht auf Objekte außerhalb des Threads zu.
Erst Recht nicht auf VCL Komponenten.

Wie waere denn ein korrekter Aufbau fuer folgendes Szenario (grundasetzlich, ohne TTimer):

Eine TForm hat eine Status-Anzeige einer Verbindung.
Die Verbindung wird selbstverstaendlich Threaded aufgebaut, damit die Anwendung nicht einfriert.
Die Status-Anzeige der TForm soll anzeigen, ob der Verbindungs-Aufbau gerade in der Suche ist, oder bereits erfolgreich war.

Ist es so ueberhaupt vermeidbar, aus dem Thread auf die VCL-Statusanzeige zuzugreifen?

[jziersch]

Man könnte hier doch einen Timer nutzen um den aktuellen Zustand des Threads in der Statusbar anzuzeigen.

Der Timer wäre damit nicht in dem Thread sondern in der GUI.

Alternativ kann man auch eine message an das Hautpfenster von Thread aus schicken, asynchron mit PostMessage. Diueses kann dann updaten wenn es idle ist.

[hzzm]

Laut der Antwort in String data from Thread to Main koennte man doch die Aktion der Status-Anzeige .Queue'en, oder nicht?

Kann man infolge dessen nicht auch den Anstoss eines TTimers aus einem TThread ohne AV-Gefahr .Queue'en?

[Stevie]

Wenn Threads irgendwas nach außen zu funken haben, dann bekommen sie callbacks, die man entsprechend synchronisieren kann.

Wenns komplexer wird, dann einfach OTL oder so nutzen, da gibt es zig Mechaniken.

Zitat:

Zitat von hzzm (Beitrag 1393199)

Laut der Antwort in String data from Thread to Main koennte man doch die Aktion der Status-Anzeige .Queue'en, oder nicht?

Genau - wobei ich lieber den eigentlichen Wert per callback rausgeben würde, das string zusammentackern kann dann dort gemacht werden.

[himitsu]

Mit TTimer geht es nunmal nicht im Thread, aber natürlich kann man SetTimer auch innerhalb eines Threads benutzen.
* man muß nur ein Message-Windows im Thread erstellen und da drin einen Timer aktivieren
* und man muß im Thread natürlich auch auch die Window-Messages verarbeiten, vor allem WM_TIMER

[hzzm]

Zitat:

Zitat von himitsu (Beitrag 1393206)

Mit TTimer geht es nunmal nicht im Thread

Mein Problem ist momentan eher, dass ich ausserhalb des Threads einen riesigen Timer-gesteuerten Ablauf je nach Thread-Ergebnis an- oder ausschalten muss.
Den kann/moechte ich gar nicht komplett im Thread unterbringen, da dieser Ablauf noch an zig anderen Stellen im Code regulaer verwendet wird.

Ich muesste den Timer ausserhalb eben nur aus dem Thread anstossen.

Darf ich das mit .Queue?

[himitsu]

TThread.Synchronize oder TThread.Queue ... wird beides im Hauptthread ausgeführt.

SendMessage und PostMessage ebenso (wenn das zugehörige Window im Haupthtread erstellt wurde) und PostThreadMessage sowieso.

[Zacherl]

Zitat:

Zitat von CCRDude (Beitrag 1393184)

Sleep in einem Thread ist auch nicht gut. Wenn das System runter fährt, benachrichtigt es Dein Programm, das muss sich in einer kurzen Zeit beenden können, sonst wird es als eingefroren angezeigt.

Das kann man umgehen, indem man statt

Delphi-Quellcode:

Sleep

einfach WaitForSingleObject mit einem Event (bzw. die entsprechende Kapselung

Delphi-Quellcode:

TEvent

) verwendet. Das Event lässt man permanent auf nonsignaled, bis man von Windows die

Delphi-Quellcode:

WM_QUERYENDSESSION

bzw.

Delphi-Quellcode:

WM_ENDSESSION

Nachricht erhält. Sobald man das Event dann aktiviert, arbeiten alle Threads unmittelbar weiter, ohne auf das Timeout zu warten. Im Thread selbst sollte man dann noch die Rückgabe von

Delphi-Quellcode:

WaitForSingleObject

prüfen, und die Bearbeitung entsprechend sofort einstellen, wenn nicht

Delphi-Quellcode:

WAIT_TIMEOUT

zurückgegeben wurde.

[CCRDude]

Zitat:

Zitat von Zacherl (Beitrag 1393211)

Das kann man umgehen, indem man statt

Delphi-Quellcode:

Sleep

einfach WaitForSingleObject mit einem Event (bzw. die entsprechende Kapselung

Delphi-Quellcode:

TEvent

) verwendet. Das Event lässt man permanent auf nonsignaled, bis man von Windows die

Delphi-Quellcode:

WM_QUERYENDSESSION

bzw.

Delphi-Quellcode:

WM_ENDSESSION

Nachricht erhält.

Noch praktischer: ich verwende eine von TThread abgeleitete Basis-Klasse, die dieses Warten als Methode anbietet und das Event im Terminate auslöst. Damit hilft das nicht nur beim Runterfahren Verzögerungen zu vermeiden, sondern auch beim schlichten Beenden des Programmes oder gar nur des Threads.

[Zacherl]

Zitat:

Zitat von CCRDude (Beitrag 1393234)

Zitat:

Zitat von Zacherl (Beitrag 1393211)

Das kann man umgehen, indem man statt

Delphi-Quellcode:

Sleep

einfach WaitForSingleObject mit einem Event (bzw. die entsprechende Kapselung

Delphi-Quellcode:

TEvent

) verwendet. Das Event lässt man permanent auf nonsignaled, bis man von Windows die

Delphi-Quellcode:

WM_QUERYENDSESSION

bzw.

Delphi-Quellcode:

WM_ENDSESSION

Nachricht erhält.

Noch praktischer: ich verwende eine von TThread abgeleitete Basis-Klasse, die dieses Warten als Methode anbietet und das Event im Terminate auslöst. Damit hilft das nicht nur beim Runterfahren Verzögerungen zu vermeiden, sondern auch beim schlichten Beenden des Programmes oder gar nur des Threads.

Ja, genau so hatte ich es damals auch umgesetzt und dafür die

Delphi-Quellcode:

TerminatedSet

Methode überschrieben :thumb: