Warum hängt die Konsolenanwendung bei der Verwendung einer DLL mit statischen Variablen, die Mutex verwenden, nicht auf?

Question

Ich habe eine DLL-Bibliothek geteilt, die wie unten eine Klasse enthält:

innerhalb A.dll >>Header-Datei:

class API ErrorHandler 
{ 
public: 
    ErrorHandler(); 

    virtual ~ErrorHandler(); 
protected: 
    static ErrorHandler* defaultHandler(); 

private: 
    static ErrorHandler* _pHandler; 
    static std::mutex  _mutex; 
}; 

Quelle (CPP)

ErrorHandler* ErrorHandler::_pHandler = ErrorHandler::defaultHandler(); 
std::mutex ErrorHandler::_mutex; 


ErrorHandler::ErrorHandler() 
{ 
} 


ErrorHandler::~ErrorHandler() 
{ 
} 

ErrorHandler* ErrorHandler::defaultHandler() 
{ 
    static SingletonHolder<ErrorHandler> sh; 
    return sh.get(); **<<====== here we get hanged** see the declaration of get 
} 

SingletoneHolder Header-Datei

template <class S> 
class SingletonHolder 
{ 
public: 
    SingletonHolder(): 
     _pS(0) 
    { 
    } 

    ~SingletonHolder() 
    { 
     delete _pS; 
    } 

    S* get() 
    { 
     std::lock_guard<std::mutex> lock(_m); <===== cause thread hang 
     if (!_pS) _pS = new S; 

     return _pS; 
    } 

private: 
    S* _pS; 
    std::mutex _m; 
}; 

Nachdem ich den obigen Code erstellt habe (alles was mit der Compilereinstellung zu tun hat), möchte ich ihn jetzt in meiner Konsolen App verwenden.

Nach dem Ausführen der Konsolen-App hängt die App und erreicht nie die Hauptfunktion.

Warum std::lock_guard<std::mutex> lock(_m); hängt und verhindern, dass Hauptthread weiter ausgeführt wird?

Was ist eine Alternative?

Ich verwende VS2013 Update5.

Inhalt der Hauptdatei:

#include "ErrorHandler" <== when remove this include app run correctly 
#include <iostream> 

int main() 
{ 
    getchar(); 
    return 0; 
} 

Answer 1

Zunächst sollen Sie genauen Inhalt der main Post - mit einem leeren main allem funktioniert. Die Dinge gehen nach Süden, wenn die ErrorHandler Klasse in main instanziiert wird. Die Initialisierung Ihrer statischen Member tritt innerhalb von __DllMainCRTStartup auf. Und wie in der SO-Frage, die ich als doppelt gekennzeichnet habe, angegeben, gibt MSDN an, dass die Verwendung von Synchronisierungsprimitiven aus __DllMainCRTStartup einen Deadlock verursachen kann. Eine mögliche Lösung besteht darin, zu einem kritischen Bereich zu wechseln.