什么可能导致 EventWaitHandle.Set() 阻塞当前线程？答案

【问题标题】：What could cause EventWaitHandle.Set() to block the current thread?什么可能导致 EventWaitHandle.Set() 阻塞当前线程？
【发布时间】：2012-03-27 03:48:56
【问题描述】：

我在 ManualResetEvent 的一个实例上调用 Set 方法，它偶尔会死锁。我在文档中找不到任何内容表明这是一种阻塞方法。什么可能导致 MRE.Set 阻塞？

堆栈跟踪：

[Managed to Native Transition]
mscorlib.dll!System.Threading.EventWaitHandle.Set() + 0xe bytes
MyCode.StopAll(bool force) Line 179 + 0xd bytes
MyCode.CalcCheckThread() Line 250 + 0xb bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x66 bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x6f bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x44 bytes



private static void StopAll(bool force)
{
    if( !force )
        LogHelper.SendAllCloseState(logger);

    _forcablyExit = force;
    _running = false;
    _stopWait.Set();  // This line appears to be blocking
}

【问题讨论】：

代码是什么样子的？？
我添加了调用 Set() 的方法。我还没有在其他线程的堆栈跟踪中找到模式。
这很奇怪，因为我从未听说/经历过MRE.Set 阻止。您是否尝试在调用后放置 Console.WriteLine 或其他一些输出以确保它不会返回？
没有。我将添加额外的日志记录 (NLog)。这只会发生在我们满负荷的服务器上，所以我今天不会有额外的日志。但是，我能够通过将 VS2010 连接到一个有问题的进程（从昨晚深夜挂起）来验证堆栈跟踪。
这是一个控制台应用程序，由 Windows 服务启动/控制。没有用户交互。它接收表示要做的工作的 Tibco EMS 消息，通过 COM dll 调用单线程计算引擎，然后通过 Tibco EMS 将结果发送出去。

标签： c# multithreading .net-3.5 deadlock manualresetevent

【解决方案1】：

在 Microsoft 开发人员支持的朋友的帮助下，我们找到了问题的根源。

EventWaitHandle.Set() 进入关键块部分，如果本机代码进入关键块并且从不释放它，则可以被阻止。这发生在我们正在使用的一个非常旧的第 3 方库中，并且无法轻松替换/更新。

【讨论】：

哇，不开玩笑吧？这意味着您将需要一个完全托管的ManualResetEvent 版本。 ManualResetEventSlim 也不起作用，因为它在幕后使用旧的 MRE。
无论如何都试试ManualResetEventSlim。只有某些代码路径会导致创建底层ManualResetEvent。毕竟 MRES 可能会起作用。
谢谢。不幸的是，这是 3.5 SP1，MRES 是在 4.0 中引入的。 MRE 用于通知主线程它应该完成它的工作并退出应用程序。一种这样的情况是本机代码永远不会返回的已知状态。鉴于这无论如何都是致命的，我们已经向父应用程序 (stdout) 发出信号，如果该子应用程序没有在 X 秒内自行退出，则需要强制终止该子应用程序 (taskkill.exe)。丑陋的黑客，但解决了当天的问题。如果我们升级到 4，我会记住 MRES。