Synchronize blockiert Anwendung

[Der schöne Günther]

Guck mal, ich glaub ich kenne den Kerl:

http://www.delphipraxis.net/177923-thread-dll.html

[himitsu]

Kompilierst du mit Laufzeitpackages oder ohne?

Wenn ohne, dann hat die DLL ihre eigene RTL/VCL und deren eigenen globalen Variablen.
Die EXE hat ebenfalls ihre eigene RTL/VCL/Variablen.
Also das Synchronize der DLL weiß nichts von der VCL in der EXE und kann demnach nicht richtig arbeiten.

* mit Laufzeitpackages die EXE und DLL kompilieren
* oder kein Synchronize in der DLL (z.B. per Callback in der EXE das Synchronize)
* oder siehe CheckSynchronize in Antwort #4 von http://www.delphipraxis.net/177923-thread-dll.html

[norwegen60]

Zitat von Der schöne Günther:

Guck mal, ich glaub ich kenne den Kerl:

http://www.delphipraxis.net/177923-thread-dll.html

Oh, Schitt, wie peinlich.
Das blöde ist, in der damaligen Anwendung habe ich es zum Laufen gebracht und gestern und heute eigentlich gleich implememtiert und jetzt hänge ich wieder an derselben Stelle.

Das Synchronize soll nicht rauf zur EXE sondern raus aus dem Thread un dim nächsten Schritt entweder auf eine ANzeige oder zur Exe.

[norwegen60]

So jetzt habe ich mir angeschaut wie ich es damals gemacht habe. Letztlich habe ich das Synchronize aus dem Thread raus geschmissen und von außen direkt auf die Variablen zugegriffen. So wie man es bei einem Thread ja wohl eher nicht machen soll. Oder gelten in einer DLL andere Regeln?
D.h. mir fehlt eigentlich immer noch der korrekte Weg wie ich in einem Thread einen Wert veröffentliche und und ihn dann als Callback an die EXE zurück gebe.

[jaenicke]

Du kannst Synchronize problemlos in einer DLL nutzen, wenn du das OnIdle aus der Anwendung durchreichst...
Das habe ich bei uns z.B. in die Standardschnittstelle für DLLs direkt eingebaut.

In der DLL rufst du dann einfach in der im OnIdle aufgerufenen exportierten Prozedur CheckSynchronize auf. Schon funktioniert Synchronize.

[himitsu]

Alles, wo "gleichzeitig" mehr als ein Thread auf eine Variable zugreifen kann, egal ob EXE oder DLL, muß abgesichert werden.

Die genannten Interlocked-/Atom-Funktionen arbeiten "atomar", dass heißt, dass die Operation nur in einem CPU-Schritt erledigt werden, wo auch andere Threads während dieser Zeit keinen Zugriff haben.
Somit sind diese Operationen per se thread-safe, da nur Einer zur selben Zeit Zugriff hat.

Alles Andere muß über Sperren (z.B. CriticalSections) oder über Synchronisationsfunktionen (wo alle Operationen in einen eintigen Thread verschoben werden und somit er der Einzige ist) abgesichert werden.