Verwirrung des Thread-Synchronisationsproblems

Dies ist ein seltener Fall, in dem Sie davon profitieren, dass Windows die Thread-Synchronisierung für Sie durchführt. Der Grund dafür ist, dass für eine Listbox die Elemente mithilfe von SendMessage mit steuerspezifischen Nachrichten bearbeitet werden. Aus diesem Grund stellt jeder SendMessage-Aufruf sicher, dass die Nachricht von demselben Thread verarbeitet wird, für den das Steuerelement erstellt wurde, insbesondere vom Hauptthread.

Wie gesagt, das ist ein seltener Fall. Es verursacht auch einen Threadwechsel für jeden dieser drei Aufrufe, was die Leistung beeinträchtigt. Es ist immer noch besser, mit "Synchronisieren" zu verhindern, dass dieser Codeblock im Hauptthread ausgeführt wird, zu dem er gehört. Es stellt außerdem sicher, dass Sie nicht gebissen werden, wenn Sie mit einem Steuerelement arbeiten, das SendMessage nicht intern verwendet.

Tatsächlich. Möglicherweise ist das Beispiel nicht problematisch, da während der Ausführung des Threads keine Änderungen an der Benutzeroberfläche vorgenommen werden. Aber UI-Dinge müssen immer innerhalb des UI-Threads auftreten.

Die einzigen Unterschiede zwischen den synchronisierten und den nicht synchronisierten Anweisungen sind:

• die nicht synchronisierten sind keine No-Params-Methoden, so dass das Programm schwieriger zu schreiben ist:)
• Die sync'ed-Methode aktualisiert ein TLabel, das kein TControl ist (wenn ich mich an meine Delphi-Tage erinnere), so dass es Canvas direkt verwendet ...

Aber trotzdem: UI wird von einem einzigen Thread berührt. Immer. Sobald ich eine TTreeBox innerhalb eines Threads aktualisieren wollte (kein Paralelismus noch Cross-Updates, einfach ein separater Thread) und es war eine sehr schlechte Sache (zufällige Fehler) ...