线程中止状态问题
我有一个库来管理基于 .NET 3.5 构建的线程。当我尝试将其升级到 .NET 4.0 时，根据 Thread.Abort 方法，某些单元测试失败。
简而言之，这些单元测试会跟踪线程从创建到停止的状态。当线程被中止时，这些单元测试会跟踪“运行”->“运行”的状态。已请求中止 ->已中止 ->停了。该序列在使用 VS2008 或 VS2010 的 .NET 3.5 上运行完全相同。直到我在 VS2010 上将其升级到 .NET 4.0 之前，单元测试都失败了。结果是线程仍处于 Aborted 状态。
我已经检查了 MSDN 关于 Thread.Abort 的信息，这里有这样一句话：“在线程上调用 Abort 后，线程的状态包括 AbortRequested。在成功调用 Abort 导致线程终止后，线程的状态更改为已停止。”
有人遇到同样的问题吗？ .NET 4.0 线程行为是否正确？如果线程一直处于Aborted状态，有什么影响吗？
I have a library to manage the threads built on .NET 3.5. When I am trying to upgrade it to .NET 4.0 some of the unit tests failed according to the Thread.Abort method.
In brief of those unit tests, the thread states are tracked from creation to stopped. When the thread is being aborted, those unit tests track the states from Running -> AbortRequested -> Aborted -> Stopped. The sequence is working exactly identical on .NET 3.5 using VS2008 or VS2010. Until I upgrade it to .NET 4.0 on VS2010, the unit tests fail. The result is the thread remains in Aborted state.
I have checked MSDN about the Thread.Abort and here is the words, "After Abort is invoked on a thread, the state of the thread includes AbortRequested. After the thread has terminated as a result of a successful call to Abort, the state of the thread is changed to Stopped."
Is there anyone having the same problem? Is the .NET 4.0 threading behavior correct? If the thread stays on Aborted, does it have any impact?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我重现。继续假设这是一个错误修复。让状态回到 Stopped 没有多大意义。
有一个旧的反馈报告关于它在这里。他们承认 .NET 2.0 中的行为与记录的行为不符，但解决问题为时已晚。虽然关闭了，但我强烈怀疑他们在 4.0 中修复了它。具有讽刺意味的是，记录的行为似乎已在 MSDN 库中更新，现在又与实际行为不匹配。
I repro. Go ahead and assume it is a bug-fix. Having the state going back to Stopped doesn't make much sense.
There's an old feedback report about it here. They acknowledge that the behavior in .NET 2.0 doesn't match the documented behavior but that it was too late to fix the problem. Although closed, I strongly suspect they fixed it for 4.0. Ironically, it looks like the documented behavior was updated in the MSDN Library, now again mismatching the actual behavior.