c# - 单元测试、死锁和竞争条件

Question

关于如何为可能易受死锁和竞争条件影响的代码编写可重复单元测试的任何建议？

现在我倾向于跳过单元测试并专注于压力测试。问题是你可以运行 5 次压力测试并看到五个不同的结果。

编辑：我知道这可能只是一个梦想，但如果有一种方法可以控制单个线程并让它们一次执行一条指令，那么我可能会到达某个地方。

score 3 · Accepted Answer

看看TypeMock Racer（它处于测试阶段）

编辑：实际上是阿尔法

score 2 · Accepted Answer

通常可以通过使用诸如 ManualResetEvent 之类的东西来强制预见的竞争条件和死锁在释放它之前让每个线程进入预期状态 - 即让线程 A 获得锁定并等待信号......让线程 B 请求锁等...

但是 - 您通常可以编写这样的测试来调查可疑的错误，以证明它何时被修复并且它不会重新出现。您通常会围绕竞争条件进行设计（但尽可能实用地测试它们）。

score 2 · Accepted Answer

我不认为寻找竞争条件真的属于单元测试的范畴。根据定义，或多或少，测试竞争条件的唯一方法是伪随机。除非您愿意努力正式证明您的锁定策略的正确性，否则您将不得不进行一些压力测试。

您仍然需要编写单元测试，以验证算法的正确性，而不是锁定策略。

在对多线程代码进行压力测试时，您需要在每个线程有一个 CPU、多个线程共享 CPU 以及 CPU 多于线程（如果可能的话）的条件下进行测试。

score 2 · Accepted Answer

您可以编写一个锁类，通过查看锁操作的顺序来检测潜在的死锁。我们通过拥有一个线程上下文来做到这一点，所有锁在获取时都会注册（可以设为仅调试选项）。

这个想法是创建一个图，其中节点表示锁，A 和 B 之间的有向边意味着“在获取锁 B 时，锁 A 被持有”。让您的程序使用正常负载运行，然后检查图中的循环。循环意味着即使您的代码没有命中它，也有可能出现死锁。

score 1 · Accepted Answer

想不出一个好的自动化方法，但我最接近的方法是编写一个“暴露”死锁的单元测试，它是在单元测试之外使用断点。我只是添加了一些关于在何处添加断点的说明。这涉及到一些手动工作，但有了它们，您总是可以公开您的最坏情况线程调度。

也许有人想出了一种自动化此类功能的好方法？我可以想象自动运行调试器，在特定行中断一个线程，让另一个线程运行直到特定条件，然后断言单元测试。

score 0 · Accepted Answer

我之前在代码中使用了由请求中的某些参数触发的人为延迟。例如，一个请求告诉服务器在两次写入之间延迟写入，另一个请求在两次写入之间不延迟。

Mark Bessey 写道，这仅对创建重现有用，而不是用于发现问题。

score 0 · Accepted Answer

0

你试过Corensic Jinx吗？

于 2011-07-22T21:32:00.987 回答

7 回答 7