blocks|key|3015565|text|我已经追踪到void+__cdecl+_lock(int+locknum)+inside+mlock.c了。当main()结束时，主线程转到那里并进入临界区EnterCriticalSection(+_locktable[locknum].lock+);。然后调用单例析构函数，另一个线程试图进入相同的临界区，但无法进入，因此它开始等待主线程离开临界区。主线程依次等待另一个线程。所以我猜这是个bug。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3015566|entityMap^0|6|V|19|7|1J|6|26|1D|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|G|$]]

I've traced it down to <code>void __cdecl _lock(int locknum)</code> inside <code>mlock.c</code>. When <code>main()</code> ends, the main thread goes there and enters critical section <code>EnterCriticalSection( _locktable[locknum].lock );</code>. Then Singleton destructor gets called and the other thread tries to enter the same critical section, but can't, and so it starts waiting for main thread to leave the critical section. Main thread, in turn, waits for the other thread. So I guess it's a bug.

blocks|key|184127|text|在主线程上，在main()终止后，CRT获取退出锁并调用静态实例析构函数，该函数等待后台线程退出。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|184128|在后台线程中，在线程函数终止后，CRT会尝试获取退出锁来执行一些线程终止工作。这将永远阻塞，因为退出锁由主线程持有，该线程正在等待该线程退出。|184129|这是一个由CRT实现引起的简单死锁。底线是你不能在Windows的静态实例析构函数中等待线程终止。|184130|entityMap^0|7|6|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|K|$]]

On the main thread, after <code>main()</code> terminates, the CRT acquires the exit lock and calls your static instance destructor, which waits for your background thread to exit.

On the background thread, after your thread function terminates, the CRT attempts to acquire the exit lock to do some thread termination work. This blocks forever because the exit lock is held by the main thread, which is waiting for this thread to exit.

It's a simple deadlock that's caused by the CRT implementation. The bottom line is that you can't await thread termination in a static instance destructor on Windows.

blocks|key|2803276|text|好的，谢谢大家的提示。显然，这种模式的实现会导致VC%2B%2B上的死锁。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2803277|在做了一些进一步的研究之后，我发现这个实现是基于在VC%2B%2B中工作的C%2B%2B11机制的。|2803278|singleton.h|2803279|#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();
};|code-block|syntax|javascript|2803280|singleton.cpp|2803281|#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())
++++{
++++}
}|2803282|更新|offset|length|style|BOLD|2803283|看起来微软已经意识到了这个问题。在VC%2B%2B论坛上，一位名为"dlafleur“的用户报告了这篇文章：https://connect.microsoft.com/VisualStudio/feedback/details/747145|2803284|entityMap|0|LINK|mutability|MUTABLE|url|https://connect.microsoft.com/VisualStudio/feedback/details/747145^0|0|0|0|0|0|0|0|2|0|1E|1U|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|16|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|17|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|18|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|19|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|1A|8|@$Q|1B|R|1C|S|T]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1D|8|@]|9|@$Q|1E|R|1F|1|1G]]|A|$]]|$1|W|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]]]

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

<pre><code>#pragma once
#include &lt;thread&gt;
#include &lt;atomic&gt;
#include &lt;memory&gt;
#include &lt;mutex&gt;


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

private:
 static std::unique_ptr&lt;Singleton&gt; mInstance;
 static std::once_flag mOnceFlag;
 std::thread mThread;
 std::atomic_bool mRun;

 Singleton();

 void threadFoo();
};
</code></pre>

singleton.cpp

<pre><code>#include "singleton.h"

std::unique_ptr&lt;Singleton&gt; Singleton::mInstance = nullptr;
std::once_flag Singleton::mOnceFlag;


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


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

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

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

void Singleton::threadFoo()
{
 while(mRun.load())
 {
 }
}
</code></pre>

UPDATE

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

blocks|key|186398|text|请参阅标准中的basic.start.term：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|186399|186400|如果在(1.10)完成具有静态存储持续时间的对象的销毁和std::atexit注册函数(18.5)的执行之前没有发生在信号处理程序(18.10)内不允许的标准库对象或函数的使用，则程序具有未定义的行为。注意:如果使用具有静态存储持续时间的对象，而该对象在销毁之前没有发生，则程序具有未定义的行为。在调用std::exit或从main退出之前终止每个线程就足以满足这些要求，但不是必需的。这些要求允许线程管理器作为静态存储持续时间对象。-end笔记|blockquote|186401|186402|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|J|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|K|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|L|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|M|8|@]|9|@]|A|$]]]|H|$]]

See [basic.start.term] in the Standard:

<blockquote>
 If there is a use of a standard library object or function not
 permitted within signal handlers (18.10) that does not happen before
 (1.10) completion of destruction of objects with static storage
 duration and execution of std::atexit registered functions (18.5), the
 program has undefined behavior. [Note: If there is a use of an object
 with static storage duration that does not happen before the object’s
 destruction, the program has undefined behavior. Terminating every
 thread before a call to std::exit or the exit from main is sufficient,
 but not necessary, to satisfy these requirements. These requirements
 permit thread managers as static-storage-duration objects. —end note ]
</blockquote>

blocks|key|2803442|text|此死锁错误与|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2803443|std::thread::join()+hangs+if+called+after+main()+exits+when+using+VS2012+RC|offset|length|2803444|而且它在Visual+Studio+2013中没有修复。|2803445|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/10915233/stdthreadjoin-hangs-if-called-after-main-exits-when-using-vs2012-rc^0|0|0|23|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

This deadlock bug is the same as in 

<a href="https://stackoverflow.com/questions/10915233/stdthreadjoin-hangs-if-called-after-main-exits-when-using-vs2012-rc">std::thread::join() hangs if called after main() exits when using VS2012 RC</a>

and it is not fixed in Visual Studio 2013.

blocks|key|185744|text|它似乎在Visual+Studio+2015和更高版本中得到了修复，至少在这个特定的例子中是这样。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|185745|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It seems to be fixed in Visual Studio 2015 and above, at least for this specific example.

i have implemented a singleton (static version) in C++. I know all the controversy about this pattern and potential thread-safety issues, but i am curious why this exact implementation won't halt. The program never quits, it remains in a deadlock state at the end.

singleton.h:

<pre><code>#pragma once
#include &lt;thread&gt;
#include &lt;atomic&gt;

class Singleton
{
public:
 static Singleton&amp; getInstance();

private:
 std::thread mThread;
 std::atomic_bool mRun;

 Singleton();
 ~Singleton();
 void threadFoo();
};
</code></pre>

singleton.cpp

<pre><code>#include "singleton.h"

Singleton&amp; Singleton::getInstance()
{
 static Singleton instance;
 return instance;
} 

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

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

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

void Singleton::threadFoo()
{
 while(mRun)
 {
 }
}
</code></pre>

main.cpp

<pre><code>#include "singleton.h"

int main()
{
 Singleton::getInstance();
 return 0;
}
</code></pre>

What I already know:

<ul>
<li>the thread terminates</li>
<li>the main thread is stuck in the join</li>
<li>it has something to do with the static, if i make the constructor public and create an instance of Singleton in main() it will correctly terminate.</li>
</ul>

Using Visual Studio 2012. Thanks for your advice.

Why does this C++ static singleton never stop?

Visual Studio

Windows

我在C++中实现了一个单例(静态版本)。我知道关于这个模式的所有争议和潜在的线程安全问题，但我很好奇为什么这个确切的实现不会停止。程序永远不会退出，它在结束时仍处于死锁状态。singleton.h：#pragma once#include <thread>#include <atomic>class Singleton...

问为什么这个C++静态单例永远不会停止？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么这个C++静态单例永远不会停止？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么这个C++静态单例永远不会停止？
EN