Thread Programmierung

[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.