Std::Thread::Join() Hangs If Called After Main() Exits When Using VS2012 Rc

std::thread::join() hangs if called after main() exits when using VS2012 RC

Tracing through Fraser's sample code in his connect bug (https://connect.microsoft.com/VisualStudio/feedback/details/747145)
with VS2012 RTM seems to show a fairly straightforward case of deadlocking. This likely isn't specific to std::thread - likely _beginthreadex suffers the same fate.

What I see in the debugger is the following:

On the main thread, the main() function has completed, the process cleanup code has acquired a critical section called _EXIT_LOCK1, called the destructor of ThreadTest, and is waiting (indefinitely) on the second thread to exit (via the call to join()).

The second thread's anonymous function completed and is in the thread cleanup code waiting to acquire the _EXIT_LOCK1 critical section. Unfortunately, due to the timing of things (whereby the second thread's anonymous function's lifetime exceeds that of the main() function) the main thread already owns that critical section.

DEADLOCK.

Anything that extends the lifetime of main() such that the second thread can acquire _EXIT_LOCK1 before the main thread avoids the deadlock situation. That's why the uncommenting the sleep in main() results in a clean shutdown.

Alternatively if you remove the static keyword from the ThreadTest local variable, the destructor call is moved up to the end of the main() function (instead of in the process cleanup code) which then blocks until the second thread has exited - avoiding the deadlock situation.

Or you could add a function to ThreadTest that calls join() and call that function at the end of main() - again avoiding the deadlock situation.

std::thread::join blocks indefinitely out of main

Yes it is the same bug as in the referenced link since your example also hangs on _Thrd_join. You could be interrested in this question which contains a far more detailed analysis.

std::thread.join() deadlock

I have just had this issue, so I post the real answer for others.

In visual studio at least, there is an "exit lock", that is locked when a thread enters the exit code (ie. after main() for the main thread, and after f() for std::thread(f)).

As your Test class is only destructed after main() completes, the "exit lock" is locked. Only then you set mExit = true; and the other thread is allowed to complete. This other thread then waits to obtain the "exit lock" which is already taken by the main thread, while the main thread waits in mThread.join(); resulting in the deadlock.

So yes, you need to join all your threads before the main thread has completed.

Do child threads exit when the parent thread terminates

There is no parent/child relationship between threads. If thread A creates thread B and then thread A terminates, then thread B will continue to execute.

The exception to this is when the main thread (that is, the thread that runs the main() function) terminates. When this happens, the process terminates and all other threads stop.

Relying on order of initialisation

1. Is is safe according to the standard.

2. Extremely unsafe. Few folk are aware of this, and someone maintaining your header file might reorder the members with disastrous consequences.

I wouldn't rely on it.

Why does this C++ static singleton never stop?

Ok thank you all for your hints. Apparently this pattern implementation results in a deadlock on VC++.

After doing some further research i found this implementation based on C++11 mechanics which is working in VC++.

singleton.h

#pragma once
#include <thread>
#include <atomic>
#include <memory>
#include <mutex>

class Singleton
{
public:
    static Singleton& getInstance();
    virtual ~Singleton();

private:
    static std::unique_ptr<Singleton> mInstance;
    static std::once_flag mOnceFlag;
    std::thread mThread;
    std::atomic_bool mRun;

    Singleton();

    void threadFoo();
};

singleton.cpp

#include "singleton.h"

std::unique_ptr<Singleton> Singleton::mInstance = nullptr;
std::once_flag Singleton::mOnceFlag;

Singleton& Singleton::getInstance()
{
    std::call_once(mOnceFlag, [] { mInstance.reset(new Singleton); });
    return *mInstance.get();
}

Singleton::Singleton()
{
    mRun.store(true);
    mThread = std::thread(&Singleton::threadFoo, this);
}

Singleton::~Singleton()
{ 
    mRun.store(false);

    if(mThread.joinable())
        mThread.join();
}

void Singleton::threadFoo()
{
    while(mRun.load())
    {
    }
}

UPDATE

It looks like Microsoft is aware of this issue. In the VC++ forums a user named "dlafleur" reported this post:
https://connect.microsoft.com/VisualStudio/feedback/details/747145

---

Related Topics