valgrind在多线程套接字程序中失速

Question

我正在使用valgrind运行多线程套接字程序。客户端将通过TCP向服务器发送请求，然后忙于等待布尔值。当调用服务于服务器响应的回调函数时，布尔值将被设置。一旦接收到响应（并设置了布尔标志），服务器将再次发出请求，并在循环中重复执行此操作。我知道对共享变量（布尔值）的非同步访问可能会导致线程问题，但我尝试过使用pthread互斥体，并且程序减速了大约20％（这里速度很重要）。我相信写入共享布尔变量是好的，因为它可以在一个周期内完成。

该程序在valgrind之外运行良好，但通常在使用valgrind运行时会停止运行。我离开程序在一夜之间运行..通常需要几秒钟才能完成，所以我不认为这是一个等待程序完成的时间不够的情况。线程由开源引擎框架（快速修复）管理，所以我认为这不是线程创建/管理的问题。

有没有人知道valgrind围绕多线程程序/繁忙的等待循环/套接字通信（或这些组合）的任何问题？

Answer 1

虽然其他答案的重点是坚持采用标准同步方法（我完全同意这一点），但我认为应该回答你关于Valgrind的问题。

据我所知，Valgrind在多线程环境下运行时没有问题。我相信Valgrind强制应用程序在单核上运行，但除此之外它不应该影响你的线程。

Valgrind可能对您的应用程序做了什么，正在改变线程之间的时序和交互方式，可能会暴露代码中的错误和竞态条件，您在单独运行时通常不会看到这些错误和竞争条件。

您应用相同的逻辑来判断您使用的开源代码线程框架中的错误不适用于我认为的Valgrind。我建议您将这些挂起视为代码中的错误并对其进行调试，因为这很可能是它们的原因。

作为一个方面说明，使用互斥对您描述的问题可能是过度的。您应该调查信号量或条件变量。

祝你好运。

Answer 2

读取/写入布尔值不是x86上的原子操作。

见我的问题在这里：Is volatile a proper way to make a single byte atomic in C/C++?

Answer 3

即使写你的布尔是一个原子操作，周围的其他内存compiler and the CPU are free to re-order the update访问。忙线等待线程可能会从繁忙循环中唤醒，并发现共享数据结构有而不是实际上已被更新。

我强烈建议坚持使用可用的线程原语来编写一致的程序，这些程序每次都按照您的需要执行。