VCL not thread save

[stahli]

Der Sachverhalt ist ja bekannt.

Was müsste die VCL (oder allgemein eine GUI) denn tun/berücksichtigen, damit es nicht so wäre?

Alle Controls und Daten (Objekte, Listen) mit einer Critical Section schützen? Oder gibt es andere grundsätzliche Aspekte/Überlegungen?

Die CS-Lösung habe ich gerade mal (noneVCL) angetestet, was sehr gut funktioniert hat.

[jensw_2000]

Die komplette VCL bekommst Du bis zur Rente nicht thread safe.
Am besten ist es, die UI/VCL Zugriffe aus den Threads sinnvoll zu bündeln und die Zugriffe zu synchronisieren bzw. Teilbereiche über Critical Sections zu atomarisieren.

[Furtbichler]

Bei sehr vielen Änderungen, die in Threads vorgenommen werden, habe ich Messages verwendet. Alternativ einen Timer, der im Hauptthread die Daten periodisch aktualisiert. Kommt immer drauf an, was öfter vorkommt: Änderungen oder ein Timer (z.B. alle 20ms-200ms). Viele Änderungen => Timer, Wenig Änderungen => Messages oder Synchronize (oder Queue)

[himitsu]

SendMessage/PostMessage sind erstmal thread-save und Funktionen, welche darüber laufen (GetWindowText usw.),
da sie praktisch selber die Zugriffe in den Thread reinsynchronisieren, in welchem die angesprochende Komponente erstellt wurde (Aufruf von CreateWindow).

Meistens ist wirklich die VCL selber nicht thread-save und da müsstest du erstmal alle Methoden und Property sämtlicher VCL-Komponenten absichern. (z.B. über eine CS oder via Messages)


Und wenn du dann in 2+ Jahren damit fertig bist, dann darfst du die restlichen Lücken suchen.


Lösung: Die VCL ist nicht thradsave und an den "wenigen" Stellen in anderen Treads mußt du die zugriffe eben synchronisieren.

[Bernhard Geyer]

Die VCL ist nicht Thread-Save weil auch die Win-API hier nicht Thread-Save ist. Alle Windows-Handles darf nur im erzeugenden Thread darauf zugegriffen werden.

[Sir Rufo]

Wofür muss ein UI-Framework (bzw. UI im Allgemeinen) threadsafe sein?

Für die Kommunikation mit dem Benutzer reicht ein Thread.
Die Daten selber liegen in irgendwelchen Daten-Objekten und werden bei einer Änderung im UI dargestellt oder Daten vom UI dort hineingeschrieben.

Der Zugriff auf diese Daten-Objekte, der muss threadsafe sein (wenn multithreading).

Wenn die Rückmeldungen von den Threads zu häufig passieren, dann schaltet man einfach einen Timer dazwischen, der die eigentliche Aktualisierung des UI bremst (throttle) und diese Aktualisierung nur alle x Millisekunden zulässt.

Das menschliche Auge kann 25 Bilder pro Sekunde erfassen, so dass 40ms als throttle ein guter Ausgangswert ist. Allerdings werden auch 100ms gefühlt nicht wahrgenommen.

Und ob der Benutzer einen Mehrwert hat, wenn die Informationen über den Schirm rasen oder sich die Werte extrem schnell verändern glaube ich auch nicht, so dass also auch kein Informationsverlust entsteht.

Wenn bestimmte Werte wichtig sind, dann lässt man diese nicht durch die Anzeige den User kontrollieren, sondern durch die Anwendung und signalisiert, dass die Situation X eingetreten ist.

[stahli]

Ich möchte das Thema gern grundsätzlich diskutieren (also gern weg von der VCL im speziellen).

@Sir
Ich beschäftige mich noch mit dem Databinding (nicht dem von Emba) und betrachte die GUI als "Abbild der BL(+Daten)". Wenn sich in der BL etwas ändert sollte das in der GUI auch erkennbar sein.
Natürlich muss das nicht jede ms erfolgen.
Es sollte eine Art "natürliche Verbindung" zwischen GUI und BL geben, um die sich der Programmierer dann nicht mehr kümmern muss.

Mal ehrlich: JEDER wundert sich doch am Anfang seiner Karriere, warum ein

Delphi-Quellcode:

Label.Caption := SchleifenWert.AsString

oder ein

Delphi-Quellcode:

Progressbar.Step

im Formular nicht dargestellt wird.

Ich möchte das eben gern anders lösen.

[Sir Rufo]

Die Anzeige informieren, dass sich etwas verändert hat und die Anzeige holt dann (sobald es möglich ist) die neuen Werte und stellt diese dar.

Der UI-Thread sollte eigentlich fast immer schlafen (idle) und nur kurz aufleben um neue Informationen anzuzeigen oder Eingaben vom User entgegennehmen und diese dann weiterreichen.

Idealerweise müsste der Business-Layer (allgemeiner: alles was nicht zu UI gehört) im eigenen Thread-Kontext laufen, was aber in den meisten Fällen nicht passiert, da sich die Laufzeit der Aktionen meistens auf ein paar Millisekunden beschränkt (wenn überhaupt messbar) und ein eigener Thread-Kontext wäre dort mit Kanonen auf Spatzen schießen.

Somit werden sich nur die langwierigen Abläufe herausgepickt und diese werden in einen separaten Thread-Kontext verschoben.

Zurück zu deinem Beispiel mit der Schleife:
Die Schleife gehört in einen eigenen Thread und die Werte in ein Daten-Objekt. Das UI wird informiert, dass sich die Daten geändert haben und dann entscheidet das UI wann genau es diese neuen Informationen abruft und darstellt (ASAP oder maximal alle x Millisekunden).

Die meisten Programmier-Anfänger haben allerdings vor dem Start ihrer Karriere auch das Prinzip des UI nicht verstanden bzw. sich darüber keinen Kopf gemacht (ich möchte mich dort unbedingt eingeschlossen wissen). Daher auch diese "Fehler", denn es passiert etwas anderes als man erwartet hat. Es passiert aber nun mal genau das, was man programmiert hat. Diese Erwartungshaltung rührt aber von Unwissenheit her, und das schützt nun mal nicht vor der Strafe ;)

[sx2008]

Die Synchronize - Methode von TThread kann man in neuen Delphi Versionen auch mit einer Closure aufrufen.
Dazu ein interessanter Artikel von Uwe Rabe:
http://www.uweraabe.de/Blog/2011/01/...th-parameters/
Ich denke das ist der Weg den man gehen muss da man die VCL selbst nicht ändern kann.

[stahli]

@Sir

Früher hat man Automobile mit einer Kurbel in Gang gebracht ... bis es andere Lösungen gab. :wink:

Mir wäre eine Lösung, die das Binding und Handling zwischen GUI(s) und BL automatisiert auf jeden Fall sehr willkommen.
Dann kann man sich mehr um das Wesentliche kümmern, hat deutlich weniger Arbeit und dennoch eine flüssige grafische Schnittstelle, die sich für den User gut anfühlt (also gut funktional ist).

Mein Wusch war so etwas schon lange und so langsam etwickelt sich das auch... :)


@sx2008

Ich versuche das aus dem von Dir genannten Grund gerade mal ohne VCL.

[sx2008]

Zitat:

Zitat von stahli (Beitrag 1250968)

Ich versuche das aus dem von Dir genannten Grund gerade mal ohne VCL.

Das würde ich nur für ganz kleine Anwendungen tun, denn Oberflächen lassen sich mit VCL ca. 10 Mal schneller entwickeln als mit einer Non-VCL Lösung.
Der Ansatz von Uwe Rabe benötigt zwar einige Zeilen Boilerplate-Code dafür kann man aber einer Thread-Klasse relativ bequem Events mit beliebig vielen Parametern verpassen.
Mit den Events wird der Thread und GUI voreinander entkoppelt.
Das ist besser als aus dem Thread direkt die Controls zu manipulieren.
Ausserdem kann man so die gleiche Thread-Klasse in verschiedene Formulare oder Anwendungen einbauen, da die Thread-Klasse kein Wissen über die GUI benötigt.

[Sir Rufo]

Zitat:

Zitat von stahli (Beitrag 1250968)

@Sir

Früher hat man Automobile mit einer Kurbel in Gang gebracht ... bis es andere Lösungen gab. :wink:

Ähm ja ... was hat das jetzt hiermit zu tun?

Menschen sind Sauerstoff-Atmer und du möchtest jetzt Stickstoff-Atmer werden?

Das gesamte Konzept von Windows baut auf diesem UI-In-Single-Thread auf.
Bis vor Windows 7 konnten die einzelnen Anwendungen sogar immer nur brav nacheinander die Forms zeichnen.
Da wurde also jede Anwendung beim Zeichnen mit dem Haupt-Desktop-Maler-Thread synchronisiert.

Zitat:

Zitat von stahli (Beitrag 1250968)

Mir wäre eine Lösung, die das Binding und Handling zwischen GUI(s) und BL automatisiert auf jeden Fall sehr willkommen.
Dann kann man sich mehr um das Wesentliche kümmern, hat deutlich weniger Arbeit und dennoch eine flüssige grafische Schnittstelle, die sich für den User gut anfühlt (also gut funktional ist).

Mein Wusch war so etwas schon lange und so langsam etwickelt sich das auch... :)

Das verbietet dir ja keiner, es gibt aber gewisse Spielregeln beim UI an die man sich halten muss oder die Hütte fliegt einem um die Ohren. Da kann man sich ruhig auf den Boden werfen und die Luft anhalten bis man blau wird. Das Betriebssystem wird lediglich zur Kenntnis nehmen, dass von den Eingabe-Devices kein Input mehr kommt und irgendwann sich schlafen legen (den passenden Energie-Sparmodus vorausgesetzt).

[Union]

@Stahli: Stell Dir das ganze doch wie eine c/s Architektur (z.B. mit REST/JSON) vor, in der ein Client bis auf die Adresse vom Server keinerlei Daten besitzt. Du hast nur saubere Schnittstellen an die Du Daten von der UI sendest und auch wieder empfängst und darstellst. Dabei sollte es egal sein, ob der Server als Thread der Clientanwendung oder sonstwo läuft.

[stahli]

Zitat:

Zitat von Sir Rufo (Beitrag 1250977)

Da kann man sich ruhig auf den Boden werfen und die Luft anhalten bis man blau wird.

Im Supermarkt bekomme ich dann meist einen Lolly, aber nicht immer. :stupid:
(Rest per Mail)


@Union
Genau so ist mein aktueller Ansatz.

[Furtbichler]

Wir setzen gerade ein MVVM-Konzept ein und eigentlich ist das sehr einfach. Ein bischen mehr Aufwand und einiges an (Binding-)Vorarbeit, aber dann geht das echt einfach. Das einzige, was man auch hier beachten muss, sind die Property-Change-Notifications, die nicht als einfaches Event umgesetzt werden, weil ja die Notification aus einem anderen Thread erfolgt.

Blöd an dem Original-MVVM ist, das man das NotifyPropertyChanged mit dem Namen der Property aufruft, die sich verändert hat. Als String :wall: Wir haben das mit Expressions gelöst, die es in Delphi leider nicht gibt, aber -na ja- meckern kann man immer.

[stahli]

Wie schon mal gesagt: Schade, dass da jeder sein eigenes Süppchen gekocht hat.
Meins köchelt jetzt eben auch noch...

[himitsu]

Zitat:

Zitat von sx2008 (Beitrag 1250964)

Die Synchronize - Methode von TThread kann man in neuen Delphi Versionen auch mit einer Closure aufrufen.
Dazu ein interessanter Artikel von Uwe Rabe:
http://www.uweraabe.de/Blog/2011/01/...th-parameters/

Wobei das hier Einige (:angel:) auch schon vor 2011 gemacht haben.

Denn das ist eigentlich sogar eine der wenigen "einfachen" Möglichkeiten Parameter "threadsicher" an den Zielthrad zu übergeben.
(ohne sich eine threadsichere globale Variable anzulegen, oder gar gleich eine ganze Liste, wenn diese Methode aus mehreren Threads gleichzeitig aufgerufen werden könnte)

Delphi-Quellcode:

// innerhalb von TThread.Execute
Synchronize(procedure
  begin
    CallMyProgress(PercentComplete);
  end);

Delphi-Quellcode:

// in Threads, die nicht von TThread abstammen oder wo man auf die TThread-Instanz keinen Zugriff hatte.
TThread.Synchronize(nil, procedure
  begin
    CallMyProgress(PercentComplete);
  end);

Wobei man ja mindestens seit XE3 sich eine Pseudoinstanz des eigentlichen TThreads oder gar eine Instanz für etwas, daß dein TThread ist, erstellen lassen kann.
Ich glaub das ging mit TThread.CurrentThread, oder so.

[Sir Rufo]

Aber vor dem

Delphi-Quellcode:

TThread.Synchronize

oder

Delphi-Quellcode:

TThread.Queue

immer vorher prüfen ob man sich ausserhalb des MainThread-Kontext aufhält.

Delphi-Quellcode:

if MainThreadID <> TThread.CurrentThread.ThreadID then
  TThread.Synchronize(...)
else
  ...
end;

[himitsu]

Die Funktionen prüfen das eigentlich selber ab,
ABER für das Debuggen macht sich diese Prüfung besser.

Jedenfalls so weit ich das mitbekommen hab, in leidlichen Debugsessions.
Denn wenn es innerhalb des synchronisieren Codes eine Exception gibt, dann langes man gerne sonstwo in der CPU-Ansicht und noch schlimmer wird es, wenn man EurekaLog im Code hat (das muß dabei noch nichtmal aktiv sein).



Außer daß TThread.Queue im MainThread nicht unbedingt das macht, was ich ihm unterstellt hatte ... gibt es sonst keine Probleme (wenn es nicht kallt).

[mjustin]

Zitat:

Zitat von Sir Rufo (Beitrag 1251005)

Aber vor dem

Delphi-Quellcode:

TThread.Synchronize

oder

Delphi-Quellcode:

TThread.Queue

immer vorher prüfen ob man sich ausserhalb des MainThread-Kontext aufhält.

Delphi-Quellcode:

if MainThreadID <> TThread.CurrentThread.ThreadID then
  TThread.Synchronize(...)
else
  ...
end;

... und bevor man das macht, immer zuerst prüfen ob man sich in Delphi 2009 aufhält ;)

Delphi TThread.CurrentThread and EAccessViolation

Bis 2009 war System.IsConsole geeignet und wird z.B. im Indy Telnet Client Quelltext (IdTelnet) verwendet, aber ab 2010 ist CurrentThread natürlich erste Wahl.

[taveuni]

Zitat:

Zitat von Sir Rufo (Beitrag 1251005)

Aber vor dem

Delphi-Quellcode:

TThread.Synchronize

oder

Delphi-Quellcode:

TThread.Queue

immer vorher prüfen ob man sich ausserhalb des MainThread-Kontext aufhält.

Delphi-Quellcode:

if MainThreadID <> TThread.CurrentThread.ThreadID then
  TThread.Synchronize(...)
else
  ...
end;

Warum? Geht da was kaputt wenn man in den eigenen Thread synchronisiert?

[HeZa]

Hallo Stahli,

Zitat:

Zitat von stahli (Beitrag 1250991)

Wie schon mal gesagt: Schade, dass da jeder sein eigenes Süppchen gekocht hat.
Meins köchelt jetzt eben auch noch...

Ich habe schon zuviel schlechten Threading-Code gesehen. Entweder wurden die Risiken der Threading Programmierung nicht vollständig berücksichtigt, was dann dazu führte, dass das Programm unvorhersehbar und unerklärlich merkwürdiges Verhalten zeigte oder aber es waren soviele Critical-Sections darin, dass man sich fragte warum überhaupt Threads verwendet werden.

Deswegen habe ich mir geschworen, dass ich vor dem nächten Projekt mit Threading, zu allererst die Fähigkeiten der OmniThreadLibrary auschecken werde.

Da hat ein echter Threading-Experte seit 2008 seine Wunsch-Library gebaut und (und das ist viel zu selten der Fall) sie auch dokumentiert. In dem Blog des Autors kannst du viel über die Entstehung der OmniThreadLibrary erfahren, aber auch über Threading allgemein.

Bevor als die eigene Suppe überbrodelt, würde ich mal die OmniThreadLibrary schmecken.

Ciao Heinz Z.

[Sir Rufo]

Zitat:

Zitat von taveuni (Beitrag 1251071)

Zitat:

Zitat von Sir Rufo (Beitrag 1251005)

Aber vor dem

Delphi-Quellcode:

TThread.Synchronize

oder

Delphi-Quellcode:

TThread.Queue

immer vorher prüfen ob man sich ausserhalb des MainThread-Kontext aufhält.

Delphi-Quellcode:

if MainThreadID <> TThread.CurrentThread.ThreadID then
  TThread.Synchronize(...)
else
  ...
end;

Warum? Geht da was kaputt wenn man in den eigenen Thread synchronisiert?

TThread.Synchronize

Zitat:

Warnung: Rufen Sie

Delphi-Quellcode:

Synchronize

nicht aus dem Haupt-Thread auf. Dies kann zu einer Endlosschleife führen.

[himitsu]

Vermutlich ein Bug, bezüglich auf sich selber warten und so.

[BUG]

Zitat:

Zitat von himitsu (Beitrag 1251091)

Vermutlich ein Bug

Nicht alles, was nicht so funktioniert wie du willst, ist gleich ein Bug :stupid:
Insbesondere dann nicht, wenn das Verhalten dokumentiert/by-design ist. Wenn dir die API nicht gefällt, ist das eine andere Sache.

[Namenloser]

Kann da wirklich eine Endlosschleife auftreten oder meinen die eher ein Deadlock? Soweit ich weiß, sendet Synchronize eine Message an den Thread und wartet anschließendä vermutlich auf ein Signal (Lock). Wie eine Endlosscheife entstehen sollte, kann ich mir nicht so richtig vorstellen, Deadlock wäre dagegen logisch, weil die Message ja nicht abgearbeitet werden kann, während der Aufrufer-Thread blockiert.

Abgesehen davon meine ich aber mal den Source-Code von Synchronize gelesen zu haben, und wenn ich mich recht erinnere, war da am Anfang eine Weiche drin, die prüft ob GetCurrentThread = Ziel-Thread.

Kann natürlich sein, dass das erst in späteren Versionen in die RTL eingebaut wurde. Aber mindestens seit Delphi 2006 sollte es dann schon drin sein.