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.