WaitForSingleObject mit Gewinde Griff stecken, während Sie laufen regsvr32.exe

Habe ich Ein thread erstellt einen weiteren thread B, als thread A wartet mit WaitForSingleObject warten, bis thread B stirbt.

Das problem ist, dass auch wenn thread B wieder aus dem thread "thread_func", thread nicht signalisiert!.

Ich weiß das, weil ich Spuren zugesetzt (OutputDebugString) zum Ende der thread_func (thread B main-Funktion) und ich kann sehen, dass thread B beendet seine Ausführung, aber Ein thread kommt nie aus der WaitForSingleObject.

Nun, ich muss auch hinzufügen, dass dieser code in einem COM-Objekt, und das oben beschriebene Szenario passiert, wenn ich rufe regsvr32.exe (es stecken!), also ich glaube, der thread kommt aus der DLLMain.

Irgendwelche Ideen, warum Ein thread nicht signalisiert ?!?!

InformationsquelleAutor TCS | 2011-07-24
  1. 14

    Könnte man auf ein problem mit der loader-lock. Windows hat einen internen kritischen Abschnitt, der verriegelt wird, wenn eine DLL geladen/entladen oder wenn thread gestartet/gestoppt (DllMain wird immer aufgerufen, in das Schloss). Wenn Ihr wartet thread A hat, dass ein Kritischer Abschnitt gesperrt ist (d.h. Sie warten irgendwo aus DllMain), während ein anderer thread B versucht, Herunterfahren und versucht zu erwerben, die loader kritischen Abschnitt, müssen Sie Ihre deadlock.

    Um zu sehen, wo die deadlock passiert, nur führen Sie Ihre app aus der VS-IDE-debugger und nachdem es hängen bleibt, unterbrechen der Ausführung. Dann schauen Sie auf alle Laufenden threads, und beachten Sie den stack von jedem. Sie sollten in der Lage sein zu Folgen, jeder Stapel und sehen, was jeder thread wartet.

    • Sie sind absolut richtig!!!!! Ich wusste nicht seine Arbeit Weg! Also ich denke, ich werde ein weiteres Ereignis, signal am Ende thread B thread.
    • +1 auf diese Antwort. Mit DllMain aufrufen jede nicht-triviale code-Pfad (einschließlich code-system und die API-Aufrufe) ist nur ärger bringen.
    InformationsquelleAutor DXM
  2. 4

    Ich denke, @DXM ist richtig. Die Dokumentation auf genau das, was Sie können oder nicht tun können innerhalb von DllMain ist spärlich und schwer zu finden, aber die Quintessenz ist, dass Sie sollten in der Regel halten Sie es auf ein minimum, -- Initialisierung der internen Variablen und so, aber das ist über es.

    Den anderen Punkt, den ich machen würde ist, dass Sie sollten in der Regel nicht "call" regsvr32.exe -- immer.

    RegSvr32 ist im Grunde nur ein wrapper, der lädt eine DLL in den Adressraum mit LoadLibrary Fordert GetProcAddress um die Adresse einer Funktion namens DllRegisterServer, ruft dann die Funktion. Es ist viel sauberer (und letztlich besser) zu tun, den job auf eigene Faust, so etwas wie dieses:

    HMODULE mod = LoadLibrary(your_COM_file); 
register_DLL = GetProcAddress(mod, "DllRegisterServer"); 
if ( register_DLL == NULL) { 
        //must not really be a COM object... 
} 

if ( S_OK != register_DLL()) { 
        //registration failed. 
}
    • sorry, aber ich wusste nicht, warum regsvr32 schlecht ist und warum das schreiben von eigenem code ist es earier
    • Sie sehen nicht das problem mit der Erstellung eines gesamten Prozesses, nur um rufen Sie eine Funktion? Hier haben wir vier Zeilen code, die funktionieren. Ihrem code verwenden system sollte mindestens drei Zeilen, und funktioniert noch nicht -- und die Zeit, die Sie tun, machen, arbeiten, deutlich mehr (sowohl mehr, als Sie haben, und mehr als vier -- ein bisschen mehr).
    • Ich sehe keine Erwähnung von system. Wahrscheinlich OP läuft regsvr32.exe von der Konsole-Fenster manuell (wie viele von uns) zum registrieren seiner COM-Bibliothek, und es stecken, weil das system zu sperren. Also ich ganz nicht verstehen, wie die Implementierung weiterer Tools nur zu registrieren-COM-Bibliothek kann hilfreich sein, oder auch relevant für die Frage. Ihre Methoden werden das gleiche tun und seiner Bibliothek stecken die gleichen
    InformationsquelleAutor Jerry Coffin
Schreibe einen Kommentar