我想测试一个大而复杂（超过1.3M LOC）服务器应用程序的竞争条件。该应用程序使用C和C ++编写，并在64位Linux上运行。我做了一些研究并提出了一些动态工具（例如，英特尔检查员，Tsan，Helgrind和DRD）和一些静态工具（例如，RELAY，RacerX）。
动态工具应该更准确（误报率更低），并且可以处理自定义同步机制，但会产生大量的运行时开销，从而触发应用程序的超时。静态工具的问题在于它似乎主要是学术性的而不是维护的（例如，RELAY的最新版本是从2010年开始）。
目前我正在考虑使用Tsan并延长应用程序的计时器以适应增加的开销。有没有人面临类似的挑战，并有一些我可能错过的见解？
答案 0 :(得分：1)
不幸的是，我认为这可能是基于意见的过去＆＃34;问题，但我会采取行动。
在不了解应用程序的任何内容的情况下，几乎不可能说出使用tsan时可能需要考虑的内容。在我工作的较小（103k LOC）项目上，专为高吞吐量网络设计而设计，它几乎总是足以设计测试来运行各种代码路径并测试它们。我从来不需要延长计时器或超时。我想如果你有一些硬实时约束（我没有），这可能会有问题。我没有经历过巨大的开销。
我要注意的一点是，tsan不能很好地处理并发数据结构（例如concurrencykit和其他人提供的数据结构）。这是因为这些并发数据结构的实现经常依赖于检测数据争用来确定执行行为。
例如，考虑一个具有两个并发消费者的完整环形缓冲区。读者可能会被标记为临时读取戒指前面的比赛，因为他们这样做。然而，消费者在原子comare-and-swap操作上线性化以将递增的，读取的值设置为环的下一个索引。如果交换失败，则重试该操作。因此，虽然读写可能会竞争，但保证了正确性。从tsan的角度来看，这些并不被认为是误报，因为它们是实际的数据竞赛。另一方面，它们对于所有实际目的都是误报，因为它们实际上不会导致任何不正确或未定义的行为。有一些方法可以检测你的代码以避免这种情况，但是当我尝试它时，它比它的价值更麻烦。这取决于你的输出有多嘈杂。
另请注意，如果您的应用程序调用未经检测的库（libc，openssl等），您将错过潜在的比赛。如果在同时调用未经检测的库时发生竞争，您将错过竞争。
如果使用tsan，请不要忘记使用-fno-omit-frame-pointer（并且不要忘记在任何-Olevel选项之后放置）。否则你将被addr2line置于地狱，或被迫重建。
不幸的是，我对您列出的其他实用程序没有任何经验，但由于您的问题似乎与tsan有关，我希望这有用。