.net - Microsoft.NET 和毁灭战士的多核 CPU

Question

正确的问题

有人在单核机器上遇到过这个异常吗？

The I/O operation has been aborted because of either a thread exit or an application request.

一些上下文

在单 CPU 系统上，一次只执行一条 MSIL 指令，尽管有线程。在操作之间，运行时会进行内务处理。

引入第二个 CPU(或第二个核心)，就可以在运行时执行内务处理时执行操作。因此，在单 CPU 机器上完美运行的代码在多核环境中执行时可能会崩溃 - 甚至导致蓝屏。

有趣的是，HyperThreaded Pentiums 没有出现这个问题。

我的示例代码在单核 CPU 上运行良好，但在多核 CPU 上运行不佳。它就在某个地方，但我仍在努力寻找它。它的要点是，当它作为访问者模式实现时，它会在不可预测的迭代次数后出现问题，但是将方法移到访问者操作过的对象中会使问题消失。

对我来说，这表明该框架有某种内部哈希表来解析对象引用，并且在多核系统上存在关于访问它的竞争条件。

我目前还有使用 APM 处理串行通信的代码。它曾经在我的 USB 串行适配器的虚拟 comport 驱动程序内部间歇性蓝屏，但我通过在每个 Stream.EndRead(IAsyncResult) 之后执行 Thread.Sleep(0) 来修复此问题>

在随机间隔，当我提供给 Stream.BeginRead(...) 的 AsyncCallback 被调用并且处理程序尝试调用 Stream.EndRead(IAsyncResult) 时，它抛出一个 IOException 说明 I/O 操作由于线程退出或应用程序请求而中止。

我怀疑这也是多核相关的，并且某种内部错误正在杀死等待线程，从而导致这种行为。如果我对此是正确的，那么该框架在多核环境的上下文中存在严重缺陷。虽然有我提到的变通方法，但您不能总是应用它们，因为有时它们需要在其他框架代码内部应用。

例如，如果您在网上搜索有关上述 IOException 的信息，您会发现它影响了那些显然甚至不知道自己正在使用多线程的人编写的代码，因为它发生在框架便利包装器的掩护下。

Microsoft 倾向于将这些错误报告视为不可重现。我怀疑这是因为问题只发生在多核系统和错误报告上，如 this one不要提CPU的数量。

那么...请帮我确定问题所在。如果我对此是正确的，我将必须能够用可重复的测试用例来证明它，因为我认为错误的是需要在框架和运行时修复错误。

---

有人建议问题更可能是我的代码而不是框架。

调查问题的变体 A，我已将问题代码移植到一个示例应用程序中并对其进行了削减，直到唯一剩下的是线程设置和方法调用，它们在一个 CPU 上工作但在两个 CPU 上失败。

变体 B 我没有测试过，因为我不再有任何单核系统。所以我重复这个问题:有没有人在单核平台上看到这个异常？

不幸的是，没有人可以证实我的怀疑，只能反驳它。

告诉我我容易犯错误并没有帮助，我已经意识到了这一点。

如果您知道一种将 .NET 应用程序固定到单个 CPU 的方法，那么解决这个问题会非常方便。 ---感谢虚拟机的建议。我会做到的，好电话。

Answer 1

蓝屏不仅仅是因为应用程序或框架中的错误。蓝屏需要内核模式的“帮助”。您的问题之一是有缺陷的驱动程序，无论有缺陷的驱动程序是在哪个“时代”编写的。

关于一个线程关闭端口而另一个线程仍在使用它的可能性，我认为这可能与框架管理中的一些著名错误有关。我认为这些错误不取决于内核的数量，但是当有更多的内核时，被这些错误击中的频率可能会增加。尝试添加 GC.KeepAlive 调用以防止框架过早删除您的端口。