2012-06-28 18 views
10

Ich arbeite an einem Webdienst, der mit einer nativen DLL interagiert, und ich benutze LoadLibrary/GetModuleHandle/FreeLIbrary und GetProcAddress, um die DLL dynamisch zu laden/zu entladen, weil sie nicht sehr stabil ist.Sind LoadLibrary, FreeLibrary und GetModuleHandle Win32-Funktionen threadsicher?

public class NativeMethods 
{ 
    [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)] 
    public static extern IntPtr LoadLibrary(string libname); 

    [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)] 
    public static extern IntPtr GetModuleHandle(string libname); 

    [DllImport("kernel32.dll", CharSet = CharSet.Auto)] 
    public static extern bool FreeLibrary(IntPtr hModule); 

    [DllImport("kernel32.dll", CharSet = CharSet.Ansi)] 
    public static extern IntPtr GetProcAddress(IntPtr hModule, string lpProcName); 
} 

Ich habe bemerkt, dass w3wp.exe Prozess occationally unter hohen Last abstürzt und wenn ich es der Debugger oft an meinem NativeMethods.GetModuleHandle stoppt zu debuggen versuchte (Funktionsaufruf).

Ich konnte keinen Beweis dafür finden, dass GetModuleHandle nicht threadsicher ist, also frage ich mich, ob jemand ähnliche Erfahrungen gemacht hat, wenn er diese kernel32.dll-Funktion von multi-threaded .NET-Anwendungen interagiert?

Oscar

+1

LoadLibrary und FreeLibrary sollten relativ zur DLL-Ladeliste Thread-sicher sein, und theoretisch sollte GetModuleHandle, aber ich würde wahrscheinlich ein LoadLibrary/FreeLibrary-Paar anstelle dieser Methode verwenden, als dann sicherstellen, dass Sie einen Verweis auf die Bibliothek haben und es kann nicht einfach aus dem Speicher verschwinden, während du es benutzt. – tyranid

Antwort

6

Laut Igor Tandetnik (Microsoft MVP).

Abgesehen von GDI-Funktionen, die nicht Thread-sicher sind. Fast alles, was eine HWND und/oder eine HDC dauert, muss auf dem gleichen Thread aufgerufen werden, wo diese HWND oder HDC erstellt wurde (, PostMessage und ähnliche sind beachtenswerte Ausnahmen). HBITMAP s, HICON s und solche können zwischen Threads übergeben werden, sollten aber von jeweils einem Thread bearbeitet werden.

Die meisten anderen Funktionen - diejenigen, die sich nicht mit GDI oder Fenstermanagement beschäftigen - sind tatsächlich threadsicher.

Dies sollte LoadLibrary, GetModuleHandle, FreeLibrary und GetProcAddress enthalten.

Beachten Sie jedoch, dass FreeLibrary nicht von DllMain aufgerufen werden sollte.

Ich kann auch hinzufügen, dass ich diese Funktionen in einer Multithread-Umgebung seit einiger Zeit ohne Problem verwendet habe.

+0

https://mvp.support.microsoft.com/profile=b3eb0170-44f2-4819-b048-8616caa4d107/http://social.msdn.microsoft.com/profile/igor%20tandetnik/?ws=usercard-mini (Wenn dies die richtige Person ist) funktioniert nicht für MS? aber er ist ein MVP ... – Anders

+0

Geändert Antwort, um vorherigen Kommentar widerzuspiegeln –

+0

Beachten Sie, dass 'LoadLibrary' die Referenzzahl des Moduls erhöht, während 'GetModuleHandle' die Referenzzahl des Moduls nicht erhöht. Leider macht dies "GetModuleHandle" nicht threadsicher. Weitere Informationen finden Sie im Abschnitt ** Bemerkungen **: https://msdn.microsoft.com/en-us/library/windows/desktop/ms683199(v=vs.85).aspx Key Note: ** Nehmen wir zum Beispiel an dass ein Thread ein Modul-Handle abruft, aber bevor es das Handle verwendet, gibt ein zweiter Thread das Modul frei. .... ** –

Verwandte Themen