Weitere Synchronisierungsmöglichkeiten ?

[geskill]

Mit Messages würde es bestimmt gehen, aber dann müsste ich ja ziemlich viel ändern (überall einen Message-Listener). Und dass dann Kreuz und Quer Windows Nachrichten hin und her geschickt werden gefällt mir auch nicht. Zumal auch mehrere Instanzen von einer Komponente existieren können. Wenn man dann an diese eine Nachricht schickt, wird die andere die dann doch auch bekommen?

Es muss doch eine einfache Möglichkeit geben, wie man sich mit dem Hauptthread synchronisieren kann

[s.h.a.r.k]

Ist die DLL in Delphi geschrieben?

[geskill]

Ja, aber genau das möchte ich auch offen lassen. Deshalb würde ich gerne wie oben im Ausschnitt angedeutet an dieser Stelle Synchronisationspunkte einfügen. Sprich ich müsste am Code der DLL nichts ändern.

[s.h.a.r.k]

Mir würden dies bzgl. zwei Möglichkeiten einfallen:

• Alle Properties, die via DLL abgefragt werden können sollen, sollten via CriticalSection/TMonitor oder sonst was abgesichert werden. Dann spielt es keine Rolle mehr, welcher Thread darauf zugreift. Dies kann aber seeeehr komplex werden.
• Eine weitere Idee wäre es, eine Schnittstelle zu schaffen, mit der ein DLL-Thread kommunizieren kann. Diese Schnittstelle synchronisert dann jeden Aufruf mit dem Mainthread. Vorteil hiervon wäre, dass du die Technik "hinter" der Schnittstelle auch noch austauschen könntest, ohne, dass du die DLLs ändern müsstest.

Vielleicht wäre es für alle anderen noch interessant, wie viele Daten denn für die DLLs zur Verfügung stehen müssen. Sind es wirklich beliebig viele Daten, dann ist so eine Schnittstelle evtl. auch sehr komplex...

[geskill]

Ich habe mir jetzt gerade mal ein kleines Testprogramm geschrieben, dass permanent mit 2 Threads auf ein Memo schreibt. Zusätzlich habe ich auch noch versucht Werte in das Memo einzugeben (also manuell). Das ganze habe ich jeweils mit einer TCriticalSection, TMonitor und TMultiReadExclusiveWriteSynchronizer probiert und bei allen drei Klassen kam es nie zu irgendwelchen Fehlern - sprich jeder Zugriff wurde anscheinend sauber synchronisiert.

Eigentlich genau das was ich will, nur habe ich nicht gedacht, dass es so funktioniert. Ich dachte jetzt für die richtige VCL-Synchronisation (also mit dem Hauptthread) wäre noch mehr notwendig.

[Sir Rufo]

Warum sollte mehr notwendig sein?

Allerdings ist eine CriticalSection auch ein sehr harter Eingriff der alle beteiligten Threads ausbremsen kann bis zum Deadlock.
Ähnlich verhält es sich mit Synchronize.

Ein fast ungebremstes Verhalten bekommt man mit Queue, da hier ein Thread etwas in die Warteschlange des Hauptthreads schickt und nicht auf die Fertigstellung wartet.

[geskill]

Zitat von Sir Rufo:

Allerdings ist eine CriticalSection auch ein sehr harter Eingriff der alle beteiligten Threads ausbremsen kann bis zum Deadlock.

Entstehen diese Deadlocks durch Fehler vom Programmierer oder durch die Komponente selber?

Weil ich habe das Demo Programm gerade etwas geändert, sodass 2 Threads in ein Memo schreiben (dauerhaft). Nebenbei klicke ich auf einen Button der mehrere Male etwas in das Memo schreibt. Wenn man das Programm nun etwas länger laufen lässt und ausgiebig auf den Button klickt wird es früher oder später zu einem Deadlock kommen.

Im Debugger unter Thread Status steht dann z.b. sowas:

Code:

Projekt1.exe
 - 5516 | Ausführbar
 -  996 | Ausführbar
 - 4700 | Ausführbar |   |   | Blockiert beim Aufruf von SendMessage an ein Fenster im Besitz von Thread 5516

Mir ist schon klar, wenn ich einen Thread schlafen lege, welcher gerade innerhalb des Locks ist, dass es so zu einem Deadlock kommt.
Könnte es sein, dass es unter extremen Bedingungen (wildes Kicken auf einen Button) dazu kommt, dass es der Komponente zuviel wird und sie dann selber Aussetzer macht?

Beim googeln bin ich auch gerade auf folgenden Artikel gestoßen:
http://dn.embarcadero.com/article/28258
Dort steht im Code ein Kommentar von wegen:

Zitat:

//Still important to synchronize VCL calls

Deshalb war ich auch verwirrt und dachte, wie im Beispiel ist ein Synchronize-Befehl wichtig.

EDIT:
Der Button auf dem Formular benutzt ja auch den Lock, obwohl es an dieser Stelle unnötig ist, da man ja schon im Hauptthread befindet. Ja das sollte das Problem sein