Threads und DLL's
-
Hi,
ich benutze eine Library, die in c geschrieben ist und daher nicht multi-thread fähig ist.
Ist es denn möglich die DLL via. LoadLibrary für jeden Thread einzeln zu laden sodass sie sich nicht gegenseitig stören oder geht das auch nicht (bitte mit einer kleinen Begründung).
-
JayJay schrieb:
ich benutze eine Library, die in c geschrieben ist und daher nicht multi-thread fähig ist.
Was macht die Library? Warum sollte sie nicht multithreadingfähig sein, nur weil sie in c geschrieben ist?
-
1. Die DLL benutzt globale Variablen.
2. Ich hab es ausprobiert und das ding stürtzt ab
-
Ok scheint wohl auch nicht zu funktionieren. Gibt es eine Möglichkeit Ohne "CriticalSection" so etwas zu managen?
Ich will für jeden Thread eine eig. DLL laden - klappt irgendwie nicht, da er bereits die DLL geladen hat und das dann auch nicht mehr macht? Hat jemand dafür eine Idee?
-
Hm und nu?
-
Nein, es geht nicht. Begründung: weil Windows die DLL nicht nochmal lädt, so einfach ist das.
Lösungsmöglichkeiten: 1) DLL umschreiben 2) andere DLL verwenden 3) sämtliche Zugriffe auf die DLL selbst synchronisieren
-
Je nachdem was in den globalen Variablen steht, kann es auch nichts bringen, den zugriff zu synchronisieren.
-
JayJay schrieb:
ich benutze eine Library, die in c geschrieben ist und daher nicht multi-thread fähig ist.
Die beiden Aussagen ("in C geschrieben" und "nicht threadsicher") mögen richtig sein; aber die Schlussweise ist falsch.
JayJay schrieb:
1. Die DLL benutzt globale Variablen.
Es gibt bei DLLs gemeinerweise 2 Arten von globalen Variablen; nämlich solche die nur prozessweit global sind und solche die systemweit global sind (im "Shared" Segment)
Weisst Du ob diese DLL auch noch von anderen Prozessen benutzt wird?
Hast Du eigentlich den DLL-Source?
Spielt OLE/COM irgendwo eine Rolle?Grüsse
*this
-
Hi, nein es ist eine "reine" DLL. Ob es Systemweite Variablen sind kann ich leider nicht sagen.
Ich gehe mal von aus, dass es nicht systemweite sind.
-
Was mich daran stutzig macht ist dass die durch die Threadunsicherheit entstehenden Fehler sich offenbar leicht reproduzieren lassen, da Du's scheinbar einwandfrei darauf zurückführen kannst.
Das heisst nämlich oft dass es eine Zusicherung gibt die zwischen Aufrufen erhalten bleiben muss und wenn die Threads konkurrieren invalidieren sie sich ständig gegenseitig diese Zusicherung.
Wenn Du dann "von oben", also per Adapter, synchronisierst warten die Threads lediglich auf den jeweils anderen um dann doch abzustürzen!
Am besten Du "verzahnst" mal die Aufrufe zweier Funktionen künstlich
- T1 ruft F1
- T2 ruft F1
- T1 ruft F2
- T2 ruft F2(4 Events; per Hauptthread steuern)
Wenn's da auch noch knallt kannst Du imho die DLL vergessen.
Grüsse
*this
-
Dank für deine Hilfe. Es scheint jedoch ich hab ein generelles Problem mit dem Quellcode.
ICh benutze Managed C++ mit Nativ. Der Main-Thread hat die DLL als Klasse. Im aktuellen Fall benutze ich dort eine "Critical-Section" Kombination, sodass die SubThreads nicht gleichzeitig drauf zugreifen.
Jedoch erhalte ich folgende Fehlermeldung, wenn ich gerade von einem Thread drauf zugreifen:
-----------
(*[0]).m_pPG error: managed EE does not understand expression's syntaxkann jemand damit was anfangen?
-
Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum C++/CLI mit .NET verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
WO kommt diese Fehlermeldung??? Doch vermutlich im Watch-Fenster, oder?
Und was hat dann diese Meldung mit Deinem Programm zu tun?
-
Hm, das war eig. meine Frage - ist diese Information brauchen?
