15,471
社区成员
发帖
与我相关
我的任务
分享关于dllmain中的创建新线程，然后...导致死锁
//dll name "dll2.dll"
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
HANDLE hThread;
DWORD ThreadId;
switch(ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
//DisableThreadLibraryCalls((HINSTANCE)hModule);
hThread = CreateThread(NULL,0,ThreadProcFun,NULL,0,&ThreadId);
WaitForSingleObject(hThread,INFINITE);
CloseHandle(hThread);
break;
case DLL_PROCESS_DETACH:
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
}
return TRUE;
}
在另一main cpp中
#include <windows.h>
#include <stdio.h>
typedef int(*PFUN_fnDll1)(void);
void main()
{
HINSTANCE hInstDll;
PFUN_fnDll1 pFun;
LPCSTR dllfile = "dll2.dll";
hInstDll = LoadLibrary(dllfile); //执行到这里时出现死锁
}
烦请各位给个死锁的理由
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
HANDLE hThread;
DWORD ThreadId;
switch(ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
//DisableThreadLibraryCalls((HINSTANCE)hModule);
hThread = CreateThread(NULL,0,ThreadProcFun,NULL,0,&ThreadId);
WaitForSingleObject(hThread,INFINITE);
CloseHandle(hThread);
break;
case DLL_PROCESS_DETACH:
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
}
return TRUE;
}
在另一main cpp中
#include <windows.h>
#include <stdio.h>
typedef int(*PFUN_fnDll1)(void);
void main()
{
HINSTANCE hInstDll;
PFUN_fnDll1 pFun;
LPCSTR dllfile = "dll2.dll";
hInstDll = LoadLibrary(dllfile); //执行到这里时出现死锁
}
烦请各位给个死锁的理由
...全文
请发表友善的回复…
发表回复
borz 2001-12-14
- 打赏
- 举报
我的qq:57226475
borz 2001-12-14
- 打赏
- 举报
谢谢 caigzhi，一语中的，能交个朋友吗？
给分了，
给分了，
caigzhi 2001-12-14
- 打赏
- 举报
新线程在DLL_PROCESS_ATTACH结束前不会跑的起来，那时还没有新线程的入口地址和执行代码
dgb 2001-12-14
- 打赏
- 举报
han012(阿毛) 说的很好 Cannot Create an MFC Thread During DLL Startup
borz 2001-12-14
- 打赏
- 举报
可我认为在DisableThreadLibraryCalls（）之后，DLL_PROCESS_ATTACH能走完啊（线程
ThreadProcFun可以走完，WaitForSingleObject也可以走完，然后CloseHandle(),然后break; 难道有错吗？
--请恕小弟愚笨
ThreadProcFun可以走完，WaitForSingleObject也可以走完，然后CloseHandle(),然后break; 难道有错吗？
--请恕小弟愚笨
caigzhi 2001-12-14
- 打赏
- 举报
如果没有，建议一定买一本（最好是它的第四版（Windows核心编程）），
这是windows用户态编程最好的书
这是windows用户态编程最好的书
caigzhi 2001-12-14
- 打赏
- 举报
你理解错了，只有DLL_PROCESS_ATTACH完成以后系统才能使用导入DLL的地址空间，这是常规方法不可逾越的步骤。
borz 2001-12-14
- 打赏
- 举报
小弟一时半 找不到那本书啊
borz 2001-12-14
- 打赏
- 举报
一时半晌找不到这本书啊
caigzhi 2001-12-14
- 打赏
- 举报
《Windows高级编程指南》P433-434里有一样的例子和说明
borz 2001-12-14
- 打赏
- 举报
小弟不明白，为什么不会再次有调用dllmain的企图了而还是会
"系统根本到不WaitForSingleObject的后一句指" ？，我的理解是ThreadProcFun，
很快就会执行完毕，而WaitForSingleObject也会执行成功并且反回
请"caigzhi"继续指点
"系统根本到不WaitForSingleObject的后一句指" ？，我的理解是ThreadProcFun，
很快就会执行完毕，而WaitForSingleObject也会执行成功并且反回
请"caigzhi"继续指点
caigzhi 2001-12-14
- 打赏
- 举报
就算如此，系统必须在执行从DllMain的DLL_PROCESS_ATTACH完成后才会继续Dll的操作，
刚刚说的DLL_THREAD_ATTACH只是代表DLL_PROCESS_ATTACH的后续动作而已，
也就是系统根本到不WaitForSingleObject的后一句指令，所以也不会对Dll继续执行
刚刚说的DLL_THREAD_ATTACH只是代表DLL_PROCESS_ATTACH的后续动作而已，
也就是系统根本到不WaitForSingleObject的后一句指令，所以也不会对Dll继续执行
cmpp 2001-12-14
- 打赏
- 举报
我来学习一下！
hdj0569 2001-12-14
- 打赏
- 举报
把WaitForSingleObject先注掉，不处理同步。
试一试。
试一试。
han012 2001-12-14
- 打赏
- 举报
DllMain()中不能创建线程!
PRB: Cannot Create an MFC Thread During DLL Startup
SYMPTOMS
An MFC DLL that creates a new MFC thread during startup hangs when loaded by an application. This includes whenever a thread is created by calling AfxBeginThread or CWinThread::CreateThread inside:
the InitInstance of a CWinApp-derived object in a Regular DLL.
a supplied DllMain or RawDllMain function in a Regular DLL.
a supplied DllMain or RawDllMain function in an Extension DLL.
CAUSE
For Regular DLLs, which have a CWinApp-derived object, the CWinApp::InitInstance override is called from MFC's supplied DllMain when a process is attaching to the DLL. That is, DllMain is entered with a Reason For Call of DLL_PROCESS_ATTACH, and in handling this, MFC calls in to InitInstance before cleaning up and leaving DllMain.
For Extension DLLs, the startup of the DLL is the same, except Extension DLLs do not have a CWinApp-derived object and therefore have no InitInstance.
Whenever new threads are created that use code in the DLL, DllMain is called with a Reason For Call of DLL_THREAD_ATTACH to announce to the DLL that a new thread is attaching to it. If a new thread is created in the InitInstance of an MFC Regular DLL or in the DllMain of any MFC DLL during DLL_PROCESS_ATTACH, this second thread will attempt to re-enter the DllMain, which has not yet been exited from in an effort to announce DLL_THREAD_ATTACH.
DllMain, however, is not re-entrant. That means that the second thread will not start executing until the initial creating thread has finished its work in InitInstance, returned to and left DllMain.
In versions of MFC included with 32-bit Visual C++ versions 2.2 and earlier, MFC allowed threads to be created during startup, and usually DLLs that did this would work acceptably. The second thread would get created without problem but would not start executing until the first thread left DllMain. However, it has never been a good idea to create threads in DllMain during DLL_PROCESS_ATTACH.
As of MFC 4.0, the CWinThread::CreateThread function, which is called by AfxBeginThread, now waits on the created thread to start up and initialize MFC specific data before it returns control to the calling thread. Because the second thread is waiting on the first thread to leave DllMain, both threads crash headlong into deadlock and the application hangs.
Note that this information is equally valid for the RawDllMain function. Moreover, MFC DLLs should not use a RawDllMain function at all.
RESOLUTION
Regular DLLs that create threads should only do so in functions exported from the DLL and called by client applications. Furthermore, no MFC DLL -- neither Extension nor Regular -- should create an MFC thread in the DllMain or RawDllMain function. This ensures that the thread will not be created in the middle of any critical startup code.
The recommended solution for MFC DLLs that need to create a thread when the DLL starts is to add a specific exported initialization function and create the thread in it. Applications that use the DLL would need to call this function sometime during startup, most likely during the application's InitInstance if it uses MFC. Or, if the application is loading the DLL explicitly, the application should call the initialization function immediately after the call to load the library.
The practice of exporting an initialization function for a DLL is not uncommon. Nevertheless, there may be situations where DLLs created with earlier versions of MFC are being ported but the client application cannot be changed to include a call to an initialization function. The alternative to an initialization function is to create the thread in one of the pre- existing exported functions. Any of the DLL's exported functions that require a running thread should be responsible for first checking to see if that thread exists and then creating it if it does not.
STATUS
This behavior is by design.
PRB: Cannot Create an MFC Thread During DLL Startup
SYMPTOMS
An MFC DLL that creates a new MFC thread during startup hangs when loaded by an application. This includes whenever a thread is created by calling AfxBeginThread or CWinThread::CreateThread inside:
the InitInstance of a CWinApp-derived object in a Regular DLL.
a supplied DllMain or RawDllMain function in a Regular DLL.
a supplied DllMain or RawDllMain function in an Extension DLL.
CAUSE
For Regular DLLs, which have a CWinApp-derived object, the CWinApp::InitInstance override is called from MFC's supplied DllMain when a process is attaching to the DLL. That is, DllMain is entered with a Reason For Call of DLL_PROCESS_ATTACH, and in handling this, MFC calls in to InitInstance before cleaning up and leaving DllMain.
For Extension DLLs, the startup of the DLL is the same, except Extension DLLs do not have a CWinApp-derived object and therefore have no InitInstance.
Whenever new threads are created that use code in the DLL, DllMain is called with a Reason For Call of DLL_THREAD_ATTACH to announce to the DLL that a new thread is attaching to it. If a new thread is created in the InitInstance of an MFC Regular DLL or in the DllMain of any MFC DLL during DLL_PROCESS_ATTACH, this second thread will attempt to re-enter the DllMain, which has not yet been exited from in an effort to announce DLL_THREAD_ATTACH.
DllMain, however, is not re-entrant. That means that the second thread will not start executing until the initial creating thread has finished its work in InitInstance, returned to and left DllMain.
In versions of MFC included with 32-bit Visual C++ versions 2.2 and earlier, MFC allowed threads to be created during startup, and usually DLLs that did this would work acceptably. The second thread would get created without problem but would not start executing until the first thread left DllMain. However, it has never been a good idea to create threads in DllMain during DLL_PROCESS_ATTACH.
As of MFC 4.0, the CWinThread::CreateThread function, which is called by AfxBeginThread, now waits on the created thread to start up and initialize MFC specific data before it returns control to the calling thread. Because the second thread is waiting on the first thread to leave DllMain, both threads crash headlong into deadlock and the application hangs.
Note that this information is equally valid for the RawDllMain function. Moreover, MFC DLLs should not use a RawDllMain function at all.
RESOLUTION
Regular DLLs that create threads should only do so in functions exported from the DLL and called by client applications. Furthermore, no MFC DLL -- neither Extension nor Regular -- should create an MFC thread in the DllMain or RawDllMain function. This ensures that the thread will not be created in the middle of any critical startup code.
The recommended solution for MFC DLLs that need to create a thread when the DLL starts is to add a specific exported initialization function and create the thread in it. Applications that use the DLL would need to call this function sometime during startup, most likely during the application's InitInstance if it uses MFC. Or, if the application is loading the DLL explicitly, the application should call the initialization function immediately after the call to load the library.
The practice of exporting an initialization function for a DLL is not uncommon. Nevertheless, there may be situations where DLLs created with earlier versions of MFC are being ported but the client application cannot be changed to include a call to an initialization function. The alternative to an initialization function is to create the thread in one of the pre- existing exported functions. Any of the DLL's exported functions that require a running thread should be responsible for first checking to see if that thread exists and then creating it if it does not.
STATUS
This behavior is by design.
borz 2001-12-14
- 打赏
- 举报
那我如果
DisableThreadLibraryCalls((HINSTANCE)hModule);
强制线程创建时不用DLL_THREAD_ATTACH来调用dllmain呢？ 我试了，还是会死锁
DisableThreadLibraryCalls((HINSTANCE)hModule);
强制线程创建时不用DLL_THREAD_ATTACH来调用dllmain呢？ 我试了，还是会死锁
caigzhi 2001-12-14
- 打赏
- 举报
很简单：
系统要再用DLL_THREAD_ATTACH来调用Dll，之后线程才真正启动，
但是系统在DLL_PROCESS_ATTACH时就WaitForSingleObject(),
所以永远都没机会用DLL_THREAD_ATTACH,而线程也不会得到执行并退出，
所以也没机会通过WaitForSingleObject，因此死锁了
系统要再用DLL_THREAD_ATTACH来调用Dll，之后线程才真正启动，
但是系统在DLL_PROCESS_ATTACH时就WaitForSingleObject(),
所以永远都没机会用DLL_THREAD_ATTACH,而线程也不会得到执行并退出，
所以也没机会通过WaitForSingleObject，因此死锁了
borz 2001-12-14
- 打赏
- 举报
DWORD WINAPI ThreadProcFun(LPVOID lpPar)
{
printf("Hello ! I'm in ThreadProcFun(..),that created by DllMain()'s section:DLL_PROCESS_ATTACH\n");
return 1;
}
{
printf("Hello ! I'm in ThreadProcFun(..),that created by DllMain()'s section:DLL_PROCESS_ATTACH\n");
return 1;
}
xiaoxiaohan 2001-12-14
- 打赏
- 举报
不用CreateThread，换成beginthreadex吧。
threads 2001-12-14
- 打赏
- 举报
ThreadProcFun也帖出来吧
