正确的问题
有没有人在单核机器上遇到过这个异常?
The I/O operation has been aborted because of either a thread exit or an application request.
一些上下文
在单个 CPU 系统上,一次只执行一条 MSIL 指令,尽管有线程。在操作之间,运行时可以进行内务处理。
引入第二个 CPU(或第二个内核),就可以在运行时进行内务处理时执行操作。因此,在单 CPU 机器上完美运行的代码在多核环境中执行时可能会崩溃,甚至导致蓝屏。
有趣的是,超线程 Pentium 并没有表现出这个问题。
我有在单核上完美运行并在多核 CPU 上剥落的示例代码。它在某个地方,但我仍在努力寻找它。它的要点是,当它被实现为访问者模式时,它会在不可预知的迭代次数后剥落,但是将方法移动到访问者操作的对象中会使问题消失。
对我来说,这表明该框架具有某种用于解析对象引用的内部哈希表,并且在多核系统上,存在与访问它有关的竞争条件。
我目前也有代码使用 APM 来处理串行通信。它曾经在我的 USB 串行适配器的虚拟 comport 驱动程序中间歇性地蓝屏,但我通过Thread.Sleep(0)
在每次Stream.EndRead(IAsyncResult)
以随机间隔,当我提供的 AsyncCallbackStream.BeginRead(...)
被调用并且处理程序尝试调用Stream.EndRead(IAsyncResult)
时,它会抛出一个IOException
声明The I/O operation has been aborted because of either a thread exit or an application request.
我怀疑这也与多核相关,并且某种内部错误正在杀死等待线程,从而导致这种行为。如果我对此是正确的,那么该框架在多核环境的上下文中存在严重缺陷。虽然有我提到的变通方法,但您不能总是应用它们,因为有时它们需要在其他框架代码中应用。
例如,如果您在网上搜索有关上述 IOException 的信息,您会发现它会影响那些显然甚至不知道他们正在使用多线程的人编写的代码,因为它发生在框架便利包装器的掩护下。
微软倾向于吹嘘这些错误报告是不可重现的。我怀疑这是因为问题只发生在多核系统上,并且像这样的错误报告没有提到 CPU 的数量。
所以...请帮我解决问题。如果我对此是正确的,我将不得不能够用可重复的测试用例来证明它,因为我认为错误的是需要在框架和运行时进行错误修复。
有人建议问题更可能是我的代码而不是框架。
调查问题的变体 A,我已将问题代码移植到示例应用程序中,并对其进行了精简,直到只剩下线程设置和在一个 CPU 上工作但在两个 CPU 上失败的方法调用。
变体 BI 还没有经过如此测试,因为我不再有任何单核系统。所以我重复这个问题:有没有人在单核平台上看到过这个异常?
不幸的是,没有人能证实我的怀疑,只能反驳它。
告诉我我容易犯错是没有帮助的,我已经意识到了这一点。
如果您知道将 .NET 应用程序固定到单个 CPU 的方法,那么解决这个问题会非常方便。---感谢VM的建议。我会这样做,很好的电话。