TThread.Synchronize

[Der schöne Günther]

Vielen Dank für die Antworten!

Zitat von Sir Rufo:

Wichtig ist hierbei auch der Blick in die Dokumentation TThread.Synchronize.

Zitat von TThread.Synchronize:

Führt einen Methodenaufruf im Haupt-Thread aus.

Also egal von wo auch immer das ausgeführt wird, es wird synchron zum Hauptthread ausgeführt.

Wenig später heißt es jedoch:

Zitat:

Hinweis: Wenn Sie die statische Version der Methode Synchronize mit nil/NULL als der erste Parameter verwenden, wird die von AMethod referenzierte Methode im Haupt-Thread synchronisiert.

Das hatte ich bislang so interpretiert, als könnte ich mit der gleichnamigen Klassenmethode angeben, von welchem Thread aus der Aufruf tatsächlich stattfindet. Denn wozu gebe ich einen Thread sonst überhaupt als Parameter an?

Zitat von Furtbichler:

Wichtig ist hier, das Synchronize so lange wartet, bis der Hauptthread sich drum kümmern kann. Es geht also Zeit flöten.

Gut (und beruhigend) zu wissen. Aber gerade hier beschleicht mich jetzt das Gefühl, dass ich meinen TThread noch mit irgendwas hätte ausstatten müssen, um darauf überhaupt (und auch wo) zu reagieren - Eine Art kümmereDichUmSynchronize-AufrufeVonAnderenThreads() .


Um kritische Abschnitte gibt es dann wohl wieder keinen Weg drum herum, ich möchte nicht, dass die Funktion "von außen" aufgerufen/angefordert wird, wenn der Thread selbst auch gerade in dieser Funktion wühlt. Jetzt bin ich mal gespannt, was TCriticalSection bereithält...

[Sir Rufo]

Was soll TCriticalSection schon bereithalten?

Betreten oder Versuchen zu betreten, Verlassen that's all

[Der schöne Günther]

Und es funktioniert sogar, der Tag ist gerettet.

Im Endeffekt bin ich zwar immer noch etwas ratlos, was für konkrete Vorteile es mir bringt, nicht direkt über die WinAPI zu gehen, aber das wird sich sicher noch zeigen.

[Medium]

Ich bin von Synchronize mittlerweile ganz weg. Wenn ich im Thread API Ressourcen brauche erstelle ich sie mir dort (nicht als Kompo auf dem Formular z.B.), Threads teilen sich nur via PostMessage mit, und haben Properties deren Getter und Setter mit jeweiligen Critical Sections versehen sind. Zwar wimmelt es in der Thread-Methode je nach Fall von CS.Enter; try ... finally CS.Leave; end; , aber so muss das Hauptprogramm nachher nicht mehr machen, als die Messages zu emfangen und kann einfach so auf den Feldern des Threads agieren. (Üblicherweise dann Work-Queues und erweiterte Status-Objekte o.ä.)

Ist etwas mehr Tipperei, aber seit ich das so durchziehe habe ich nie wieder einen Thread gegen die Wand fahren lassen.

[Furtbichler]

Zitat von Medium:

Zwar wimmelt es in der Thread-Methode je nach Fall von CS.Enter; try ... finally CS.Leave; end; , ...

Und das sollte -der Lesbarkeit wegen- in kleine lokale Prozeduren oder private Methoden ausrefaktorisiert werden, dann wimmelt es nicht mehr so und... das Ganze gewinnt einen Preis für sauberen Code

[Sir Rufo]

Zitat von Furtbichler:

Zitat von Medium:

Zwar wimmelt es in der Thread-Methode je nach Fall von CS.Enter; try ... finally CS.Leave; end; , ...

Und das sollte -der Lesbarkeit wegen- in kleine lokale Prozeduren oder private Methoden ausrefaktorisiert werden, dann wimmelt es nicht mehr so und... das Ganze gewinnt einen Preis für sauberen Code

[Medium]

Kommt er mir hier mit Selbstverständlichkeiten ;P (Aber auch diese bekommen dadurch hie un doa etwas Verschachtelungstiefe dazu, wobei ich es meist so mache, dass ich in der CS ein Objekt aus der Liste in eine lokale Variable packe und es aus der Liste werfe. Die Verarbeitung geht dann ausserhalb der CS, sonst würde das doch arg blockieren. Setzt natürlich voraus, dass andere Threads nur die Queue anfassen, ein keinen Finger mehr auf den enthaltenen Objekten behält.)