Windows:在什么情况下 SetEvent() 可能不会立即返回？

Question

我有一个线程，当它的函数退出循环时(退出由事件触发)，它会进行一些清理，然后设置一个不同的事件让主线程知道它已完成。

但是，在某些情况下，SetEvent() 在设置线程的“我完成了”事件后似乎不会返回。

此线程是 DLL 的一部分，问题似乎发生在 DLL 加载/附加、线程启动、线程结束以及 DLL 分离/卸载多次且应用程序在此期间没有关闭之后。在此问题发生之前必须重复此序列的次数是可变的。

如果您怀疑我知道我在说什么，我已经通过将 SetEvent() 调用与对 OutputDebugString() 的调用放在一起来确定发生了什么。出现 SetEvent() 之前的输出。然后，等待线程产生指示事件已设置的输出。

但是，退出线程中对 OutputDebugString() 的第二次调用(在 SetEvent() 之后的调用)永远不会发生，或者至少它的字符串永远不会出现。如果发生这种情况，应用程序会在几分钟后崩溃。

(请注意，对 OutputDebugString() 的调用是在问题开始出现后添加的，因此它不太可能卡在那里，而不是在 SetEvent() 中。)

我不完全确定是什么原因导致崩溃，但它发生在 SetEvent() 没有立即返回的同一个线程中(我一直在跟踪/输出线程 ID)。我想 SetEvent() 有可能最终返回，到那时它返回的上下文已经消失/无效，但是什么会导致这样的延迟？

原来我看这段代码这么久都瞎了，根本没想过要查看返回码。我今天已经看完它了，所以我会在星期一知道它返回了什么(如果它返回)，然后我将使用该信息编辑这个问题。

更新:我更改了(主)代码以等待线程退出而不是等待它设置事件，并从从属线程中删除了 SetEvent() 调用。这改变了错误的性质:现在，它不再从 SetEvent() 返回失败，而是根本不退出线程，整个事情都挂起。

这表明问题不在于 SetEvent()，而在于更深层次的问题。还不知道是什么，但最好不要追逐那条死胡同。

更新(2009 年 2 月 13 日):
原来问题比我问这个问题时想的要深。 jdigital(可能还有其他人)几乎解决了潜在的问题:我们试图在分离 DLL 的过程中卸载一个线程。

我当时没有意识到这一点，但后来通过这里和其他地方(例如 Raymond Chen 的博客)的研究发现，这是一件非常糟糕的事情。

问题是，由于它的编码方式和行为方式，根本问题并不明显 - 它被伪装成我不得不费力解决的各种其他不良行为。

这里的一些建议帮助我做到了这一点，所以我感谢所有做出贡献的人。谢谢!

Answer 1

谁在卸载 DLL，卸载是在什么时间完成的？我想知道这里是否存在时间问题，即在线程运行完成之前卸载 DLL。