Concurrency 竞赛条件检测工具

我想测试一个大型且复杂（超过130万LOC）的服务器应用程序，以了解比赛情况。应用程序用C和C++编写，运行在64位Linux上。我做了一些研究，提出了一些动态工具（如Intel inspector、Tsan、Helgrind&DRD）和一些静态工具（如RELAY、RacerX）

动态工具应该更准确（误报更少），可以处理定制的同步机制，但会带来很大的运行时开销，从而触发应用程序超时。静态工具的问题在于，它似乎主要是学术性的，没有维护（例如，继电器的最新版本是2010年的）

---

目前，我正在考虑使用Tsan并扩展应用程序的计时器，以适应增加的开销。是否有人面临过类似的挑战，并有一些我可能错过的见解？

不幸的是，我认为这可能已经超越了“基于意见”的问题，但我还是要试一试

不了解应用程序的任何情况，在使用TSAN时，几乎不可能说出您需要考虑的内容。在我所从事的一个较小的（103k LOC）项目中，设计用于高吞吐量网络的东西，设计测试来执行各种代码路径并测试它们几乎总是足够的。我从不需要延长计时器或超时时间。我想如果您有一些硬实时约束（我没有），这可能会有问题。我还没有经历过tsan开销过大

我要注意的一点是，tsan不能很好地处理并发数据结构（例如由和其他人提供的数据结构）。这是因为这些并发数据结构的实现经常依赖于数据竞争的检测来确定执行行为

例如，考虑一个具有两个并发使用者的完整环形缓冲区。读卡器可能会被标记为在戒指正面的临时读卡器上比赛，因为他们确实如此。然而，消费者在原子comare和swap操作上线性化，以将递增的racy读取值设置为环的下一个索引。如果交换失败，将重试该操作。因此，尽管读写可能会竞争，但正确性是有保证的

从tsan的角度来看，这些并不是误报，因为它们是实际的数据竞争。另一方面，它们在所有实际用途中都是误报，因为它们实际上不会导致任何不正确或未定义的行为。有很多方法可以让你的代码避免这种情况，但是当我尝试它的时候，它比它的价值更麻烦。这取决于输出的噪音有多大

还请注意，如果您的应用程序调用未安装指令的库（libc、openssl等），您将错过潜在的竞争。如果对未指令库的并发调用发生竞争，您将错过竞争

如果使用tsan，不要忘记使用

-fno省略帧指针

（不要忘记将其放在任何

-Olevel

选项之后）。否则，您将陷入地狱般的

addr2line

，或者被迫重建

---

不幸的是，我对您列出的其他实用程序没有任何经验，但由于您的问题似乎是关于tsan的，我希望这会有所帮助。

谢谢，问题是我们现有的单元测试不是多线程的，因此，为了执行并发执行，我必须运行系统集成测试，这涉及到很多计时器。幸运的是，虽然没有无锁代码，但有自定义锁实现以及自定义板分配器。我们来看看TSan是怎么处理的。。。不过你可能是对的，这不是一个结构良好的问题。。。