Thread und VCL Zugriff

[Mavarik]

Hallo Zusammen!

Thread kann man sicherlich für die unterschiedlichsten Anwendungsbeispiele einsetzen.

Ich weiß nicht wie es Euch geht, aber in einer Anwendung entscheide ich mich immer dann einen Thread zu benutzen, wenn das Hauptprogramm keine "Zeit" hat oder nicht auf das Ergebniss warten soll.

In 99% aller Fälle, will ich aber im Thread etwas ausgeben, einen Status, einen Log oder einen Progress-Balken.

Da ein Zugriff auf die VCL jedoch "nur" über Syncronize(XY) erlaubt ist und dieser Code dann im Haupt-VCL-Thread ausgeführt wird, bringt mir der ganze Thread eigentlich nix, da ja mein Hauptprogramm gerade wie gesagt keine "Zeit" hat bzw. eben kein Application.Processmessages aufrufen kann oder soll...

Wie macht Ihr das? Gibt es dafür eine Lösung?

Grüsse Frank :coder:

[chaosben]

Eine Lösung ist ein threadsafe gecodeter Puffer, in dem die zu visualisierenden Daten liegen.

[Mavarik]

Zitat:

Zitat von chaosben

Eine Lösung ist ein threadsafe gecodeter Puffer, in dem die zu visualisierenden Daten liegen.

Ich dachte genau das ist das Problem, da die VCL eben nicht threadsave ist... Hast Du ein Beispiel?

Frank :drunken:

[Robert Marquardt]

Das klingt nach Schwachsinn. Man macht einen Thread damit der Hauptthread weiterhin nur mit dem Betreiben der Oberflaeche via VCL beschaeftigt sein kann.
Die in "keine Zeit haben" verklausulierte Aufgabe gehoert in einen weiteren Thread.

[chaosben]

Das Stichwort für meinen Vorschlag lautet "TMultiReadExclusiveWriteSynchronizer".

Davon erzeugt man ein Objekt und nutzt es, um den Zugriff auf den Puffer (irgendeine Variable) zu regeln.

Zitat:

Zitat von Die Delphihilfe ©Borland

Mit TMultiReadExclusiveWriteSynchronizer kann der Zugriff auf den Speicher in einer Multithread-Anwendung überwacht werden. Im Gegensatz zu einem kritischen Abschnitt, der alle anderen Threads am Lesen und Schreiben in den zugeordneten Speicher hindert, ermöglicht es TMultiReadExclusiveWriteSynchronizer, dass mehrere Threads gleichzeitig aus dem geschützten Speicher lesen können. Bei einem Schreibzugriff eines Thread stellt TMultiReadExclusiveWriteSynchronizer sicher, dass der Thread exklusiven Zugriff auf den Speicher hat.

TMultiReadExclusiveWriteSynchronizer kann die Ausführungsgeschwindigkeit von Anwendungen wesentlich verbessern, in denen Threads häufig Lesezugriffe auf ein Objekt oder eine Variable ausführen, aber nur gelegentlich in das Objekt bzw. die Variable schreiben.

Jeder Zugriff auf den geschützten Speicher muss in Aufrufe der Methoden BeginRead und EndRead bzw. BeginWrite und EndWrite eingeschlossen werden. Andernfalls kann es zu Konflikten zwischen den einzelnen Threads kommen.

[Mavarik]

Zitat:

Zitat von Robert Marquardt

Die in "keine Zeit haben" verklausulierte Aufgabe gehoert in einen weiteren Thread.

Ok wenn es dabei um eine Neuentwicklung geht, gebe ich Dir recht, aber wenn es darum geht eine bestehende "alte" Software ca. 1.2 Mio Source-Zeilen etwas zu parallelisieren, geht es nicht so einfach...

Frank :gruebel:

[SirThornberry]

wenn dein Hauptthread nie zeit hat einen Status anzuzeigen dann kannst du das ganz sein lassen. Ansonsten wäre noch die Möglichkeit das du nur alle 10 Sekunden den Status durch Syncronize mit dem Hauptthread abgleichst. Oder du postest eine Message an ein Fenster des Hauptthreads. Dann ist der Status jedoch assyncron zum Thread und macht keinen großen Sinn.

[Mavarik]

Zitat:

Zitat von SirThornberry

Ansonsten wäre noch die Möglichkeit das du nur alle 10 Sekunden den Status durch Syncronize mit dem Hauptthread abgleichst.

Ja darum geht es ja gerade nicht...

Eine 2. Exec mit eigenem VCL-Thread kann ja auch parallel arbeiten... Die Frage ist, wie kann ich einen 2. VCL-Thread abspalten ohne eine 2. Exe zu erzeugen?

Frank

[Udontknow]

Hallo!

Zitat:

Zitat von Mavarik

Zitat:

Zitat von SirThornberry

Ansonsten wäre noch die Möglichkeit das du nur alle 10 Sekunden den Status durch Syncronize mit dem Hauptthread abgleichst.

Ja darum geht es ja gerade nicht...

Eine 2. Exec mit eigenem VCL-Thread kann ja auch parallel arbeiten... Die Frage ist, wie kann ich einen 2. VCL-Thread abspalten ohne eine 2. Exe zu erzeugen?

Frank

Eine 2. Exec? Du meinst dasselbe Programm noch einmal aufgerufen? Das ist doch ein anderer Prozess! Das die sich nicht in die Quere kommen ist doch klar.

Ich sorge immer dafür, daß der Hauptthread "Freizeit" hat, während ein anderer Thread ackert und zwischendurch seine Fortschritte per Synchronize durchgibt (wohlgemerkt, die Arbeit fällt natürlich nicht im Synchronize an!).

Cu,
Udontknow

[Mavarik]

Zitat:

Zitat von Udontknow

Eine 2. Exe? Du meinst dasselbe Programm noch einmal aufgerufen? Das ist doch ein anderer Prozess! Das die sich nicht in die Quere kommen ist doch klar.

Nein natürlich nicht..

OK dann eben so... Wie erzeuge ich aus meinem Programm einen Thread/Prozess mit einer eigenen VCL-Thread?

Frank

[Udontknow]

Imho gar nicht. Das, was du als VCL-Thread-Funktionalität siehst, ist ja nichts anderes als das Aufrufen der Prozedur Application.Run (siehe DPR-Code bzw. Forms-Unit). In der dort vorhandenen Schleife werden die Messages, die die Anwendung empfängt, verarbeitet. Ich wüsste nicht, wie du die Nachrichten dort unterscheiden willst, ganz davon abgesehen, daß du ein separates Application-Objekt benötigen würdest. Ob nicht im VCL-Code der einzelnen Steuerelemente auf die Application-Variable von Forms verwiesen wird, ist auch noch zu prüfen, also alles sehr schwierig.

Cu,
Udontknow

[Mavarik]

Zitat:

Zitat von Udontknow

also alles sehr schwierig.

Cu,
Udontknow

lol genau... Wenn es Einfach gewesen wäre, hätte ich es einfach mal programmiert... *lach*

Trotzdem Danke ...

Frank :mrgreen:

[Udontknow]

Ja, das kommt davon, wenn man was durch die Blume sagt. :roll:

Ersetze "alles sehr schwierig" durch "sehr wahrscheinlich nicht zu realisieren". :mrgreen:

Cu,
Udontknow

[SirThornberry]

Zitat:

Zitat von Udontknow

Imho gar nicht. Das, was du als VCL-Thread-Funktionalität siehst, ist ja nichts anderes als das Aufrufen der Prozedur Application.Run (siehe DPR-Code bzw. Forms-Unit). In der dort vorhandenen Schleife werden die Messages, die die Anwendung empfängt, verarbeitet. Ich wüsste nicht, wie du die Nachrichten dort unterscheiden willst, ganz davon abgesehen, daß du ein separates Application-Objekt benötigen würdest. Ob nicht im VCL-Code der einzelnen Steuerelemente auf die Application-Variable von Forms verwiesen wird, ist auch noch zu prüfen, also alles sehr schwierig.

Cu,
Udontknow

Es ist möglich die VCL in einem anderen Thread als dem Hauptthread laufen zu lassen. Das ganze ist recht simpel, man muss nur drauf kommen. Und zwar erzeugt man einfach einen Thread und lädt in diesem Thread eine DLL. In der DLL kann dann wieder VCL etc. verwendet werden welche dann im Context des aufrufenden Threads läuft. Man braucht also einfach nu im Execute von TThread die DLL laden, eine Procedure der DLL aufrufen und diese läuft dann eben im Threadcontext

[Udontknow]

hehe, ok. :lol: Ist ein wenig "von hinten durchs Auge in die Brust" geschossen, aber gut. Ob man sich mit dem separaten Modul dann einen Gefallen tut, was Speicherverwaltung & co. angeht...

Cu,
Udontknow

[Mavarik]

Zitat:

Zitat von SirThornberry

In der DLL kann dann wieder VCL etc. verwendet werden welche dann im Context des aufrufenden Threads läuft. Man braucht also einfach nu im Execute von TThread die DLL laden, eine Procedure der DLL aufrufen und diese läuft dann eben im Threadcontext

Eine DLL hat eine eigene Messageque?

Frank

[SirThornberry]

nein, in der DLL musst du natürlich auch Applicaiton.Run aufrufen. Da aber die DLL aus einem Thread aufgerufen wird läuft diese Messageque im Threadcontext. Jeder Thread hat eine eigene MessageQue

[Mavarik]

Zitat:

Zitat von SirThornberry

nein, in der DLL musst du natürlich auch Applicaiton.Run aufrufen. Da aber die DLL aus einem Thread aufgerufen wird läuft diese Messageque im Threadcontext. Jeder Thread hat eine eigene MessageQue

:wiejetzt: Ein Thread hat doch auch eine MessageQue... Wo ist der unterschied zur DLL-Lösung?

Frank

[SirThornberry]

die DLL hat nur den Vorteil das du in dem Thread VCL nutzen kannst. Die Delphi-VCL ist so ausgelegt das sie nur im initialisierenden Thread des Moduls läuft. Du kannst die VCL also innerhalb eines Moduls also nicht ohne Probleme in mehreren Threads nutzen. Wenn du ein Modul (die DLL) allerdings innerhalb eines Threads lädst wird die VCL in diesem Thread-Context initialisiert und somit kannst du zum Beispiel ein Formular innerhalb des Threads anzeigen welches den Fortschritt anzeigt.

[Udontknow]

Also wenn ich nicht viel Unsinn erzähle, ist es so, daß eine DLL als eigenständiges Modul sozusagen seine "eigene" Forms-Unit, Application-Variable etc. hat, und daher ist zum Beispiel ein in der DLL erstelltes Formular unabhängig von der eigentlichen Anwendung. Ist aber mehr Hörensagen als alles andere.

Cu,
Udontknow

[Mavarik]

Zitat:

Zitat von SirThornberry

die DLL hat nur den Vorteil das du in dem Thread VCL nutzen kannst. Die Delphi-VCL ist so ausgelegt das sie nur im initialisierenden Thread des Moduls läuft. Du kannst die VCL also innerhalb eines Moduls also nicht ohne Probleme in mehreren Threads nutzen. Wenn du ein Modul (die DLL) allerdings innerhalb eines Threads lädst wird die VCL in diesem Thread-Context initialisiert und somit kannst du zum Beispiel ein Formular innerhalb des Threads anzeigen welches den Fortschritt anzeigt.

Ja Prima... War das jetzt so schwer? :dp:

Frank :mrgreen:

[jbg]

Zitat:

Zitat von Udontknow

Also wenn ich nicht viel Unsinn erzähle, ist es so, daß eine DLL als eigenständiges Modul sozusagen seine "eigene" Forms-Unit, Application-Variable etc. hat

Dem ist so, außer wenn man die DLL gegen das VCL-Package linkt. (=> "Mit Laufzeitpackages kompilieren"). Denn dann gibt es wieder nur eine VCL.