an Hagen Reddmann: Geht das doch?

[Matthias Jaensch]

Hallo Hagen,<br>

ich bin jetzt doch wieder etwas verunsichert wegen meiner Thread-Story.<br>
(Inzwischen geht es zwar mit dem Panel.canvas direkt, aber???)<br>
Im VirtualExplorerListviewEx machen die genau das, was ich auch machen wollte.<br>
Sie basteln den Thumb als Bitmap in einem Thread und "updaten" <br>
die Anzeige aus dem Thread heraus!<br>

Was denn nun? Ist das in Ordnung oder nicht?<br>
Vielleicht habe ich mein Problem nur nicht richtig beschrieben!?<br>

Gruß<br>
Matthias

[Hagen Reddmann]

Ich kenne die Sourcen nicht. Grundsätzlich ist es ein Problem der Synchronisierung bzw. des Blockings. Der Thread erzeugt die Bitmap ohne währenddessen auf die externe VCL zuzugreifen. Das ist aber einfacher gesagt als getan. Die sicherste Methode im Thread die Bitmap zu erzeugen wird sicherlich der Verzicht auf die VCL sein. D.h. keine TBitmap, TCanvas, TPen, TBrush und TFonts nutzen, alles per API. Das Problem mit diesen Objecten ist das diese durch einen "Resourcen" Manager in der VCL verwaltet werden. Dieser ist aber nicht Threadsafe. Ist der Thread fertig mit zeichnen besteht noch das Problem des Updatens im Control. Ich würde per Locking die Bitmap des Controls mit der des Threads austauschen. Das Control muß beim zeichnen natürlich das selbe Locking durchführen. Damit wird der Thread beim Austauschen immer warten müssen falls das Control sich gerade zeichnet. Nun nach dem Austausch veranlasst der Thread das das Control neu gezeichnet wird, mit InvalidRect(), NICHT Control.Invalidate da ja das wiederum die VCL benutzten würde.
Ein direktes Zeichnen im Displaycontext = hDC des Controls aus dem Thread heraus würde ich nicht machen, da das dahinterliegende GDI eben nicht threadsafe ist. Ich hatte mit meinen GIF Image das auch per Threads gezeichnet wurde genau an dieser Stelle arge Probleme. Erst als die EXE auf einem anderen Rechner lief traten massive AV's an allen möglichen Stellen auf, bis hin das selbst der Explorer permanent im GDI AV's erzeugte. Darauf hin habe ich per Synchronization mit PostMessage() gearbeitet. Im Falle meines GIFImage kommt es nicht darauf an ob nun mit 10ms Verzögerung der nächste Frame dargestellt wird oder eben nicht.<br>

Gruß Hage

[Matthias Jaensch]

Hallo Hagen,<br>

ich danke Dir nochmals für die sehr ausführliche Antwort.<br>
Also werde ich den Thread lieber doch vermeiden.<br>
Es geht ja auch ohne hinreichend schnell.<br>

Gruß<br>
Matthia

[Hagen Reddmann]

Ich möchte hier nicht den Eindruck erwecken ein "Thread-Gegner" zu sein, aber Threads im allgemeinen lohnen nur dann wenn sie vollständig getrennt zum Mainthread laufen, oder aber auf Ereignisse irgendwelcher Treiber usw. lange warten müssen. Z.b. Overlapped Zugriffe auf Ports, Internet o.ä.<br>
Werden Threads für andere Zwecke benutzt muß man immer bedenken das man den Souice der benutzten Schnittstellen, wie VCL/COM usw. nicht kennt und somit immer ein hohes Risiko einkalkulieren das es eben überhauptnicht threadsafe geht.<br>
Kleines Beispiel: Zur zeit arbeite ich mit SmartCards und somit auch mit dem PC/SC Server Schnittstellen. Normalerweise sollte dieser absolut Threadsafe sein, und Microsoft weisst sogar darauf hin das z.B. die Funktion SCardStatusChange() absolut für Threads geeignet ist um auf Statusänderungen des SmartCard Treiber zu warten.<br>
Nun gesagt und getan, einen Thread gecodet der mit SCardStatusChange() darauf wartet das eine SmartCard in den Reader geschoben wird.<br>
Klappte alles wunderbar. Nun will man nicht jedesmal diese Code als Units direkt in die EXE einlinken und fängt an eine DLL zu code. Gesagt getan und ja und... Die Anwendung kackt beim Beenden ab und der SCard Server meldet mir doch eine MFC C++ Fehler. ?? Shit was ist passiert ? Ganz einfach der fucking Treiber von Towikoto nutzt den Process Messagequeue um zu kommunizieren. Da aber der Thread erst beim Beenden der Anwednung, also NACH dem Zerstören des Messagesques des Processe versucht zu terminieren reagierte SCardStatusChange() überhaupt nicht mehr. Im Falle ohne einer Delphi Debugging IDE würde die Anwendung noch heute auf ihre Beendigung warten.<br>
Was ist passsiert: Ich nahm auf Grund der Behauptungen vom MS an das SCardStatusChange() threadsafe wäre. Die Coder bei Towikoto schlafen aber anscheinend und lesen nicht das DDK, deshalb funktioniert deren Treiber NUR mit Anwendungen die auch einen Messagequeue nutzen, also nicht mit COM DLL's, Server EXE's, oder eben in Thread innerhalb von DLL's. !!

Gruß Hage