Thread in dll

[clownxx]

Hey, ich benutze die Komponente TComport von

http://comport.sf.net/

um mit der seriellen Schnittstelle zu arbeiten.

Ich habe nicht das Package installiert sondern lediglich die Unit eingebunden. Klappt alles wunderbar.
Nun möchte ich diese Komponente über ein neues Interface in eine DLL packen. Klappt auch soweit.
Diese Komponente TComport erstellt einen Thread, welcher nach neuen Charactern auf der seriellen Schnittstelle sucht. Wurde eines gefunden, wird ein Event ausgelöst. Das klappt auch, jedoch nicht in der DLL. Hier ergbit sich folgendes Problem:

Im Execute des Threads der TComport Komponente wird auf neue Zeichen geprüft. Dann wird die Thread-Methode DispatchComMsg aufgerufen. Diese ruft dann

synchronize(DoEvents)

auf. Do Events ist auch einen Threadmethode. Sie feuert dann das Event. Wenn ich den haltepunkt nun auf den synchronize-Aufruf setze gelangt der Compiler dort an, aber er geht nicht in die Methode DoEvents. Lasse ich den Befehl synchronize weg, geht er in DoEvents. Allerdings kommen dann nicht immer sinnvolle Zeichen an. Kann mir jemand einen Ansatz geben, wie ich das Problem angehen kann?

Danke schonmal.

Güße

[Muetze1]

Synchronize arbeitet mit der VCL Nachrichtenschleife im VCL Thread. Wenn du keinen VCL Thread hast, hast du keine entsprechende Nachrichtenverarbeitung und somit läuft Synchronize in's leere.

[clownxx]

vielen Dank für die Antwort. Die dll binde ich ja in eine Anwendung ein, also sollte ich ja auch einen VCL Thread haben oder sehe ich das falsch? Was kann ich tun um einen VCL Thread zu bekommen? Gibt es da eine Möglichkeit?

[Muetze1]

DLL und Anwendung sind zwei unterschiedliche Dinge. Die haben (im Normalfall) nichtmal den Speichermanager gemeinsam, somit ist da nichts mit Synchronisation von Dingen in einer DLL. Wie sollte das die Anwendung mir nichts, dir nichts bewerkstelligen? Du kannst sonstwas für DLLs mit LoadLibrary z.B: laden und da soll die Anwendung automatisch und völlig konfigurationslos Threads synchronisieren? Wenn du da eine gute Formel hinbekommst: patentieren lassen. Damit kannste auch Geld machen...

Also: Die DLL hat soweit keine Oberflächen VCL mit drin, somit muss auch nichts synchronisiert werden. Rufe einen vorher von der Anwendung übergebenen Callback einfach vom Thread aus auf und gut ist. Die Anwendung muss ich darum kümmern das zu synchronisieren. Sie muss einfach so programmiert werden, dass dieser Callback jederzeit aufgerufen werden kann....

[clownxx]

ja das hieße also, ich nehme einfach synchronize weg, das klappt ja auch. Allerdings kommen dann keine gescheiten werte an der Callback an. Muss ich dann in der Callback synchronisieren? Denn diese verwendet dann den Mainthread des Comports um aus der schnittstelle zu lesen. Ich denke das, was ich synchronisieren muss ist nur der Zugriff auf FEvents, da hier ja events geschrieben werden können, wärend sie gelesen werden. das sollte ja denke ich auch mit synchronize bewerkstelligt werden. Ist das so richtig?

[Muetze1]

Schau dir mal in Bezug auf die Events die Klasse TMultiReadExclusiveWriteSynchronizer an, die macht genau das gesuchte. Eine Instanz bilden und dann alle Lese und Schreibzugriffe mit den entsprechenden Methodenaufrufen säumen (BeginRead/EndRead; BeginWrite/EndWrite)

[clownxx]

vielen Dank für deine Hilfe!!!! Ich glaube ich habe das Problem nun in den Griff bekommen.

Viele Grüße

[clownxx]

eines ist jedoch nun komisch. Wenn ich das ganze mit deiner vorgeschlagenen Klasse versuche, wird die Procedure DoEvents auch nie abgearbeitet, geanu wie wenn ich synchronize verwende. Lass ich die ganzen Synchronisationsmechanismen weg klappt das ja. Wenn ich nun in der Callback ein Showmessage(text) aufrufe, ist der Button des Fensters ganz klein und es steht erstmal nichts drin. Schreibe ich den TExt den ich in der Callback empfange einfach in ein Memo ist alles top. Dann wird dieser korrekt angezeigt. Ist das normal oder was habe ich hier noch falsch gemacht?

[Muetze1]

Zitat:

Zitat von clownxx

Wenn ich das ganze mit deiner vorgeschlagenen Klasse versuche, wird die Procedure DoEvents auch nie abgearbeitet, geanu wie wenn ich synchronize verwende.

DoEvents kannst du doch dann direkt aufrufen. Somit kann ich nun erstmal schlecht nachvollziehen, warum du niemals zum DoEvents kommst.

Zitat:

Zitat von clownxx

Lass ich die ganzen Synchronisationsmechanismen weg klappt das ja. Wenn ich nun in der Callback ein Showmessage(text) aufrufe, ist der Button des Fensters ganz klein und es steht erstmal nichts drin.

Weil du dann immernoch im Thread hängst und nicht im VCL Thread. Dass müsstest du in den VCL Thread synchronisieren. Dadurch auch der Fehler, da die Elemente vom falschen (der VCL unbekannten) Thread aus aufgerufen werden. Die VCL ist grundsätzlich nicht thread-safe!

Zitat:

Zitat von clownxx

Schreibe ich den TExt den ich in der Callback empfange einfach in ein Memo ist alles top. Dann wird dieser korrekt angezeigt.

Es tritt nur kein offensichtlicher Fehler auf, heißt aber nicht, dass alles klappt.

Zitat:

Zitat von clownxx

Ist das normal oder was habe ich hier noch falsch gemacht?

Ok, eine Idee, wie ich das ganze anfassen würde.

Anforderungen:

1. Du hast einen Thread der ab und zu Daten ermittelt, welche in einen Datenspeicher abgelegt werden.
2. Wenn was empfangen wurde, dann müssen die Daten an die Applikation weitergereicht werden.
3. Zu diesem Zeitpunkt muss dieses Ereignis der Applikation mitgeteilt werden

Schnittstelle ist der Datenspeicher. Dieser muss synchronisiert werden, damit nicht gleichzeitig gelesen und geschrieben wird.

Lösung:

Dazu wird eine Instanz von TMultiReadExclusiveWriteSynchronizer erzeugt, welche dem Thread und einer DLL Funktion bekannt gemacht wird.

Der Thread läuft und immer wenn er Daten hat, dann nutzt er BeginWrite/EndWrite um in den Datenspeicher die neuen Daten abzulegen.

Die o.g. DLL Funktion dient der Applikation um die Daten abzuholen. Dazu ruft die Applikation die Funktion auf und darin (DLL Seite) wird die TMultiReadExclusiveWriteSynchronizer Instanz mit BeginRead/EndRead verwendet.

Soweit haben wir die Datenübergabe samt thread-Sicherheit geschaffen. Nun fehlt nur noch, dass die Applikation Bescheid bekommt, wenn neue Daten angekommen sind. Dazu kann die Applikation einmalig eine DLL Funktion aufrufen, bei der sie ein Fensterhandle mitgibt. Dieses merkt sich die DLL und sendet u.a. mit PostMessage innerhalb des Threads eine Botschaft ab. Innerhalb von BeginWrite/EndWrite im Thread darf die Liste auch gelesen werden (Write ist Exklusiv) und dadurch könnte die abgesendete Message sogar die Anzahl der empfangenen Daten und noch vorhandenen Daten in dem Datenpuffer übermittelt werden. Damit weiss die Applikation auch gleich, wie oft sie die o.g. Funktion zum Daten abholen aufrufen kann/muss.

Damit wird das Auslesen innerhalb des VCL Threads angestossen (durch die Botschaft) und ist somit mit der GUI synchron.

Hinweis:
Die von der Applikation ausgelesenen/abgefragten Daten sollen bestimmt danach im Datenpuffer entfernt werden. Wenn die Applikation mehrfach liest bis sie alle Daten hat, dann wäre es besser, wenn es eine Löschen Funktion gibt. Dafür wäre nämlich ein exklusives BeginWrite/EndWrite nötig, und das würde für jeden einzelnen Datenblock den ganzen Thread so stark behindern, dass der Thread nichts mehr bringt. Von daher lieber so auslesen und extra löschen.

[clownxx]

hey, vielen Danke für die Ausführliche Antwort. Ich werde mir das mal zu Gemüte führen. Aber vom Konzept her ist das für mich nun sehr gut nachvollziehbar. Vielen Dank nochmal.