1

我正在编写一个通过 USB 与硬件通信的接口 Dll。为了完全满足硬件的时序要求（防止它在没有操作消息的情况下超时等），只要我的“Open()”方法被调用，我就会为每个延迟初始化创建一个工作线程。当我的“close()”方法被调用时，我设置了一个名为“terminate”的事件，该事件由工作线程监视并等待工作线程终止。终止最多需要几百毫秒，因为需要与硬件交换一些消息。

到目前为止一切顺利，唯一的问题是当程序在不调用我的“Close（）”方法的情况下卸载 Dll 时......我通过在 DllMain（PROCESS_DETATCH）中设置“终止”事件解决了这个问题，我很确定我' m 允许做并且仍然完整填写最佳实践。唯一的问题是，如果 Dll 在没有调用 close 的情况下卸载但在旧工作线程终止之前再次重新加载，我会导致加载我的 Dll 的过程超时，因为我正在等待旧工作线程完成。

所以这是我的问题：如果我只在工作线程存在并且只有当我被卸载（通过freeLibrary）和不是当我的整个过程被终止时，我通过查看 lpvReserved 参数来测试？

另外：有没有更好的方法来解决我的问题？

4

2 回答 2

0

唯一会发生的事情是让调用的线程FreeLibrary（FreeLibrary 不是异步的，它等待返回值）只要您的模块正在卸载就等待。

我已经制作了一些 DLL，有时甚至是while(!IsDebuggerAttached()){}DLLMain 附加/分离中的循环，并且我测试的程序的行为就像他们需要的那样。

至于其他问题解决方案：除了具有相同功能的 DLLMain 附加/分离之外，您为什么还需要其他任何东西？

于 2013-01-22T07:51:40.553 回答
0

我在我的 PROCESS_DETACH 中实现了一个等待，它起初可以工作，但在一个极端情况下，它最终导致了问题。问题是我们的调试输出设置加载了一个专有 DLL 以在调试输出中包含版本信息。如果我们的 DLL 被快速加载和卸载，并且在后台有足够多的事情导致这个版本信息读取速度很慢，那么它可能最终发生在进程在 PROCESS_DETACH 中等待的时间，从而导致死锁。

对于未来，我决定永远不要在 DllMin 中等待任何东西，因为我等待的任何东西都可能在某些极端情况下或在其他人向某个被触及的类添加功能之后，导致加载程序锁死锁。

我希望这个建议对将来的人有所帮助。

于 2013-11-28T10:36:52.057 回答