C/C++:std::thread构造函数死锁问题:WIN32下不可以在DllMain中创建线程

最近在设计一个动态库时,在全局变量中创建了线程,在Windows下动态库加载时导致死锁。根本的原因是Windows要求不可以在动态库的DllMain函数中创建线程，而我的代码结构恰好满足这个条件。
以下是简化后的示例代码：

class_a.hpp

#include <thread> // c++11 support
#include <iostream>
class A {
	A(){
		// 启动线程
		std::thread t([]{ std::cout << "thread runing." << std::endl;});
	}
}

动态库源码
dll.cpp

#include <class_a.hpp>
// 全局变量
A a;
// 定义动态库接口函数
extern "C"  __declspec(dllexport) void hello()
{
}

上面的代码中A类的构造函数中创建了线程，a对象被定义为全局变量，不论是作为exe还是dll执行a都会在程序启动初始化阶段被执行初始化。

当在动态库执行时，这个a对象的初始化是在动态库入口点(DllMain entry point),也就是DllMain函数中完成的。

std::thread的构造函数中创建新线程,在新线程开始执行线程过程之前不能返回。创建新线程时，在开始执行线程过程之前，会以DLL_THREAD_ATTACH方式调用动态库 的入口点(DllMain)¹。为此，新线程必须获取加载程序锁。但是当前线程已经持有加载程序锁。

因此，会造成线程互锁：在新线程开始执行线程过程之前，当前线程无法释放加载器锁，但新线程在获取加载器锁之前无法执行线程过程，因为加载器锁由当前线程持有。

所以当前线程会一直呈阻塞状态，通过IDE调试器也无法看到新创建的线程，因为这时新线程还没开始执行。

在stackoverflow上，找到了同款问题：²

文中给出的建议就是绝对不要在DllMain中创建线程.
这也是Microsoft官方文档³中给的要求:

参考资料

---

1. 《DllMain entry point》 ↩︎

2. 《std::thread cause deadlock in DLLMain》 ↩︎

3. 《Dynamic-Link 库最佳实践》 ↩︎