Multithreading und DLL?

[rollstuhlfahrer]

HI @all,

wenn ich in meinem Programm einen Thread erzeuge und dann per Synchronize mit dem VCL-Thread kommuniziere funktioniert das alles wunderbar. Verlagere ich aber den Thread aus in eine DLL, dann kann ich zwar Synchronize aufrufen, aber dann beginnt der Thread zu hängen. In dem Beispiel ruft CallbackMethod eine Funktion in der EXE auf. Ohne Synchronize funktioniert alles wunderbar, nur bin ich der Meinung, wenn man mit VCL-Objekten in Threads rumspielen will, sollte man das so nicht machen.

Delphi-Quellcode:

procedure TMyThread.Execute;
begin
// irgendwas berechnen
  if Ergebnis = 0 then
  begin
    BerechnungErfolgreich := true;
    Synchronize(CallbackMethod); // ist in der EXE-> geht; ist in der DLL -> bleibt hier hängen.
  end
  else
  begin
    BerechnungErfolgreich := false;
    CallbackZusaetlicherParameter := 1;
    Synchronize(CallbackMethod);
  end;
// weiter machen
end;

Was mache ich falsch?

Bernhard

[Bernhard Geyer]

Das wird vermutlich nur klappen wenn Exe und Dll mit Runtime-Packages kompiliert werden.

[Luckie]

Warum sollte die Callback in der DLL liegen? Du definierst sie in der DLL und implementierst sie in der Exe. Das hat schon seine Richtigkeit.

[himitsu]

Synchronize nutzt globale Mechianismen, um sich mit TApplication/VCL zu verständigen.
Ohne BPLs hat die DLL aber ihre "eigene" eigenständige RTTI, VCL usw.


Lösungen:
- Laufzeitpackages
- oder das Synchronize IN die Callbackprozedur der EXE

Da hätte man auch selber drauf kommen können, da man ohne Laufzeitpackages, sowieso keine Objekte und andere Dinge über EXE/DLL-Grenzen hinweg nutzen darf.

[Luckie]

Oder alles per SendMessage regeln. Das ist auch threadsafe, da SendMessage auch erst zurückkehrt, wenn die Nachricht verarbeitet wurde.

[rollstuhlfahrer]

Dann werde ich wohl Abstand von der Synchronize-Methode nehmen und alles über Fensternachrichten verschicken. Laufzeitpackages wollte ich nicht verwenden, aber wenn es anders nicht geht, werde ich wohl kaum drum herum kommen.

Bernhard

[m_junglas]

Hallo,

ich hatte das Problem vor Urzeiten in einem Projekt auch, doch es hakelt dann auch an weiteren Ecken. So habe ich in DLLs eigene Threads laufen und es kam dazu, dann auch das "OnTerminate"-Event nicht ausgeführt wird, da dieses auch über einen Synchronize-Meschanismus ausgelöst wird.

Ich habe dann auch Notgedrungen Am Ende des Threads eine Message per SendeMessage ans Fenster geschickt, was dann funktioniert und damit war ein spezielles OnTerminate machbar.

Ganz genau habe ich nicht herausbekommen welche Lösung welches Teilproblem entspannt hat, da ich einiges ausprobiert habe, aber hier mal ein paar Hinweise... vielleicht hilfts ja bei Problemen mit Threads/Fenstern in DLLs auch [ich benutze Delphi 7]:

* Wird die Forms-Unit in der DLL benutzt (z.B. weil ein Fenster erzeugt wird) so sollte das Handle-Property von "Application" beim Start mit dem Handle des Hauptmoduls (exe) beschrieben werden. So bilden die Fenster innerhalb der DLL und das Fenster des Hauptprogrammes ein zusammenhängende Application. Mir schien auch das o.a. Problem damit erledigt zu sein.

* Die globale Funktion "WakeSynchronize" wird bei Events wie Synchronize() oder beim Starten des OnTerminate aufgerufen, aber dies gelangt offenbar nicht zur "richtigen" VCL durch. Ich habe daher der Funktion eine eigene zugewiesen, die meinem Fenster per Postmessage einen Hinweis schickt. Kommt diese Message im Fenster an führe ich "while CheckSynchronize do;" aus. Aus unerfindlichen Gründen muss diese Zeile doppelt ausgeführt werden, sonst wird manchmal (!) ein Aufruf ausgelassen.
Durch den Aufruf von CheckSynchronize() werden wartende Synchronize bzw. OnTerminate-Aufrufe ausgeführt.

Naja, vielleicht hilfts ja weiter. Ich hab daran damals recht lange gehangen...

/\/\arcus