Unerklärte Deadlock-Situation bei Verwendung des statischen Mutex in Funktion

Question

Der folgende Code ist eine extreme Vereinfachung des eigentlichen Codes, mit dem ich es zu tun habe. Dies ist nur für jemanden, der in der Lage ist, das Problem zu reproduzieren, dem ich gegenüberstehe.

#include <mutex> 
#include <thread> 

using std::mutex; 
using std::thread; 

void Do() 
{ 
    static mutex myMutex; 
    static int dataToProtect; 
    return; 
} 

class MyClass 
{ 
    public: 
     ~MyClass() 
     { 
     mythread_.join(); 
     } 


     void RunMyThread() 
     { 
     mythread_ = thread(&Do); 
     } 

     static MyClass *Instance() 
     { 
     static MyClass single; 
     return &single; 
     } 

    private: 
     MyClass() 
     {} 

     std::thread mythread_; 
}; 



int main() 
{ 
    MyClass::Instance()->RunMyThread(); 
    return 0; 
} 

Wenn mit gcc auf MinGW-w64 erfüllt, wird die Ausführung in fest:

static mutex myMutex; 

Es sieht aus wie die Kombination aus dem Faden und das Singleton Design dieses Problem schaffen, denn wenn ich telefoniere() ohne einen Thread zu verwenden:

void RunMyThread() 
    { 
    // mythread_ = thread(&Do); 
    Do(); 
    } 

das Programm wird bis zum Ende ausgeführt. Oder, wenn ich, indem die Konstruktor Öffentlichkeit rund um das Singleton-Design, und ich rufe RunMyThread() durch eine Instanz von MyClass:

int main() 
{ 
    // MyClass::Instance()->RunMyThread(); 
    MyClass o; 
    o.RunMyThread(); 
    return 0; 
} 

das Programm ausführt, als auch bis zum Ende.

Jetzt, wenn ich den ursprünglichen Code an der Spitze mit gcc unter Linux kompilieren, gibt es kein Problem. Das Programm wird bis zum Ende ausgeführt.

Ich kann nicht herausfinden, welches Verhalten in diesem Code plattformabhängig ist. Irgendeine Idee?

Answer 1

die bisherigen Kommentare/Antworten betrachtet, eine einfache Antwort auf die Frage ist: Erlauben ein Thread, nachdem die Hauptfunktion zurückkehrt auszuführen ist, was das undefinierte Verhalten führt. (Wenn Code-Portabilität erforderlich ist, sollte dies vermieden werden.)

Answer 2

Dies wird höchstwahrscheinlich durch die Reihenfolge verursacht, dass Dinge in der Windows-Laufzeit bereinigt werden. Sie können dies testen, indem Sie einen expliziten Aufruf an Ihre Klasse wie folgt ergänzt:

ShutDown() 
{ 
    mythread_.join(); 
} 

den Anruf aus dem destructor beitreten Nehmen. Dann in Ihrer Hauptfunktion:

int main() 
{ 
    MyClass::Instance()->RunMyThread(); 
    MyClass::Instance()->ShutDown(); 
    return 0; 
}